Agile Forest

Find your path to agility with Renee Troughton

Scrum as implemented within teams is something that many of us have been doing for a while. It isn’t a simple implementation, but we have done it for over a decade. As teams begin to invest in applying Scrum at scale, the complicated quickly becomes complex. Methods such as LeSS, Enterprise Scrum, SAFe, DAD and Spotify are good examples of where people have aimed to return this complex set of activities back to complicated.

But they are all missing the realisation of a very simple concept, that all people and teams are not created equal. Sure there is a vast appreciation in these methods of the concept of teams – teams that are autonomous, fully empowered to work with their Product Owner to deliver customer value. These teams, often known as feature teams, pull items of larger work off a portfolio backlog, a backlog recognised to often be owned by someone further up the organisational chain of decision making.

However, where are the technical leaders in this? Where are the managers, be it project managers, or people leaders? Some would argue that in a truly agile organisation such roles shouldn’t exist, and maybe a more lean or autonomous organisation would seek ways to immediately remove these roles. But in a transformation, when so much is in flux, when there are already so many risks of change around, maybe there is another way.

What could the alternative be? What if we could be more tolerant and respect people’s roles and the value that they could provide in these roles?

This blog post is dedicated to such an approach and seeks to discover and highlight the concept of team types.


Feature Delivery Teams

The first team type is the one that we all know best. This is the team that does Kanban or Scrum, or whatever else in order to deliver value to customers. This type of team commonly works off a Product Owned backlog.

Interestingly, at scale they can be either one of many teams delivering as part of a product centric focussed tribe or part of a project centric focussed tribe. Which approach of tribal grouping – project versus product would depend on multiple factors.

This team should also be accountable for the outcomes that they deliver to production – work is not considered complete until the benefits have been realised through hypothesis validation, and any production incidents are also owned and resolved by this team. In simple terms, rather than passing off their problem to another group who only do fail and fix, this team “fixes whatever problems it may create”. In this respect, the team will have a clear desire on good quality software and reducing technical debt because they will also own the maintainability of the code. If technical debt or refactoring is ignored by the Product Owner, they will acutely feel the pain of it further down the line and consequently better appreciate the balance of feature delivery with quality.

There are three points that need to be highlighted for feature delivery teams:

  • The backlog, owned by a single person, the Product Owner
  • This backlog will contain Features and User Stories for the team to work on. This work is expected to provide an outcome that results in either increased customer value, increased customer growth, increased customer retention, increased business revenue or increased cost avoidance. In high feature outcome focussed teams, increased business revenue or increased cost avoidance, are usually related to customer centric features. In a more balanced team, for example one with a stronger devops focus, some features are less direct functional and are more focussed on increased customer retention through reliability and availability of performance. But this balance, or sliding of focus is probably worthy of a separate blogpost.
  • The team’s regular cadence around their transparency of work, often known as a Daily Scrum, Daily Standup or a Huddle, is focussed on the individual work items, blockers to progress and potentially the current team goal.

Project Support Team

Not necessarily applicable in all organisations, if the Agile transformation hasn’t tackled removal of the term “Project”, or if it simply makes more sense to bundle together like business goals that cross cut multiple products, then the project support team is an important team to recognise for the value that it provides.

Common activities that this team will own include:

  • Managing (solving and potentially further escalating) risks and roadblocks escalated up from the feature delivery teams associated with the project
  • Raising risks and issues to the Product Support team if they are more globally impacting than the project itself
  • Managing the project financials
  • Maintaining user experience consistency across all of the feature teams associated with the project
  • Managing cross team dependencies
  • Maintain the Project Delivery Roadmap and definition of the Minimal Viable Project

