Agile Forest

In large enterprises where Agile is being scaled and huge transformation programs are in progress there seems to be a growing trend towards standardization. But what does this actually mean? What benefits can you get from standardizing within Agile transformations and where should you avoid standardization?

Terminology/language

What would standardization look like?

All coaches throughout the organization use the same terminology and when they explain what the term means the interpretation is the same. Examples include being clear on the hierarchy and relationships between features, epics, user stories, themes, potentially removing some of these terms. Which terms should be used – MMFs? MVPs? What about Daily Scrum vs Standup vs Huddle? Sprints vs Iterations?

The benefits on standardizing terminology? 

From team to team the understanding and usage of language is the same. This means that management conversations are on a level playing field. It would also enable more consistent reporting.

The risks of standardizing terminology?

If Agile language is already established (and varied), then some people and teams will have to change. This would be frustrating for those impacted who are already trying hard to tackle the large change in language.

Roles and responsibilities

What would standardization look like?

• A clear definition that is understood throughout the organization of the roles of  the Scrum Master vs the role of the Project Manager.
• Whether the role of the Project Manager is still required or not.
• The recognition that KPIs by role may need to change to align with responsibility changes.
• A shift from “that’s not my role” mentality to “what do we need to achieve as a team” mentality, ie becoming more ‘T-shaped’. This would need to be a conscious choice to breakdown silo like behavior resulting in quite a significant mind shift.
• Importantly, and often neglected, is the change in responsibilities for management – in all layers. Agile transformation isn’t about a change only at the grass roots, the shift needs to be throughout all layers of the organization.

The benefits of standardizing roles and responsibilities? 

A clear understanding of boundaries on roles is always going to be a good thing, you don’t want two different people doubling up on the same responsibility.

The risks?

That said, being too restrictive can be dangerous. How dangerous can depend on the culture – you want people to know what they should be doing but in an Agile environment there shouldn’t be an attitude of ‘That’s not my job.’ The mentality shift moves away from ‘me’ and ‘I’ including the fear ridden culture to one of ‘team’ and ‘what can I do to help the team to realize value even if it isn’t in my role’.

Deciding on what to do with Project Managers is a key decision that needs to be made in Agile transformations. Anyone who worked hard to get into a position of authority may have issues with the perception of a role shift being a downgrade – especially if you are going from being called a ‘Manager’ to a ‘Scrum Master’.

Logistically changing formal role descriptions, role descriptions that people were hired against, can be very challenging. It is a process that can take many months, requiring enterprise agreement changes and potentially trade unions. Most organizations avoid this and opt to not change the formal role descriptions, instead working with informal agreement changes.

Phases and governance

What would standardization look like? 

Whilst Scrum is often considered a lightweight Project Management method, when applied to organisations, and in particular large enterprise organisations, it often doesn’t scale up by itself. SAFe is a good example of an approach trying to solve this problem, but to a good extent SAFe doesn’t know your organisation. It doesn’t know the historical risks that you have had to tackle and the steps that you have taken to mitigate these risks from happening again. And while over the years these measure may have become stale, some of them are still useful even in an Agile and lightweight environment. These extra steps, steps like how you go about building a backlog, how you gain funding (when you haven’t yet shifted to beyond budgeting), how you manage your risks, they are steps that are really important to enterprise organisations.

You cannot fix everyone at once as an Enterprise Agile Transformation Coach, you will need to pick and choose your fights and in order to do this you will need to identify which parts of the existing governance model and process you want to shift.

Standardization here would be a guideline of:

• How to build a backlog
• How to kickoff new projects (including funding)
• How to manage and escalate risks and roadblocks
• How to incorporate security, UX, architecture and infrastructure into your work delivery practices; and
• How the work will be overseen to ensure that continue/stop the line decisions can be made

The benefits of standardizing phases and governance? 

In some respects this is about senior level management feeling somewhat secure that the world hasn’t completely changed. That the toys haven’t been thrown out with the bathwater. Agile can change so much as a disruptive change model and consequently it scares the hell out of most managers because they no longer feel safe. It isn’t about feeling like they are still control, because we all know no one ever is in software delivery, it is about ensuring that organisational risks are mitigated, and that where possible complexity is dampened.

By having some framework in these areas it means as a coach you can tackle and target certain areas to focus and change and segment off portions to get to in the future.

The risks of standardizing phases and governance?

• That we forget it was always about individuals and interactions over process and tools.  
• That inefficient process just gets replicated again
• That extra steps added in slow down delivery. Sometimes it isn’t about injecting process to ensure that a problem doesn’t re-occur, it is about knowing the cost of the problem and consciously making a call to accept this cost again in the future if it happens and hence avoid adding in process.

Visual management

What would standardization look like? 

• Board flows are standardized for like work type teams – eg software development teams all have the same flow
• The same metrics are displayed from team to team – eg Cumulative Flow Diagram, Release Burn Up, Mood charts, Feature usage and uptake analytics
• Card colours no longer require a legend or a key as it is consistent from team to team – eg features are blue cards, stories are white cards, technical debt are yellow cards

The benefits of standardizing visualisation? 

• You can short cut the time it takes to understand what the board is telling you, able to go from team to team and take in the work and what is happening with the work rather than trying to understand the board itself. Importantly who would want this? This would benefit coaches, managers and curious people who pass by, but to the team itself it would have limited benefits.
• Training of important metrics and how the metrics are represented would cost less time.
• Teams could be compared, but I believe this is a potential anti-pattern. You don’t want to encourage team improvements by comparison, you want to encourage improvements by focusing on the team’s metrics by themselves.
• Procuring stationary becomes simplified

The risks of standardizing visualisation? 

