SAFe

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

Scaled agile (what?)

As mentioned in a previous post, I am now part of an organisation that is attempting to convert much of its IT development to an “agile” approach, more specifically by adopting the “Scaled Agile Framework” (SAFe®). Although I am not directly involved in this work I still see and hear enough to notice some patterns emerging.

The origins of agile are in development, i.e. where you basically turn requirements into code. This is more or less the same all over, but when you start scaling agile to cover bigger “organisations”, then suddenly there are a couple of different flavours to be considered.

If you develop software as a product to sell to others, either by putting it on the shelf or using a “made-to-order” approach, the objective is either to put the most appealing product on the shelf or most effectively and efficiently meeting the customer requirements. Once the product is done, that effectively concludes the exercise and your agile approach is therefore really “scaled agile product development”.

However, if you are an organisation that develops or implements software for internal use using agile, then you are effectively doing “scaled agile system implementation”, which is a slightly different flavor to the development one. It’s different because you are now responsible as an organisation for realising the business benefits of the solution and not just completing the product (in essence, outcome vs. output responsibility), and that means that new parameters/considerations start to creep in.

  • How do we ensure usability of the solution over the entire life cycle?
  • How do we cover compliance requirements, not just for the base product but also whatever is required for usage and maintenance of the solution over the entire life cycle?
  • How do we cover user stories to deal specifically with upgrades and maintenance activities in our organisation? (and, just as importantly, how do we get those user stories prioritised during development?)
  • And last but not least (actually, probably the opposite!) – how do we include organisation change management activities and user acceptance as part of the agile implementation cycle.

That is of course not to say that these points are not important when you develop software for sale, but they form a bigger part of the total cost/total value equation when the scope is a full implementation and usage cycle – and it’s becoming clear to me that much of the complexity in scaling agile are not in the development, but in the parts that follow being agile at scale…

Being SAFe…

New job, new abstraction level (EA) and among the first points on the agenda is an introduction to the Scaled Agile Framework (SAFe®)

As someone who has previously only had a high-level conceptual exposure to agile – but has always found the thinking behind quite appealing – actually seeing it work (or at least being implemented) is a bit of a revelation.

What strikes me is that it is very stringent, and at the same time very sensitive to context. At first glance SAFe® itself looks like a very detailed playbook, but go a little deeper and I don’t really see a prescriptive way of doing things here anyway. The (excellent) glossary of explanations is peppered with “context-based” words like “fit for purpose”, “excessive”, “combination of” and so on. So really, the success of the framework in a given organisation relates very closely to the ability of the organisation to interpret these variables and find the right level of application for the specific context. Now those previous struggles I’ve seen with making agile work in practice suddenly make a lot more sense…

Another thing that makes an impression is the extreme reliance on dedicated resources to ensure minimal delays in execution and communication. The culture clash with the world I came from where everyone is constantly booked on five projects at the same time is plainly obvious… and the changes required to the corporate culture in order to execute a successful pivot to agile methods in a single department (let alone a full enterprise transformation) are staggering!

Looking forward to seeing where this is going – it’s going to be both fun and highly educational I’m sure 🙂