How to Scale Agile?

Scaling agile is not simple. The complexity increases not in proportion to the size of the team but at the square of the size of the team. That means a 20 member team project will be 4 times as complex as a 10 member team.

To ensure that complexity does not turn into chaos it is inevitable that the pure agile way of working may have to be sacrificed – is it possible without violating agile manifesto? It is also inevitable that the agile practices will need to integrate into other practices of the enterprise.

To be able to scale agile we need to understand:

• What the dimensions to this complexity?
• How to split the problem and the team?
• How to introduce processes and tools?
• How to manage collaboration among distributed team members?
• How to plan and manage workflow?

Dimensions of scaling and the need to integrate with other enterprise processes

Scaling Agile: An Executive Guide – Scott Ambler

To scale agile to an enterprise level, eight dimensions of complexity needs to be handled.

1. Team size – from less than ten to hundreds
2. Geographical distribution – from collocated to globally distributed
3. Regulatory compliance – need for mandatory compliance
4. Domain complexity – straightforward to complex and emerging
5. Organizational distribution – from all in-house to multiple external parties
6. Technical complexity – from homogeneous to heterogeneous including legacy
7. Organizational complexity – from flexible to rigid
8. Enterprise discipline – from no external constrain to need to adhere to enterprise standards

Different options of splitting the teams

Scaling agile teams – by features or by component? – David Draper

There are four options to split a large team into smaller sub-teams

1. Component orientation: (Pro) Typically this is how developers align themselves. (Con) Need to split user-centric feature – focus shifts away from business value.
2. Discipline: (Pro) This is how enterprises are already organized. (Con) Risk longer lead times with a “throw over the wall” attitude.
3. Location: (Pro) Collocated teams tend to be more effective. (Con) Need to match feature set with specific team.
4. Feature: (Pro) Aligns well with goal of delivering value. (Con) Integration issues may arise.

In practice a mix-and-match approach may be best where the split is done primarily based of feature and location.

Harmonizing the tool and process dimension with agile practices

Scaling Agile for Project Teams – Alan Bustamante & Rahul Sawhney

There is a need to harmonize three dimensions of people, process and tool. Here are some of the recommendations on how to achieve it.

1. People issues are best tackled through structure, empathy, communication, and people-oriented policies.
2. Addressing process challenges for scaling requires organizations to understand their process focus and validate that it is aligned with the organization’s vision, mission, and values.
3. Focus on tools that support and facilitate the team and sub-team’s processes by eliminating or minimizing non-value added work.
4. Configuring tools around a flawed process will still yield a flawed process. Fix the people and process issues first.

Making distributed teams effective through communities of practice

Scaling Agile to work with Distributed Teams – Mike Cohn

Total team size increases complexity. Distribution increases complexity. It becomes impossible for all team members to know each other let alone trust each other. One way to build the bridge is to set up communities of practice.

• A group of likeminded or like skilled individuals which is self-organizing, organic and can span projects / location
• All communities need not be officially sanctioned – they can completely informal to highly institutionalized
• Creating proper environment for the communities is important

Managing the product backlog at multiple levels

Scaling Agile Processes: Five Levels of Planning – Hubert Smits

Agile planning activities for large-scale development efforts should rely on five levels:

1. Product Visioning
2. Product Roadmap
3. Release Planning
4. Iteration Planning
5. Daily Planning

Product Vision is more like a desire of what the product will deliver once it is finished and would not talk about specific features. On the other hand Product Roadmap would talk about high level product backlog from which backlog for lower levels will be derived. It will communicate when releases are needed, what would be sufficient functionality and what business value would be delivered.

Like the two previous levels Release Planning is also for all the teams. Releases are defined by fixed date, theme, and planned feature set to which all teams must commit to. Typically, the product release would be once a quarter and the iteration cycle would be 2 to 4 weeks.

Managing workflow between multiple teams using Kanban

Large-Scale Agile – James Shore

Use Kanban for workflow not within a team but between teams.

1. Treat each agile team as a work cell
2. Use Kanban to manage cross-team workflow
3. Create a Product Portfolio team which is collocated, cross-functional, intact team consisting of product managers, business experts, UX designers, architects etc.
4. Partition the teams in such a way as to minimize the dependencies
5. Monitor the system using lean techniques which is Visual control, Throughput and Value-stream mapping
6. Sacrifice reuse in favor of throughput
7. Keep communication flowing with Scrums of Scrums

Finally…

Since, to scale agile, we may have to deviate from the spirit of the original manifesto, the question is how much can we deviate and still call the resultant methodology agile? And, when does it become an iterative development methodology?

Incidentally, iterative development seems to be as successful as agile development. Have a look at this survey outcome.

Udayan Banerjee on Google+