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 the following article is to bring a different perspective into 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", so let's revisit some successful cases such as the building of the Empire State building. Demolition started on September 22, 1929 and building opened on May 1, 1931 exactly on time and 18% under budget. How did they do it? On a time before computers? They focused on the flow, on their constraint.

From 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. They did a simple scheduling of their constraint: ‘Material Flow' without that focus, there's no point on scheduling other resources such as workforce (which by the time, was abundant) This is like finding the critical path[AE3] [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 this type 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 for the projects that I have participated as a Technical Lead is that we try to schedule a lot, too many variables, and when we loose 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. Sounds familiar?

Hey... 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, most of the times our constraint has been the information on the problem to solve (we have business analysts in the US and some application design is done there as well) however we have been scheduling our resources based on a perfect flow of information which never happened. 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 and gather inputs 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 (if I have more available resources than what I need then I should not focus on that one) 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 [4]

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[2] 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 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, else we risk oversimplifying the list in a way that the people processing it wouldn't find the level of granularity that they need.

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

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 (time box) 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 to 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 them. Just think about the times when you have a laundry list of things to do, in reality do you always get them done?

5. Simplicity it is probably one of the principles that is the easiest to forget when developing software. I have a personal strong opinion that unconsciously as developer look for technical challenge during their normal work, they find it by introducing complicated algorithms and unnecessary technologies. Technical leaders should be responsible to validate that developers always have simplicity in their 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 some Business Analyst (BA) works with the business to define the requirements inside a release, and they ship those to us. Usually we used to focus the scheduling on resources to fill up their capacity as soon as we got the requirements from the BA using ballpark estimations; furthermore we also scheduled miscellaneous things such as research sessions and hardware availability.

We always looked bad on our retrospectives. Finally we got the idea that we needed to change and focus on our constraint. For the particular scenario the constraint was and continue to be the flow of information that needs 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 plain and simple Theory of Queues [3] minimizing the number of "TO DO" things for each Developer and QA so that they wouldn't loose focus thinking on what they have ahead without finishing what they have currently on their plates, by using our Project Managers as gatekeepers of tasks and releasers of them at a regular cadence and limiting those releases to the capacity of the team; and finally using our Technical Leads as experts on the art of simplicity focusing their work on reviewing 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 (winner of the ACM Turing award) mentioned that "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 some of the things we can do to influence a successful schedule on our projects are:

• Know your constraint, schedule it and follow through it
• Level the workload by even out the arrival of work and establish 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
The following are good starting points on the topics presented on this article.

Theory of Constraints

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

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

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

Lean

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

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

Comments (2)

...
written by Mauricio Fonseca, March 10, 2009

Project Management is all about keeping constraints identified and controlled. Scheduling, being a critical step in Project Management would definitely benefit from theory of constraints, and that's where I think this article is very valuable. My only addition to it would be to explore other Agile concepts such as iterative approach, refactoring,collective ownership, small releases all applied to scheduling. Some may work right off the bat, others may need to be adjusted or dismissed altogether but nonetheless attractive subjects for a follow up article. In the best spirit of Agile, crank up the volume knob to MAX and see what happens. Food for thought...

• 
• +0
• 
• 

...
written by Alejandra Gonzalez, March 01, 2009

This is a good article that shares the importance of making a pause before committing to estimates and tasks for a project to think in our resources twice and keep in mind the customer value. We need to minimize waste and here is where lean recommendations can be applied to improve the response times and quality of the software development cycle. Implementing an Agile Approach to Scheduling will definitely optimize the whole cross-functional teams to achieve customer satisfaction through continuous delivery of valuable software.

• 
• +1
• 
• 

Write comment

Show/hide comment form