|
Back in October 2009 I had the opportunity to attend a conference in Buenos Aires where Mary Poppendieck was scheduled to speak about Lean Product Development and the Theory of Constraints (TOC) applied to software development. Most of this paper is based on the impressions I had from that session and my own personal points of view.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 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 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:
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? 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 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
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 Theory of Constraints 1. http://en.wikipedia.org/wiki/Critical_path_method 2. http://en.wikipedia.org/wiki/Little's_law 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.
Set as favorite
Bookmark
Email this
Hits: 1526 Comments (2)
|
| Last Updated on Tuesday, 23 June 2009 18:19 |
Agile Marketplace - Announcements and Special Offers
Rally Software Extends Agile ALM Platform to Meet the Unique Needs of Global Organizations
Rally Unlimited Edition – Promote Agile practices throughout your organization by providing a complete system-of-record of each product's status, progress and quality across the full idea-to-deployment lifecycle. Sign-up today for your free trial!
iPhone iPad Developers Conference
The iPhone iPad Developers Conference, September 27-29 in San Diego, is the world's premier independent event dedicated to building and marketing apps for Apple's iPhone, iPad and iPod Touch. The format includes 45+ technical classes, workshops and breakout classes. It will also be the first major developer conference after the release of iPhone OS4. CMC subscribers can receive a $100 discount off the Full Event Passport and/or gain free admission to the exhibits (first time registrants only - cannot be combined with other offers) by inserting the code MEDIASPONSOR when prompted on the eRegistration page linked from www.iphonedevcon.com
AgilePalooza - Serious Learning in a Fun Atmosphere
AgilePaloozas are community events sponsored by VersionOne and Agile Journal. These one day conferences provide serious learning in a fun atmosphere. Two tracks are included: Learning Agility and Advancing Agility. Speakers include internationally recognized agile coaches and trainers. The next seminar will be held August 27th in Dallas, TX – use discount code agilejournal and save $20!
Register Here
CollabNet Subversion Edge Improves Governance, Security, Administration
Quickly configure SVN, Apache, and ViewVC with one certified stack, fronted by a powerful UI.
Try our beta version and let us know what you think!


Back in October 2009 I had the opportunity to attend a conference in Buenos Aires where Mary Poppendieck was scheduled to speak about Lean Product Development and the Theory of Constraints (TOC) applied to software development. Most of this paper is based on the impressions I had from that session and my own personal points of view.
