September 29, 2006
Want to Build Better Software? Better Teams? Build Trust by Putting People (including yourself) at Ease.
Last night, at AgileKC, an agile software development professional group in Kansas City, our discussion began with writing the word 'trust' on the whiteboard. A couple of hours later, we had covered a lot of ground and one of our members finished at the board collaborating with the group to help him generate ideas for an upcoming column he's writing which will mostly focus on 'Agile Smells', identifying symptoms of and suggesting remedies for software development team and process issues. Not surprisingly, 'trust' was a recurring theme during that discussion as well.
We started AgileKC approximately one year ago and these meeting formats tend to be my personal favorites as the ideas and perspectives are openly shared and discussed and I always walk away with useful things to include in Visionpace agile pursuits. Next month we'll have a format where we'll meet in a private room at a local restaurant and sit around tables informally discussing a variety of topics and enjoy a meal in addition to hearing a more formal topic presented by a member of the group. In my experience attending professional meetings over the years this is by far the best format for maximizing learning and networking.
So back to 'trust'. I stumbled across a post on an XP list I'm on that referenced a video featuring Kent Beck discussing, 'Ease at Work' which among other things, related to the softer or more personal side of software development teams, including accountability, responsibility and of course, trust. I think there's a lot of valuable overlap with last night's discussion and as always, Kent shares a number of useful perspectives.
September 27, 2006
The problem with percent-complete
Does this sound familiar?
PM: “Jason, what is the status of the XYZ Modulator? Last week you were at 55% and management is breathing down my neck.”
Jason: “Well, I implemented the auto-reload, and the changes from QA. I’d say were about 70-75% done.”
PM: “Great 20% more than last week! That will make the Powers that Be happy.”
… One week later …
PM: “Jason I need an update on the project status.”
Jason: “Uhhh, yeah about that. Well I found that the auto-reload didn’t work for have the new data types so I spend the last week fixing that.”
PM: “Oh. Well what should I put as the percent complete? It’s 75% now.”
Jason: “Ummm, how about 80%...???”
When I witness these conversations, or hear about them, I see red flags everywhere. Percent complete seems to have taken a life of its own outside a Gantt chart. It has become, in some instances, the measure of all work. Don’t get me wrong. I think it’s valid to say that we are X% to implementing a piece of functionality provided you also include a reference to a percent complete of what you’re measuring. (I.E “We initially thought this was going to take 30 hours. That’s still valid and were about 50% there.” From this, one can deduce that about 15 hours have been worked on the code, and about 15 hours remain.)
One problem with the initial, and far too common, example above lies in not having an underlying measure to use as reference. If you don’t have some reference included the use of percent complete gets clouded. Even trying to say ‘I’ve been working on the code for the last three days and I’m 60% through’ leaves some information out of the status. Were you spending all of your time for the last three days on the code, or were you working on other tasks as well? What are the plans moving forward? Are you saying that you anticipate being done in two more days? In 16 hours? You’re 60% of what?
Another problem is using percent complete as the only measure of progress in a project. By updating percent complete as the only means of a project metric, a project can appear to be progressing all the time at a steady pace when its not. The risk is that a culture can develop that the developers are conditioned to give some number greater than the last number they gave for percent complete. Unfortunately for the developer, the number can’t go above 100%. So what usually happens is a feature is started and the developer spends say two days working on the feature and feels that they are making good progress and say at the first status meeting that they are 30% (or some other optimistic number) complete. The next two days they find that they didn’t account for a needed architecture originally in the first two days, so they spend the time implementing it. In the larger picture, in terms of having the feature implemented, they are at the same place as the last status meeting, but have a better architecture. Since the metric is percent complete, not updating the metric would indicate that they didn’t do anything for the last two days. So they have to give a number to justify their efforts. So they choose a number like 15% and report that they are now 45% complete. You get the picture. Before too long the status chart shows the code at 80% complete, and in terms of hours spent to date over the overall amount of hours forecast, the number is much less than 80%. Usually the percent complete starts to increase much more slowly; in increments of 1-5%, until the measurement is finally reset. Eventually the reporting becomes a dance that everyone feels they have to perform, but nobody on the team has any faith in it. Unfortunately the memo to the executives is seldom sent…
It doesn’t always work out this way, but often I find that projects that rely on percent complete do so because management likes it. It’s an easy thing for management to understand. In addition the management in question often hangs their hat on the number and holds it to assumed (and often not-discussed) standards.
Some of these standards include:
- If you’ve spent time working on the project and the percent complete didn’t increase, you didn’t provide any value to the project. (As described in refactoring example above.)
- Percent complete shouldn’t go backward. If a house if 50% complete this week, it won’t be 40% complete next week unless some outside factors are in play (like a wind storm.) Software development doesn’t work like this.
- Percent complete will increase at the same rate during the entire project. Reporting that the project is 20% complete after two weeks often times allows people to assume that the project will be done in eight more weeks.
- Percent complete is perceived to always be accurate. If you say that you are 86% complete, it is assumed that there are empirical calculations to back that up. Often times, the only thing to back the number up is the number a developer pulled out of the air during a meeting. Even worse each developer throws out the number for the things they have been working on, so there isn’t any consistency between the metrics for the different tasks the team is working on.
This is why Visionpace follows the model of forecasting pieces of work in ‘story points’ and then when we start working on a specific feature, we break the feature into tasks. The tasks are estimated in hours, and ideally the entire team is involved in determining the estimates. This allows for multiple viewpoints and voices, and tends to create more realistic estimates. As the tasks are worked on the status meeting focuses on:
- What did you work on yesterday (how many hours did you get to spend working on the task)?
- What are you going to work on today (how many hours are left on the task at hand)?
- What are the roadblocks, if any? By asking these questions regularly, the entire team is involved on all of the development. Tasks that are underestimated initially are identified quickly and the factors that led to the underestimation are presented to the entire team, so they can be understood for the next estimating session. Additionally, with this approach, if a developer is struggling with a task, it is apparent to the entire team and assistance can be addressed sooner rather than later. One final benefit of measuring the tasks in hours, is that it’s easier to plan on when the tasks is expected to be implemented. (Consider the statement, ‘I think there are six hours remaining on this task. I’m out half a day tomorrow for my kid’s doctor appointment, so I expect to have it done before lunch the day after tomorrow.’ This explains in succinct detail, what is going with the task.
If you’re interested in this approach feel free to contact me at Visionpace. We deliver custom software development following agile principles in Kansas City.
September 11, 2006
Observations from the field – if you’re going to be held accountable for making sure a conversation happens, then make sure the conversation happens.
One aspect of business that his often difficult to manage is making sure the difficult conversations that need to occur during a project actually do occur. The topics of these kinds of conversations can vary from delivery dates, budgets, team dynamics, etc. The underlying theme is that for a variety of reasons, no one wants to bring them up when the team is discussing the project. I think a lot of the difficulty comes directly from people’s desire to maximize pleasure and minimize pain. That is people tend to not address the problematic issues, or it they do, not address them directly. This causes issues when the problems, left unaddressed begin to affect the team’s or organization’s performance, or in a worst case scenario doom the project. Conversely, by focusing on the easier conversations a team might develop an overly optimistic view of a project and miss potential pitfalls along the way.
So how does one address this issue? I think it’s best done by stressing honesty and integrity. Frequently reminding the entire team that they collectively have the responsibility (and duty) to talk openly and honestly about their project and commitments, both good and bad, can go a long way to mitigate this potential time bomb. The way I like to describe it is; if you are responsible for making sure the team addresses the 500 lb. gorilla in the room, don’t mince words. At an iteration review meeting, or a similar time when it is appropriate, bring up the topic by stating ‘One of my roles is to make sure we talk about this 500 lb. gorilla. So I would like to do that now.’ Then begin stating your understandings, questions, etc. about the topic.
It can be uncomfortable to do this the first couple of times, but after a while it becomes matter of fact. With experience, one realizes that the fear and anxiety are usually associated with brining up difficult topics are a personal reaction that should be separated from the business needs associated with discussing the topic. Even if you never get over the butterflies, you start gaining the ability to address topics for their business value, not your personal value. That’s where the integrity and honesty come into play. If you have a high sense of integrity and honesty, then the personal aspects of difficult conversations become even more moot. Instead, your can rely on your sense of ethics to help bring the hard topics to the table.
Another aspect that helps mitigate this risk is to have a role, owned by someone on the team, within the project that makes sure these topics are brought up. Usually this responsibility falls to the project manager. If the project manager is unable to fulfill this responsibility, then someone else must take it over. Some options might be an outside executive, another person on the team with the role as the devil’s advocate or even a group of project manages that critique each other and then present their findings. It cannot be left orphaned, or the conversations will not occur.