The cumulative flow report is used as a key agile metric because it gives teams an historical snapshot of how stories move through the various stages of the software development process and provides key insights to teams on their process execution.  Frequently reviewing cumulative flow reports is an extremely valuable retrospective activity

Cumulative flow charts are a key agile metrics for many teams

Identifying bottlenecks

You can see in the chart above that the team did come across some impediments but these were cleared relatively quickly.

Meeting Commitments

The team did completed more than they committed to but I would be concerned as the amount of defined issues brought into the does not stay constant at any point in the sprint.  This may point to the fact the team is new and still trying to ascertain their velocity.  They eventually pull in far more than they are able to accept, this is something that should be watched carefully in future sprints.

Steady Acceptance

You’ll notice that acceptance happened relatively late in the sprint, this could be because of a heavy weighting of large stories in the sprint.  In this case the team were suffering through lack of Product Owner availability sign off the stories and so the team were not getting fast feedback they relied on.

So that’s it the first of many posts on agile metrics.  Cumulative flows are highly informative and deserve a place in every teams performance metrics.

This often happens when ScrumMaster’s try to over-optimise team performance by taking on administrative or secretarial responsibilities. Whilst in the short-term it may seem that the ScrumMaster is assisting team performance by shielding the team from waste by focusing them on development and thereby maximising throughput.  In reality this hinders team performance in the long-term and is a significant blocker to achieving high performing teams.

The biggest problem with this approach is it enforces perceptions of old school project management where there is a separate person that takes on the role of team scribe. This inevitably leads to problems though with teams not taking responsibility and an over-reliance on the ScrumMaster.

If you are already in this situation then you have a challenge on your hands to change your team culture, in either case you can do the following:

1. Make sure the team know your role, the ScrumMaster is not an admin assistant, the role of team scribe is not in your job description.  Your role is to facilitate, coach and help the team achieve high performance through continuous improvement and servant leadership
2. Let the team lead sprint planning, don’t be a scribe writing down stories or tasks, your job is to enable the team to do this.  The product backlog is the responsibility of the product owner the sprint backlog and tasks are the responsibility of the team.  Take a step back and enable them to take the responsibility
3. The ScrumMaster should take retrospectives, but not necessarily be the only person to write them up.  Sure maybe you want to take your turn at writing them up (you are a team member after all), perhaps start up a rota.  If you are the sole person to take the notes then the team will never become accountable or truly own their team’s continuous improvement
4. The ScrumMaster shouldn’t be putting up story cards or tasks on the Scrum board, leave it to the team, it’s their information radiator and it is the team’s responsibility to reflect project status.  The team should be proud to make their work visible

Project Initiation Documents

Focus On High-Level Project Objectives

PIDs should be created with Agile principles in mind, so keep them short and give the high level criteria of what a successful project would achieve.  If you start going into detailed requirements then it will become a requirements document, which you won’t be able to complete anyway as you’re likely not to know all the requirements.

When the Product Owner in a Scrum team needs another way to communicate their vision to stakeholders.  

Whilst Scrum promotes all interested parties being present when planning takes place be realistic, even the most Agile teams struggle getting everyone into the planning session all of the time. Whilst (at minimum) all members of the feature team plus Product Owner and ScrumMaster should be present you may like me struggle to get the  higher level stakeholders there too. Sales directors, CEO’s, CTO’s all have various calls on their times, are often out of the country and so usually unavailable.

What Scrum says should Happen

This is why we have a Product Owner right? The Product Owner is the business representative in the team it’s the Product Owner’s responsibility to ensure they have listened to the stakeholders and make decisions on priorites and direction in the interests of the product. A key part of the Product Owner role is ensuring this vision is communicated to the stakeholders.

Communicating the Product Owner’s Vision

In the past it’s not been uncommon for stakeholders to return to the office after a story workshop and realise they misunderstood the Product Owner’s vision. The team have wasted valuable time running a story workshop and starting the first sprint when it seems the senior stakeholders are not sharing the same vision.

Yes, a great idea would be to get these people together into one room and have a high level discussion around the Product direction. However, when it is difficult to get these people into the same room (especially when it’s very senior stakeholders such as):

• Managing Director/CEO
• Sales Director
• Product Director
• CTO

The Product Owner has a tough (almost impossible job) to get these guys on the same page.

To address this problem we introduced Project Initiation Documents (PID) into our Scrum process. Surprised? Well, it made sense, after all Agile is largely common sense and we felt this document would really add value and (hopefully) prevent communication issues. We decided the main purpose of the document was to give stakeholders (and once signed off) the team a high-level insight into the project. Prior to approval it was intended as a document that would promote discussion. The PID had a few very simple rules:

The purpose of the PID is to gain agreement on the project before any work was done.

• PID is authored by the Product Owner.
• The PID is business focused and gives:
  • Business Case
  • High level overview of the features,
  • ROI strategy through releases
  • Risks
  • Assumptions
  • Potential Blockers
• The PID:
  • Would not be more than 3 pages (A4) long
  • Must be signed off by all stakeholders before the story workshop can take place
  • Will be used for all medium/large projects

Conclusion

We found Scrum with PID’s does work and it actually works really well. The Product Owners found it wasn’t till they started writing the document that they really started thinking about their decisions. It’s a reflective process that before the PID they didn’t do enough of, by writing the PID they were constantly re-assessing their decisions and had to ensure they took could defend their decision within the doc. The senior stakeholders liked it as they could read the document when they could give it their full attention and could spend time collecting their thoughts.

The document template forced Product Owners to tie their release strategy directly to ROI. This helped lessen waste by ensuring the proposed features had clear value. The document created lots of interest and generated the sort of conversation that was not present before. The team liked it as they had a well thought out product vision before the project’s story workshop had begun and they knew it had the full support of the senior management team.

The PID was intended to generated conversation and that’s exactly what it did.

Agile retrospectives are an important yet often neglected part of the Agile/Scrum process. Central to Agile is inspect and adapt – retrospectives are an important part of this. Agile promotes continuous improvement but this can only happen if Agile teams have regular retrospectives to look back, learn and improve.

When should Agile retrospectives stop?

When Agile teams can no longer improve they can stop retrospectives. Seeing as this never happens, there will always be a need for retrospectives in agile.  In fact, even non-agile environments can benefit hugely from retrospectives.

How do Agile retrospectives help ensure continuous improvement?

Action points are taken directly into the next iteration so the improvements identified are acted upon immediately and the team gets instant feedback – short feedback loops are important!

What is the ScrumMaster’s Role in Retrospectives?
In Scrum the ScrumMaster’s role during retrospectives is to facilitate the meeting. The ScrumMaster should not find themselves taking all the action points. Agile teams need to take responsibility for their process and so need to be taking action points too!

Who Should Attend?
In Agile anyone can attend an Agile retrospective, however normally it is only pigs that are allowed to participate, chickens can only observe.  Sensitive subjects may be raised at retrospectives, therefore a safety check should be performed before chickens are allowed to attend

Did you know?
Retrospective is derived from “retrospecatre” which means look back in Latin.