Will Your Project Ship On Time?

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.

You May Not Know the Business You Are In

Here is a simple question:

• What is the business of Seagate and Western Digital?

If you confidently answered “Hard Drives!” you’d be wrong.

Unfortunately, it’s clear that both Seagate and Western Digital themselves define their business as the “hard drive” business. How short-sighted. It’s highly unlikely that I will continue to own a hard drive within 3-5 years. Neither will you. Within 10 years, it’s unlikely that anybody will be purchasing hard drives for any purpose.

Why? Because there will be better, faster, lower power consuming alternatives with no moving parts. These alternatives exist today. Flash comes to mind, but price has been a barrier. While flash memory capacity is doubling every 10 months, flash prices drop by half. Hard drives have had a good 50-year run and Seagate is clearly in the hard drive business. Even though it’s clear what the future holds, Seagate and Western Digital don’t seem to be making the right moves to position themselves appropriately to take advantage of the disruptive technology that awaits them.

If I owned any Seagate or Western Digital stock, I would dump it now.

Flash is a disruptive technology. It’s a lot like what motor boats were to sail ships in the 1800s. Motor boats could go much much faster, but they were relatively small and their range was extremely short. Sailboat makers thought they were in the sailboat business and completely ignored the motorboat business, seeing them as just a short-range toy. Of course, over time, motorboats became better and their range eventually had the ability to cross the Atlantic. As a result, none of the sailboat manufacturers of the time were able to survive this disruptive change while motorboat producers thrived.

The problem was that they were all in the transportation business, but they didn’t see it that way. The people purchasing sailboats didn’t care about sailboats. They cared about getting people and merchandise from point A to point B as quickly and economically as possible. Over time, motor boats did a much better job. Eventually, airplanes did a better job for carrying people and the transportation of people via motorboats business also died. Today’s cruise liners are in the entertainment business, not transportation.

There are, of course, numerous other examples. CDs to tapes, MP3s to CDs, DVDs to VHS, but for now, let’s get back to Seagate, hard drives and flash. So is the Hard Drive market slowly going to transition to the Flash market? The answer is no. The storage market will remain the storage market.

People in need of storing information digitally will store it wherever is most convenient, fast and economical. Sound familiar? Do you really care about hard drives or do you just want to store your files? If the web or Google could store your files as conveniently, fast and economically as a hard drive, that’s where you’d store your files. But before we get to web storage, Flash will beat Hard Drives. Hopefully Flash memory makers will not make the mistake of thinking they are in the Flash business. Eventually something like DNA-based storage (or something entirely different) will beat out flash. Anybody in the flash business will go out of business, but the storage business will continue to thrive and expand.

What Business Are You In?

If you are a Software Engineer, don’t call yourself a C# developer or a Java developer. That’s the equivalent of Seagate being in the hard drive business. What happens when nobody needs a Java or a C# developer anymore? If you think that can’t happen, just look at all the Cobol and Ada developers today. How many do you know?

The same applies to your business. It’s time to think long and hard about the business your company is in. At Axosoft, when I released OnTime V1.0, it was a bug tracking application. Most competing companies who create a bug tracking tool see themselves in the bug tracking business. Some venture to say it’s a project management tool. I’ve always viewed OnTime as a tool to help software teams ship software on-time and not as a bug tracking application.

That view has lead us to build requirements management, help desk and now wiki inside the same product. It’s now obvious that OnTime is not just a bug tracking tool, or just a project management tool, but a tool that helps software teams ship great software. The focus is on driving the team to ship.

When trying to determine the business you are in, think of the problem you are solving rather than the way in which you are solving it. If you make MP3 players, you’re in the portable entertainment business. MP3 just happens to be a short-term technology that delivers digital music in an efficient way, but eventually, there will be a better way to deliver portable entertainment and everybody who is in the MP3 business will die. People will always continue to need a solution to their portable entertainment problem. Nobody has an MP3 player problem.

To create great software and to continue thriving, it’s important to know your business. To be alive 10 years from now, Seagate needs to continue being in the storage business and not the hard drive business. It’s crucial to know the difference.

Building a Great Team

