Start Agile coaching with a business value goal

When I first got into Agile coaching I had just become a convert.  In fact I’d been a skeptic of Agile for many years having only seen “agile” shops that were anything but Agile.  These shops used the agile name to rationalize their no planning just code model.  As you might expect, they wasted incredible amounts of company money producing very little of any value.  They all talked about agile being better because it didn’t waste time on functional requirements specifications.  But I had been running successful projects for 30 years creating fairly detailed project specifications yet their “better way” was failing.  But Agile continued to win converts.  There had to be something more there.  So I decided to take an Agile course.  Robert Annis was my instructor and over the course of the next three days I was blown away by how different real Agile was from everything I’d seen out in the field.  Yes, I found, there was planning, plenty of it.  I also saw the value of “right time” planning.  We had done plenty of that along the way on our other successful projects but it was always after the big weeks or months of functional requirements specifications.

So I got out of the class a convert and started using Agile in the field.  My first big opportunity came when a friend of mine, Peter Sauer had a need for some coaching for his team.  As a new coach I offered to do it for free to find out if I could navigate the waters.  He accepted and then we did something that was key to the success we achieved.  We set a business value goal for the effort, not an Agile learning goal.  Our goal was in 3 months he would have a development schedule that he could depend on because the team was delivering reliably on a set of estimated items.  We did not say things like, the team will understand the value of stand ups, or planning poker, or retrospectives or any of the things that were necessary to achieve the goal.  The business goal was measurable and I hoped achievable.

The team really didn’t know Agile or Scrum when we started but they were receptive.  As we moved through the process having the goal was instrumental for me in remaining focused.  I brought in new ideas as needed to achieve the goal. Things that occurred that didn’t really stand in the way of the goal could be left for later.  Things that did not occur that were going to risk the goal were things I could focus on very strongly.

For instance there was a resistance to the estimating with Story Points.  The product owner, Peter, was having trouble seeing the benefit vs the time it was taking.  The team thought they were having trouble estimating relative size, even though they were doing a pretty good job as it turned out.  It wasn’t so much estimating in hours, story points or ideal days that was the issue for Peter, he was not yet seeing the value compared to the time it took away from programming.  We pushed through because it was imperative that we had some form of estimating relative size in order to achieve the goal.  About the 4th sprint it came together enough for the whole team and P.O. to see the value.   It was very exciting to watch and without the primary goal to keep us focused I’m not sure we would have had the success we did.

The end result actually took more like 4 months and Peter now has a good idea when things will be delivered.  He likes seeing the incremental deliveries and he has already released some of the functionality that will be in the complete end product.  The goal was achieved.