software development

The Essence of SAFe

Scaled Agile Framework (SAFe) can look quite complicated and intimating at first glance. However the essence of SAFe is pretty simple:

  • Fractal Plan-Do-Check-Act feedback loops (Team- and Program-level)
  • Fractal levels of work filtering and prioritisation
  • Priority alignment at scale (i.e. across a large number of people)

Around 6 months ago I got trained in Scaled Agile Framework (SAFe) and became certified as a SAFe Program Consultant (SPC) for SAFe 4.0. Before doing the training, I had a somewhat negative opinion of SAFe, as well as other scaling frameworks, e.g. LeSS, DAD etc. I can now say that my former opinion was based on very little understanding of what SAFe is and how it works, and was without a doubt an uneducated opinion. I admit to being somewhat ashamed for having the views I held then. Anyway, since the training, I have coached almost full-time in an organisation practicing SAFe, and have done a fair amount of thinking, training and speaking on SAFe. The following is what I believe to be the essence of SAFe. (Disclosure: my training and certification is in SAFe 4.0. SAFe 4.5 was released relatively recently. I have not yet caught up with 4.5, though I believe my thoughts remain valid and accurate.)

Fractal feedback loops: SAFe has 2 main Plan-Do-Check-Act feedback loops. At the team level, Scrum (or Kanban), and at the program, or team-of-teams level, the Program Increment. A Program Increment (PI) is analagous to a sprint in Scrum, that is a timebox wherein a group of people plan, execute, reflect and adjust together. The differences between a PI and a sprint are that a PI involved more people, is longer lived (typically 4-5 sprints), and has ceremonies designed for the level of scale. Note that although a plan is made at PI Planning, this plan is not set in stone. It is revisited frequently during execution of the PI, much the same way a Sprint plan is revisited every day at a Daily Stand-Up or Daily Scrum (HT to Kevin Shine for reminding me about this point).

Fractal work filtering and prioritisation: Kanban is used at various levels (portfolio, value stream and program levels in SAFe 4) to filter and prioritise the work that the people in the teams do. This is to ensure as far as possible that we don’t waste time and effort working on the wrong things. This is similar to how work gets filtered and prioritised in Scrum. The feedback loops mentioned above provide a limit to the length of time the teams work on anything before getting feedback from stakeholders.

Priority alignment at scale: An Agile Release Train is a way of making sure that everybody, across the organisation, required for work to happen has the same single list of priorities. That is, all the necessary people are dedicated solely to this set of priorities. This is analagous to cross-functional teams in Scrum. When everyone has the same priority, we have much less coordination overheard and much less waiting for each other compared to being dependent on people with other priorities.

SAFe does have a lot of roles and moving parts, there is no doubt. However I believe that the three things mentioned above form the core and essence of the framework. I certainly believe that most organisations, certainly those I’ve worked in, would benefit from all three of these structures and practices.

Kent Beck is fond of saying:

Work on the most important thing until either its done or its no longer the most important thing

If you look closely at the three things above, you might find that they’re simply ways of doing just this, when there are a large number of people working together on the same thing.

Advertisements
software development

That’s Not Agile!

TL;DR People spend a lot of time arguing whether things are ‘Agile’ or not. ‘Agile’ has become the tail wagging the dog and asking that question misses the point. The question we should be asking is “Does X help us (or our client) achieve the outcomes they desire?”


I recently spoke at a community meetup on the topic Agile Release Trains: Agile, or not so much?. The talk had 2 parts, the first explaining what Agile Release Trains are; the second part discussing whether the question But is it Agile? is a useful question to ask. In my previous post (What is ‘Agile’), I discussed my current interpretation of the Manifesto for Agile Software Development and what I believe ‘Agile’ means.

I no longer believe that there is much value in discussing whether something, e.g. Agile Release Trains, is Agile or not. The term ‘Agile’ has become a misnomer, a red herring. It has become the tail wagging the dog. In his Agile Africa 2015 Keynote, Kent Beck used the analogy of dogs and small children looking at the pointed finger, instead of what the finger is pointing at, to describe Agile. Alistair Cockburn, another Manifesto signatory has launched his own ‘new branding’: Heart of Agile. I assume this was because he was frustrated by what Agile had become.

Agile has become a goal in its own right, and has moved away from its origins as a guideline for a way of operating. Instead of asking “does this help me (or my client) achieve the outcomes we seek?”, we’re so caught up in debating what agile is or isn’t, and spend a lot of time in No True Scotsmen arguments.

Who cares if its agile? Are we moving in the direction of continuous improvement or not? Do we even know what continuous improvement means for us in our context? What would imrovement look like? How would we measure it? Would we know it if it bit us in the backside? The next time you hear, or say, “That’s Not Agile!”, stop. Ask yourself what’s really being said and why.

For what it’s worth, my opinion is that any operating model that follows the 4 value statements described in the Manifesto is, by definition, agile.

software development, Uncategorized

What is ‘Agile’?

TL;DR Agile is a way of operating wherein the decisions we make are guided primarily by 4 trade-off statements expressed as value statements in the Agile Manifesto. Following this guidance is believed to lead to improved ways of developing software.


Recently I have again started to question what is meant by ‘Agile’ (I make no distinction between ‘Agile’ and ‘agile’). I have asked this question at a few conferences, Lean Coffees etc. This is my current interpretation of ‘Agile’, as informed by the Manifesto for Agile Software Development, specifically the first statement and the four value statements:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

These statements provide guidelines for trade-off decisions we should be making. If you’re in a situation where you can choose between working on either working software or comprehensive documentation, rather choose working software, especially if you don’t yet have working software.

If you’re in a situation where you have a plan but have discovered that the plan no longer makes sense, you can choose between either following the plan (even though you now know it no longer makes sense to do so), or responding to the change, the guidance from the Manifesto is to rather respond to the change. (I personally prefer adapt to learning over responding to change but that’s another story.)

The same thinking applies to the other two value statements: should you have to choose either contract negotiation or customer collaboration, rather choose the latter. If you need to choose between processes and tools and individuals and interactions, again rather choose the latter.

The original authors and signatories of the Manifesto believed, based on their collective experience, that if you follow these decision making guidelines, you will become better at developing software. I certainly don’t disagree with them.