Is Agile at all compatible with project management? Should we even try to make them talk to each other? The answer in this talk was a resounding, YES. The problem is that most of PM practices and most of Agile practice have been incompatible.
Wolfram Müller of Speed4Projects talked through his views on Agile (for an audience not quite so familiar with the concept), and on how some of the TOC applications could be thought of as working together with the Agile mechanisms.
I did like Müller's basic description of Agile as, "Let the people work." Both Agile and TOC talk about similar challenges in environments like projects and software development: what is the value of the effort; who is the customer; engaging people to work together; WIP control; and multitasking reduction. The incompatibility is around how the approaches tend to handle these things. The "let the people work" description of Agile has to do with the assumption that teams can figure out what they need to do without significant management oversight. Any kind of additional project management seems like too much oversight.
He also made the interesting observation that there are buffers in Agile, but many people don't like to hear that. People can modify their work estimates (more/fewer story points), or pull in a different amount of stories to a fixed-duration sprint. The other evidence for this is that when crises strike, more work can get done than was originally estimated. Just as we say in CCPM, we know there is safety in the individual task estimate - and it is there for very good reason. The CCPM approach has a lot to do with modifying the operational focus so that there is less incentive to protect individual work - the goal is to complete the project on time/scope/budget.
The general approach for Müller is to look at how work flows through the various levels in a business that includes software development. At the high level, there is an overall project which needs software as a component (maybe THE component).
The software development tasks are mostly a big jumble of "stuff to be developed" (stories / use cases in software). There often is not a sequence of work that ties together the stories. This makes for a challenge in project management. But at the story/task level there is a sequence of work to the development work, like the sequence ready-doing-testing-done. Müller suggested that at this level, it looks very similar to a repeatable, defined flow. For the TOC audience, something like Drum-Buffer-Rope might apply. I believe approaches like Kanban and other software methods that help manage the flow can apply here - with Muller's cautions that these need to support the overall direction and not just be islands unto themselves.
Again, for the TOC audience, what is the constraint of the development activity? Müller strongly recommends that it should be developers. Not testers/testing or any other resource, but developers. This then helps focus the flow of work and exploit/subordination decisions as well. For example, This recommendation also leads to a simple test about whether there is too much work-in-process: How many developers are there? How many active tasks? If # tasks > # developers, you have too much.
What I missed in the discussion was the details of how the local workflow management ties back into the overall project management. He hinted that you could use the cumulative flow diagram (CFD) to provide estimates on remaining duration. I'd just like to see how this works to understand a bit better.
Upcoming book: Müller is working with Steve Tendon to create a book related to the topic, Taming the Flow, to be published in a week or two. I may get a pre-publication copy to review in the next few days.