Results do not spontaneously and magically appear; they are the end result of an often long and potentially complicated set of actions. In many cases, the choice of when something is done is the one with the single largest impact.
When looking at a timeline, any specific activity is bounded by the endpoints of “First Possible Moment” [FPM] and “Last Possible Moment” [LPM]. Prior to the FPM, there is one or more conditions that prevent the activity from being undertaken. After the LPM, undertaking the activity will not achieve the required goal.
These endpoints are further constrained when one is going to act responsibly. Every activity has some type of risk which can cause it to take longer than expected. Other activities may benefit from a specific activity being completed. These types of considerations introduce the “Last Responsible Moment” [LRM]. A similar set of conditions occur at the beginning of the timeframe. While it may be possible to start an activity, doing so without additional information may increase risk. Deferring the start of action can provide benefits without significant impact on the outcome. This introduces the “First Responsible Moment” [FRM]
The book Lean Software Development: An Agile Toolkit covers the LRM is detail, and is a recommended read. Test Driven Development: By Example shows how addressing testing as early as possible [FPM or FRM] provides significant benefits. In general, the type of activity will be indicative of the value curve for the times between FRM and LRM. The time at which the maximum value is theoretically achieved is the “Maximum Value Moment” [MVM]. From a practical standpoint, this item is impossible to determine; but, it does provide a very useful conceptual point.
Historically this general thought process was used to layout large, complex Gantt charts which would span the entire lifecycle of the application. While modern iterative approaches have largely eliminated the attempt to do “detail at scale”, the underlying factors which drive effective execution of the workflow has not changed.
If one looks at a relevant set of activities (perhaps those to be accomplished within a Sprint / Iteration) and places them on a timeline based on the MVM, the first thing that is likely to be noticed is that there are large peaks and valleys in the work targeted for any specific point in time. Given that a given teams capacity is typically constant over the interval, this is extremely problematic. To address this, activities need to be moved. This can be a move to either an earlier or later point in time, provided that the constraints of FRM and LRM are not violated.
When this approach is first attempted, it is not uncommon for it to be difficult (or even apparently impossible) to level out the workload while maintaining the constraints. In many (most?) cases, the underlying issue is that the activities are too large in scope; refactoring into smaller items allows for independent positioning on the timeline. If this is done, care should be taken to ensure that the individual smaller items can be “completed” – If not, then the amount of Work in Progress can grow rapidly.
In the next installment, we will examine some of the specific scenarios where these techniques can be applied.