8th Light Blog

“Under Promise, Over Deliver” (origin unknown)

“How are you going to get a reputation as a miracle worker if you tell the Captain the actual amount of time it will take?!?!” Scotty on Star Trek

I used to think the first statement was a just a more cynical restatement of the second, which is just a con job. Tell the boss you can’t have it done until Tuesday, finish on Friday, play golf Monday morning and deliver Monday afternoon. Everybody wins right? Except it’s fundamentally dishonest. Lately I’ve come to realize I do the first one every day, and I hope never do the second.

I have three step-children and I rarely promise them anything. It’s not because I’m a horrible father, but because a promise is a fundamentally special thing. I promised my wife I’d stay with her until the end of time, now that’s a promise. If I promise I know damn well I will do what I said, and I can’t have excuses. Now I’m naturally a very busy and easily distracted person so I know that if I promise too much, I’ll deliver a lot of disappointment. Instead I say “maybe” because it’s the honest answer. There is a huge difference between “I promise” and “I’ll try”, and I doubt “I’ll do my best” would have been an acceptable answer on my wedding day.

So what the heck does this have to do with development? I was thinking about iterations, and how the stories taken on are really a promise to the customer, but we don’t always treat them that way. A lot of teams, including at times our own unfortunately, instead Over Promise and Under Deliver. It’s usually done with the best of intentions because the customer wants more stuff done. You know what? My kids want to go to Dunkin Dounuts tomorrow, but I don’t know if I can take them so I won’t make a promise. We should look at our iterations the same way. I’m not talking about padding estimates like Scotty does, but what I’m talking about is avoid the traps of wishful-thinking when estimating stories. Specifically three things I see all the time.

• The Talk Down

The talk down usually happens when one or two team-members are out of sync with the rest of the group on the high side, but can also happen when the team’s points cover a range from small to large. Higher estimates mean higher risk and yet the lower estimates usually win this “battle.” There are two kinds of ways team members (and sometimes customers) encourage other developers down from their estimates, one good and one bad. I’ll illustrate with two stories where I was out of step with the group.

Right after I joined 8th Light we had a store that involved converting text to base64. I was inexperienced with Ruby and hadn’t done this before, so my estimate was higher than the others. At some point somebody said, “Eric that’s a method that’s built into ruby, it’s one method” and I sheepishly shrank my estimate. Hey I used to be a C++ programmer, cut me some slack! The point is this time being talked down made perfect sense. I didn’t know something, somebody told me the answer, and we fixed it.

Much more recently we had a story that involved showing the difference between two objects in the database. In this case I was again much higher than the group. I explained I had no idea how we would do this in a way that would satisfy the customer, but the team thought using the Unix diff tool on the already existing XML Output would be fine. With something feeling wrong in my gut I reluctantly brought down my estimate. A few minutes later Micah and I started on development, and discovered the problem. A few small changes to a product resulted in four pages of indecipherable XML differences. The story was scrapped, fortunately quickly before any time was invested in it.

Now what was different between the two times? In the first there was a concrete and clear way that my estimate was wrong. Yea! In the second there was still an icky feeling in my gut, yet I budged. Why? Because I don’t want to hold up my team, I don’t want to look stupid, and most importantly I failed to articulate my concerns with the approach given. You see for years I worked with InstallShield Developer, and for a while now they’ve saved their file format for projects as XML. But when two people attempted to work on the same file, then merge, it was almost always a nightmare, and this was with tools that just did diffing like Araxis Merge. Our quickly done tool to solve an immediate business need had little chance of success, but I was uncomfortable saying so. The moral: Don’t let yourself be talked down unless you really feel talked down. The team wasn’t wrong for stating how they felt, I was wrong for failing to articulate the issues I had.

• The extra points

Occasionally as a team you really want to impress the customer, and they’re in a hurry. So maybe you take on a few extra points. I don’t feel this needs much explanation, don’t “hope” you can get it all done. Use your velocity, trust your estimates, and KNOW you’ll get it all done.

• The “Ambitious” Iteration

Sometimes your iteration feels just…off. You’ve taken on the same number of points as the previous iteration, but it feels in your gut like it’s too much. Now this is where the promise kicks in. Would you promise your loved ones something that in your gut you just didn’t feel like you could deilver? Than don’t do it to your customer. When the iteration feels ambitious try to put it in concrete terms, maybe you’ve been the victim of the “talk down.”

Remember a promise is a very important, even sacred, thing. It should not be taken on unless you are absolutely sure you can do it. Try saying to yourself before an iteration, “We promise to get all this done.” If that causes a shiver to go down your spine there’s a good chance you really hope you’ll get it all done, and maybe should take a bit off the board rather than be proven right later.

There is no perfect software. At least I have never seen it. Bugs and minor feature changes are indications people are using your software. Real users hit a system in ways that no control group can, and on non-critical applications, this is the best way to test your software. Let people use it and see what happens. This is goes in line with the agile philosophy of release early and often. Get your application out there as fast as you can, so you can mold the finishing touches around the real users experience rather than a faux-environment.

