Agile Metrics

This article presents guidelines and examples of metrics you as a leader can help set for the group or team

It is really important that an organization does not measure only to demonstrate to others in the company that things are getting done. There is a false sense of comfort in these metrics. It is important to measureless.

“Remember – What you measure gets done”

–Attribute pending

5 rules when selecting metrics: ( VOIRS Rule)

  • Make what you measure, is Visible.  Everyone should be able to see what is being measured. Customer satisfaction survey results -outcome metric, velocity – output metric. A good mix is always required.
  • Outcome driven metrics always produce better results that output driven metrics.
  • Make it Inclusive let those who you want to measure have a say on how they want to be measured. Get input from teams. If you get buy-in from teams then metrics makes a lot of sense
  • Make it Real-Time. – If metrics need translation by humans in an excel sheet there is something wrong with such metrics.
  • System metrics are better than People metric. Measure more of how the system is doing and less of how people are doing.

Measuring Process Effectiveness

Measuring ability to reach Strategic goals at a regular cadence

Screen Shot 2018-07-28 at 9.16.22 AM.png

Any product or service organization has business goals. These goals are often things like  ( in this case we have shown an airline example )

  • One Integrated Airline Booking Experience
  • Reduce customer complaints by 30 %
  • The launch of 4 more cities for new flights.

When it comes down to the teams these goals are compounded with so many other little internal goals etc that somewhere along the lines, the big picture goal is lost. So leadership job is to regularly communicate these goals and make sure everyone in your organization is focused around these key goals. There will be other things but many times those other internal work items slow down the more important strategic priorities.

Screen Shot 2018-07-28 at 9.45.41 AM.png

In the example above 9 different epics have to be done to get the three goals achieved. Each epic could be made of many many smaller epics or smaller user stories or backlog items.

So how do we measure things from here?

MetricLead Time – This is the time when the requirement was first identified in the organization and added as the core component of the strategic initiative to the time it was actually delivered to the customer.  Tools can do this easily. The difference of end and start is the lead time.

Screen Shot 2018-07-28 at 1.27.31 PM

Monitor “Cycle time”.

Cycle time is the time taken at each step. in the doing column. Time from the time some work start till it is finished. The customer does not see it

Screen Shot 2018-07-28 at 2.10.46 PM.png

Lead Time is = Sum of Wait Times + Sum of Cycle Time. In this case, we are taking Cycle Time to be the actual Value Add time. Really go and figure out where waits are in the process and help remove these waits. Waits are often seen

  • when people are waiting for approvals,
  • Only a few people in the organization can get some things done. Remove the silos.

All the work note ” All of the work” a team does should go from one list. 

Screen Shot 2018-07-28 at 2.26.50 PM.png

Show a live report of where these epics are at any given moment

Screen Shot 2018-07-28 at 2.42.22 PM.png

Measuring Agility.

How do we know how Agile we are. It’s surely not a gut feeling or some massive assessment. Assess systems, not people. Using Agile Principles as a measure of Agility.

http://agilemanifesto.org/principles.html

Shown here is an Agile Principles Card. Have each team sort through the 12 principles from “Yes to do it” green or no we don’t do it ” Red”. Collectively prioritize the red ones and then come up with action items as story cards to move items from Red to Green.

Screen Shot 2018-07-28 at 2.56.26 PM

 

Measuring Product Effectiveness

Customer Satisfaction 

If you have a good product you should see higher customer satisfaction. Regular customer feedback collected real time from customers should be shared as is with teams that produced that feature. A much-debated technique is called Net Promoter Score. It is just one measure and should be used for what its worth. A point of reference.

Amount of features in the product that is actually used. 

80 % of the features we produce are hardly used. You could use the four categories in the Kano Model https://www.mindtools.com/pages/article/newCT_97.htm

Every product manager should know how many of the four categories of features they have from the Kano Model in their product

As per this model, every feature can be categorized into:

  • Mandatory features – Must be present in order for users to be satisfied.
  • Linear Features – The more of this is better
  • Exciters or Delighters – These are not the reason we buy a product for. A feature she does not know exists until she uses it.

fullkanomodel

The image above is from http://foldingburritos.com

Mandatory Features – Customers are quite indifferent to must-be featured. For Eg Do you ever buy a phone because it makes a phone call?

Linear features – Customer satisfaction is more around linear or performance features

Exciters or Delighters – These are huge pluses to customer satisfaction. For eg the first time Gmail said, Hey you have forgotten to attach a document when your document says something is attached.

Collect data about all the features in the product broken down by the three categories in real time. This can be achieved when you tag epics as a Linear, Mandatory or Exciter in your Product Backlog tool.

Screen Shot 2018-07-28 at 3.48.48 PM

 

 

Measuring Leadership Effectiveness

A #1 reason for Agile to not be as successful in the organization is due to lack of middle management support. See State of Agile Survey By Version One. 

 

Screen Shot 2018-07-28 at 3.54.15 PM

– the picture above is from State of Agile Survey By Version One