• Innovation and creativity associated with the visual management of the board is stifled
• Consequently buy-in and motivation related to the method and/or the work is reduced
• Team specific problems which could be resolved or managed through adaptive visual management strategies are not tackled – eg the need for expedites, the need to split work based on class of service, varying card colour for the purpose of making a particular series of stories pop, creative approaches to solving prioritisation issues in the backlog
• Metrics of low value (but considered mandatory) are displayed when metrics of high value are not due to limited physical space available in the visual management zone.

These risks can be somewhat mitigated by a clear statement that standardisation of visual management is more a guideline (for those in the ‘shu’) and can be enhanced or modified based upon the needs of the work or team.

Estimation and sizing

What would standardization look like? 

• An understanding of what method should be used to estimate stories and features – eg t-shirt sizes, Fibonacci sequence; and
• What the boundaries of these are, for example, a story should never exceed a sprint, a feature should never exceed a release.
• It may be worthwhile to go a little further and give a guideline that a 13 point story is potentially exceeding a sprint, or that a XXL is likely to have multiple releases.
• At the extreme this would be clear cut – expressing features or stories in many different methods of relative and fixed:

XS – 1/2 sprint, 3 ideal dev days
S – 1 sprint, 6 ideal dev days
M – up to 2 sprints, 12 ideal dev days
….. and so on

The benefits of standardizing estimation and sizing? 

A common language and image is formed when sizes are used across multiple teams. Again this has significantly more benefit for managers  and coaches/trainers than the teams themselves, but if team members shift around (which really they shouldn’t) then at least they are already familiar with how to size and can hit the ground running. 

The risks of standardizing estimation and sizing? 

Estimates can be used as a weapon against teams. When the same model is used, it can then consequently be used to compare teams. I believe this is a very risky place to be and do not, under any circumstances, recommend comparing teams. That said, if you have this as a standard, a manager will always inevitably do this if they do not have a coach nearby. It is for this reason that I probably wouldn’t go the extreme and relate a relative value to a fixed period of time – it enables misuse and also doesn’t harness the power of relative estimation and how it naturally scales based on risk, uncertainty and historical delivery variability.

Reporting

What would standardization look like? 

• The same types of reports are generated from team to team and how the information is represented within them is consistent- for example, all teams must use a Cumulative Flow Diagram and a Release Burn Up Chart.
• What metrics are reported, when, and under what circumstances is well understood.
• Certain types of metrics may be generated for flow based teams, whereas fixed deadline teams may have different metrics that are required.
• Quality realisation, employee engagement, customer satisfaction, feature build-measure-learn analytics, progress and risks are understood and consistently reported.

The benefits of standardizing reporting? 

Management can focus on asking the right questions rather than trying to understand what the graphs mean, consistency of training and education regarding reading information from teams.

The risks of standardizing reporting?

 Potential to compare teams, potential to ignore important data purely because it is not standardised.

Team size/composition

What would standardization look like?

 Team structures are setup for a defined ratio with a maximum limit to team size. For example 1 Product Owner : 4 Developers : 1 QA.

The benefits of standardizing team size/composition? 

Team sizes that are greater than 10 people are renowned for being sub-optimal due to the communication cost and risk of the Scrum Master being stretched too thinly to see the woods and the trees. Setting a limit so that this does not occur will benefit productivity and reduce risk. Establishing team ratio also ensures that certain specialities are not being overstretched.

Even better would be establishing feature teams that pull work to them rather than re-forming teams around work.

The risks of standardizing team size/composition? 

Not all work is the same, you could have a feature which is heavily test focussed that would not align well to the defined ratio. Balancing this can quickly become complex.

If the product requires significant enhancements with multiple feature teams working on it all at once, establishing a fixed ratio and size can help to scale up to the delivery problem, but multiple teams working at once on the same product introduces many other issues and complexity so a good approach to handling scaling up and communicating across teams needs to be introduced.

Cadence heartbeat

What would standardization look like? 

All teams use the same Sprint length and start and end the Sprint on the same day.

The benefits of standardizing a cadence heartbeat? 

When I say ‘this feature will be delivered in Sprint 14’ to a downstream dependent team, it means the same date to them as it does to me. Portfolio wall alignment is simplified, especially if you are using industrial tracking tools.

The risks of standardizing a cadence heartbeat? 

• Teams who have been using Agile a while will be forced back to a Sprint number that they have already likely delivered to when the cadence reset is done
• Getting meeting rooms for the first and last day of the Sprint can be incredibly difficult.
• Agile coaches who are working with multiple teams will only be able to attend a maximum of four teams cadence activities on those two days before they get stretched too far, requiring a triage of ‘who needs the most help’ and potentially missing important content on those teams that were skipped due to scheduling conflicts.
• Teams with higher levels of maturity are forced into a cadence block that may not be effective for them.

Standards to avoid

There are standards that should be avoided:

• Target velocity for all teams (drives fudging of estimates to meet targets)
• Restriction that you can only work on items in your flow state only
• How long (fixed time) Inception should take
• How long Sprint 0 should take
• and probably many more but this blog post has gone on long enough

Conclusion

I have tried to present a somewhat non emotive opinion on the elements that I have seen standardized over the years. On a personal level I have felt very uncomfortable with vast amounts of standardization. I cannot really put my finger on why, but it may have to do with the fact that a lot of problems with teams I see have ‘it depends’ answers to them and require some creative thinking which gets constrained by the standards in place.

Maybe the word ‘standard’ is the biggest problem. ‘Guidelines’ have more wiggle room in them, and this may be a term that your audit group is not comfortable with.

As always, the key tenant is individuals and interactions over process and tools and a strong focus on removing waste – if you keep these as guiding principles then whatever standards or guidelines you put in place should not be too negatively impacting.