Agile Lifecycle Management

Implementing practises that increase agility in collaborations is most often a good thing. However, there are two problems with the most popular approaches of today:

1. they focus on only one category of services: services that are based around an IT asset,
2. they focus on only one part of the service lifecycle: the development.

This is understandable since IT solutions are complex, especially when developing them. During IT development new insights are constantly being made, so a collaboration framework that facilitates rapid knowledge sharing, restructuring, and replanning (such as Scrum and the like) is a valuable tool. It is just that this could be said about all kind of services, and it could be said about other parts of the lifecycle, like deployment or operation, as well.

Lifecycle management frameworks like ITIL aims to point out not only what is needed during development but during other parts too. In them, there are elements one recognize from the lean and agile family of practises such as continuous improvement and cross functional collaboration. But when trying to implement them in a lean and agile fashion, there are always many "BUT" you need to say:

— "Yes, there is a CSF/KPI there that says that reducing the number of change requests is a good thing BUT if you think about it: a good change request is really a new insight about how we could be better at attending people's needs, so we should in fact increase the flow of change request instead while improving our capability to deal with them!"

— "Yes, there are descriptions there that separates the group that makes strategic decisions from the group that makes more tactical or operational decisions BUT that doesn't mean that it can't be the same people in them! Or that the mandate to make the decisions can't be delegated!"

— "Yes, there are requirements that there should be a document for each request BUT please note that a small sticky note on a whiteboard is a document that can meet all the formal requirements. Yes, the processes must be documented, BUT don't you agree that a hand-drawn poster on the wall explaining how you do things is a document even though it doesn't sit in a binder on a shelf (where no one sees it)?"

The number of "BUT"s is above any reasonable limit. Both I and other lean and agile guides have come to the conclusion that it is time for expressing what lifecycle management means when doing it the agile way. We need to have a set of organisational patterns we can point at, without having to tweak models that come from a fundamentally different management tradition.

It needs to be a pattern collection. Organisational patterns works just as design patterns: they aren't blue prints or rules but suggestions on how to organize things, given that things already are in a certain way. What suits your organisation is situational. The correct answer is always: "It depends!" and patterns aim to explain on what.

It needs to be free. People should be allowed to use, reuse, teach, and build upon the patterns. No trademark, no proprietary control, no over-prices certifications, manuals, or consultants.

It needs to have a name, maybe even from a clever acronym. I propose ALMA: Agile Lifecycle Management Anatomy. "Anatomy" since organisations are organic, and "Alma" since it is a name that means something along the lines of "sweet and soft soul".

Stay tuned, I will soon post some of my favourite ALMA patterns.