The First Rule of Holes
At some point someone made a promise. Now the team is in a bad position and struggling hard to meet the deadlines of the original plan.
I’ve been in that position more than once, and as a Scrum Master I have used the same strategy:
- Working with the customer to lower expectations and make the plan more aligned with reality.
- Find more time for the team to do its work.
The second part would make me cancel everything not immediately helping the team accomplishing its short-term goals. The retrospective meetings were always the first thing that went out the window, and I felt like I was helping the team by doing it.
That was before the first rule of holes was brought to my attention (by Henrik Kniberg).
The first rule of holes: When you’re in one stop digging.
That wonderful quote by Molly Ivins really got me thinking. To bring a derailed train back on track, the solution is not to make the engines run faster. Instead we need to make a careful evaluation of the situation, and find solutions that will help us achieve the end goal of getting the passengers and cargo reach its destination on time.
In software development terms, when the going gets tough, we need our retrospectives the most.
Another way I’ve violated the first rule of holes is the thing I wrote about in my previous post. Although I know that automated tests is one of the best ways to increase productivity, I came up with all sorts of excuses why “it wasn’t for us”. So, I’ve let my teams dig deeper holes and making a bad situation worse.
Yet another common violation is the building up of technical debt. We’re so busy digging for new features that we forget that we have to be able to ascend from the pit. We need to stop digging and clean the small messes before they become drainers of effort.
What holes have you created or ended up in? What did you do about it? I’d love to hear your stories.
Cheers!
The problem, as I’ve always seen it, is that the clients want a fixed price, but the programmers are unable to pin down the work exactly, and hate overcharging. Also, often overcharging causes the clients to move on to someone else, so there is a culture of having to promise more stuff for less money (or time), just to get the chance to be allowed to build it.
A while back I figured out a way around this. Phases. You just keep promising whatever the client wants, but you get tentative about which phase it is going to appear in. “We can do that for you, but it might be in phase 3”. And to give the clients their fixed price, you simply set a fixed price per phase (and you give the developers a fixed date for each release).
For each phase, you schedule a number of changes that ‘have’ to be there, and a number that ‘may’ be there. It’s nice to leave some slack beyond the mandatory work, so that most of the time you over-deliver with some of the optional stuff.
As you’re coming up to a release date, you ‘freeze’ and rollback any uncompleted changes (no exceptions). Between the freeze and the release, any scope increases are chucked to the next phase, or beyond (I like to chuck things that I don’t want to do out to phases like 10,232 🙂
At the begging of each new phase, you schedule in an initial cleanup/refactoring period (which also helps to fill the time while the clients argue over priorities), so you keep aggressively paying down the debt (and it helps warm up for a another round of coding).
In this way, sometimes you’ll have to push a bit to get out of the mandatory stuff as soon as possible in the middle of the phase, but if fatigue has set in (from previous phases), you have the option to coast a bit.
Since the clients aren’t getting hit with unexpected bills, and mostly you’re over-delivering, everybody is happy (well, as happy as they are ever going to be with software). When they get pushy about having to get things done right away, you can say “sure, but we’ll have to move X to the next phase”. That makes the costs immediately apparent to them, while allowing some procrastination to slip in (some things stay on the ‘later phase’ list perpetually). If they stomp their feet, then the phase is extended, and so is the bill (but its far better to fight hard to avoid this, since it works out to ‘morale debt’).
Then the only hard bit is trying to get a reasonable handle on the estimates for work. It’s possible, but its not an easy skill to master, although it does get easier as the project progresses (the unknowns decrease naturally iff the technical debt isn’t piling up).
Paul.
@Paul W. Homer
Hi Paul,
the thing you describe sounds to me like a traditional project done well. Still, it has the inheritent problem of fixed price and fixed scope combination (although divided into smaller chunks, or phases, which are easier to handle and estimate)
One problem is, depending on the severity of your competition, you’re forced to lower your margins and the slack you’re talking about won’t happen in reality.
I prefer the agile take on this. As a product owner you:
* may fix price (and time) or you may fix scope, but not both.
* decide the order in which the system is built.
* get the system delivered in working increments so that you get continuous feedback on your investment, and with the help of this information can help steer the project in the direction you want.
* may cancel the project at any time and still have the best system possible for the money spent so far.
Still, we need to provide good estimates. And estimates, as you point out, are hard and takes experience.
@Hans-Eric
Yes, I’m only half Agile at best. 🙂
I agree with your four points and they actually fit well with what I am saying*, but with one difference. Generally I’ve been fortunate enough have been the product owner as well as the architect, analyst and lead programmer. Luck not withstanding, I think software projects should be ‘controlled’ by software developers, not domain experts, stakeholders, or business people. We are after all, the experts in what we do (some of us at least 🙂
There are appropriate times were the technological choices have to take a backseat to the business ones, but I always found that balancing that mix was better handled by a technical person with some business sense, than by a business person with some technical sense.
*fixing scope is possible, but it’s a hard sell. You need a client with deep pockets.
For me, I say ‘phases’ to the clients and ‘iterations’ to the developers, and then don’t insist on a one-to-one mapping. Short iterations bump up the cost, but reduce the risk. Phases help one negotiate with the clients in a way that they appreciate. There is often multiple iterations within a phase.
Getting back to your post, lowering expectations can have severe long term consequences with the clients, while pushing the coders into overdrive will cause morale and fatigue problems. It’s best to avoid that hole as early as possible, since neither answer will make you happy.
As for margins, when you’re the new guy on the block, the only way to get your foot into the door is to over-promise and suffer low or negative margins. Skilled entrepreneurs generally don’t let this bother them, the trick is knowing when to switch over after you’ve gotten out of the hole. That is, initially you start with negative slack (and lots of excuses for why you are late), but once your foot is in the door you switch tactics (quietly and slowly) and start building in slack. While that is a necessity for a startup, I’ve also successfully applied it in large companies as well. Still, that type of strategy is clearly on the domain side, and those in charge should know how to insulate the technical people from it as much as possible. The game of keeping a project going is very different from the game of actually building it. One is sales and politics, while the other is (or should be) engineering.
Paul.
@Paul W. Homer
You touch one interesting point there: the role of the product owner. It is probably the most important support role, and done well it can be the difference between success and failure.
(I call it a support role because that’s the way I look upon IT projects: The developers are the most important asset. Without developers no developing. The rest of us, be it architects, Scrum Masters, Project Managers, testers, coffee ladies – you name it – are there so that developers can spend as much time as possible developing.)
I don’t think that a technical person generally is better than a non-technical as a product owner. I have seen many technical-driven projects, and the results are usually poor. Many important decisions are made based on technology, when they should be based on user experience and business value. With that said, I have yet to see a business person make a good product owner. But I think that can be changed with a shift of paradigm, once the companies realize that the best way to protect their IT investments is to have their people “on-board”. And of course, with education.
***
Your comment on margins conforms with my experience as well. But I think that all those “excuses for why you are late” (Been there, done that) haven’t helped the trust between our parties. 🙂
I definitely agree, purely technical people focus too much on the underlying technical problems, and thus they often loose big at the business level. Basically they optimize for the long term (lack of technical debt), and fail in the short. Business people on the other hand reverse the issue. They keep piling up technical debt because everything they do is short-term thinking. Neither side wins, which likely explains why our industry is so plagued with failures.
To get the best trade-offs you need to have a good understanding of both sides, and what they need for success, and be able to walk the middle. It’s a rare skill set, because they are diametrically opposed. A good business choice is often a bad (and unpopular) technical one and vice versa. There are ‘hybrids’ out there, but for the most part they’re unappreciated. Pure business people are suspicious of someone with some technical skill, while programmers are suspicious of someone with business savvy (and generally they think their rigidly logical worldview is superior anyways). I think it’ll stay this way for quite a while.
I agree about the trust issue. For me, I accept those types of problems as a consequence of getting my foot into the door, but then I move rapidly to try and repair the situation. Also, I’ve learn that ‘excuses’ (being mostly defensive) are not appreciated even if you think you’re being honest or straightforward, so I almost never present them to clients. Instead I’ll just say something like “we moved the date back a month, but it’s not going to cost you extra”. You end up giving more away for free, but you don’t sound defensive and you’ve moved the issue away from being late. Experience entrepreneurs are masters of this, since it happens on a regular basis, and I was lucky enough to spend some time hanging out with some.
A couple of more points. If you’re going to be late by two weeks, ask for a month. Going back twice is fatal, and your lateness was already caused by your lack of understanding (in some area), so build in some slack. And, if you’re going to present an option to a client, always present three options, no more, no less. Honestly, I don’t know why this works, but for some reason it does (at first I resisted this, because it seemed silly, but strangely I think giving people a choice somewhat softens their expectations. Often I’ll pick two other choices that I’m certain the clients won’t go for, so I’ll still get them to do what I want, but it will seem as if they decided on their own). And the biggest point: business is irrational OK, it’s not, but it is from a techie’s point of view. The worst thing a techie can do is construct some type of logical explanation for business, and then expect it to work that way (it never does). Treating it as being irrational helps to avoid making bad assumptions.
Paul.
@Paul W. Homer
We agree on a lot of things. Good! 🙂
Interesting that you brought up The rule of three. I have never used it the way you describe, but I’m eager to give it a try.
Cheers!
Yea, it’s weird and somewhat counter-intuitive, but after I was ‘pressured’ to use it, and found that it worked amazing well, I’ve never missed a chance to apply it.
Another funny one is to spin around an awkward question with another open question. Works best if you get someone who is talkative. If they say “When is this going to be done?”, you follow with “When do you need it by?”, which generally changes the course of the discussion. It’s a little bit ‘evil’, but if you use it only for reasonable circumstances it can really help steer clients away from pushing you into a corner (and thus avoid getting pushed into playing defense). A lot of what programmers and software developers complain about is that they are being controlled by their users, so it is worth it to learn how to take control back from them. Experience with consulting, support and sales helps a lot.
Paul.