As you look through the list, it is clear that effective leadership can actually help resolve a lot of these challenges listed. So how do we measure effective leadership?

  • Are leaders solving daily the biggest impediments of the organization? Are they helping daily?
  • Are they delegating decisions down where information exists and don’t punish people for making decisions?
  • Are they setting clear boundaries for teams to operate in?
  • Have they separated feedback from performance reviews?  Feedback should be routine not drama.

This can be collected from teams from regular automated surveys or 360 feedback. Leadership effectiveness is a much bigger topic that we will surely address in a later blog.

Conclusion:

This article presents very few metrics mainly around three categories Process Effectiveness,  Product Effectiveness, and Leadership Effectiveness.  Note that velocity is an output indicator and not good to measure effectiveness. It can simply be used to predict future dates that is all and it is a lagging indicator.  Also, note that it is important that all of this be automated and be touch-free leaving nothing to interpretation. Also, this is the main metrics that should measure and it’s really up to you as long as you pay attention to  VOIRS rule. 

Make it useful, measureless, get more done….

How Does Scrum Feel?

Let’s get some keywords out of the way first.  

Scrum  – A framework to deliver value to the customer iteratively.

Sprint – A time box where an increment of value is delivered. Mostly 1, 2, 3 or 4 weeks.

Roles-  Scrum has Three Roles.

    1. Scrum Master – Remover of impediments. Team motivator, Servant leader
    2. Product Owner – Voice of the customer. Works with team and stakeholder to create value.
    3. Development Team – A self-organized cross-functional team that delivers value.
    4. Scrum Team – Collectively the Scrum Master, Product Owner, and Development team are called this.

Events– The Scrum Framework has four productive events. ( meetings )

    1. Sprint Planning – Plan the work of sprint so that we can deliver value at the end of Sprint.
    2. Daily Scrum – A 15-minute daily plan.
    3. Sprint Review  A product feedback, inspect and adapt cycle.
    4. Sprint Retrospective – A process improvement Inspect, Adapt Cycle

Artifacts – Things of value produced in a time-box.

  1. Product Backlog – A backlog is a term for a list of things to do, also called Requirements. This is owned by the Product Owner
  2. Sprint Backlog  Also called As Task Board or Scrum Board.A tool used by the development team to be transparent about the work they are doing in the sprint.
  3. Product Increment – This is the reason we do Scrum. To build something of value in Short iterations of time.

An easy way to remember the core Scrum Framework is with the 3-4-3 rule. Yes, there are only 10 things to the Scrum Framework.

In Scrum, 3 Roles, the Scrum Master, Product Owner, and Development team go to 4 Events – Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective in which the produce 3 core Artifacts. The Product Backlog, Sprint Backlog and the Product Increment Itself.

Let us look at what goes on in one sprint for a Scrum Team which is doing two-week sprints.

Day 1: Sprint Plan -The Development Team, Product Owner, and Scrum Master meet in a sprint planning event. This is normally 4 hours max for a two-week sprint. In this event, the team “Pulls” items that are ordered as high priority and breaks them into what done means for each item.  The team defines a Sprint Goal that they can march towards.

As the team finishes the sprint planning the Scrum Master is cleaning up the task board and getting it ready for the current sprint. The team members help prepare the board too.

Screen Shot 2018-04-30 at 11.26.43 PM

Day 2:

The team starts with a Daily Scrum in the morning. The Daily Scrum is done in front of the task board.

It is a good practice to update the task board before the daily scrum to keep the daily scrum going smooth.

Day 5:

Screen Shot 2018-04-30 at 11.26.50 PM

This team works on something called one-piece workflow. Which means they really like to finish one story completely before pulling another.

The task board on Day 5 looks like this. ( This is just an example)

The team has finished story A and is working on B on Day 5.

What else do you notice that is different from the task board today?

The team has also updated the burndown chart. Their burndown chart has the number of tasks on the Y-Axis and the number of days on X-Axis.

They also demo the  Backlog item A to the Product owner and get acceptance from him.

Day 9:

 

The team has finished two stories and decides not to pull the third story as planned as they have no more time. They get acceptance on the second story too. Way to go team.  You Rock!.

They meet in the evening for half an hour to “Get Ready for the Sprint Review”.

Day 10:

Screen Shot 2018-04-30 at 11.26.54 PM

The team is delighted to have finished two of three stories. This is called the Say Do Ratio.

Sprint Review:  The Development Team, Product Owner, Scrum Master meet for an hour and a half to talk about what was delivered in the sprint. 

The product owner talks about the two stories completed and then the team members take turn to show the two stories to the stakeholders in the room. 

They get feedback back about a small change that was requested in the Story B. The product owner says he will get it changed.

The sprint review ends with a small celebration.

Sprint Retrospective:

The Development team, Product Owner, and Scrum Master meet to discuss improvements they can do to the process so that they can do better. They plan to meet for an hour and a half.

The entire Scrum team talks about the two impediments that came in between the sprint, that slowed them down due to which the second story took a bit longer than they thought. One of them being story B turned out to be much bigger than they thought.

They take an action item to break stories smaller so that this problem does not happen again. The Scrum Master erases all content in the room except the one action item that they took. 

This sprint ends.