Leading Indicators in Agile

Often in the world of project management, even the most experienced project managers occasionally get caught with their “pants down”.  How does that happen to even the best leaders?  Usually it involves people and their lack of communication within and beyond the team.

So how does a project manager minimize the odds of getting surprised?  Well surprises will always occur, but finding about them quickly and addressing their root causes efficiently is the behavior that is needed.  The key description heard throughout the industry is “communicate”.  We (ScrumMasters / Project Managers) hear it all the time: “Must be an excellent communicator…”  “Be an Information Radiator”, “Effective at delivering the right message”.  As one study conducted by the South Illinois University Edwardsville states, communication is the top skill to possess: http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1491&context=amcis2013

Well, communication will help manage those quite team members that may be hiding a potential land mine, but how does that communication get delivered to top leaders that don’t speak with the ScrumMaster?  My solution involves Leading Indicators.

This is a recommendation to test out the measuring of new metrics to help determine if a project is heading the wrong way before the standard metrics of schedule, budget, scope, value and quality hit into the red status.

Consider the following leading indicators:

  • Happiness (team level)
  • Code check in Ratings
  • Staff changes
  • Average overtime worked
  • Active Issues
  • Active Risks (see my article on Risk Burn Down)

These metrics can really help identify if your project is heading in the wrong direction.  My thoughts are that the process of collecting these metrics brings out the true health of the project.  Leave “no person unturned” and ensure your entire team has their input or have a delegate obtain that input for larger delivery teams.

From my experience of collecting these metrics, make sure the process is as automated as possible and that it doesn’t burden the delivery teams too much to obtain.  I find the cadence of doing once during the middle of a sprint usually works best.

Also, recommend normalizing the results so that impacts are equally noticeable for each metric.  For instance, if you are measuring happiness, set to zero if everyone is very happy and scale up if the team is very unhappy.  If you are measuring overtime, scale at a similar level to show the impact.  This is where the subjectivity comes in and would recommend having agreement by the project sponsor on how the scales should be measured.  For instance, should losing a key team member be the same weight as an unhappy team?  Should working 10 hours a week have the same impact as an average poor code check-in ratings?

Leading indicator scale

When experimenting with new ways to improve communication as reduce the risk of having an ugly project, leading indicators may yield beneficial results.  However, every project is unique and you should determine by experience or by trial whether leading indicators will help improve your delivery quality.


Published by Agile Mike

“Agile Mike” has over 25 years of experience with software development and product leadership. He is published under the “Built for Success” column in CIO.com magazine and held the position of Vice President in the Agile Leadership Network. Michael has taught multiple SAFe courses for over the past three years to over 400 people and is currently an Enterprise Agile Coach at Lean Agile Enterprises and a certified SAFe SPC5, AWS Cloud Architect, Scrum CSP, and PMP.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: