Jul
16

XP 2005 TOC Poster 1

Theory of Constraints session at XP2005, participants were given an experiential crash course in the Theory of Constraints. They then had to apply their new knowledge to solve real world problems.

They did this in 3 groups. Each group had a “customer”, the others played “TOC consultant” to help the customer to understand and improve their system.

XP2005_TOC_poster1_small This is the output of one of the groups: it gives an overview of the whole process from requirements, over analysis, development, testing, writing manuals, training and finally putting “stuff” into production.
Click to enlarge the image
(picture courtesy of Marc Evers)

Remarks about the poster

The goal of the system is to “Put stuff into production“. An IT system can only generate value when it’s put into production use and users are actually using it (well). Hence the User Guide and training before releasing. Part of the value in releasing a system is the feedback and ideas you receive to improve the system, hence the loop back to project initiation.

The bottleneck of this system was actually two bottlenecks (indicated as [1] and [2]), which ocurred at different times during the project. Bottleneck [1] holds the system back at the beginning of the project; bottleneck[2] holds the system back near the end of the project. It’s not as bad as a “constantly shifting constraint”, but we need to focus in different areas depending on the phase of the project.

Notice how the part marked with “XP” is between two bottlenecks. This is something that has been observed in many (if not most) XP projects: XP has very effective techniques to exploit, subordinate to and elevate a development team bottleneck. If you apply the techniques, the development team’s throughput improves a lot and it’s no longer the bottleneck. The bottleneck shifts. And who’s the bottleneck then? Usually the Customer (role) becomes the bottleneck, either in keeping the team fed with stories or in accepting the stream of finished features. Or both, as in this case.

XP in a nutshell, from a Theory of Constraints perspective:

  • XP assumes that the development team is the bottleneck
  • IF this is correct, XP increases the throughput of the development team and thereby shifts the bottleneck to the Customer
  • If this assumption is not correct…

In the session we chose one bottleneck to concentrate on, the one the customer wanted to remove the most.

Our newly graduated “TOC consultants” suggested several ways to exploit, subordinate and elevate these bottlenecks, coming up with some novel ideas that their customer could apply to this situation. What are some of the interventions we could suggest here?

  • We have two bottlenecks, before and after “XP”. They are bottlenecks at different times in the project. If they are different resources, they could help each other out: bottleneck [2] resources can help (subordinate to) bottleneck [1] resources at the beginning of the project; and vice-versa at the end of the project. E.g. testers can help analysts at the start of the project by devising acceptance tests; analysts can help testers to perform and analyze acceptance tests.
  • We have a non-bottleneck resource, the “XP” team. They could subordinate to both bottlenecks, by spending some of their slack time in helping the bottlenecks. One way of doing is to assign one person from the development team to “follow the release”. This developer helps the analysts to write stories and clarify acceptance tests. They also help the testers during acceptance, the writers writing manuals, the operators installing the software. Their primary job is to smooth the interface between the development team and the world outside the team. They have a good overview of both the functional and technical content of the release. While this developer works at the end of the release, another developer starts preparing the next release and follows that release through to the end. This is a “rolling wave” planning, which is great for continuity and is a good way of “leveling the load” (One of the 14 principles of the Toyota Way). You do need people in the development team who are skilled at interfacing with other teams, who understand both the functional and technical side of a project…

Comments are closed.