Scaling through Building Organisational Support.

As we kick off 2018 talk around scaling agile seems to have reached new levels  I've no hard and fast facts to support that statement only endless discussions of  the topic constantly filling up my Twitter and Linkedin feeds. Most of this discussion tends to be framework focused, pitching LeSS again DAD against SAFe and so-forth.

I'm not sure how productive this discussion often is, moreover it tends to just turn into one big slanging match. Not least though because when it comes to the topic of scaling agile I'm not even convinced everyone's talking about the same thing. Most of the time the discussion seems to be focused on the question of how to spin up as many Scrum teams as possible. How do you get fifty teams working seamlessly together? Or something similar.

A common response to such a problem often goes something along the lines of getting one team working well first. That seems like an eminently sensible position to take. If you can't even get single team Scrum working well then what is it that you'd be scaling to fifty teams?

The discussion often ends there, although perhaps there's something else we should be asking - how do you hope to even get a single Scrum team working well until you start scaling? It's important here to qualify that statement with a specific definition of 'scaling'.

In the above question the focus of 'scaling' shifts from how many Scrum teams can be instantly spun up to one of creating and scaling the conditions for effective agile practices across the organisation. Such a focus is represented as the fourth enabling pillar in  the team coaching model - a supporting organisational context. In other words, for a team to be successful then the wider organisation mechanisms and structures need to be in place to support the desired way of working.

In an agile context these organisational mechanisms and strictures will covering issues such as HR, performance and rewards, recruitment, architecture and product landscape etc. The fundamental question being asked here is that if such factors are not addressed at scale, i.e. at the organisational level, then will individual teams ever be able to realise meaningful and sustained success? If individual teams cannot realise success then what impetus will there be to start seeding activity more widely? Such a situation could be represented by the cycle below:

As such, if we take our definition of 'scaling' to mean simply replicating the practices of individual teams then perhaps we could be enabling a self-defeating cycle which works to discourage and prevent establishing effective wider practices and agility.

If we shift the focus of scaling to that of enabling supporting conditions then perhaps we can work to avoid this negative cycle and actually work to build a positive reinforcing one.

We can see from this why enabling organisational support forms a pillar in the team coaching model, because that organisational support is not just crucial for the performance of any one given team but also for the building of desire and momentum for wider change and improvement.

Perhaps therefore, the common question associated with scaling agile needs to switch from how can you scale until you've got single team Scrum right to how can you even get single team Scrum right before you start to scale, i.e. start to build the foundations for organisational support? In this context, good single team scrum can be seen as the result of effective scaling rather than being seen as the precursor to starting.

Often the focus of scaling seems to be a narrow attempt to increase the number of teams. If we consider scaling though to represent the appropriateness of the supporting organisational context, rather than simply the number of so-called Scrum teams then maybe we'll be better positioned to realise success.

Change the Language not the Terminology

I remember picking up Dan Mezick's book The Culture Game and turning it over to read Jeff Suthlerland's quote on the back that if you can change the language in an organisation then you can change the culture. I thought this was a fascinating quote, not least because I wasn't sure how much I agreed with it.

I thought back to some of the teams that I'd worked with or alongside and some of the fundamental challenges they faced from an outdated and unaligned organisational culture - even though they'd shifted the language they used to a new way of working. I had fundamental questions about how much a shift in language really can lead to a shift in culture. Lots of teams are using a new language, so why are so many of those teams struggling to change the culture?

Then I realised something. On deeper thought, had those teams shifted their language at all? They'd adopted a new terminology but in doing so were essentially just using new words to layer over an existing paradigm.

