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.