There are three points that need to be highlighted for the Project Support Team:

  • The backlog, is owned by a Chief Product Owner, with Feature Delivery Teams executing on the items in the Portfolio backlog through their work with their Product Owner. Arguably the activity of portfolio backlog management could be considered a Project Support Team responsibility, but clear accountability lies with the Chief Product Owner.
  • This portfolio backlog will contain significantly large enough activities for a Feature Delivery Team to break down and work on. These could be loosely called “Features” or may be even bigger and called “Initiatives” and “User Stories”. Most of the Project Support Team’s work however is risk and issue management and such doesn’t exist as a backlog but should equally be managed in a transparent manner.
  • The team’s regular cadence, more commonly known as a Scrum of Scrums, is focussed on mitigating risks and issues.

Product Support Team

In the duel relationship with the Project Support Team, the Product Support Team is an important group of people who own the multi-team related risks, issues and release activities related to the Product (sometimes considered a platform or channel).

Common activities that this team will own include:

  • Managing (solving and potentially further escalating) holistic risk to the product based on release drivers from the feature delivery teams
  • Aligning marketing campaigns to potentially drive down multiple messages being released at the same time for the same product
  • Working with other areas of the organisation to prepare them for release readiness
  • Demonstrating to all teams working on the Product the recent changes- think of this as a multi team Sprint Demonstration so that if teams are working on different projects they have the opportunity to be aligned with how the product is changing
  • UX consistency, patterns, standards and alignment where multiple feature delivery teams are impacting the same product zones
  • Architectural vision and guidance (note execution should be with the feature delivery teams)
  • Performance and penetration testing
  • Capability uplift of teams with respect to critical changes to either the product or process to deliver on the product

In a number of cases, the greater the amount of automation that this team or the feature delivery teams can build in to reduce the above activities, the better – especially when it comes to release and testing automation. Note that I haven’t even mentioned production acceptance regression testing as I do fully expect the feature delivery teams to build up this suite.

In SAFe, this is where the Release Train Engineer and the Architecture related elements may fit in, but I don’t really see this team as delivering architectural features, they are responsible for product delivery capability.

There are three points that need to be highlighted for the Product Support Team:

  • The backlog, unlike the Project Support Team, is likely a multi Product Owner scenario, with the full Product Support Team driving and agreeing to priority.
  • This backlog will contain activities for the team to work on. These could be loosely called “Features” and “User Stories”, but the customer in most of this work is not going to be an end user and is more likely to be an internal customer such as the Project Support Teams, the Feature Delivery Team, Marketing, IT Service Centre, Risk or Compliance areas of the organisation. This work is expected to provide an outcome that results in either increased customer retention (through minimised interruptions/updates), or increased cost avoidance (through risk avoidance).
  • The team’s regular cadence, more commonly known as a Scrum of Scrums, is focussed on mitigating risks and issues, transparency and execution of both release management and of capability uplift activities.


I understand that many people will read this blog and go “that’s not very Agile”, but the reality is that a transformation doesn’t happen overnight and unless you have a horde of Agile Coaches going across massive 30,000 people, you are going to have to pick and choose battles, with those battles often not immediately targeting both governance, finance and human resources sections of the organisation.

This is a way of an intermediary step until you may be ready to transform systemic organisationally wide dysfunctions.


In oldschoola query that recently spammed the Agile universe by Abder-Rahman Ali was a question posed about the difference between User Stories and Software Requirements Specifications, specifically

1) Do you think that “user story” is just a fancy name for SRS?

2) How do you compare a “user story” to “SRS”?

3) Do you think that “user stories” replace “SRS”?

4) Which of the two do you prefer working with?

So let me open with a clear positioning stance:

User Stories are not a fancy name for an SRS, they are not the same thing, they should replace an SRS when working in an Agile environment and I prefer working with User Stories.

The following comments are focused on how I believe they are different and are naturally based on subjective opinion.


A SRS is usually created part way through a project, once the Business Requirement Specification (BRS) has been crafted and signed off. An SRS is crafted by a Business Analyst, often with minimal collaboration to other team members and the business throughout its development. As part of its development the BRS is cross referenced to ensure traceability. Once produced the SRS undergoes a review and approval process that does generally have an extensive audience. Often this review and approval process can take several versions until the document is deemed correct.

