A little while ago an associate in the Agile Coaching community, Yves Hanoulle, asked me about the contention often raised that Agile software development practices don't mesh with the ITIL Framework.
On the surface, Agile practices are a solution to provide faster speed of software delivery than alternative development techniques, and the ITIL Framework with its focus on process appears to slow things down.
For example: Yves had a conversation on Twitter where someone said that continuous deployment is not possible with ITIL. Yves wrote me to say that he thinks that is “horsefeathers” [my word] because they don't understand ITIL. He continued: “I think a lot of ITIL people are using it as a prescriptive way of working. And I don't think it has to be like that.”
I agree.
We have always believed there is no discrepancy between Agile and ITIL. In every conversation with Project Managers and Agile folks about how Agile is not “waterfall development” and therefore doesn't fit with ITIL processes, we have shown them that this makes no difference.
Consider the questions of automation or traceability.
Both the Design and Operations books in version 3 of the ITIL Framework are very clear on the interdependency of Design & Development and Operations, in terms of:
- the design meeting specifications,
- that all of this can be confirmed by tests,
- and that Operations staff need to be able to provide input to Design to ensure the systems are operable, robust, and maintainable.
It is much more than the question of automation or traceability - it is a mindset / mental perspective of the integration of knowledge - and finally teamwork.
Let's break this down into more detail:
- continuous deployment is of course possible, even if one, incorrectly, took ITIL as prescriptive.
- even the so called "ITIL experts" argue about "implementing" ITIL word for word from the book which is not the intent
- ITIL recommends using - adopting - the best practices, as they suit the organization and its needs. Again it is not law, it is a Framework. One uses the best practices as they make sense, just as you do in Agile. And where an ITIL practice can make an improvement one should use it, just as in Agile.
- it all boils down to keeping the Great Teams commitment to not do anything dumb
Often people believe that rapid deployment / continuous deployment / daily builds etc. can't work in a an environment that is highly process oriented, where rules and process have to be followed. (Usually they just don't like someone else's rules.)
Well, the process is there to ensure consistency, responsibility, accountability, communication, traceability, etc. and of course it CAN be designed to be a hinderance. It. alternatively, CAN be designed to allow quick passage of releases. People blaming process or ITIL are just being immature. They may as well blame the weather.
The meaningful question in such environments is: What has caused the development of process controls to ensure such an approach for the management of risk?
- are the controls in place to reduce the error rate?
- was the previous situation causing buggy software to be released which impeded the business?
- has someone mis-interpreted the intent of the ITIL Framework and used it as law?
I'd be delighted for someone to find me an example of how ITIL recommends that the process gets in their way. So far in these conversations I find the combatant has yet to read the ITIL books.*
How does Agile play with other frameworks in your experience?
*By the way: I haven't read books on Agile either. However, the Core Protocols include the Intentional Development Protocol (an Agile foundation stone), and I am informed by Agile coaches such as Christophe Thibaut, Gino Marckx, Yves Hanoulle, and Esther Derby who recently posted STILL NO SILVER BULLETS (http://www.estherderby.com/2011/03/still-no-silver-bullets.html) on Agile methods.
3 comments:
Good article. In my limited experience of agile, it strikes me as being an excuse for not planning properly, just get it in there...
This goes against the ITIL Change Mgt process, where the control and rigour is a must....
There's an easy answer to how an IT dept using ITIL-adopted-and-adapted processes could do continuous deployment: standard changes.
The project takes their proposal to CAB for continuous deployment, the CAB approves the risk and the conditions described in the standard change template and it's approved.
Then the project can do continuous deployment, they just need to get their build/deployment system to update the ITSM tool with a change record every time it deploys the change, and to update any CIs that have been affected.
Actually, Agile requires continuous planning and scrutiny of the deliverables on each build cycle. It requires the business and the development team to meet everyday to focus on what was completed, what will be completed, and what is or will be a roadblock.
Lastly, the product development must support the economic benefit. All requirements are stated as stories of what business problem or value is being addressed.
In short there must be a lot of discipline or process to deliver via agile.There are risks because the team has to ensure all of the pieces make a whole, and some items like infrastructure need to be planned & monitored or the team will run out road.
Post a Comment