The Problem with Precision

Last Updated on Saturday, 17 December 2011 03:02 Written by Mike Cottmeyer Thursday, 22 December 2011 05:00

I think engineers are interesting people… especially software engineers. Given what I do for a living, I get to work with a lot of software companies, and that means I get to spend time with a lot of software engineers. If you spend enough time, in enough software companies, with enough software engineers, some patterns start to emerge.

One of the patterns that I see quite a bit is that software engineers like things to be really precise. Being precise is a good quality for software engineers… it helps them build software that doesn’t break. Sometimes broken software kills people. The problem with being precise, is that it sometimes creates a tendency to want to know everything before we are willing to do anything.

Sometimes the level of precision necessary to build a system isn’t the same level of precision necessary to understand requirements, or to do a high-level design, or to estimate a project, or to know when a system is going to be done. Sometimes directionally correct is good enough. I realize that knowing the difference is a big deal and I’m not minimizing that.

I think though that recognizing this tendency is an important first step to making progress… and not letting that innate need for precision prevent us from taking those first critical steps forward. For many problems… understanding the requirements, or the design, or the estimate, or the date in a directionally correct way is good enough.

Once we get close enough, we can make trade-offs to the requirements, or the design, or the estimate, or even the date to make sure we can deliver what needs to be delivered. Precision isn’t always necessary to start… sometimes directionally correct is good enough.  Sometimes directionally correct is all we’ve got, and maybe even all we are ever going to have.

Kanban Isn’t the Answer to Bad Product Ownership

Last Updated on Saturday, 17 December 2011 03:27 Written by Mike Cottmeyer Tuesday, 20 December 2011 05:34

The Scrum Product Owner has a tough job. Translating business strategy into product strategy and ultimately into teeny-tiny user stories takes a ton of time and effort. Most Product Managers don’t have the time or inclination to be a good Product Owner and most Business Analysts, the people most likely to fill the gap, don’t actually own the product. I almost always recommend to my clients that a team of people work together to fill this role. I don’t really care about the whole ‘single wringable neck’ thing… all I want is well groomed prioritized product backlog, and I think there is more than one way we can get there.

Here is the deal… when teams can’t get well groomed product backlog, it is almost impossible to do Scrum. Teams spend too much time figuring out what to build during sprint planning and not enough time figuring out how to build it. Because teams don’t know how to build the stories, they never really consider if the stories were estimable, nor really discuss how they could swarm to get the stories done earlier in the sprint. This will often result in teams of people that don’t work as teams, daily standup meetings that suck, and missed commitment after missed commitment. Not fun.

Anyway… as Kanban gains popularity and mindshare, many folks think that going iteration-less is the answer. If we can’t get user stories that are small enough to deliver a handful of them in a sprint, and we are always missing our sprint commitments, the problem must be with the time-box itself.  If the time-box has no value… it’s unnecessary…. it’s waste and needs to be eliminated. Maybe what we need to do is just take these big chunks of undefined requirements, run them through a Kanban, and just forget about splitting stories and managing iteration boundaries and totally avoid the issue altogether.

I’m all for eliminating waste, but let me ask you this… how does an iteration-less approach better help us know when we are going to be done?

Like it or not, this whole done thing is going to keep being a thorn in our side.  It’s not going to go away anytime soon. I think people are hardwired to want to know what they are going to get for their money before they agree to spend it. Some of us desperately want this to change, and maybe it will change as business models change, but for now we have to deal with it. I know, I know… if our customers would get out of the way, just let us code, and stop asking what they are going to get for their money, life would be a whole lot simpler.  I get it… it’s just not reality.  At least not my reality.

Okay, back to Kanban… Kanban can answer the ‘what are going to get for our investment’ question just as well as Scrum can. Scrum answers the done question by having us know the size of our backlog and the rate at which the team can complete that backlog, in other words, our velocity. When we know both of these variables we know what we are going to get, when we are going to get it, and we have a way to communicate project status. Kanban doesn’t use velocity, but instead measures cycle time and standard deviation to help us figure out what we can deliver and when.

In Kanban, we still have a queue of necessary features, but rather than measure our velocity sprint to sprint, we measure how long different sized stories take to complete and how much variation we have in that number over time… that’s cycle time and standard deviation. When we know the size of all the items in the backlog, and the normal variation of all the items in the backlog, we can use that data figure out when we are going to be done and what we can deliver in any given timeframe.  That’s good… there lot’s of ways to answer the done question… we just need one of them.