A User Story can be created at the start of the project or throughout the life of the project. Through a collaborative workshop(s) called “Inception”, features are defined. Often these features are broken down into User Stories using the Story Mapping technique. As everyone who needs to deliver the project is in the room there is no handoff of documents and no extended review and approval process.

The key differences in the origination process is that User Stories are not dependent on the existence of a BRS to be created, that everyone is engaged to identify and define the requirements, and that there is no formalized approval process (because it is not needed if we are one team, all responsible for the outcomes that we agree to).

A simple analogy is that Inception is requirements gathering on steroids.


SRS content is often lengthy, comprehensive but lacking depth to implement against. Normally, an additional deliverable is produced in between the SRS being delivered and software starting coding (normally referred to as a Detailed Design Document, or DDD for short). Field rules, expectations of behaviour under error or abnormal conditions are also specified within (sometimes as an appendix, or separated out into an additional deliverable). There are often multiple SRSs to a single BRS, but rarely would this number exceed a magnitude of 10. How a SRS is tested comes down to separate test deliverables.

A User Story is a promise for a conversation. It is often a single sentence written as a narrative of “As a <persona>, I want <requirement not solution>, so that <value obtained>”. In addition to this single sentence the conditions under which the User Story will be tested are included as Acceptance Criteria. Well-formed User Stories, like system requirements, cross cut components or architectural tiers of the system(s).

Critically there is an expectation that the documentation of the User Story itself is unlikely to be sufficient or comprehensive. The conversation placeholder is the opportunity to discover these elements of the requirements and to clarify needs in person with a business representative. This conversation has representatives from all specialists. This conversation may also extend to a group of developers in order to determine the best architecture or design to deliver the User Story. In this respect a DDD is not normally produced, but photos of whiteboard outcomes are kept in a repository for prosperity. Field rules are often discussed as part of this conversation.

Expectations of behaviour or abnormal conditions are often split out from the story – ie a new User Story is created per condition or behaviour to handle expectations. In this respect a single business need, described within Inception as a Feature, may result in potentially several dozen User Stories. This is especially true when good User Story splitting principles begins to focus on one Acceptance Test per User Story and the team moves towards an estimationless environment of reduced User Story size variability.


As part of the SRS development, as the BRS may undergo several change requests. As part of the DDD development, test deliverable development, actual development & testing the SRS may also undergo several change requests. Over the life of a Project this could result in hundreds of change requests to approved deliverables – this is to ensure that what is delivered is of value to the end user, otherwise the system is unlikely to meet their needs. Each one of these change requests takes the team away from delivering to estimate the impact of the change.

As User Stories never undergo an approval process they can be changed at anytime prior to a developer picking it up to deliver. The cost of change at this point in time is negligible with conversations often being the only highlight. Once development has begun there an team internal change policy often guides what happens next. As a rule of thumb, if the change would take the team less than 30 minutes to do then it should be absorbed, otherwise the change should be raised as a new User Story. That User Story then gets prioritised by the Product Owner and may or may not be done based upon that priority. As a rule of thumb, unless the original User Story was completely off base, then it would still be delivered as it stands, otherwise it would be pulled from development.

Realising value

A SRS does not have it’s value ever realised or assessed. The BRS is tied to benefits and it consequently gets assessed for benefits realisation. Only through traceability of requirements is there confidence that the SRS realises value. From a delivery standpoint, only once all the SRS(s) and BRS has been delivered does the software often go into production. The outcome, is often a delivery near the realm of a year or more. The benefits realisation activity is consequently months, if not years after the production delivery.

Both the Features and the User Stories realise value within their originating narrative of “so that…”. As developers deliver User Stories they can go into production once they have been tested against their acceptance criteria. For iteration based team this often means fortnightly deployments to production and consequently a fortnightly realisation of value. Sometimes teams may not release to production at the end of these iterations because a minimal viable product is still not achieved. Some teams, especially those that have focussed on technical excellence through continuous integration and continous delivery, can realise value several times a day through regular deployments to production.

