Archive

Posts Tagged ‘software teams’

Will Your Project Ship On Time?

June 17, 2008 8 comments

Will Your Project Ship OnTime?I am working on a simple test that software development teams could use to determine whether or not their projects will ship on-time. I ran this test by Eric Sink who helped refine a couple of the questions. I think his input made the test stronger and I’d like to get some feedback from you.

It would be great to see what your results are and if you agree with the results based on this test:

Question Response Calculate Points
1. How many total team members do you have (count everybody)? _____ x -2 = _____
2. How many non-engineers (non-developers) in your team (testers/mgrs/etc.)? _____ x -2 = _____
3. Break down your team to # of Members with:
– Negative or Neutral Productivity
– Normal Positive Productivity
– Superstar Productivity
_____
_____
_____
x -5 = _____
x 3 = _____
x 10 = _____
4. Expected Project Duration – Use This Scale:
< 3 Months = 0
3-6 Months = -2
6-10 Months = -6
11-18 Months = -15
18+ Months = -30
  x 1 = _____
5. Organizational strictness on methodologies or processes:
– Hard Core about following a heavy methodology (6-sigma or similar) = -6
– We strictly follow an agile process (scrum, XP, etc.) = 0
– We follow best practices or loosely follow agile process = 2
– We don’t do any process or best practices = -6
  x 1 = _____
6. Is your project broken down into tasks & features with estimates for each?
– Yes = 2
– No = -6
  x 1 = _____
7. Does each team member have a task-level checklist of when the project is done?
– Yes = 5
– No = -15
  x 1 = _____
  Total: _______

To determine whether your team will ship the project on-time, use your Total Score and compare it to the following scale:

Negative Total: Forget about it – Your project is at risk of cancellation.
1-9: Project will finish late.
10-24: Project has a good chance of finishing close to schedule (within 10-15% of estimate)
24-50: Your team has a reputation of delivering on-time!
50+: It’s unlikely that you have that many superstars. Go back and take the test again.

The goal here is to make questions easy to answer and still be able to get accurate results. I am going to make this test into a web-based calculator that any member of the development team could use to help determine their team’s chances of shipping software on-time, so I need as much feedback as you can give.

There are a lot of other factors that came to mind, but were omitted from the test to keep things simple. For example, you might be thinking “what about using past success rates” or “quality of estimates” in determining whether the team will ship on-time. However, I’m trying to leave out questions that are difficult to answer (too subjective) and allow for first-time teams to still be able to use the calculator to estimate their success rate (no reliance on historical data).

You might also ask “isn’t it subjective to categorize your team into 3 levels of productivity?” The answer is yes it’s a little subjective, but I bet most people would agree with your categorizations (with possible exception of the individuals who are being categorized in the negative or neutral category). Most of us know who the super-stars and the bozos on the team are. Everybody else is a normal, productive team-member.

So the questions are easy to answer, but the result should be extremely accurate. I’m curious to know if you agree.

Building a Great Team

November 12, 2007 6 comments

A Good Team is Critical to Success of a ProjectThe centerpiece of any successful development project is the team that builds it. There is no other single most important contributing factor to building great products. No tools, no development methods, no amount of money and no amount of time can substitute for the importance of an exceptional team if you plan to create an exceptional product.

Some in our industry operate under the assumption “with a good system and a fine-tuned set of processes, you can build anything with a group of average Joes.” If that sounds like your company, congratulations! You must be that average Joe. The assumption that with the right systems and tools, anybody could build great products couldn’t be any further from the truth.

Only driven, motivated and talented teams can make great products. Heavy systematic methodologies of product development and processes can only slow down those teams to ensure that the slowest person on the team can keep up. Process-heavy systems are designed for the weakest team member and therefore must slow down the pace of all other team members to ensure that few mistakes are made by those who are not exceptionally skilled. The cost of such systems is incredibly high.

See if this sounds familiar: Your team is fast at work on the latest project. Due to the size and importance of the project to the company’s success, the executive team is providing the budget necessary to expand the team. It’s estimated that your team will need to increase the “headcount” by 5 or 10, in order to meet its project deadlines. To quickly ramp up for the new required headcount, the bar for qualified candidates falls nearly as fast as the team’s cohesiveness. Within a short time your team successfully adds 10 new “heads” to meet the aggressive project schedule.

