Scheduling is defined as "the process of deciding how to commit resources between a variety of possible tasks." In the software industry, most of us use this term interchangeably for project scheduling, which builds on prior project planning. This idea has always been one of the most challenging areas in software construction: How do I complete all artifacts required for a specific release? How do I manage and commit the resources available? What happens if something goes wrong? The goal of this article is to bring a different perspective to the table, hoping that the reader will start rethinking scheduling in a different way.

The Empire State Building History
Let us all remember that famous quotation "Those who ignore history are destined to repeat it" while we revisit some successful cases, such as the building of the Empire State building. Demolition started on September 22, 1929, and the building opened on May 1, 1931, exactly on time and 18 percent under budget. How did they do it in a time before computers? They focused on the flow; on their constraint.

In the book Building the Empire State. Builders Notebook by Carol Willis, the builders mention that they focused their schedule on steel and that they thought of work as if it were a band marching through the building. In other words, they did a simple scheduling of their constraint: "material flow." Without that focus, there was no point scheduling other resources, such as workforce (which by the time, was abundant). This is like finding the critical path [1] and scheduling to that, which is certainly sensible. The critical path won't remain fixed though. It has to be tracked as any unpredictable events unfold. The important take away is that we can borrow these types of ideas and apply them to the software development world.

Lessons Learned? Know Your Constraint, Schedule It, and Follow Through It
Perhaps, in the software industry, we have been too focused on too many things. My personal experience as a technical lead has been that we try to schedule too many variables, and when we lose sight of one of those variables, even for a valid reason, we offer excuses and finally end up throwing away the schedule. Without the vision that a schedule offers, we end up sacrificing functionality or quality. Sound familiar?

But, what if we stop scheduling too many variables? How should we focus? We focus on the constraint. For example, within the projects that I participate on, most of the time our constraint has been the information about the problem to solve; however, we schedule our resources based on a perfect flow of information, which never happens. So, you must know your constraint and schedule it. The constraint could be:

• Information about the problem to solve
• Understanding the best solution to the problem
• Available developers, quality analyst, business analyst
• Available equipment

Meet with your team members and gather input from them on what the real constraint is and the risks that may trigger other, greater, constraints. This comes from borrowing some of the lean manufacturing ideas, which are all about taking care of what provides value to the customer and eliminating everything else. In this case, we are defining what brings value to the schedule (the constraint) and getting rid of the other variables that will not impact it (e.g., if I have more available resources than I need, then I should not focus on that). Of course, learning to eliminate what is not needed from a schedule in order to focus on what's really important is more art than a science. Womack and Jones are a good reference on lean [2].

What's Next?
Once you know your constraint and use a pacemaker to schedule it, you must think about the best way to address your schedule: What's the best way to process the tasks on the queue? How do you eliminate what does not add value? Let's take a look at Little's Law [3] to address a queue:

Time Through the System = Number of Things To Process / Average Completion Rate

How do we reduce the "time through the system"? We either reduce the number of things to process or increase the average completion rate. Easy, right? Here are some recommendations:

1. Reduce the "number of things to process" by using some type of backlog or "to-do" list in such a way that the team members focus only on what they have at the top of a short queue. However, you don't want to reduce the number of items on the to-do list by bunching together smaller tasks. There has to be a reasonable level of granularity, or else we risk oversimplifying the list.

2. Establish a regular cadence so that the team knows when it will pull things from the queue and how frequently.

3. Limit the work to capacity. Why do we keep accepting more than we can handle? Of course, the real question is: How do I know what I can handle? That's why we should commit to a release date (timebox) but not to a scope + release date (scope box), and for that, we should undust our negotiation skills to effectively collaborate with the business to come up with a win-win situation. The ideal state will be a commitment by the development team to a release and a minimum set of deliverable requirements (if time allows it, the team will pull from a queue of things to process), also the business will commit to receive a working product of the highest quality with a minimum set of deliverable requirements.

4. Optimize the throughput not the utilization by minimizing the number of tasks to be processed as well as the size of the tasks. Just think about the times when you have had a laundry list of things to do, in reality do you always get them done?

5. Simplicity is probably one of the principles that is the easiest to forget when developing software. I have a strong opinion that, unconsciously, as developers look for technical challenges during their normal work, they find it by introducing complicated algorithms and unnecessary technologies. Technical leaders should be responsible for validating that developers always have simplicity in mind.

What's the purpose of a well-defined and detailed schedule that no one will look at or that no one will be able to comply with?

Experience Report
My team's work is a classical outsourcing example where a business analyst (BA) works with the business to define the requirements inside a release, then they shipped those requirements to us. Usually, we focused on scheduling resources using ballpark estimates as soon as we got the requirements from the BA; furthermore, we also scheduled miscellaneous things, such as research sessions and hardware availability.

We always looked bad on our retrospectives. Finally, we realized that we needed to change and focus on our constraint. For this particular scenario, the constraint was the flow of information that needed to go through a BA. Once we got this part and stopped focusing our scheduling efforts on other miscellaneous tasks, we moved on to optimize our work queues by using the Theory of Queues [4], minimizing the number of to-dos for each developer and QA so that they wouldn't lose focus thinking about the tasks they had ahead before finishing what they currently had on their plates. Our project managers became gatekeepers of tasks, releasing them at a regular cadence and limiting those releases to the capacity of the team. And our technical leads acted as experts on the art of simplicity, focusing their work on reviewing the day-to-day decisions of the team to refocus the work on simplicity. That all has made a huge impact in our work and lives, up to the point that I find myself with enough time to write this article.

Summary
Frederick Brooks said, "Software development is the most complex task ever undertaken by humanity," and scheduling of the tasks required for it are no child's play. Experience has shown that there are some things we can do to influence a successful schedule on our projects:

• Know your constraint, schedule it, and follow through it.
• Level the workload by evening out the arrival of work and establishing a regular cadence.
• Limit the work to capacity per a timebox instead of a scopebox, and pull tasks from a queue as needed instead of pushing them.
• Optimize throughput and not utilization by minimizing the number of things in process and minimizing the size of things in process.

Naturally, the reader might be thinking of several reasons why some of the presented conclusions might not be applicable to their specific business, and as usual they are not silver bullets. They are just some of the conclusions we have gathered over time.

References

1. http://en.wikipedia.org/wiki/Critical_path_method

2. Womack and Jones, Lean Thinking, Free Press, 2003.

3. http://en.wikipedia.org/wiki/Little's_law

4. Goldratt and Cox, The Goal, 3rd edition, North River Press, 2004

Further Reading

Poppendieck and Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley Professional, 2003.