When Agile teams take on Lean Startup practices a User Story does not get deemed completed or done until analytics have been gathered in production to prove or disprove the value realisation.

A good analogy of Lean Startup as it applies to User Stories is “continuous micro benefits realisation”. In this respect, Agile teams have a higher confidence that they are reducing the #1 waste in software development – building the wrong thing, because they are constantly checking with real customers if they are on the right path (not the proxy customer who may be the Product Owner or Business Stakeholder). The other key difference when Lean Startup applies to User Stories is that the narrative alters to no longer be a requirement and instead is a hypothesis that critically should be proven.


When a BRS is completed the service delivery team does a detailed estimate to deliver not only the SRS, but all artefacts and actual software delivery outcomes. The change request process is often the only means to recover further money. Critically, this estimate is done when the largest amount of unknowns are still unknown. Re-estimation after the SRS is completed is not normally done, especially in fixed price bidding environments. Estimates are commonly done by Project Managers and Architects and have next to no input from the people who actually do the work. There is no relationship to SRS and actual delivery rates (with the exception of the rare teams that still do Function Point Counting).

In Agile teams estimation is done throughout. Both Features and User Stories are often estimated, but critically not in hours or days. Instead Agile teams used comparative based estimation techniques where one User Story’s complexity is compared to other already existing estimated User Stories to best gauge its approximate size. As teams begin to deliver User Stories they track throughput rates, either by cycle time or amount of work done within an Iteration. This information is then used to forward project confidence of delivery. All team members are actively engaged and encourage to estimate the User Stories as a single unit.


It is hard for me to write all the above content and not continue to think “Why do we still do waterfall?” especially in the commercially fast paced world that we live in these days. An SRS is not the same thing as a User Story. The outcomes that each achieves are quite different because of how they are utilised, not because of the description of the need that is within them.


North Korean Innovation


A North Korean Architect was commissioned to draw a futuristic version of North Korea with zero limits on both financial feasibility or even

structural integrity.

The result? In what seems straight out of a 1963 ‘The Jetsons’ episode, the architect seemed to produce drawing after drawing stuck in an era of decades past. Simplistic treehouses, ancient decor and ordinary footbridges made up a few of the images created.

So why with such an open remit did the architect produce such backward thinking results? Maybe it was purely the individual, maybe they misunderstood the brief, or maybe this is a glimmer of what happens when innovation is stymied by a lack of injected ideas.

1963 Jetsons apartment

1963 Jetsons apartment

The secret to innovation isn’t just having the time to think freely, but also having a great depth of material to draw on. This architect was not influenced by decades of shifts and ideas in architecture.

So the next time you think that innovation is all about having 20% downtime or having hackathons, think about the learning culture you are creating instead. Are you creating a learning culture to enable innovation or are you just enabling the creation of more Jetsons apartments?

magicThere are some great things about Scrum. Having a regular cadence for planning how to do work, working together to progress work and regularly reflecting and getting feedback both on how we work together and what was delivered are all great concepts.

But I have come to a somewhat scary hypothesis that it isn’t the practices, the roles and the artifacts that are actually making Scrum successful.

I think it is because you are taking your inefficient, over bloated process and replacing it with a very simple method. It works because you are taking something very heavyweight and replacing it with something lightweight.

You see, the trick to succeeding at Scrum, isn’t really the implementation of Scrum. It is whether you win the culture over process race.

As you get more used to Scrum you find weaknesses, areas where it isn’t dealing with organisational problems and you start to add in process to fill the gaps. Usually what you add in is something similar to what you used to do. At the same time, you are trying to transform the culture by changing hearts and minds towards Agile – to be agile rather than just doing Agile. This is the culture shift. When you have succeeded in this culture shift you would be less likely to introduce the additional process.  Basically you have to be faster at changing the culture to enable pushing back on process bloat over the injection of new process.

