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 🙂