So, we’ve gotten rid of the time-box, but have we actually solved our problem with predictable delivery?  For Kanban to be predictable, we need know the rate at which we deliver requirements, and reduce the variability between the requirements over time. Let’s ask this though… if we don’t know really understand what it takes to build the requirements in our backlog, are we going to know our rate of delivery?  What about our standard deviation? It’s going to be all over the place.  Unless we know something about what we are building and how we are going to build it our delivery process won’t be any more predictable that if we were using Scrum.

I’d suggest that in both Kanban AND Scrum… to increase flow and reduce variation… we break things down into smaller more similarly sized and well understood work items.  In short, the same things that break Scrum are the same thing that breaks Kanban. And therein lies the problem… If we have to answer that pesky done question… we have to break things up small enough that we can tease out the risk and uncertainty, make fine grained trade-offs, and all get on the same page about what we are going to build. Kanban can solve lot’s of problems… and I believe we don’t even yet fully recognize the importance of David Anderson’s contribution… but here is my belief…

Kanban isn’t the answer to poor Product Ownership.

E is for Estimable

Last Updated on Wednesday, 14 December 2011 05:13 Written by Mike Cottmeyer Thursday, 15 December 2011 06:00

I’ve been a big fan of Bill Wake’s INVEST model since I first learned about it through Mike Cohn’s book on user stories. Like every other agile blogger out there, I’ve shared my take on these principles and what they mean for product owners writing good agile requirements. The more I teach these concepts though, the more I find myself spending a little extra time talking about what it means for a story to be estimable.

On the surface, the notion of estimable seems pretty clear. In order for a story to be ready for a sprint, the team has to be able to determine what it’s going to take to build it. They have to be able to give an estimate. Why is the ability to put an estimate on the story so important? Well… if the team does’t know what the story is going to take to build, they don’t know if they can get it done by the end of the sprint.  If they don’t know how big it is, they can’t make a commitment to build it.

If the team cannot consistently make and meet commitments then velocity never stabilizes. When velocity isn’t stable, teams aren’t predictable delivering sprints. When teams aren’t predictable delivering sprints, we have no idea what we can deliver releases. When we don’t know what it takes to deliver a release, roadmaps fall apart and we have no ability to plan forward. In multi-team environments, this is catastrophic because the teams get out of sync and no one is able to deliver an integrated product.

But wait, we have an answer for fixing a story when a story is not estimateable… all we have to do is put in a spike! What’s a spike you ask? Usually I explain a spike as an investment the Product Owner makes to figure out exactly what needs to be built and how the team is going to build it. The Product Owner allocates a little bit of the teams capacity now, ahead of when the story needs to be delivered, so that when the story comes into the sprint, the team knows what to do.

In other words… its an investment to make the story estimable.

Here’s the deal with spikes though… spikes represent risk. Spikes represent uncertainty. If our backlog is full of spikes, that means that our backlog is full of stuff we don’t know how to do. If our backlog is full of stuff we don’t know how to do… that means that our product delivery process isn’t stable. It means that we have no business making commitments at the product level, or even at the release level, because we don’t have a credible plan for getting to done.

One of the things I’ve been talking a lot about lately with my clients… and plan to talk more about here over the next few months… is the idea that the only way to make better estimates, the only way to deliver releases on time and with a reasonable approximation of the scope expected… is to remove risk and uncertainty from what we are building. Removing risk and uncertainty involves doing one of two things: buffering for the unknown or mitigating risk ahead of time.

Buffering for the unknown is always a good idea… but mitigating risk and uncertainty is something that we don’t talk much about. If I want to reduce risk in a sprint, I pull some work forward to do the discovery before I am asked to make a commitment. If I want to reduce risk in a release, I pull some work forward to do the discovery before I am asked to make the commitment. If I want to reduce risk in a project, that means that I pull some work forward to do the discovery before I am asked to make a commitment.

All I’m really saying here is that we need to extend the spike metaphor beyond the level of user stories and sprints and up to the level of features, epics, releases, projects, and products. The more we need to be certain, the more we need to invest (no pun intended) up front to figure out how to build what it is we plan to build. Now, lest you think I am making the case for waterfall… all this is done in the context of small batches, doing just enough just in time, rolling wave planning, and progressive elaboration.