This is arguably why SAFe could be a little less effective in transformation and in significant improvements – because to an extent the process is probably more medium-weight and doesn’t do enough to push back on process waste.

So the next time you plan on changing a way a team or organisation works, think about why it may be working and focus on whether every additional step being added in after the change will really add value. I find that 80% of process is added in to handle less than 5% failure scenarios. There has to be a better way.

agiledoesntworkOn my way to someone’s desk at work I overhead a blunt and emotive statement “Agile doesn’t work”. I smiled slightly and hung back to overhear the conversation further.

I learnt through listening that the person making the statement was a Product Owner. They were unhappy with the fact that their team hadn’t been delivering on their product backlog, that they team instead had gone off and begun to work on something else.

I was a little shocked to hear this, and could deeply empathise with the concern. If it was the case then the team was indeed not performing to expectations.

I spoke to the Scrum Master later about it (note they were not a team that I had direct coaching involvement with) and learned that team had actually begun working on something else because it had been a directive that had come down from several layers above the Product Owner.

Delving further, the reason why the Product Owner only knew about this after the end of the Sprint was because:

  1. They were not investing their time co-locating with the team
  2. They were not attending the Daily Scrum nor Sprint Planning

… and people wonder why Agile gets a bad rap.

So the real issue here was never that Agile didn’t work, it was that:

  1. The Product Owner wasn’t investing properly in their role, either because they were overstretched (poor capacity planning), or due to care factor (bad engagement)
  2. The Product Owner wasn’t co-locating, again either to being overstretched or due to physical desk limitation issues
  3. The Product Owner was superseded by his own management and yet his management failed to inform him of this change in direction

Some would also say that the fact that the Product Owner’s management trumped his work is an indication of concern, that he may not be empowered to calls the shots. Normally I would suspect such a problem, but in this instance this was an urgent unplanned change that impacted hundreds of people and dozens of teams, it was highly irregular.

I asked the Scrum Master if they would be willing to talk further through the above problems with the Product Owner in order to reach a common understanding of where the problems with Agile in the team were.


Agile does work. It, just like any process, needs people to understand the process and follow the steps to enable it to succeed.

In my last post I opened up the questions about a disruptive force out there to induce change and what potential options may exist.

In this post I am proposing an option – the creation of a political party where its foundations lie in the values and principles of Lean and Agile.politics

This party could be funded through crowdfunding, with a policy statement drafted to kick it off.

An example of a political direction could be:

Intra Government Reforms

  • Have the people of Australia determine where spending should go using a model similar to Luke Hohmann’s work in San Jose
  • Significantly reduce the management layer in the government, ensuring that servant leaders were in leadership positions
  • Normalise and make all salaries transparent, using a model similar to Buffer
  • Remove all bonus systems, focus on intrinsic motivation through opting in to programs and self organised teams
  • Departments to be headed up by Agile+Lean thinkers to change the culture significantly

Corporate Reforms

  • Reform tax to influence spend on sustainable environment strategies. I know of an organisation in Australia that has 15000 employees and their spend on being sustainable is 0.5 FTE. It is abhorrent and needs fixing.
  • Reform tax to dampen usage of offshoring.
  • Dedicate funding to a Lean Startup incubator. Capital investment is almost impossible to get in Australia. I want to encourage new small business, but I am also conscious that the success rate of Lean Startups is only 3%.

Educational Reforms

Break the model of extrinsically motivated learning and the command and control pattern of teaching through:

  • Roll Agile and Lean thinking out to the teachers and headmasters of the schools
  • Support the growth of empowered learning where students can choose how they learn. There are many examples of schools successfully using a working model of this throughout the world

Other Policy

  • We need to listen to the world experts on how we can turn around global warming and start taking action right now. They have the answers and a hypothesis of what needs to be done. We need to begin work on the dramatic changes needed, though I suspect some of the corporate reforms would make a headway into it.
  • Support the front lines of hospitals. They do not have enough staff and financial support to exist in a sustainable manner.


