I made a simulation of an XP-like process. I won’t go as far as to say it’s exactly XP, but it’s a reasonable approximation. The first one is an unconstrained workflow with a single customer. It is a PIPE2 simulation, and the file is here. Multiple customers (or nested stories) would require a colored Petri net, which PIPE2 doesn’t support. One of the keys to understanding the model is the bidirectional edge between the customer and write a story. The team keeps writing stories until the customer doesn’t want any more stories and accepts a final build. Other keys are the bidirectional edge out of accept story and the inhibitor arcs into accept build. Those things give the model most of the “iterative goodness” you’d expect. Not surprisingly, the unconstrained workflow rarely reaches a checkpoint where the customer has nothing in process, so the deliver build transition rarely triggers. If we add a stories in process kanban limit, then there is also much more reengagement with the customer as a consequence. That model is here. I would be interested to hear of any improvements to the model. |
{ 2009 03 09 }
Keith Braithwaite | 10-Mar-09 at 12:31 am | Permalink
The limit on stories in flight is called “velocity” and is built in to XP. It’s interesting to have another reason to talk about why that’s important. Thanks.
I’m not convinced by the Customer has problems write a story arc. The customer generally has many more stories in mind than the team can deliver, and new stories are written in parallel with earlier stories being built. I just don’t see XP teams going around a “write stores until no more problems” loop with nothing else going on. Is this a widespread misunderstanding of what goes on in the contemporary planning game? In fact, they just pull as many as they’ve demonstrated they can do off the priority queue.
I also don’t buy that having pending or integrated stories inhibits accepting a build. To my mind iterative development means exactly the opposite: the customer is able (and eager) to accept a build knowing that work remains on some stories (given that other constraints are met).
PIPE2 looks like fun. Post QCon I might have a go at modelling an agile workflow in it myself.
Dew Drop - March 10, 2009 | Alvin Ashcraft's Morning Dew | 10-Mar-09 at 5:11 am | Permalink
[...] Extreme Programming workflow simulation (Corey Ladas) [...]
Corey Ladas | 10-Mar-09 at 9:39 am | Permalink
The accept build transition is there to model the case where the customer decides that she has enough and wants to disengage. Nothing requires her to ever take that transition. That case is important when a team is part of a larger group with internal dependencies or multiple customers. I changed the labels to clarify the intent.
How is SCRUM related to a Web Application Tester? | 15-May-09 at 1:44 am | Permalink
[...] Extreme Programming workflow simulation [...]
bin amer | 12-Apr-10 at 3:38 pm | Permalink
I have downloaded the pipe2 but how i can run this model? i tried to save it as xml file then open it but it did not work..
So, how can i run this model?