The Impact of Agile Quantified

Turns out, Rally has been collecting some very useful data!  Have a look!

Traditional Project Management vs. Agile Project Management: Week 7

How the heck are you supposed to have an up-to-date status of your team’s needs, let alone an up-to-date status of project progress? 

As of last week, we have twice-a-week scrums on Tuesdays and Thursdays.  I can glean only a smattering of what the team is working on at these meetings since said meetings seem to morph into I-have-a-problem or I-can-help-you meetings.  This format is actually great for this team since they aren't communicating otherwise.  I see very little email traffic.  I hear very little of anything, really, and I find that I’m pulling information from reluctant teammates.  I pushed for a daily scrum, but many people – including my project sponsor – balked at that idea. 

So in light of the fact that I was not having any daily meetings until last week (sort of), I resorted to using the weekly status meeting that the project sponsor set up.  I asked how I thought we were tracking and then asked about blocking issues.  To my surprise, the project sponsor wanted these meetings to be about the PM (me) reporting to the team how things were going.  I find this very limited, and I end up getting updates from the team anyway. 

I’m learning that Traditional Project Management is more about going to each person on the team – daily, if need be – and asking them how they’re doing or where they’re at.  While this can be great from a relational standpoint, it can also be detrimental.  The PM eventually becomes a pest in the eyes of his/her teammates instead of being a trusted source of roadblock-removal.   In an environment like the one I’m in, the fact that these teammates are matrixed resources who are far too overloaded doesn't help me when I have to ask them about the status of the project for which I am responsible.  They are not happy to see me, so this immediately drives a wedge between us that is sometimes difficult to pry loose. 

Gathering status one teammate at a time is also a waste.  By the time I get status from everyone, the status of the first person I talked to has changed.  Also, if I hear of roadblocks, then I have to bounce around from person to person to see if I can clear the roadblock before it becomes an issue.  This is why I think daily scrums are so valuable.  We can get everything out of the way all at once and keep the team moving forward one day at a time.    

Don’t even get me started about the tools we’re using to track progress.  We have a very high level project schedule in Smartsheet.  If you aren't familiar, Smartsheet is an MS Project clone that is all online.  We then have a “test control sheet” that lists high level test case names.  (Remember my post a few weeks ago pondering the reasons why I, as a PM, was required to put together a test plan?  Yeah, this “control sheet” was the end result of that.)  On top of the “control sheet,” we have test scripts and individual test plans we’re updating.  I have to peruse all these places to see where things are and then somehow keep track of it.  I've created a private Trello board just to keep all of this straight.  I would much prefer that we had everything tasked out… user stories… something!  This is what we have, though, and I have to work with it.

While I think Traditional Project Management definitely has its place, in the software world, Agile is a much more efficient way of getting things done.   

Agile Metrics: Be careful what you ask for

Albert Einstein once said, "Not everything that can be counted counts, and not everything that counts can be counted."  Ain’t that the truth? 

When looking at agile projects, there are a few very obvious ways to track team progress.  You can look at sprint and release burndowns, velocity charts, cumulative flows, etc.  However, what the business needs to ask itself is what it really wants from agile metrics, and it needs to be prepared to get what it asks for.   

 

There are many examples in which companies have set certain metrics that gleaned disastrous results.  There is one example in particular that seems to resonate the most, though.  A company once set the metric that the developers that found the most defects during code reviews would get extra “incentives”.  You can imagine what happened.  These developers wrote bad code, found bad code, and then collected the incentives.  The phrase “I’m gonna code myself a minivan” has its origins in this example. 

We can all agree that this was NOT the company’s intention.  Not in the slightest.  Yet, the company got what it asked for, yes?  So the company needs to ask the hard hitting question as to what it wants to measure and what it will mean.  Here’s a breakdown as to which metrics are for team use and which are for business use.

Velocity

Measuring the velocity of a sprint should be a metric to help the team.  Why?  Because velocity is all about estimating, and the team needs to become great at estimating.  Once a team has a few sprints under their belt, they can better estimate for the business how long certain projects will take.   Why would it be a bad idea for the business to harp on this metric?  Because the team will worry about how much they get done (quantity) and not what they get done (quality/priorities).  

Burndowns (Sprint and Release)

Again, this is another metric for the team.  This helps them gauge how well their tasks are progressing in relation to overall remaining work.  I think this is for both the team and the business, but again the business must be careful how it uses this data.  Every team is different.  Some teams hit the ground running and deliver daily.  Other teams take a little while to get traction, but they still meet their goals and deliver on time.   If you must draw a line, then do so between Sprint Burndowns and Release Burndowns.  The Sprint burndowns are more for the team to help them adjust on a micro level.  Release Burndowns are for the company so it can adjust on a macro level.   Again, if the business focuses on this metric, the teams will worry more about quantity rather than quality.   

  

Cumulative Flow

This chart is a more visual way to show what the team has finished in comparison to what is still left to do.  This is valuable for the team, but on a macro level, this is very valuable for the business when looking at product dependencies and delivery dates.   

Value Delivered

This isn’t as obvious as the cold hard numbers you can collect from velocity or burndown charts.  This one is a bit more subjective since the business needs to rank stories based on business value.  However when implemented effectively, this metric can provide a ton of value for the business.  This metric promotes value, not quantity, and in the end, customers want value. 

Time to Customer

Another valuable metric for the business is measuring the time it takes to deliver a product to the customer.  If a business can track how long it takes teams to deliver value, then it can better predict product launches and business costs.  This could get out of hand if the business pushes getting as much done as possible in any given timeframe.  Quality can seriously take a hit if value isn’t also encouraged. 

These are just a few ways to measure work in an agile environment.  There are many more that deserve a lot more discussion.  In the meantime, what do you think is valuable and how would you use it to satisfy  business needs?