If we take the following definition of language: a systematic means of communicating ideas or feelings by the use of conventionalised signs, sounds, gestures, or marks having understood meanings (http://www.merriam-webster.com/dictionary/language) then we can suppose that a change in language should result in two main outcomes:

- Communication of new ideas and concepts
- A shared understanding around the new ideas and concepts

Teams that merely adopt a new terminology arguably fail to deliver on both of these points and their shift in language is only ever shallow. Using lots of surface level language, most of the time focused around Scrum, such as sprints, stories, points, epics etc doesn't by itself communicate a new idea or build a shared understanding around it. Moreover, the new terminology just layers over existing ideas and is often banded around so freely that it lacks any real shared understanding of what it actually means.

Changing culture requires deeper language change. Shifting to a new language which doesn't even shift the thinking around ideas and concepts will never lead to a change in culture. Actually it could, but probably towards some sort of cargo-cult oriented thing   (http://agilecoachingcircle.blogspot.co.uk/2012/08/were-agile-were-doing-stand-ups-ever.html). Effective and meaningful culture change requires a change in the way that we think about and represent ideas and concepts. In an agile context that means shifting the language towards core principles of collaboration and early and continuous delivery of value.

Adopting terminology is easy and is probably why most teams start and stop at that point.
Beneath the surface though they're still firmly plugged into the conceptual and behavioural language of yesteryear. Shift the language, Mindlessly adopt new terminology and dress up the status quo or truly shift the language, shift the thinking and shift the culture. To me, the difference is now clear.

Driving Enterprise Agile through Agile HR

When talking about scaling Agile to the enterprise level there's often lots of talk around team structures, process and technologies but not so much about the supporting people operations. Yesterday evening Fabiola Eyholzer presented her view on Lean/Agile People Operations and it's role in enterprise Agile efforts.

Below is a brief summary of her talk and brings to the forefront the importance of this often overlooked subject. It's time to embrace change in HR.

It was proposed that "People operations is your secret weapon for bringing Agile to an enterprise level". After all, culture evolves around people and corporate values and thus a well aligned HR function is crucial in any enterprise level Agile effort. Although important, it was argued that the role of HR in an Agile context is often overlooked and misunderstood, it was the intention of this presentation to illustrate how an appropriately modelled HR approach cannot only support an Agile effort, but moreover, can actually drive it.

Many people based decisions in organisations, it was argued, are actually the result of hidden forces associated with functions such as finance, legal and management. HR are often responsible for enacting associated policies but the underlying thought behind many of these if often outdated. On the back of this suggestion Fabiola introduced the concept of Agile HR, using a manifesto of values and principles to build an approach for HR which aligns with Lean/Agile principles and concepts. Lean/Agile People Ops, as she coined it.

The core values of Lean/Agile People Ops

- Individuals and interactions over processes and tools

- Inspire and engage over manage and retain

- Collaboration over organisation structures

- Responding to individual needs over following a career plan

The Principles of Lean/Agile People Ops

(I didn't note these down, so you'll have to make do with a picture)

Following on from the introduction of the values and principles, Fabiola then introduced some core instruments of practice. These included:

- Agile hiring. Create an experience to assess ability to thrive in an Agile environment. Avoid prolonged performance improvement traps and be brave enough to hire slow and fire fast.

- Turn leaving talents into winning ambassadors. Stay connected, build an alumni.

- Flexible resource planning.

- Talent development. Inspire and boost personal and professional growth in order to boost organisation growth. Build an environment of continuous learning and sharing.

- Compensation. Offer enough to take the topic of money off the table. Make the life of people easier and better. Focus on inspiring and engaging rather than retention through compensation.

- Performance Management. Art of setting meaningful goals that spark the imagination and drive of people. Supporting of team work.

An overview of how such practices link and work together was then provided with an Employee Cycle, illustrating how an Agile HR approach needs to interact effectively with current, former and also potential talents.

Finally a seven step game plan was introduced for getting Agile HR established in the organisation:

- Get the team on board with a shared vision

- Create empowered working groups

- Create solutions iteratively

- Build bridges

- Achieve tangible results to build trust and to reshape culture

- Improve and Innovate

- Communicate, communicate, communicate

To sum up, it was proposed that HR is at a crossroads. To truly support enterprise level Agile, organisations need to be brave enough to adapt their approach to HR. Adopt Agile HR values, principles and practices, help shape and mould the organisational culture and help Agile to thrive.

The Perils of the Large Backlog

This post is a result of some thinking triggered by a recent quote by Dan North; "How can you respond to change when you have 600 stories in your backlog?".

This statement seems so seemingly obvious but at the same time so often overlooked. We know that throughout the course of a project new requirements will emerge and existing requirements will change. As an Agile team we want to be able to effectively respond to that change and, as the Agile Manifesto tells us, be positioned to harness that change for the customer's competitive advantage.

That said, the first thing we see many project teams doing in their quest to be Agile is create massively long product backlogs. Backlogs containing so many stories that the team immediately find themselves rooted in a level of detail which directly inhibits their responsiveness to change. I refer to 'level of detail' in two contexts:

- Low level (overly granular short term requirements)
- Long term (overly vague and non relevant longer term requirements)

Both contribute to the problem by creating a backlog which is so low level and long term that any requirements change requires a complete review, restructure and rewrite of the backlog. This is obviously a massive overhead and will probably lead to a team actually trying to avoid change, never mind trying to harness it. It isn't Agile and in turn the customer/business will struggle to be agile in their operation.

We can even go a step further and use queuing theory to reflect on the effect that long backlogs have on our Agile process. Not only does a long backlog affect out ability to respond to change it affects our ability to deliver change in the first place. Little's Law as part of queuing theory tells us that:

Size of Inventory = Processing Rate x Delivery Time

We can adapt this, as below, to see the impact that the Size of Inventory has on Delivery Time.

Delivery Time = Size of Inventory / Processing Rate

We can see from this that Delivery Time can be reduced by either a reduction in the Size of Inventory or an increase in the Processing Rate. Let's now place this in an Agile context:

Story Delivery Time = Size of Backlog / Story Throughput

Now lets apply some simple numbers:

100 stories in the backlog / 10 stories completed a week = 10 weeks for a story to be delivered

This 10 week Delivery Time results from a culmination of the time it takes for a story to get into the backlog, the time it takes for work to start on the story and the time it takes to complete work on the story.

There are two things that can be done here to reduce the Delivery Time. Firstly we can speed up the time it takes to complete stories. There are many ways in which this could be done e.g. better specification and engineering practices, those however are a subject for another post. The second way in which we can reduce Delivery Time is by reducing the number of stories in the backlog. With a smaller backlog we can start working on stories sooner, complete the work and deliver value for the business sooner.

Now, in reality this may be slightly complicated by the fact that stories don't necessarily go through a backlog sequentially, indeed some stories might end up not being done at all. Generally speaking though queuing theory shows us that we can get items through a system more quickly if there are less items waiting to be completed in the first place. Lean thinking, Work in Progress limits and flow systems all provide us with practical ways in which to benefit from this understanding. Further examination of these however is again a subject for another post.

Future posts aside, the message from this post is a fairly simple one. Long backlogs inhibit our ability to respond to change and deliver value. They inhibit the Agility of the project team and in turn inhibit the agility of the business. We should therefore strive to avoid them. Down with the massive backlog!