Agile vs. ITIL

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:

1. continuous deployment is of course possible, even if one, incorrectly, took ITIL as prescriptive.
2. even the so called "ITIL experts" argue about "implementing" ITIL word for word from the book which is not the intent
3. 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.
4. 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.

Software for Your Head 4

Finishing the project team kickoff meeting story from Software for Your Head by Jim & Michele McCarthy.

(from page 8):

Well, hell, if he did all that, you would consider him to be all the way checked in. Hmmm. What’s more, you think maybe, just maybe, that scenario might just do the trick for the whole damn team. Tell you what, you’d bet your bottom dollar that his teammates will at least respond with their fullest, focused attention. That’s just what people do whenever someone reveals himself a bit. If he’s talking and acting with just the least little bit of enlightenment, something new, they’re going to listen up and watch closely. As long as the person says what he says and does what he does with thoughtfulness and truth. But if it is true, you’d predict that the team, just by witnessing a more honest, genuinely new engagement level, will then be much more likely to act on questions of shared vision (which, you remind yourself, is the top-level symptom). At least, you figure, they’ll be more likely to act on things they care about, anyway, and that would be all to the good. Moreover, everybody who watched this thing unfold from just one person will have been really informed, and maybe even inspired, by the difference made by his acceptance of personal accountability for how he has been spending his own life. Really, not only for his own results, but for the results of all.

You half listen to the team struggling to cram everything in the agenda in the last few minutes. Maybe the others would also begin to experiment with the new power they are seeing and feeling (and there is tremendous power in accepting individual responsibility for achieving results together). If your guidance would help one or more of them to engage more deeply, and not to waste any time and never to do anything dumb on purpose, why, you’d have made a huge difference. Hell, the dumb quota can always be met by doing things you thought were smart to begin with. You don’t have to do anything dumb on purpose to meet the quota.

You imagine that a newly awakened team member would see a whole bunch of things, maybe all at once; the problem is not a case of a team without a shared vision, a case of just another stupid project, or another example of bad management or poor leadership. No, when he thinks it all the way through, he’ll see that the trouble is not “too few people,” or “not enough time,” or some other cockamamie story about how the mediocrity was out of his control. The crux of the thing is that he, personally, has been accepting less than he wants, and less than he deserves. What’s more, he has been doing so without making any genuine creative effort to get what he requires to efficiently create what he wants. He’ll see that the problem is his own lack of integrity and his shallow engagement. The problem is rooted somewhere near his deficient caring about his own life. To persist as it has, the problem requires his repression of passion, it mandates that he fail to accept his own wisdom, and it seduces him into daily acts of cowardice that promulgate rather than abolish the general foolishness of which he is such an important part.

But should just this one person truly check in, you think, the whole team will be moved to a better ground. Even if team members backslide, and all do,they won’t forget this vivid instance of accountable behavior and the simple, unambiguous actions that supported it.

One self-respecting person, you reflect, with even a modest degree of personal engagement, is all it takes to start this team on the path toward much greater achievement. No permission is required for the pursuit of greatness, no consensus to improve your own results. All the orgs and re-orgs in the whole damn corporate universe, all the resources consumed and processes proceeding can’t stop one honest person from making sure he spends his time wisely. And that’s all that is needed to get the ball rolling.

Why not believe, you think. Pretend. OK. So from this one moment of surpassing individual and dawning team clarity, this whole group will quicken, will revive. Of course, team members will need some new supportive structures; they’ll require whatever information there is about highly effective connection and collaboration. In particular, they’ll damn well want more moments of clarity, and will be willing to adopt whatever practices create just the right conditions for genuine checking in.

They can’t hold it, probably. And would they spread it around? You have a spike of unease, but then you reassure yourself that the team you are envisioning would of course look for any behavior patterns that would achieve its goals. If there weren’t any, team members would just figure a way to create them. And put them in a book.

But first, one of them must check all the way in. Just one. Who? All this, after one of them has decided that his life, time, and creative output really do matter. But not before.

Interrupting your reverie, your nascent vision, the meeting suddenly stops as people scatter and depart, ceasing to meet rather than finishing their work. Finishing is way different from ceasing, you muse. As you gather yourself, one of the team newbies, together with the team’s most infamous cynic, approach you. You bet they want your take on things. Your help.

So that's the kickoff meeting that we've all been to, and all have wished was better.

What have you done in this situation? Thoughts? Comments?