What policies would you have in a Lean Agile Party that focuses on a new Australia?

earthAgile and Lean have come a long way for the last ten years, but I feel there is a barrier that we cannot break through without a dramatic disruptive force. For years I have been wondering what could drive this. I had hoped that Stoos could have been a means to this change, or that continued and persistent adoption of Agile and Lean would result in it, but I hold little hope for these being the avenues to it. I know they will, given enough time, but I hold a fear that the continued models that our government and teaching system uses will not result in a change in my lifetime. And my even greater fear is that by then it will be too late.

I met recently with one of the worlds leading climatologists and asked deep questions regarding our future as a race. There is clear evidence that within one hundred years it will be on average ten degrees hotter across the globe. If you thought that I was wrong writing ten and not five then make no mistake – they are telling the media five degrees so that it doesn’t cause massive panic and so that they don’t appear to be fear mongering, but the real expected figure given current global politics and policy is ten degrees.

With ten degrees there would be widespread drought. Half of the planet would be inhabitable. Ground level railway systems would fail. Heat stroke related deaths would be significant. Imagine how we would live, how much we would have to seek travel out of the sun, how much extra energy we will be burning to make ourselves cooler. I have children and I want them to be able to have a future where they can enjoy being outside.

I want a world where the politicians listen up and start to address this problem. I want a world where the people within it get to have a voice beyond an election every few years. I want a less apathetic world.

Where I have seen Agile transformations highly successful is ironically when they have been driven from the top – a desire at the upper levels of organisations to create a new culture.

So I want a massive disruptive change, something to address this problem. But how?

I have some ideas, but I am keen to hear yours – do you think a disruptive change is needed? If so, what do you think can be done from it, different to what we are doing now?

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?


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.


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


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.

Last week I revealed a little game/exercise that I have been running to demonstrate the difference between activities and behaviours in a non Agile environment versus an Agile environment and how the activities and behaviours shift to the team and the Scrum Master/Iteration Manager. I would like to now share the results of the game. I have run it twice, one with a strong group of Agilistas (Scrum Masters and Agile coaches) and a second time with a group of Project Managers. What surprised me is that despite the differences in the audience the result was pretty much the same. Maybe it was luck, but I am keen to hear of others running the exercise and if they get the same results (a few people have already shared with me that they have subsequently run it and got a similar outcome). The group of Project Managers that I did the activity with had a really good smattering of Agile practitioners in it which I believe helped to get a similar outcome. In this respect, I am concerned what the outcome would be like with a pure audience of Prince 2, never done Agile, Project Managers.

So what were the results for round 1?

When round 1 is conducted, almost all cards are voted to be best aligned with the role of the Project Manager. The following were the behaviours/activities there were not voted to be a Project Manager’s:

  • Deliver the work right
  • Deliver value
  • Quality focused
  • Is 100% allocated full time
  • Delivers the right work
  • Challenges the norm
  • Encourages learning culture
  • Mentors team

Which left the Project Manager with the following behaviours/activities:

  • Facilitates meetings
  • Primary stakeholder is Sponsor
  • Primary stakeholder is the team
  • Primary stakeholder is customer
  • Sustainable pace focussed
  • Coaches issues
  • Manages ability to deliver outcomes
  • Removes roadblocks
  • Trains approach
  • Resolves issues
  • Enables rather than controls
  • Makes decisions
  • Handles people issues
  • Directive, provides answers now
  • Has budgetary control
  • Ensures benefits realisation
  • Delivery focused
  • Supports approach

My thoughts on the round 1 results

