Theory of Constraints and Agile Project Management

Recently on the LinkedIn forum PM Toolbox, Arash Sadati asked for comments about tool support for how Goldratt's Theory of Constraints (TOC) or Critical Chain Project Management can be integrated as part of the Agile Project Management. Here are my thoughts on the subject.

One thing all agile projects share is that - because of a conscious removal of dependencies between features wherever possible - they will be resource constrained rather than critical path constrained (a generalisation but broadly valid). Methods like Scrum-XP try to avoid specific role constraints (e.g. we can't make progress because we don't have a BA or a GUI expert or a middleware expert available) by specifying only 3 role types (Product Owner, Scrum Master, Team Member). So the team as a whole must to some extent be generalists (or at least prepared to learn / fill in specific roles) to reduce the risk of role constraints. In any real application of Scrum of course such role constraints may be real and teams will have to pay attention to them. The default condition though is worth understanding because it's a means to keep the effect of role constraints to a minimum.

FDD defines many more roles and I think as a result there is a greater risk of role constraints. Availability of specific class owners for example is a typical problem which Palmer and Felsing discuss in their book on FDD. Flexibility, especially in small teams, for people to wear multiple role "hats" is crucial. The really interesting observation in comparing agile to waterfall is the requirements process where detailed specification of features is ideally "just in time". David Anderson and others point out that it is a serious waste of precious resources to allow too much work to be done on future requirements when the critical constraint is the development team.

When we were specifying the xProcess product which is designed to support any priority-driven process (any agile process in other words), we did want to be able to give visibility to problems arising from role or resource constraints. Patterns of tasks can be defined in custom processes that require specific or general roles - or even allocation to specific team members - so that forecasting can take into account not only the total development effort available, but in the cases where specialised roles are required. It can therefore show the impact of limited availability of critical roles. Custom reports can be generated to show resource utilisation, and where these show less than 100% utilisation, the situation is likely to be one where specific roles are "critical", requiring other roles to wait for them.

Latest patterns for FDD

The release of 2.8 this week sees some interesting updates to the FDD patterns. Like the Scrum updates for xProcess, the new FDD process uses "composite tasks" to define the structure of FDD projects, allowing them to be expanded top down as the details of feature sets and features are defined.

This hierarchy diagram shows the structure of the FDD project pattern. For those familiar with the method, the 5 stage process is visible in the top-level tasks:

1. Develop an Overall Model
2. Build a Features List
3. Plan by Feature and
   
4. combined with 5. Design by Feature - Build by Feature.

Note that the darker blue nodes are patterns, so these can be further expanded in the hierarchy diagram or viewed in the graphical pattern editor.

Here for example is the hierarchy view of the Feature Set pattern, which groups together a set of related features into a deliverable package which can be scheduled for a particular release. Note that here the "Features" composite task, as well as containing Features, may also group Defects (work on correcting issues from previous releases) and Tasks (any other work related to the Feature Set).

The Feature pattern has already been the subject of a number of postings on this blog (see for example...). The pattern diagram shown here uses a quite traditional view of the tasks required to deliver a feature with the emphasis on Specify (the "design by feature" part) and Develop (the "build by feature" part). We can see more detail of this task pattern by using "Go Into" in the pattern editor. Here the specific artifacts and quality gateways that are associated with each task, as well as the number and types of roles required to carry out the task, can be reviewed and modified.
Clearly other ways of breaking these tasks down are possible, and some of the FDD literature (for example Palmer and Felsing's book Feature Driven Development) provide alternative schemes that place stronger emphasis for example on design and code walkthroughs rather than the test-driven approach implied here.

The beauty of xProcess is that the task patterns are all easily and graphically editable so you can make this method match exactly what you want the FDD teams to carry out. As all plans, tasks, artifacts, processes and time records are stored in the xProcess versioned data stores, the compliance with your process can be monitored at any time, either to improve the process patterns where teams have discovered better ways of working, or to improve the teams' approach by following the best practice captured in your process patterns.

FDD has a three-level hierarchy of functionality: Features, Feature Sets and Major Feature Sets (also referred to as Business Areas). So far we've seen where Features and Feature Sets appear within the hierarchy of a project. Major Feature Sets (MFS's) are handled slightly differently. MFS's are created by an xProcess pattern in a similar way to the other patterns we've looked at, but they result in categorized folders rather than tasks which are part of the project hierarchy. This is so that the Feature Sets are visible within the Gantt charts and release schedules. Because of the scope of major Feature Sets, they generally do not have such a clearly delineated start and end date and so it would not make the project schedule clearer to include them in that way. So opening a MFS folder shows you all the feature sets and features in that category. You can then review and prioritize the features in just this one business area. Here's an example of a MFS in a particular project with its corresponding Gantt chart (click on the diagram to see more detail).
Finally in this brief review of xProcess FDD, the pattern for a Release is also instructive. Again a prioritized folder is used for the Release pattern, rather than a task in the project task hierarchy (see the Scrum method for an example of a process that uses this alternative). By default just one release will be created in the project (with a target close to the end of the project). However the Project Manager can create as many additional interim releases as he requires. The "scope" of the release is defined by moving the required features/feature sets/tasks into the release folder. The scheduler of xProcess uses the implied and defined priorities of these tasks to calculate completion dates and provide alerts if targets are unlikely to be met. As the project progresses, the scheduler uses the input from team members completing and possibly re-estimating the required effort for tasks to give immediate visibility of targets' status and costs providing all stakeholders of the FDD projects timely and detailed information to support decision making and further planning.