Untangling 'Agile', Part 2

Part 1 of this series explained why software projects fail at an alarming rate. It explored different levels of unpredictability and reasoned that we routinely try to tackle the nastiest problems.

This part lists Agile essentials, and offers 8 aspects of discussion. Each aspect comes with proposals for measurements, to provide a way to assess degrees of Agility.

What does Agile do differently?

The creators of the Agile Manifesto, by 2001 (17 years ago in 2018, with roots going back at least to the 70s), came up with the same solution as the military 150 years ago, and the manufacturing industry 100 years ago:

• Build small teams
• (Re-)Prioritize aggressively
• Let early, frequent feedback drive your decisions (not plans)
• Work on small units of work, and do the most valuable units first
• Build good skills/habits/reflexes
• Measure success over the long term, not short (because the short term is dominated by uncertainty and statistical variance, see Dr. W. Edwards Deming)

Let’s call these the 6 essential agile practices.

But what does Agile mean, and how do we know we’re Agile?

These are 8 aspects you must think about if you’re going to do Agile today (in no particular order):

• Process – that’s what people talk about most of the time if you’re listening to Scrum or Kanban proponents. Think roles, stand-ups, cycle time, backlog grooming, mapping the value creation flow, computing throughput. Those fall into the skills/habits/reflexes category above, hence it actually is a good idea to start here. You would measure progress in this aspect by measuring waste, like time spent reworking.
• People – getting individuals and their interactions on a software team and with their stakeholders right is far more important than the process they use. Look at the first line of the Manifesto: First and foremost, Agile is about people! It is about teams who own responsibilities, rather than managers assigning responsibility to a product owner. It is about creating well-performing groups of individuals. Whoever is or was in coaching will tell you that interactions on the personal level govern all other levels. Safety is a prerequisite. Values, respect, honesty etc. It is smart to start at pairing, and to measure satisfaction.
• Tech – which tools do we use, and can we exploit them to the fullest? Sutherland says that Scrum does not work if you don’t get the tech part right after one or two years. You want to nail your technical practices so that they can be used as parts of habits and reflexes. You must not think about them while you use them. A good scale of progress for this aspect is the cost of a correct change in production.
• Value – in the software industry, business success depends on you creating value for clients or consumers. The fundamental question is: ‘does my solution meet enough people’s problem, their objectives and constraints?’ To answer that question, not only do we need people who are very experienced in the subject matter, they also have to have a wide spectrum of technical, business and social skills. A product owner from the book has to tackle the CAS, VUCA, and wicked problems all by himself, so we better both look for our best player, and distribute the weight. Also, starting from the assumption that the product idea is probably bad, and using frequent feedback from all our primary stakeholders to improve it, is a very sensible thing to do! It is no surprise that the number one reason for project failure is some form of building the wrong product. The net promoter score is a method to find out about how well your customers like you.
• Enterprise – How stable are our teams? How do people get promoted? How are you incentivized? How is senior leadership participating in Agile activities? How easy is it to get information or service from other part of the enterprise? How many internal services do development teams consume? How do we handle prioritizing all requests for a team? From these questions, we could easily invent KPI for this area.
• Change – Different product discovery and ideation, different design, different development, different deployment, different testing, different documentation, different flow optimization, different waste-handling, different ways to get feedback, different involvement of senior, middle, and front-line leadership. Not many things stay the same if you transition to Agile! Scary, huh? Organizational change itself is a wicked problem: most of the time, the problem to solve it is not known, or at least uncertain (VUCA). We can look at the degree to which an organization adopts the change to find out how far we’ve come.
• Scaling – This relates to problems which require more than one small team (5+/-2) to solve, or if you choose to take on many similar problems (clients) at once. There’s more coordination needed, therefore you get less responsive. There is a variety of possible tradeoffs between coordination and responsiveness. SAFe, among other frameworks, mainly answers scaling problems, not enterprise problems. Note that it is not rational to use single independent teams and their track records as a model for Agile at scale, as the conditions are very different. Your point of attack (and KPI) is to reduce the number and strength of the dependencies between teams.
• Mindset – this often-cited aspect (‘agile is a mindset’) bears the 6 essential practices to solve unpredictable problems. While you cannot ‘see’ mindsets, you can always see behaviors. Therefore, you can assess agility by these measurements: How big are our teams? Do we prioritize aggressively? How often do we test ideas? Do we work on small units of work? How well are we doing in the tech department? What kind of period to we integrate when looking at success? In addition to that, it’s useful to check awareness (do people know we’re agile?), and affection (do they love (us) being agile?). We may also look at the absence of expressly non-agile characteristics, like management, planning, schedules, individual incentives, command, but also heroics, co-dependence, and lack of experience or expertise. Finally, an assessment like 9 LEVELS reveals information about mindset of individuals and organizations.

As a final remark, we shall be aware that developing an Agile mindset cannot be done in a year or two. It may take five or ten years, depending from where you start. Until you are ‘there’ things will be more or less ugly, and you will probably lose people over it.

It is difficult to assess Agility of an organization. While there are many possible approaches, all these measurements are complex. An experienced Agile practitioner will see symptoms of Agility within an organization much like a chess master will see a chess board in play.