It’s late at night. You’ve gotten hungry or thirsty, and have decided to pop down to your kitchen for a snack. You just want to grab it and go.
Halfway through the kitchen, you hear something skittering across the floor. You also hear a strange sticky sound, and what also sounds like water dripping. You grab a bottle of water off the counter, make a break for the stairs, and run back to your room – heart beating a little harder, breath coming a little faster. But you’ve got your water, and you drift off to sleep.
When the morning light comes, you discover that the water was a pipe dripping everywhere. It appears to have ruined your cabinets, and you are so furious, you don’t think about the other things you heard the night before.
This scenario seems to play out time and time again on software teams I work with. They have a goal. They are doing everything that can to get to it. They know that there are bad things lurking around, but they’d rather leave it until the morning. Sure, their body may have to work a little harder, maybe some overtime (or a lot of overtime), maybe not sleep, or eat junk food. But all of that is better than turning on the light and facing the problems that are really there, right?
This past week I’ve been working with the team to prepare them for our first iterations which start on Monday. Previous to my start, they had done things a pretty standard way – dump a bunch of stuff down to do, wave their hands and say they can do it, and then make a mad dash at the end to get it done. And when it is all over, do it again. This group, thankfully, had begun preparing themselves with flashlights, but even with that, the throwing on of the kitchen lights has them still adjusting a bit.
To understand why, let’s look at some key agile practices:
-
Estimation – We’ve moved away from hour estimates to a relative, effort-based estimation system. So if something is twice as hard as another thing, the latter is a 1 and the former is a 2.
This is challenging, because before, teams could just fake that they can accomplish things in a super human fashion (“40 hours to do that task? Sure we can have it done in a week!”). Using velocity, we have an objective measure of what they can accomplish. It still can be gamed – but mostly at a detriment to the team
- Iterations – The key here isn’t creating some window to work on tasks in. It is defining “done” – what has to be finished in order for a task to count as complete. Previously, many teams would be code complete, and thrown it over the wall to QA. On the teams I’m working with, we’ve defined done as code complete, some level of testing from QA, and some level of verification by the customer/business. I’ve kept it somewhat vague because I’m working across 6 teams, and I want them to define their own version of done. But having to take accountability that just because you hit compile doesn’t mean it is done is quite a shift for many developers.
- Daily Stand-Ups – Having to stand in front of your peers and say what you did yesterday, what you are doing today, and what is blocking you is scary at first. Most people just come into work, zone out on tasks, and head home at the end of the day without really thinking all that much about it. These meetings have the dual-effect of focusing the teams on what is going on, and sharing information that otherwise might not be shared. But keep them quick
- User Stories – This was an interesting one. Which task would you rather work on – “Add a form for choosing a user” or “When a user goes to the Foo screen, they can click on a button which pops up a People Picker similar to what we have in Ghazoo product”. Identifying the weakness in communicating the requirements is helpful for a couple of reasons – it helps clarify what the devs are going to do (and how the customer wants it done), and it gives everyone a head start on testing, since you have an idea of how it is supposed to work
- Velocity – This is perhaps one of the most important one. Developers are an optimistic bunch, and will happily tell you they can build you a whole, brand-new auction site in a day or two. The business will happily accept that, even though they know there’s no way it is going to happen. Velocity switches it around to say, “Here’s what we’re capable of – what can we fill it with?” instead of, “Here’s what needs to be done, can we get it all done?”
I really applaud the team I’m working with right now for the great shifts they’ve made over the past couple of weeks. Some of the practices they were heading towards, but we’ve taken it further than I think they would have, and that can be scary. Because when you turn on the light, you might find a family of hamsters running across your floor, jelly smeared all over the counter, and a huge, watery mess. Or you might find out that the water leak has only just started, and with a turn of a wrench, you were able to fix it right then and there.
But before you can do anything, you have to turn on the light. Go ahead, do it. I’ll be here with the Raid, a pipe wrench, and some paper towels.
(And if you are going to be in the Tampa area on August 13th, be sure to come to my talk at Agile Tampa where I’ll be covering many of these and more)