Agile methods accept the fact that some things are going to change… but that doesn’t mean EVERYTHING is going to change. I think it is fair for us to look far enough ahead to have some idea of where we are going, some idea of what we might want to build the next release, and some idea of the risks involved moving our product forward. Sometimes a little bit of planning, at the right level of abstraction, can help us make the case that we need to spend some time in this release getting ready for the next release.

At the end of the day, it all comes down to your context…

If you need to have a stable predictable product delivery process that can reliably look 6 months or so out… I think this kind of an approach is your only option, especially if your team is building a bunch of stuff they don’t know how to build. If your business is content figuring out your product strategy 2 weeks at a time… if a 4 to 6 week planning horizon is sufficient to make your customers happy… feel free to ignore this advice. Most Product Managers I talk to want  to commit at least a quarter out… most want 6 to 9 months.

Putting your product desires on a roadmap is not a strategy. Committing to things that you have no idea you can deliver is not a strategy. Asking the business to throw money at you on the promise we’ll do the best we can do and you’ll get what you get when the money runs out isn’t a strategy. Coming up with a credible plan, proactively mitigating risk, making trade-offs daily, and proactively managing your delivery is what makes your roadmap a reality.

So… next time you are committing to a sprint plan or a release plan… the next time you are laying out a product roadmap and making commitments to the business… ask yourself if the work is estimable. If it isn’t estimable, and you have no idea what it takes to get the work done, then you are assuming a ton of risk for yourself and asking your business to do the same.  In some contexts, some of the time, that is a perfectly fine strategy… just make sure you are intentional about what you are trying to accomplish.

If figuring it out as you go isn’t part of the plan… remember that E is for estimable and act accordingly. 

Winding Down 2011… Nearing Blog Post 400

Last Updated on Monday, 12 December 2011 01:53 Written by Mike Cottmeyer Tuesday, 13 December 2011 05:00

As LeadingAgile nears its 400th blog post… it’s interesting to look back and see, not only how my writing has evolved and matured over the past 4 or 5 years, but also the kinds of topics I’ve chosen to write about. It’s an interesting study of what’s been important to me professionally and how my thinking on this stuff has emerged during this time.

I started LeadingAgile back when I was working for CheckFree, just before it was acquired by Fiserv. Like many folks that are heads down working in companies, it’s tough to write… not just because you have an all consuming day job and a family to raise, but because all your really interesting stories are about the people you work with everyday… you have to be careful.

It wasn’t until I started working for VersionOne that writing became a big part of my life. I remember talking with Ian Culling one day and realizing that blogging could actually be part of my day job. Not only did I have license to write, VersionOne provided a ready made audience for my work and allowed me a platform to really grow as an author. There are lot’s of things about VersionOne I am thankful for, and that was one of them.

Another great thing about VersionOne was having the privilege to work with somewhere around 100 companies over the two years I was there. It was fascinating to take my experiences as a company guy and vet them against so many different organizations in such a short period of time. It was like getting a lifetime of experience in just a few years. All of that experience really helped shape my views on what it takes to adopt agile practices and transform a company into an agile organization.

I’m not sure if I’ve ever explicitly stated this over the years I’ve been writing… but I’ve never really looked at my posts as a means to share what I know… they’ve been more a way to explore and share what I’m learning. Writing is a great way to sharpen your thinking and really helps refine and simplify your messaging. It’s the only way I know to teach yourself how to talk about this stuff. If you write your thoughts down they are in you. They are more readily available to share with others.

One of the themes that has emerged from my writing is that I seem to care less about how to solve problems and more about making sure we are solving the right problems. In large part, I am methodology agnostic. Of course I tend toward lighter weight agile methods, but I’ve never been a Scrum guy or an XP guy or a Kanban guy. I tend to be more pragmatic and open to using anything I can to make stuff work.

I find in my work that most people are solving the wrong problem or they are just thinking about the right problems the wrong way. Helping people solve the right problems and think about problems the right way is what I’m all about. It’s interesting to me how often my posts are more about trying to clearly articulate what’s wrong rather than offering some sort of solution. I’ve felt guilty about that over the years, but process isn’t rocket science. Figuring how to apply methodology to specific problems is much more interesting.

Another thing that’s been on my mind lately is the frequency with which I’m writing. I’ve been on the cusp of 400 posts for way too long now. The past few years have been pretty disruptive for me… not bad disruptive… but it’s been very difficult to get in a groove or to establish any kind of habits or patterns. For me, writing has to be a habit… it has to be a routine… and the demands of building a business have just blown that out of the water. Probably just an excuse, but something that’s been on my mind lately.

