In regards to pull, some observations:
I think any time you try to look at “Pull” as if it were a complete, end-to-end pull system, you’ve taken it too far, and observations based on that analysis become difficult to defend. Don Reinersten says something like “Don’t try to implement a perfect pull system. Nobody does that. Toyota doesn’t order one car’s worth of steel.”

In software development, especially, I think it is important to understand Pull in terms of two factors: Customer Value and System/Team Capacity. The Lean principle of defining value only in terms of what the customer values is key because we often forget that as software developers. Traditionally, we have tended to call the job “done” at some point before real customer value is realized, and then move on to the next thing. Saying things like “we delivered 28 story points this iteration” reflect this misunderstanding of “value”.

I’ve never seen a software development team that had too little to do. Perhaps I’m mixing in some ideas from Kanban here, as well, but I think that understanding the system’s real capacity, and implementing pull to maximize the value delivered through that system is where you really start to see the value of Pull in software development.

In a system that limits Work In Progress and focuses on delivering small units of real customer value (as defined by the customer), implementing pull will have the effect of only allowing new work into the system when the system has capacity for that work. Pulling new work into the system, working backward from the point of delivering customer value, allows for real priorities to be set, and followed through the value stream. When work is pushed into the system beyond its capacity, the priorities put on that work become unclear as work backs up in the system, and work must be re-examined and reprioritized at multiple points within the value stream.

So, in my estimation, one of the big benefits of “Pull” in software development is that it keeps the focus of the system on delivering customer value at an optimum rate – and combined with a limited WIP system like Kanban, keeps cycle time low and priorities clear, by not overloading the team with more work in process than it really has capacity for.

Chapter 3 of Extreme Programming Explained mentions Options ( Not sure if it refers to Real Options though ).

The chapter is partly based on the work of Hakan Erdogmus and John Favaro. They produced a meatier paper that I am struggling to find…… just found on John’s web site ( http://www.favaro.net/john/home/publications/xpecon.pdf )

Chris

You mention, XP Explained first covers Real Options. I’d be interested to see what part(s) specifically you think maps to Real Options (all of it/one particular practice/the discussions around it). Did they use the term “Real Options” as well? (My memory does not serve me well)

Thanks for taking the time to publish your thoughts on this topic.

This post was mentioned on Twitter by OlavMaassen: Posted article on Lean and real options and how real options can help improve Lean Software Development: http://bit.ly/4wcCGN...

It’s very true and lots of people often make the mistake and think that software development is software /manufacturing/.

I would like to add this too:

Effective software development is about choosing what to do. And maybe more important, what NOT to do. But in order to be able to choose you need to know your options and the expire criteria.

Thanks for taking the time and writing this excellent blog about real options from a Lean perspective. Or is it looking at Lean from a real options perspective.

This post was mentioned on Twitter by dchelimsky: RT @PapaChrisMatts: My thoughts on “A community of thinkers”. Good stuff guys. http://tinyurl.com/ya29j8y / Hear! Hear!…