| Tip 27 | Get with the Project |
 | [White Belt] Before you write a line of code, someone will be asking you how long it’ll take. |
“Are we there yet?”
On the family road trip, your dad may have quipped that it’s the journey, not the destination, that you should focus on. That’s not the case for your project manager.
It turns out there’s a lot of ways to answer that question. Software projects are notoriously hard to estimate, and the industry moves so fast that a product’s specification rarely stays the same for even a month—this is why many teams have given up on writing specs. So, the answer to “Are we there yet?” is often something between “No” and “It depends on what your definition of there is.”
Our industry has put considerable effort into estimating software projects because there’s a lot of money at stake: the company makes a gamble on each project, estimating how much money it’ll make vs. how much money it spends. When the project schedule blows up, the company’s cost blows up as well. Plus, there’s the cost of lost business. Plus, opportunity cost…you get the idea.
The project manager’s job is to plan and execute the project. This person knows what needs to be done and knows where things stand right now. It’s not his job, however, to define the project’s goals—that belongs to the product manager and company stakeholders. It’s also not his job to manage the people. To you, the project manager is the guy who hounds you every week, asking “Are we there yet?”
Waterfall Project Management
The traditional method of managing software projects is to manage them just like any other engineering project:
-
Write a specification.
-
Write the code.
-
Test the code against the specification.
-
Ship it!
Figure 9. Waterfall Gantt chart
This method is called waterfall based on the Gantt charts used to illustrate it, as in Figure 9, Waterfall Gantt chart. (Real Gantt charts are often hundreds of tasks in size.) This method of project management collects all the tasks, time estimates for each task, and dependencies between tasks. Then it’s a straightforward matter to lay them out and determine how long the whole project will take.
This style works well when the tasks are well-known and there isn’t a lot of risk in the time estimates. In other fields of engineering, for example, building a road, the road engineers have a good idea of what they need to do and how long it takes. Likewise, if your team writes software to do customer billing and it already supports five methods of billing, adding another would be a project well-suited to waterfall management.
The key advantage of waterfall is its predictability: everyone has a shared understanding of what’s to be done, how long it will take, and therefore how much it will cost.
Waterfall has a couple key vulnerabilities, too: first, when new invention is involved, it’s impossible to tell at the outset of the project what tasks will be required or how long they’ll take. Programmers must resort to guessing, and the compounded effect of hundreds of guesses is a huge wild-ass guess. At best.
Second, waterfall leaves testing until the end. Technically, that testing is supposed to be a verification test, and there should be few surprises. It never works that way. In practice, engineering gets slack on quality—especially whole-system integration—because they assume the test phase will shake out the bugs. However, finding and fixing bugs becomes increasingly difficult as the software gets larger and worse when it’s supposedly “done.”
Your Role
In a waterfall project, you’ll be given some chunk of the project requirements and then asked the following:
-
What tasks does it take to meet the requirements?
-
How long will each of them take?
The totally honest answer to both questions is, “I don’t know.” But your project manager won’t take that one.
You’ll have to take your best guess. Try to communicate the unknown factors as best you can. When almost everything is unknown, communicate that, too. I suggest doing this via email so you have a written record, in case someone later claims you didn’t warn them of schedule risks.
When the schedule starts to fall apart—and it will—be sure to tell the project manager as soon as you know that a task is going to be late. The worst-case scenario for a six-month project is to be five months into it before the manager realizes there are another six months left to go. If you see the writing on the wall at month three, speak up, at least to your direct manager.
Agile Project Management
Figure 10. Agile iterations
Programmers have questioned waterfall project management—a defined process control model—for years. In 2001 crystallized it with the Agile Manifesto,[44] which issued a clear challenge to reject our waterfall ways.
Agile is a form of empirical process control. The process is started with whatever data you have, and then it’s measured while underway and adjusted based on those measurements. W. Edwards Deming applied this style of process control to manufacturing starting in the 1950s; his work was very influential to the Toyota Production System, the manufacturing process that Toyota used to become the world’s largest automaker.
Agile starts with these assumptions:
-
You can’t specify anything more than about a month’s worth of work, because you simply don’t have enough information to do it accurately.
-
The product requirements change often, so rather than resist that, just take it as a given.
-
After-the-fact testing is wasteful; you should test from the beginning.
“Agile” is an over-arching term for this approach. There are many implementations: Scrum, Lean, and Extreme Programming,[45] for example. For a big-picture view, refer to The Agile Samurai [Ras10].
Central to agile is the concept of an iteration. This is simply a regular unit of time, with a single day as its smallest unit. Days are gathered into sprints (using Scrum parlance) of one to four weeks typically. Some number of sprints are needed to finish the features needed for a release. The iterations can be visualized like the nested circles of Figure 10, Agile iterations.
Iterations in agile are opportunities for measurement and adaptation. A daily stand-up meeting is used to check in, across the team, each day. A sprint review is used to check in with stakeholders, and that’s also the point where the sprint’s software goals needs to be done. A goal may be very small in scope, but it should be production quality—the overall product should be potentially shippable to customers that very day.
It takes a lot of discipline across the whole team to get to a “done” that’s production quality. Done includes development, integration, test, and documentation. The stakeholders may not choose to ship to customers at the end of a sprint—that’s the larger topic of release planning—but part of the agreement in agile is that the product’s quality never wavers.
Your Role
Working in an agile team is both demanding and rewarding. When you sign up for work, you’ll still need to answer what tasks are needed and how long they’ll take, but you’re only answering for a small period of time (usually one to four weeks). At first you’ll get it wrong, but you get quick feedback, so your ability to estimate will get better quickly.
When you consider your estimates, remember to include test time. Ideally your team uses automated tests, so that means more code you need to write. In my experience, there’s about a 1:1 to 1:2 ratio between production code to automated test code. That means your optimistic thinking about the production code needs to be tempered by 100 percent to 200 percent to account for writing test code.
Finally, there’s one sure thing about each agile iteration: when you finish one on Friday, there’s another one starting next Monday. Sometimes you’ll need to work long hours to meet your Friday commitment. Each time, however, learn from the experience and make better-educated estimates the next time. Long hours on a regular basis is a formula for burnout. Agile projects sustain an intense pace because you’re held accountable to your commitments every couple weeks, so strive for working a solid forty hours but rarely more—those forty will be hard enough.
Actions
With this big-picture view of waterfall and agile, which style best matches your company? If it feels like some kind of hybrid—for example they use the term sprints but there’s also a Gantt chart on the wall—then try to tease it apart by thinking in terms of defined vs. empirical process control.
Next, keep track of how accurately you estimate your work. You’ll start by vastly underestimating. Use some empirical process control to improve: measure and adapt.
Finally, if you haven’t met your project manager yet, go introduce yourself!