Scaling Agile requires the coordination and collaboration of hundreds, thousands or tens of thousands of smart independently minded individuals. To scale Agile, a small set of simple goals are needed that individuals and teams in the organisation can focus on, aware that if they achieve the goal, they are part of something much bigger. They can then use the most appropriate practice to achieve that goal.

One of the key learnings from our experience at Skype was that we had to keep the process so simple that people did not have an excuse for not following it. If people did not follow the process, it was because they did not want to follow it rather than the process was too complicated and they made a mistake.

To get your head around scaled agile, we need to consider the different “levels” or “concerns” in the organisation:

So what are those things? What are the goals are each level?

Executives

There is one goal at the executive level:

1. Ensure that the executives have transparency into the system to ensure that the goals are being met.

Portfolio

There are two goals at the portfolio level:

1. Ensure that the backlog of Epics (single team and cross team) is strictly ordered (i.e. no joint 3rd priority) based on the constraints in the organisation. One of the key constraints at the organisation level is the capacity of individual teams.
2. Manage capacity by moving capacity to the constraints, and planning capacity for the future. This involves ensuring that there is capacity in the system to meet any commitments that have been made to external parties.

Team of Teams

The goals at the team of team level:

1. Deliver Value.
2. Reduce Lead time for the delivery of value.
3. Reduce Lead time for fixing production incidents.
4. Reduce the number of production incidents.

The team of teams level is fundamentally about delivering value.

Team

The goal at the team level:

1. Ensure that delivery is value focused. That means that each Epics (single team and cross team) should deliver value rather than be bucket for stories.
2. Ensure that team level delivery is predictable and consistent. Consistent in terms of quality. Consistent in terms of size. Predictable in terms of quantity.

The three steps to Scaled Agile

Here are the three steps to scaled agile:

1. Get teams to deliver value in a predictable, and focus team of teams on reducing lead time.
2. Create a system of transparency so that you can see how everyone is progressing to achieve their goals.
3. Bring business decision makers to come together to prioritise the backlog of Epics (single team and team of team).

These simple rules allow the organisation to coordinate and collaborate without having to understand the entire system. From these simple rules, the organisation can generate complex and speedy responses.

The following practices, tools and thinking tools will help you achieve the goals:

So what have I missed? Which goals do the organisation need to achieve in order to scale agile? Comments please.

Just over a week ago, Vasco Duarte, my good friend and leader in the #NoEstimates tribe posted this tweet during a mammoth twitter conversation about #NoEstimates and SWAG Estimates:

I realised that there may be some misunderstanding the purpose of SWAGS, and in particular the relationship with the #NoEstimates movement.

Lets start with story points.

Story Points Versus Story Count

Story Points are crack cocaine for managers who want to believe in a world where they have more accuracy than they really do. Story points, if used at all, should only be used by the development team and the product owner to communicate relative effort. In order to create a story point estimate, the product owner must present a story to the development team that meets the definition of ready for the team. Typically this occurs one or two sprints before the team work on the story. Often the definition of ready includes the product owner taking the story through a “Three Amigoes” session with a developer and tester. This is after the product owner has detailed the story including acceptance criteria, often in the Given-When-Then format. In other words, a large amount of effort is normally required before a story is ready for the team to give a story point estimate.

Mature development teams only work on stories within a defined size range and drop the need for story points altogether. Given the number of stories to be developed, an estimate of the elapsed time to deliver an Epic can be just as easily be determined from the story count as it can using story points. The advantage of using the story count instead of story points is that an estimate of the duration can be made before any work has been done on the story at all.

So within the sprint, some teams choose to use story points and often more mature teams will simply rely on the story count. Outside the sprint, story count is the only sensible option for estimating the lead time for an Epic that spans more than one sprint.

Whence SWAGs

Story counts are useful for Epics when you know how many stories need to be developed. However, there are times when we do not know how many stories are needed, and often when we do not even know what Epics are involved.

This is where SWAGs or Sweet Wild Assed Guesses are useful. (At Skype, that is the name that we put on the field label in Jira).

Capacity Planning

At Skype, a number of us including Tony Grout and Lisa Long developed Capacity Planning, a mechanism to coordinate all of the development of Skype and Lync (now Skype for Business). The Product Executives and Managers would prioritise the backlog for the next quarter based on the capacity of individual teams. A large number of the initiatives that went into capacity planning did not make the cut because they relied on work by a team whose capacity was being used on higher priority initiatives. As a result, we needed a cheap and simple way to estimate the effort required from a team. We used a SWAG, an estimate of how many weeks it would take a team to develop a piece of work. The SWAG was good enough to help us understand how much work a team could do in the quarter. It was understood that SWAGs were not accurate and we frequently referenced the work of Todd Little and Troy Magennis that stated the actual versus estimate followed a log-normal (Weibel) distribution with a most likely actual being double the estimate.

The SWAG estimate was used in the Capacity Planning Process that occurred weeks and months before the stories in the epic were broken down into stories. Once the stories were available, they were used on some initiatives to track progress using just the count of stories.

Subsequently Dan North introduced me to his client, a large American bank, were I introduced them to the same process. Since then the approach has been used in further organisations, large and smaller.

The key issue that Vasco’s tweet asked if we had compared estimates with story counts… The problem is that the story count does not become available until weeks and months after the capacity planning session where we needed them. Not only that, but we did not want to put the effort into breaking down Epics into stories when we might not even build the Epics if they were blocked by other work.

As a result, I suspect that SWAGs and #NoEstimates are complimentary rather than in conflict with each other.