Wednesday, April 30, 2014

How Transparent Are You?

I had the good fortune to attend Mile High Agile this year.  It was held on April 18th at the Downtown Denver Marriott, and it was a packed house!  The company I work for as a consultant, Sogeti, was a Gold Sponsor, so I had the opportunity to attend the conference and rub shoulders with some industry experts.  I attend some great seminars, shared some thoughts, and learned quite a bit.  Not too shabby for a day’s work, right?

Of course I attended the keynote this year: The Future of Agile (If There is Any) by Robert “Uncle Bob” Martin.  He had a lot of insight, and it was very eye-opening to hear from one of the people who actually crafted the agile manifesto in Snowbird, Utah in 2001.  He said a lot of things (including mapping out the history of the world on the breadth of his arm span), but one thing that really resonated with me was transparency.   

“Uncle Bob” said that the whole meaning behind what the folks in Snowbird meant to convey was transparency.  He spoke of the disconnect between businesses and the people doing the heavy lifting (i.e. developers and testers).  That disconnect created distrust because neither side could see what the other was really doing.  As a result, they didn’t trust each other.  Developers and testers were held to “estimates” as if those estimates were written in stone, so they fudged their numbers.  Business folks expected them to fudge so they didn’t share all the information with them (like the big picture). 

I wrote all of that in past tense, but really, do we see anything different today?  That chasm between business folks and developer/tester folks still exists.  I think we have some bridges across it now, and by using agile practices, we can certainly build more.

Mr. Martin also went on to illustrate this disconnect in terms of training being offered and in terms of percentages of people who attend conferences like Mile High Agile.  Of the folks at the conference, a very large percentage of them were managers of some sort (project managers, scrum masters, agile coaches, etc.).  A much smaller percentage were developers and/or testers – the technical types.   Daniel Lynn illustrated this pretty well in one of his recent blog posts on Coyote Agile.  Go check it out

So how do we fix this?  I think the first step is to ask ourselves this question: How transparent are we?  I’ve asked this question about a good many places I’ve worked, and as can be expected, some companies have been more transparent than others.  Here are a few of the transparent practices I most appreciated:

On Projects / In Teams
  • Regularly communicate status
  • Regularly solicit feedback
  • Regularly schedule demos of ongoing work
  • Promptly raise roadblocks
  • Publicly share successes
  • Regular communication about work in the form of Daily stand-ups
  • Managers communicate regularly with direct reports (one-on-one meetings are best, but even regular check-in emails are better than nothing)
  • Direct reports solicit feedback from managers and customers (both internal and external)
  • Publicly post/relate team progress

In Departments/Business Units
  • Regular communication from Directors/Executives to convey the big picture
  • Directors/Executives share timely, pertinent information
  • Directors/Executives Publicly celebrate successes, no matter how small

While most of this revolves around communication, there are many other ways we can be transparent.  What are some of your suggestions?

Thursday, April 24, 2014

Favorite Agile Tweet of the Day

This blog post resonated with me.

Wednesday, April 16, 2014

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.

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?

Favorite Agile Tweet of the Day

What do you think? As a scrum master, I most certainly agree.