Most organisations that we see adopting Agile approaches for large programmes or across an entire organisation have already seen success with one or more Agile projects. In fact, we wouldn’t recommend not having seen a few successes before embarking on large scale adoption! Based on these early successes there is a temptation to simply “Hit the gas” and do a lot more of the same by simply multiplying the small number of successful teams. Life just isn’t that simple and very often large scale adoption runs into trouble. There are many reasons for this:
- Early Agile teams have usually chosen an Agile approach themselves as opposed to the later teams who have the decision thrust on them by a corporate mandate.
- A small number of Agile projects can be a sufficiently small target and slip under the radar so as not to fall foul of corporate project management offices or be viewed as a significant threat to the status quo.
- The vision for what the organisation is trying to achieve and why it is adopting an Agile approach is poorly communicated to all those who are going to be affected by the change.
- An underestimation of the impact on organisational functions like HR and logistics.
- Resistance from middle management who feel threatened by the concept of self organising teams.
- Resistance from staff who are either in an operational role or have some operational responsibility, like application support for example where it is more difficult to see how Agile approaches can be applied.
- Departmental structure and management hierarchy – common issues are management interference with the team’s working practices and requests to work on other work outside of the project.
Communication, communication, communication …….
Getting buy-in is vital, as is communicating the “Big picture” of what is at stake. I listened to Kent Beck speak at the Agile Business Conference and he told the story of a cleaner at NASA. When this cleaner was interviewed he responded to the question of “What do you do?” by answering “Son - I send people to the moon”. This is a man who doesn’t just clean toilets but clearly gets the big picture of what his organisation’s mission is! One of the manifestations of people not understanding the overall goal is “Sub optimisation” (see Lean Software Development - Mary & Tom Poppendieck). You see this in multi-team environments where the teams just focus on their own piece of the puzzle to the detriment of the overall programme. I’ve seen extreme cases where teams don’t even have visibility of their own requirements backlog but exist on just the small list of the next iteration’s priority features fed to them by their Product Owner. I liken this to running full tilt along a London street with your eyes firmly fixed on the ground or driving at 70mph in the fog! Without visibility of what’s ahead a team will tend to make poor design decisions. Without an overall picture of the wider programme objectives a team will see any task like integration with other team’s work as an irritation and impediment to getting their real work done.
So communication is absolutely key – I don’t think I’ve ever heard anyone complain that they have been the victim of over communication! An initial communication out to the organisation explaining the strategy and the approach to achieving it is a great start. But ongoing updates are necessary as progress is made and as strategy and approach is revised. New team members need to be inducted and provided the big picture before they join.
Evolution not Revolution
Change is hard. Many people don’t like change and there is always an organisational inertia dictating the practical pace of change that depends on the organisational culture and size. Ideally the changes in process and organisational structure required to make an organisation capable of truly Agile software development should be introduced gradually. In other words it is better to start small and gather momentum, allowing time to sort out the wrinkles that will appear. This strategy applies to both a large multi-team programme and to organisational adoption.
Assuming that there are already one or more teams successfully delivering good quality software every iteration, build the existing team sizes with a gradual addition of new team members. Get these new team members trained in the fundamental principles of Agile and the mechanics of your chosen Agile framework (e.g. Scrum). Make sure that the new team members are paired with experienced team members and allow for the drop in productivity that will occur while time is spent bringing the new blood up to speed. Grow the teams above their optimal size for productivity and then divide the teams in two with a balanced mix of experienced and new team members in each new team. Repeat this process until you have the required level of scale.
Organisational Change
As the number of Agile teams increases, the conflicts with the way Agile works and the existing way the organisation works will surface. To smooth the adoption, a parallel change programme should run alongside to gradually align the two worlds. An approach that works well is to run this change programme on an Agile footing, with its own prioritised backlog of change tasks – Ken Schwaber calls this the “Transition Backlog”. This approach has a natural empathy as it supports the flexibility to incorporate new tasks that arise out of the Agile teams trying to build software and it also helps align management to an Agile mindset.
Part 3 to follow
In part 3 I will talk about some of the approaches and patterns for enabling multiple teams to work in concert.