scaled agile

The real principles of (scaled) agile…

No, I’m not talking about the agile manifesto, but the “principles” you can extract from the agile framework descriptions such as SAFe® or Dean Leffingwell’s book on agile software requirements which I recently finished. Here’s what I get:

1) Agile was made for the development of software as a product for sale to external customers.
If you want to use agile methods for developing software for use by internal customers, or – as many do – to implement software that you have acquired (whether custom-developed or off-the-shelf) from someone else, it’s definitely possible. However, you can’t use the principles and concepts blindly because they don’t always make 100% sense in those contexts so you have to be prepared to deviate – and the organisation has to understand when and why to deviate. There’s a very brief section in Leffingwell’s book (in the “Product Owner”) chapter, that deals with the challenges of owning the implementation stages as well, but it’s a bit too short to cover all the impacts.

2a) Agile doesn’t mean you can be super-flexible everywhere.
Basically, the agile methodology creates flexibility in some areas by being ultra-rigid in others. Just think about the daily stand-ups at precisely the same time and with the same fixed agenda or the preset sprint duration and the regular planning sessions and recurring demos. This trade-off has to be understood because it’s one of the cornerstones of the agile methodology and it’s one I mentioned previously as well.

2b) Agile doesn’t mean you don’t plan – just that you plan differently.
Being agile basically means you plan much more in certain areas to be able to plan less (or with a shorter horizon) in others. That means as long as you have a very strong (and very closely monitored) strategic plan, then you can make you tactical plan a bit more loose and your operational plan even more flexible. That’s good, because it empowers the organisation that executes the plan, to reach the goal even when the original road turns out to be impassable or just plain wrong, but it doesn’t mean that you can (or should) change direction on a whim.

3) Agile shouldn’t be used to define the problem/goal, but to define the best solution for an already agreed problem/goal.
Another classic misconception (IMO) is that if we do not know what we want, we can use agile to find out – I don’t agree with that. Because agile execution has a very short-term focus, if you do not understand the overarching goal of what you are trying to deliver, there is no guidance for a product manager/owner to follow and as a result you risk spending all of your budget on delivering “features” that together do not really form a whole.
Instead, you can use what I call a “gated agile” approach meaning that you do short-feedback “sprint”/”spike” iterations to investigate, align with stakeholders and test hypotheses as to what the problem could be, but keep strict evaluation “gates” where you stop and agree if you are still on the right track. This is similar in concept to the agile structure of “code it out” and using spikes to nail down hard problems or unknown issues, but the “stop and evaluate“ aspects are often overlooked or dismissed as “waterfall” thinking – it definitely isn’t!.
Once you have reached a stage where everyone then agrees on the problem, you can architect and develop the solution, break it down into epics/features/tasks and then execute on those using an agile approach without problems and with most of the initial risk of failure already mitigated.

4) Agile should be used with care on technologies that are new to the organization
This is sort of a variation of the first points, but if you do not understand the technology you are working with and what it can (and can’t) do for you, you’re very likely to fall into the traps of the first points on the list here. This problem goes up exponentially if you are not just developing but also implementing in the organisation – because if you think that development-related challenges of new technologies are tough, wait until you try adoption-related challenges (i.e. organisational resistance) to a new technology!

So, is it all complaining then? Did I not learn anything from reading the book? I did, but more of that in a second part/post 😀

Also, I will be attending an official SAFe® methodology course in a few weeks, so I look forward to seeing if I still make the same conclusions afterwards – and of course having a good discussion with some colleagues in the process.

Advertisements