There is some conversation about what is and what is not a “bug” in the software world. That is not a conversation I would like to partake in here, so lets call both bugs, integration items, minor feature enhancements, and things that fall through the cracks of development tweaks. It doesn’t matter what the nature of origin is, these are all things that MUST get done.

After the release of one of our products, a load of tweaks came in from the customer. As proud craftsman, we decided tweaks were our responsibility, and we would take them on in addition to our normal iteration. So we started to do them, to the detriment of our iteration. We accomplished only about half of our iteration’s velocity.

The next iteration, much to our surprise, we were twice as busy with production support. This is about the time that a developer looses a little faith. What did we miss? Is this high quality software we are writing? So we lost even more velocity when it came to iteration 2 after the release. Also, the customers were now unable to accurately plan new features moving forward due to an unstable velocity.

It is so hard to predict or estimate production support and tweaks. However, we needed to be able to so that the production support didn’t leave such a footprint in the project. It felt and looked like we were not getting very much done, even though we were working harder than usual. It was the time being put into a vacuum and being unaccounted for that was troubling the project. It also had a negative effect on the morale of the team.

We came up with a card, we call the “Production Support Card.” The amount of the iteration’s velocity this card took up was calculated by the amount of time we spent on production support the previous iteration averaged with the amount of time allocated for that iteration(sound like a familiar formula?). It is added as a card to the next iteration. If the developers only spend 6 of the 10 points on production support, it is expected that they will complete 4 points worth of stories, which are automatically entered in the iteration. For the first iteration where it becomes apparent that we need a production support card, we set the point value of the card at 0 and track how much time we spend, bumping out of the iteration the least important stories if needed.

So, what does this tracking buy you, if you have to spend the same amount of time on tweaks? First, it allows transparency to the customer about what you are working on that week. When they see your normal velocity of 20 points turn into 5 points, they have a right to be worried. When you say, in a defeated voice “we were fixing bugs,” they also have a right to worry about the stability of the code you have been writing, even though this spike in minor changes to the application is a part of the normal process.

Second, it raises the moral of the team, because they are working towards a specific goal, to remove the production support cards from the iteration. Also, we get the satisfaction of maintaining a velocity in points, which is something we know so well it is hard to work without.

It takes a few iterations, and the team squeezes the life out of the production support card, putting you back on track. After those iterations, the footprint goes from sasquatch to mini-me.

It also helps the customer plan around production support. Their time lines and release dates are made from a projection of feature difficulty to development’s velocity. Over a long period of time, the velocity normalizes, and it hurts the projections to have hiccups. If you have production support data, you can predict about how much time around a release you will loose on the initial release of brand new development.

One of the famous studies on peer pressure was the Stanford prison experiment. A group of average people were selected to play either a prisoner or prisoner guard. As the participant became engrossed in the role, the peer pressure from other participants quickly degraded their moral compass. The small negative actions lead the groups to quickly fall into patterns of behavior which were unlike their own.

I see peer pressure work in the same manner for good all the time. Since software is written by teams, the software is often a reflection of how well the team works together more so than individual skills of the developers. When you have a group of developers who entice each other to do good work, the outcome can be great work.

Creating a culture of positive peer pressure is about doing lots of little things. Small positive actions will lead the team to create positive patterns of behavior.

Here are different techniques which have worked for different teams I have been a member.

1. Name your team, not just your project. This gives me as a developer some self-identity as part of a team.

2. Greet your team mates each day. We shake hands to show respect each day for each team member. We generally start and finish each day with a handshake. This can alleviate tense situations by itself, as personal contact often does. No chance to avoid a team member.

3. Do some activity everyone enjoys. Anything from eating lunch together to playing a competitive game as a team. We have played basketball together. Being competitive with my team gives me pride in the team, win or loose. Get to know your team members.

4. We keep a good supply of coffee, tea, snacks, and gum for each other as gifts. This act of giving to the team promotes the selflessness any team needs from its members top succeed. There are different levels of skill on a team, but each team member is important. It is difficult to write software for any project of magnitude without the full contribution of each member of the team.

5. Switch pairs pairs often. When you work with everyone on the team, you feel closer to everyone on the team.

6. Talk while you pair. Reading someone’s mind takes more effort than talking. Talking aloud also is a great way of brainstorming. Pair communication starts when words become sound waves.

These small things can improve the accountability and creativity to make a well functioning team. A happier team will become a creative and productive team. A team that has a strong sense of togetherness will lift each other up when needed. I find myself more willing to step up to daily challenges with the support of the team on my side. There is no place for apathy and complacency in a team which has pressure to succeed.

When the team succeeds, as positive teams often do, it becomes a group success and brings the entire team great pride. A team which pressures each other to do better can turn an average developer into a great developer.