This is the latest in my series of articles on trying to understand the Scaled Agile (SAFe) approach. One of the projects I work on has recently implemented it, and we are currently learning what it means.
Having finally gone round the houses and written articles on Lean, Agile and Scrum the purpose of this article is to describe why someone might want to 'scale' agile in an organization.
Why not just let the Agile teams / Scrum teams do their own thing?
This works fine if you have one team, or the teams are not going to end up getting in each other's way. Imagining the scrum model. The teams will each go through the same stages:
- They will plan work with their customer/stakeholders.
- They will then select the items they are going to work on.
- They then work on those items.
- Once the team finishes they are going to deliver a product to their customer.
The main chances for conflict come when the work relies on anything outside the control of the team, or on the rhythm in place within another team as to whan they can start work on a given item. However good the teams own planning is, they will fail to complete their work if their priorities don't match.
Some examples of this might be:
- The team need access to a key stakeholder during their planning but the stakeholder is tied up in meetings with another team.
- The team need a stakeholder to test or review the changes at the end of their sprint. The key stakeholders are however tied up looking at the outputs from a different team
- The features rely on a particular version of some underlying code. Halfway through the sprint the team responsible for that code upgrade the system
- The features rely on a change not yet in production, and the team responsible for that change are late.
- Key specialized operations staff are not available at the point the team is ready to deliver
- Two teams create features that inadvertently conflict
- Two teams are due to deliver at the same time, but both changes rely on different versions of a core platform
- Key people leave a team halfway through a sprint to because the organization wants to start up a new team.
What's the simplest solution?
Scaled Agle suggests that a lot of these problems either disappear or are at least reduced if:
Teams work to the same rhythm or cadence:
- Making sure that teams start and stop their sprints at the same time - (SAFe mandates 2-week iterations. )
- The start and end of each iteration are fixed - if necessary work moves rather than the date.
- Having a longer timeframe during which the pattern of delivery is synchronized. (In SAFe this is the Program Increment. It consists of 4 working iterations, followed by a planning iteration)
- Changes to teams such as reasigning people happen as far as possible at the end of an iteration.
Teams have within the pattern time for planning activities and catch up:
In SAFe this is the Planning Iteration:
- Teams have a 'planning event' to coordinate and agree on priorities for the next increment.
- The rest of the planning iteration allows time for catch-up. Teams have thinking and planning time. Time to improve tools and processes or to upgrade systems
Teams have some form of higher level coordination (scrum-of-scrums) to keep the work coordinated during the time they are delivering.
SAFe suggests that this works best in 3 dimensions:
- Keeping the organization priorities aligned (a scrum-of-scrums of Product Owners)
- Keeping how the teams work aligned (a scrum-of-scrums of Scrum Masters)
- Coordinating the integration and release of software to the business (the release train)
None of this is necessarily heavyweight or bureaucratic. It is the sort of answers that would emerge naturally from within organizations.
What Scaled Agile then attempts to do is to polish these ideas into a framework with specific names and roles and some level of rules and rituals.
Tomorrow I'll round up by describing the formal terms and roles in 'Essential' SAFe
Latest comments (5)
We're about to do our first PI process where I work... should be interesting. We have a number of smaller individual teams working on various apps with various interdependencies and shared resources. I think as long as it remains flexible (ie Agile) and doesn't devolve into an inflexible waterfall-like pattern, it should be helpful.
We haven't yet had our first planning increment, so it would be interesting to hear how it goes for you.
Our frst SAFe PI planning event where all the teams get together is in a couple of weeks.
The biggest issue for us was not having a single full company-wide PI. Our company is global and our main office is in Australia. They did their PI before us, but a lot of the work done here is dependent on work done there. So it would have been much better to have them directly in on the discussions here. The teams got to present what we had planned but there was no single open discussion where people could bring up ideas, features, blockers, etc. This I think is needed on the first day, where ideas can be accepted, rejected, or tabled, so the following days all the major issues are already on the table and can be prioritized around.
For my team specifically, all it did was force us to reorganize the priority of stuff we'd already had previously planned so it could fit into the sprint lengths we decided on as well as release date/feature commitments.
Wow that doesn't sound like it was an ideal process from your perspective.
I can only go on what the literature says about all the teams working to the same cadence. Is there any scope for you to suggest aligning your next PI event with the rest of the company?
Even if you couldn't have a single company wide planning event there might at least be the scope for the sessions to feed into each other in some meaningful way.
From what I know your suggestions sound sensible. Certainly the idea of presenting plans on the first day is so there is a chance to get a consolidated view of any blockers and issues. As you say so people know what needs tabled and worked through on the second day.
It sounds as if at the very least you have some feedback from this one that would help improve future PI events. Will you get a chance to feed back?
Yeah we'll have a feedback mechanism. I know they already want to do a single company-wide PI next time, there wasn't enough lead time to organize it this time apparently.