Agile at Scale

If ever there was a hot topic of the moment; “Agile Scaling” is most definitely one of them.  Its also an interesting term that initially could be seen as a significant conundrum. The whole raisin d’etre of agile is to enable speed and efficient solutions to be delivered often despite the slow organisation behind it. Its also an obvious challenge; once a single agile project has been successful why can’t an organisation simply copy the model a thousand times.

However – and the real point of this discussion post – is that too many articles (in my opinion) focus on tools and technologies.  Don’t get me wrong – the tools and technologies definitely have their place but this is not my core focus

My prime focus is how a large organisation/enterprise can be “wholly agile”.  However, before I answer, my immediate conclusion is that this is not necessarily the correct objective.  Not every activity and process lends itself to agile methods and therefore simply making a uniform “everything must be agile” is not the right target.  More so, agile ought to be the default but its not exclusive.  This doesn’t really make the problem any easier of course

The reason for the challenge is that this amounts to a significant cultural change and as know “culture eats strategy for breakfast”(Peter Drucker; ) which means if the culture is not transformed, it doesn’t really matter what strategic intent exists (see my previous blog posts on even writing a strategy in the first place)

Culturally large institutions have a manager in place who is effectively “in charge” (the boss)  – there is an inherent mis-trust of team members and therefore the level of mandates and instructions tend to be very high. This is totally counter-intuitive to an agile team structure.  Going deeper into this structure reveals it starts at the very top of the organisation where the mission and values are aligned to shareholder value/revenue and profit targets whereas the core objective of an Agile delivery is to delight the customer which of course in turn is rewarded with financial value (if done well) .  This is exactly what the headline organisations of Apple, Google and a like have done i.e. they have specifically made the culture of the organisation  to be “customer first”  – but in a real (as opposed to simply putting it in a strategy paper)way

I am not going to quote the Agile manifesto (http://agilemanifesto.org/), however this is clearly the starting set of principles that an organisation should align to.  Breaking these down into specific organisational cultural points, the following is a good summary:

Fundamentally, Agility means being to change direction effectively, quickly and with grace:

As we covered above, move from the goal of money making to customer delighting

Create self organising , cross functional teams that don’t need everyone reporting to a single manager – and have all the skills they need with the processes relevant to them

Remove bureaucratic rules, plans and reports

Move from efficiency and predictability to transparency and continuous improvement

Move from top down commands to horizontal conversations. Allow leaders to set the direction, not the course. Theory-Y type management practices not Theory-X

The above are all very significant in their own right. There are some two specific more shorter term activities that are worthy of note:

Create workspaces that enable problem solvers to thrive.  It may seem quite obvious but if you don’t allow the teams to not only work physically close together but then to move from team to team, a project will fail before it starts

Use of Virtual technologies will help those organisations which are on multiple locations. Its all very well creating physical kanban boards and shared work areas but many organisations are forced to have multiple locations and therefore the correct use of technology will help – although not substitute

Of course, one of the key cultural challenges we be with those who are not convinced that Agile is actually the right thing to do. There are many challenges but I am going to pick out just a couple to make the point

  1. “Agile is fine for startups run by kids with earrings, tattoos and blue hair. But in our firm, respecting the chain of command and job responsibility are keys to survival. It takes a couple of days just to go through the company’s policy manual. The narrow responsibilities, and rigid policies, processes, and one-size-fits-all methodologies of our firm don’t fit the free-wheeling ways of Agile. Agile isn’t going to work here.”  Response: This effectively demonstrates the Company Culture needs reviewing – the requirements of the work—and the customer—are secondary to the bureaucracy.
  2. “There are better ideas than Agile” . Response: don’t fight on the “agile vs lean” or Kanban vs Scrum, but more see and use the commonalities and join forces

 

I am going to fast forward now. Lets  assume that there is a journey for cultural alignment, and the CEO/COO have fully embraced the prospect of full Agile.  how would an organisation actually manage 1000s of agile teams.  It would seem a rather daunting prospect…

When creating an initial agile team, there will already be a concept of a backlog that is relevant to that stream.  Scaling this up, means you need a “taxonomy”  which is the full set of opportunities across the whole organisation.   As this grows, a useful structure to break it down with could be customer experience, business process and technology systems teams.   This is also a significantly daunting activity – imagine the initial discussion with the CEO about publishing the full list of organisation-wide opportunities.

However, back to the Cultural journey (no apology here), you could imagine the Board room discussion – “how about we try this with two or three things and see how it goes”…. This won’t make the change. In creation of the full taxonomy, it will reveal functional and resource shortages.

Another interesting anti-pattern, is often an organisation will peel off quick wins, create an incubator and not surprisingly it’s a great success (even if it failed).  This model won’t scale.  Similarly, its relatively easy to establish a few agile teams across an organisation   Conflicts between teams and procedures are then resolved through personal interventions and workarounds. Once again, this doesn’t scale.

However, it would be a very brave CEO/COO to propose a big bang across the whole organisation.

So being more pragmatic would be not to create an incubator or a very small number of agile teams but more to roll out agile teams in a sequence set of steps.

This then goes back to the core and fundamental cultural change of instilling the values and principles including to those areas that don’t organise into Agile teams.  This latter point is really critical for an organisation to fully scale i.e. nobody is left out.  As an example, Organisation charts will take two themes.  Support and routine operational teams may look structurally quite similar initially although over time even these organisations will re-align, although with fewer management layers. However, functional departments will look very different, as they will be much more aligned to organisations priorities  As there become more teams, there will be the phenomena of “team of teams” that work on related initiatives.

There is one further large constraint or more dependency and that is that every thing needs to be able to built in a modular fashion – especially the technology and applications.  Its all very well hearing about how Amazon can deploy 1000s of software enhancements every day but they are only able to do this because of the modularity of the solution architecture.  If our large organisation is also the recipient of a large monolithic ERP suite, it doesn’t matter how agile and incremental the delivery of new functionality is if the systems can’t accommodate it.  So, an organisation needs to give its own systems a long hard look to assess their own viability

In summary, there is no doubt that if an organisation successfully deploys Agile processes at scale throughout, it will be more efficient and flexible and hence more successful. In order to do this though any organisation that wants to do this needs to consider how far adrift its core cultural alignment is to this and hence the amount of real change it is prepared to endure.  There may be no choice of course in reality – change or be changed….

This discussion blog is just a taster – lookout for a more comprehensive whitepaper on this subject which will go significantly deeper into these areas

References:

Open Group: Agile Architecture in a Digital Age
https://www.forbes.com/sites/stevedenning/2015/07/22/how-to-make-the-whole-organization-agile/#3f386a655841
https://www.forbes.com/sites/stevedenning/2012/04/17/the-case-against-agile-ten-perennial-management-objections/#76ca324b3a95
https://enterprisersproject.com/article/2018/5/mit-researcher-3-ways-make-your-workplace-more-agile
https://enterprisersproject.com/article/2017/10/agile-success-dont-settle-metrics-tell-half-story
https://hbr.org/2018/05/agile-at-scale
https://www.gartner.com/smarterwithgartner/five-principles-for-leading-an-agile-culture/
https://www.quora.com/What-is-Agile-Culture
https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s