The 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.

Why Software Methodologies Don’t Save Software Projects

According to Wikipedia, in Software Engineering, a Methodology is defined as:

A codified set of practices (sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools) that may be repeatably carried out to produce software.

Unfortunately, that definition is believed by many, and it’s dead wrong. If you believe it, your projects may be doomed to failure.

Methodologies are systems for the creation of things. A system designed to manufacture cars at Ford or hamburgers at McDonalds is a methodology (although not a software methodology). Ford manufacturing plants produce new cars through an assembly line where each phase of construction is extremely well defined. It’s defined to the point that even robots participate in various phases of construction. You can interchange people who work in the assembly line with relative ease and almost no impact on the end result. There’s quality assurance at every phase to ensure that each benchmark is within the predefined limits. All of this results in the manufacturing of nearly identical cars, in every single instance. It works great.

Likewise, McDonalds has a similar strategy for making hamburgers. The steps to create a burger are well defined. If you change the cook, the burger will still be the same with the same amount of materials, same ingredients, same cooking temperatures, same sauces and the same wrapping. McDonald’s burger-creation methodology results in the customer enjoying the same burger, every single time. Their success is proof that the system works and it works well.

Methodologies Don’t Produce Software

So why not a system for the creation of software? If Ford can do it for cars and McDonalds can do it for hamburgers, why can’t we have a system to produce software? The answer is that we can. The catch, however, is that the system can only re-create software that has already been created. The system cannot produce new software just as Ford’s methodology for creating new cars will never create a different kind of car. It’s designed to re-create the exact same gas-guzzling, poor quality, tire-exploding and boring car in the exact same way that you have come to expect from Ford. So it is at McDonald’s. The system doesn’t create a new kind of hamburger. It simply re-creates the same bad-tasting, low-quality, high-calorie hamburger that you’ve now come to expect from McDonald’s.

In the same light, a software methodology cannot produce new software. This concept is a major surprise to a lot of companies and the US Government, who after spending hundreds of millions of dollars on software projects that end up being canceled — projects that should have been fool-proof in their success. After all, they used the most concrete software methodologies known to man-kind (or to Grady Booch). How could such software projects fail?

Learning that methodologies or well-defined systems and processes can’t create things is important. People create things. Systems and methodologies can only re-create things, but only after people create them first. So what about successful software projects that have employed rigid systems and software methodologies? Easy. Such projects have succeeded in spite of the methodologies used, not because of them and it’s virtually guaranteed that a less restricted team would have accomplished the same task in less time.

New Trends in Software Development

The world is slowly coming to the realization that people are the most important part of any successful new software project. No systems or processes can substitute for your top software engineers. Take your own software projects as an example. Would you give up the top one or two team members or would you give up your software methodology? My guess is that the answer is a no-brainer. Even in a team of 100, losing the top couple of team members would be far more detrimental to the success of the project.

You have undoubtedly heard of new software methodologies such as Agile and Scrum. The popularity of these new light-weight systems is exactly because of the reasons I have explained above. They put the emphasis on people. Is it any surprise that trimming down detailed, process-heavy, software methodologies has produced much better results? Of course not. These new systems are putting the emphasis on individual team members, finally coming to the acceptance that the individuals are far more important in the creation of new software. The systems should only support the individuals, not get in their way. Unfortunately, even these new methodologies are slowly becoming heavy. Scrum is becoming better defined by the day and the more it gets defined, the more Scrum Masters who insist on having a burn-down chart from day 1 on a new project, the more such projects will suffer.

Finding the Right Balance

Like everything in life, there is a balance that each team must obtain between systems and processes and team and individual freedom. Each project is different. There is no one system that can meet the needs of all teams and no single implementation of a system that should be used instead of another. Google’s founders didn’t start with a methodology. Neither did YouTube or FaceBook. Even well established companies like Microsoft and Apple didn’t (and still don’t) have rigid systems in place and they provide significant team freedom to choose the right amount of process for their projects.

So unless you have a lot of free tax-money to waste or if you work on human-safety systems, reconsider the weight of your software methodology. In software, lighter is usually better.