Re: [leanagile] Takeuchi and Nonaka's limitations (Was: Scrum without ScrumMaster)
- Hi Ged,I've put my comments in-line below.On Fri, Dec 16, 2011 at 11:22 AM, Ged Byrne <ged.byrne@...> wrote:--
Wouter,Thanks, that helps a lot. I've worked on a few Scrum projects and find it effective. However, as a process geek I also find it frustratingly lacking in detail, which is why I've gone looking into it's roots to learn more.One thing that concerns me is that it is possible to do Scrum exactly right, and not get the desired results. However, time is teaching me that this is true of all methods, and that Scrums simplicity simply makes this easier to see. Other methods bury it under a see a definitions.I'm coming to the conclusion that Scrum is rather like the optical illusion with three pac-men and a triangle that isn't there, and yet you can clearly see the triangle: http://www.sandeepkejriwal.com/images/circle_triangle.gifWould you agree that Scrum defines that circles, but all of the work actually occurs within the triangle? As architects and artists often say: the empty spaces in between are the most important part.I think that that's an excellent analogy!Another part of the background for Scrum is the idea of complex adaptive systems. Those type of systems are created by setting clear boundary conditions (scrum rules and artefacts), feeding the system some attractors (user stories), and monitoring the output (review). These kind of systems very explicitly don't prescribe the detailed functioning of the system, which nicely mirrors your non-existing triangle.If you want a better description of this relationship, I can recommend this article by Joseph Pelrine: http://www.cognitive-edge.com/ceresources/articles/110510_On_Understanding_Software_Agility.pdf . Jeff Sutherland's Scrum Papers also give some more detail on his thoughts behind Scrum's set-up.If you do agree, is there a danger that people could miss the triangle if they are focusing to closer on any individual pac-man? I believe I've seen this happen more than once, but I don't have the breadth of experience to be certain.I won't say that that doesn't happen:-) But usually there is then indeed a tendency to NOT focus on some of the required boundaries of Scrum. Or simply not enough understanding of some of those conditions. Or, they'd really love to put that little pac-men there, but there's a dodecahedron in that particular location in their company. You'll observe that the triangle *doesn't* appear if you replace one of the pac-men with another shape...We've had great success combining Scrum with DSDM. DSDM defines a clear scope, roles and responsibilities. I used to believe that Scrum was lacking these definitions and needed them. Now I'm not so sure.When I've worked on projects that were purely Scrum it has been less successful. The projects don't fail, but I feel they could have done better. You wrote:One of the differences between what's described in that paper and Scrum is that in Scrum (and Agile in general), the feedbck loops are usually much shorter. Even in a large project, there is supposed to be continuous adjustment of requirements because the customer can see intermediate results. In software, this is much easier than in manufacturing. This makes the learning process much quicker.Would you agree that for this to work you must make sure that the right people must be involved in those feedback loops in order to provide the right breadth of understanding on the results.I've observed a project where the "customers" did not directly interact with the team. They fed them epics, which were individually broken down into stories and implemented. The customer were internal managers, who did not take much interest in the individual sprints. They were only interested in the deliver of the epic. Would you agree that this is an anti-pattern for Scrum adoption? If so, what would you consider the best approach to improving the situation?Yes, that is definitely an anti-pattern, one that happens quite often when organisation are transitioning from a waterfall approach. It's quite natural, as this is the way the customer is used to working. In fact, by keeping that distance it was much easier to ensure that any type of failure of the project was not on their heads...Exactly how to deal with that depends on the circumstances, and often you'll have to try a few different tactics before one works... In this case it's very important that the customer becomes convinced that his involvement is a critical success factor for the project.One way to explain this is that there are normally always change requests to fix misconceptions after delivery. Feedback on the individual user stories can help avoid those. Another way to encourage involvement is by steering towards earlier delivery ("you can release base functionality 2 months earlier" can be a very convincing argument:-)Finally, there is a more formal/nasty way to go about it, that I've used on occasion. These customers are very much used to milestone-and-sign-off thinking. By explaining that there are sign-off moments both before (story definition and acceptance criteria) and after (sprint review) a sprint can stress the importance for them. And then saying not attending the grooming session and sprint review is taken as positive sign-off can make that complete.This is not very agile (very much contract negotiation), but can be a way to get people into a setting where collaboration comes more naturally to everyone involved.Thanks for taking the time to answer my quesitons. I don't have the breadth of experience I would like to properly understand Scrum and so I hope you can help me with your experience. I also hope that others mght find the conversation informative.You're welcome. And you'll notice that people here really like discussing these kinds of questions, especially when so thoughtfully brought.Wouter
Wouter Lagerweij | wouter@...