I’ve always written about the problems I was trying to solve and the kinds of thinking tools that I was using to solve them. It’s interesting, but my biggest challenges over the past two years haven’t been really related to agile. My biggest challenges have been around building a business and selling work. I’m actually surprised by how much I like that side of LeadingAgile, LLC. I love coaching and working with clients, but the organizational side of my own company is equally as compelling.

I been giving some thought to using LeadingAgile as a platform to write about some of the stuff I’ve learned over the past few years building a business and learning to sell. I’m not sure that writing about sales would be a great way to drum up new business, but I bet there might be some other coaches out there that might appreciate some candid lessons learned about selling work. Honestly, I don’t know, but that’s something I want to give serious consideration. Maybe I’ll just give it a shot and see what kind of reaction I get.

If you’ve made it this far into the post… thanks for sticking around. I’ve got a few more introspective posts I want to do before the end of the year. I’ve been meaning to write an appreciations post for a while now. I’ve been on an amazing run the past 18 months and I’m becoming ever more aware and ever more appreciative for the people that have helped me get here… I’m living the dream right now and I think there are some folks that deserve thanks for helping me along the way. I also plan to do my usual annual retrospective and talk about some of my plans for 2012.

Finally, I’ve been doing a bunch of consulting and teaching and thinking around this multi-tier program and portfolio management stuff and I’ve got to find a way to get some of these ideas on paper (electronic paper at least). I might be to the point where the components of this emerging approach are clear enough to talk about coherently. This is another thing where I just need to get off my ass and write. It won’t be perfect getting there, but then again… LeadingAgile has never been about publishing perfect thought.

How to Think About Estimating

Last Updated on Sunday, 11 December 2011 02:26 Written by Mike Cottmeyer Sunday, 11 December 2011 02:21

Sometimes we get wrapped around the axle about estimating. People ask why we should bother estimating when we know that our estimates are always wrong. Some folks go so far as to say that all estimating is waste and we shouldn’t estimate anything ever.

A couple of posts ago I made the case that the real reason for estimating is to create shared understanding around what we are going to build and how we are going to build it. My point was that it wasn’t so much the number that was important, it was the process of getting to the number that was important.  You should check out the post, it generated a ton of great discussion.

While I still believe that estimating is primarily about creating shared understanding, I don’t think that post went far enough. Yes, we need shared understanding, but let’s get real… our customers need to know how much something is going to cost and when they are going to get it.

It all comes down to time and money… and what I am going to get for my time and money. What am I getting for my investment.

We’ve come a long way over the last 20 years understanding how to estimate. We seem to have learned that no amount of up front planning ever really makes better estimates. We seem to be getting better at deferring decisions and estimating closer to when the actual work will get completed.  All good stuff, but have our estimates really improved? Are we delivering on time and on budget more often?

Rather than give up on estimating, I want to introduce a new way of thinking about estimates. You see… we seem to think that an estimate is supposed to tell us exactly what it will take to deliver what’s being estimated. I believe that estimates are just supposed to get us close.  Estimates have to get us close enough that we have a shot. Once we are close enough to have a shot, we have to manage the hell out of the work to make the estimate real.

In other words, once we are close… estimates are no longer estimates… they are budgets.

Let’s say I bring a user story into a sprint and that user story is expected to take three points. Assuming we have a stable team, the team should have a general idea of how long a three point story will take to deliver. At the moment that three point user story is in the sprint… at the moment we have made the sprint commitment… we now have a three point budget to get it done.

With our three point budget in hand, it is now up to the team to work with the product owner to negotiate the implementation of the story to make it three points. It is up to the team to implement the simplest thing that could possibly work to make the story three points. It is up to the team to manage impediments and dependencies to make the story three points.

Delivering on time and on budget is not an accident… it is an act of will.  It’s a process of actively managing the implementation of whatever we are delivering to make the budget and schedule a reality.

Only at the point we learn our estimate wasn’t even close, only when we have learned that delivering something of value just isn’t possible, do we even get to consider slipping time or cost.  That said, if our budget was that far off, I’d say we have a bigger problem with how we estimated, how we generated shared understanding, and how we dealt with risk… but that is a series of discussions for another post.