The following were my thoughts on the results for round 1:

  • I thought it was interesting that it was the team and not the PM that was perceived to challenge the norm. Is this an admonition from PMs that they don’t push back on unrealistic timeframes or goals?
  • The PM’s primary stakeholder is considered the team, the customer and the sponsor… all at the same time. This question was deliberately worded to force a ‘x over y’ response and yet there was a strong drive for all three roles to be the primary focus for the PM. The conflict between these roles is inevitable and in my belief this is the key weakness of the non Agile environment model – one of these roles will win out over the other two and in my experience, it is unfortunately not the team nor the customer that wins.
  • I was somewhat surprised that PM’s felt that facilitating meetings was a core behaviour/activity. I normally would have thought this would have gone to the Business Analyst role but it could depend on how you interpret the question and what facilitation means.
  • I was very surprised on the sustainable pace response. I believe there is a gap here of what PMs believe to be true versus reality. When push comes to shove, most PMs I know would push the team to work extra hours/weekends to get a project over the line. I know that there are many of you who are good PMs that don’t do this, but the majority would.
  • Additionally I was very surprised that a PM would be coaching issues. Again this may come down to an interpretation of the term “coach” but I am using it in the purest sense that of ‘not providing answers, but instead asking questions to the team so that they themselves reflect to reach enlightenment on the issue’. I’m sorry, but I actually don’t think I have ever seen a PM do this.
  • Likewise I’ve never seen a PM train anyone.
  • Enables benefits realisation is a tricky one. I do believe that PM’s care for and look out for benefits realisation, certainly very much at the start of a project, but as the project progresses and trade offs begin to be made it is the better of the PMs out there that deliberately report and get validation to the trade off of benefits against time. That said, few PMs stick around long enough to see the actual benefits realised which I believe is sub-optimal as they are not receiving feedback on how well or not they hit the mark on delivery (to me delivery is more than just dates, cost and scope).

What were the results for round 2?

When round 2 was completed, the Scrum Master was given:

  • Facilitates meetings
  • Coaches issues
  • Enables rather than controls
  • Primary stakeholder is the team
  • Removes roadblocks
  • Mentors team

The team were given:

  • Delivery focused
  • Sustainable pace focused
  • Deliver the right work
  • Deliver the work right
  • Is 100% allocated full-time
  • Delivers value
  • Quality focused
  • Supports approach
  • Challenges the norm

Split very evenly between both the Scrum Master and the team were:

  • Manages ability to deliver outcomes
  • Resolves issues
  • Trains approach
  • Makes decisions
  • Encourages learning culture

The Product Owner was given:

  • Primary stakeholder is customer
  • Ensure benefits realisation
  • Directive, provides answers now

The following were put into the category of “Other”:

  • Handles people issues

And lastly, the Project Manager had:

  • Has budgetary control

The following was questionable as to where it belonged (if anywhere):

  • Primary stakeholder is Sponsor

My thoughts on the round 2 results