To ramp up the new members as quickly as possible, they have been given the proper one-day overview of the project. They weren’t even asked to write code until Day Two. Soon these new team members start contributing thousands of lines of code. Productivity seems at an all-time high. Tasks are getting done in record time and the team now seems to be functioning on all cylinders. If you’re lucky, within a couple of weeks, the first set of problems start to reveal their ugly heads. All kinds of new nasty bugs show up in QA (assuming, of course, that there is a QA team). Senior team members have to take time off of their tasks to track down these nasty issues. After days of searching and going through weeks of code line-by-line, some suspected line code are identified. The first question asked is “who wrote this crap?” and so the process expands.

In order to find out who’s responsible for poorly written code in the future, “checkin” rules requiring detailed comments are put into place.  Additionally, every single line of code is now required to go through a complete and formal code-review to help reduce errors.

The team’s pace changes drastically. Things slow down and soon it’s obvious that the deadline targets of the project schedule are impossible to meet. At current pace, you easily need to increase the headcount by another 5 to 10 to make the ship dates.  But, even that is unlikely as a frustrated, but competent teammember finally speaks up and reminds the executives (and everybody else in the room) that 9 women can’t make a baby in 1 month.

Finally, everybody comes to accept the missed deadlines and the pushed back release dates. Life goes on…slowly.

There is a Better Way

There is, of course, a better way. Among engineers and project managers, it’s common knowledge that a really good engineer can be 3, 5 or even as much as 10 times more productive than a bad engineer. What a load of crap. You’re probably thinking I’m nuts. You might even be thinking that you personally know software engineers who are 3 or 5 times more productive than the guy in the next cube. What you don’t realize is that you are probably discounting their productivity.

It’s possible for a good engineer to be infinitely more productive than the engineer sitting next to them. How is that possible? Consider this: in 1975, how many engineers could have single-handedly done what Steve Wozniak did in designing the Apple I and later the Apple II? What about the search algorithms used by Larry and Sergey (Google)? I know that if you had given me 10 years, it’s not likely that I would have thought of page ranking or search in the way that Larry and Sergey did. So how much more productive were they? I’d say about ($)150 billion times!

The problem with comparing people in terms of multiples of productivity (such as person X is 5 times more productive than person Y) is that there is an underlying assumption that both person X and person Y can do the same job. That is a huge and usually wrong assumption. Two people might be able to do the same job and if one of them is generally 5 times more productive than the other, that probably means there is a whole realm of things that is possible for one of them that’s impossible for the other.

With that in mind, if you were working on a hardware project and estimated that you needed 10 more engineers to get the job done, would you take 10 “Average Joes” or would you settle for 1 Steve Wozniak? If you were working on a Search-related project, would you take 10 “Average Joes” or 1 Larry Page or Sergey Brin? If the answers to those questions seem obvious to you, so should the importance of building a great team. It’s not about “headcounts.” It’s about talent. So to create a winning team, keep a few simple rules in mind:

  1. Hire the most talented people you can possibly find. Don’t hire someone if they don’t meet the bar you’ve set. I know it’s extremely tempting to lower the bar when it’s hard to find good people. Remember that a bad hire could actually have negative productivity!
  2. Create a system that’s flexible and light in process. Implementing any kind of canned methodology that has steps outlined from A to Z on how to create products and manage teams ensures that your team will operate at a low efficiency. A more dynamic and light-weight, low-process system is ideal when your team is already talented enough to know how to do the right things.
  3. Eliminate team members that consistently fall below the bar. Don’t kill them. Just fire them or move them to a different position if you can. If you can’t get rid of team members due to corporate culture or red tape, give them tasks that are non-critical to the success of your project. Often times you can increase productivity faster by removing team members than you can by adding them. If you find that you’re adding process to your efficient system because of 1 or 2 people who consistently need detailed guidelines to get work done, those are the guys I’m talking about.
  4. Create a culture that appreciates talent. Talented people like to work with other talented people. That’s how they’re satisfied. By giving them freedom to do the right thing and taking obstacles (and dumb people) out of their way, you’re creating a culture that appreciates and rewards talent.

By putting the emphasis on the team rather than the process, you’ll create much better products at the end.

%d bloggers like this: