At Agile and Development conferences this year some sessions have been looking at how to improve Agile techniques using failed projects as examples. Discussing some of these issues and reading blogs and articles it appears that a significant percentage of Scrum projects have failed and it is not quite the silver bullet many expected it to be.In this weeks video blog I asked some of the leading Scrum experts (Dan Rawsthorne, Alan Shalloway, Sanjiv Augustine and Ken Pugh) what they thought the most common reasons for failing Scrum projects is and what advice they can give to resolve this. In their opinion, it appears management and managing the Product Owner are currently areas to improve upon.I believe that many organizations that practice Agile techniques do not strictly follow Scrum, XP, Crystal or any of the other flavors of Agile directly, but instead adopt a hybrid ‘Agile-esque’ practice using parts of these methodologies that they feel work best for their projects. This was reiterated at Bob Martin’s keynote at Agile 2008 where he also stated that ‘Agile’ will be the term used as a practice rather than the umbrella for the individual practices such as Scrum, XP etc. Will this see an increase in Project success? Only time will tell.One opposing theory is; teams will adopt whatever practices they can implement easily and quickly to comply with senior management edicts so they can claim their organizations are ‘Agile’ (whatever that means to them?!?). The reality is, underneath they will really be working in a Waterfall manner with little change to project success.Such proponents of this theory will state that only by following the practices strictly, can you achieve project success repeatedly (as demonstrated by Menlo Innovations).

Tom and Mary Poppendieck are two leading evangelists of Lean software development who share their experiences at conferences on a regular basis. Their first book was an excellent introduction to lean principles and tools, and this book continues the theme by explaining the concepts in the real world, and how to implement them.Firstly, let me say that, in my opinion at least, this is a book for managers who want to find out more about lean processes, rather than being aimed at software engineers or architects. And in this context, it does very well. The theories and concepts described are well laid out in individual chapters that cover: Principles, Value, Waste, People, Knowledge, Quality and Partners. The book quickly gets you thinking about how to start implementing these ideas in your own organization.For a book that is less than 250 pages, I was surprised by how long it took me to read. This was mainly due to the large number of very good and equally intriguing references and examples that compelled me to investigate further.My favorite chapter is “Waste,” including the description of the “Seven Deadly Wastes.” Sound advice is concisely provided in the form of often-missed principles that lead to waste, for example:If there isn’t a clear and present economic need for the feature, it should not be developed!Other, less obvious examples are also given such as:Rotating/replacing staff – handoffs are a good example of losing tacit knowledge (waste)Map a Value Stream - although not necessarily accurate, does identify waste from the customers’ perspective.Waste is one of those concepts that is somewhat subjective, and in one part of the book there is an example of an organization that ran multiple projects to develop different versions of the same system against a hard deadline (absolute minimal functionality but guaranteed, more functionality but not guaranteed, ideal system but very unlikely to be completed by the deadline).This can appear contradictory to a key agile principle: to develop only what you need (and indeed to a key Lean tenet, which is to reduce costs). The authors justify this by stating that one system will be implemented by the defined deadline and then something much better will be built in time for the next iteration. However in my experience, organizations tend not to have the resource available to perform simultaneous development of the same system. It is more usual to deliver to the customer as much functionality as is available by the deadline (remember that it will be working through smaller iterations) and then to implement any improvements over time depending on priority against other parts of the system.The chapter on quality begins with a discussion of the Polaris Submarine project and moves onto a description of iterative development. Then follows details of what I would refer to as implementing quality gates, code reviews, test driven development, standards and continuous integration. More detail and an example of the benefits of CI would greatly enhance this chapter.I would like to have seen more examples from the software industry to explain the many well laid out concepts. But some of the brief examples used from other industries hit the mark well, for example: Deadlines! Daily Newspapers and Concerts/Theatrical Productions hit deadlines constantly and consistently unlike the software industry.I believe the best example in the book is the Rally Software Case Study, where they explain that it took 14 months to eliminate technical debt using a Strangler approach. Some of the concepts in the book read as if these are quick fixes to implement that will see a fast return. This example highlights the fact that process management change does take time to take effect.Overall, I consider this to be a great book for laying out the principles and how to begin to implement them, especially for managers wanting to find out more about lean software development. It covers the concepts well and provides excellent further reading resources.The Poppendiecks’ companion site provides an interview about the book. Other useful resources for anyone who wants to learn more about Lean are the Yahoo groups leanprogramming. and leandevelopment.