The following were my thoughts on the results for round 2:

  • What is most clear in this transition are two things, firstly the Project Manager is left with only one responsibility and the rest have been quite evenly spread between three roles – the Scrum Master, the team and to a lesser extent the Product Owner.
  • Secondly, there is the separation of primary stakeholders against role. The Scrum Master has the team, the team has the Customer and no one is left looking after the Sponsor. I don’t think this is necessarily correct and would imagine that the Product Owner has the Sponsor’s back, but this would likely also have a conflict against the Customer’s needs. What do you think – in an Agile world, who has the Sponsor (the supplier of money) as their primary stakeholder? In an Agile world should a “Sponsor” exist and if not where does the money come from?
  • I love that in an Agile world it becomes everyone’s responsibility to guide others (trains approach), encourage learning, resolve issues and make decisions. Some may argue ‘what if the team disagrees between themselves on an approach’? This doesn’t mean that it goes to a vote for the decision, it means that the team works through the pro’s and con’s and becomes more aware of the depth and breadth of the issue. A leader will always step up for the decision, but it is only done after a more collective understanding is reached.
  • Sustainable pace is probably the hardest issue to balance in an Agile environment. There will always be a push from the Product Owner and management to go faster and harder, especially if there is the ‘frozen middle’, a layer of management that does not understanding the essence of Agile. Dates are commonly still unrealistic for many teams and this leads to the inevitable push to work longer hours. Now with the Scrum Master accountable to the team they will likely be the first to push back against this, but the pressure can be immense. For my two cents I have sometimes given in on having a short burst of extra hours, never longer than a month. But let me be clear, I do not believe it helps the team in the long run, nor do I believe it is a good idea due to the impact it has on the quality of the product. This has been proven many times in studies and I have seen the results of even a month of bursting and what it does. Just don’t do it.
  • It is interesting that the Product Owner is seen to be directive and provide answers now, but if you think about it, to some extent that is what we are asking them to do. We want them to give us a quick resolution on a question so that we can meet our goals.
  • Handles people issues was shifted out as it was now likely being handled by a Team Leader.
  • And lastly, the budget problem. If a PM is only left with handling the budget then is it really a role? There is a huge shift towards “Feature teams” – teams that do not form and disintegrate on a project by project basis. In essence work is broken to fit into them rather than teams being formed to fit the work. This results in teams that only go through the Forming-Norming-Storming phase once at their initial creation or subtle dynamic change. The individuals in the team know each others strengths and weaknesses and most importantly they have a fixed team cost. If all work in the organisation is broken down to features that are implementable by the product feature teams then the problem of funding for software development really just boils down to one fundamental question – “What is the most highest value work that this product feature team can be working on?” Then it becomes a somewhat simplified matter of watching the cycle time for the product backlog and seeing the lead time for features to determine if more feature teams are required for that product, or less. In essence, it takes the problem from being a project issue to being a operational issue.

Final thoughts


For those Project Managers out there that are believers in “Theory Y” there is unlikely to be much of a negative impact on you when you shift into an Agile environment. You are already a supporter of empowered teams and consequently this transition should feel very natural and in a lot of respects will result in a better work life balance for yourself as your old duties get spread more when you take on either the Scrum Master or Product Owner role.

But for those Project Managers who align more strongly with “Theory X” then there are some tough choices for you ahead in your future. You can choose to find work in an alternative organisation that isn’t about to go down the Agile path anytime soon. There are still plenty such organisations out there, but be aware that over the next ten years the number of these will likely shrink.  You may not be able to run forever. You can try to hide. You may be lucky and not have a good number of Agile Coaches in the organisation who will spot you and elevate your “Theory X” ways to management. PMOs are great hiding grounds, until they are wiped clean.

Or you can change. It won’t be easy, in fact, it will be months and months of hard work, but you may find an enjoyment and peace that you never experienced before when you make this leap of faith.

For the “Theory X” managers, let me leave you with this parting quote and good luck on your journey.

It is difficult to get a man to understand something when his salary depends upon his not understanding it. Upton Sinclair’s Dictum

I know I am an idealist. I don’t think I have ever met a coach who isn’t. It is part of our nature, the continual strive for perfection, the search for true north, the Kaizen culture of always seeking ‘better’. 

This means that sometimes I am never appear happy with the status quo. 

It isn’t that I am not pragmatic and it’s not that I don’t want to live in reality. It is that I just won’t be happy to settle with inefficiencies. 

But sometimes this means that we forget just how far we have come. 

I was reminded of this recently when an ex-team member began to regale to me their surprise when they went from an Agile environment back into a non Agile company. 

To quote, 

At the new job site we’re not allowed to talk to each other unless we make an appointment or go through some formal process.

I tried walking over to talk to a developer last week and was apprehended by a “minder” who detained me and walked me through the correct process to communicate with him.

I guess the idea is to let the developers concentrate on their work without being interrupted but it just seems very slow and inefficient.

It is interesting to note how quickly when going back to non-Agile environments you pick up on the waste surrounding you everywhere. 

So for those of you who are coaches, Scrum Masters and Iteration Managers, battling away at inefficiencies and waste, take a moment to appreciate how far you have come. Remember what it was like when you weren’t doing Agile. Today was better than yesterday. Tomorrow, anything is possible.