“Bones” for Dead Projects
Published September 26th, 2007 Under Software Development | Leave a Comment
Rest In Peace (from Latin requiescat in pace) is a sentence that typically appears on christian tombstones. Software development projects have usually the same destiny. Once they are finished, often the best thing that will happen is a little celebration for the project team. Nobody will formally look back at a project to understand what went well or wrong and why those things happen, so that this project can actually rest in peace and lessons learned could be used for the next projects. There is however an activity to analyze project after their completion. It is called “post mortem” analysis (so the RIP reference is not far) or “retrospective” in the agile approach. If you have not heard about this practice or never performed such activity, you should not be ashamed. I have never seen its implementation in my software development life. Even in the last Agile survey published by Version One, where a large majority of respondents are using an agile approach, only 39% of the participants are using this practice. Why?
The first explanation is that time is a rare resource in software development organizations. It is often associated to money in budget-driven companies. As there is a sense of urgency, people try to use their available time for the more essential (for them) activities. It is sometimes already difficult to justify taking some time to think before coding, that trying to have time to think after coding could seems an utopia. It is also difficult to tell as a project leader that you will spend some man/days after the project’s completion to think about what went wrong. Are you not supposed to do things right in the first time?
Our difficulty to create a context for constructive criticism is another issue faced when you try to institute some “post mortem” reflections. This is mainly due to the difficulty to separate the problems from the people that are associated to them. This is an important issue in organizations where professional excellence is a driver for monetary gains and career evolution. Will you speak openly about project problems if part of your (or your colleague) salary is a bonus linked to achieving certain professional goals? Maybe not…
There are however techniques that could help you to profit from lessons learned without creating personal issues, so that your past projects could really rest in peace and everybody could improve from a shared experience. You will find more resources about post-mortem or retrospectives for software development projects in the following articles:
* Refactoring Your Development Process with Retrospectives by Rachel Davies (HTML)
* Retrospective Agility by Tim MacKinnon in Objective View issue #8 (PDF)
* Plan of Action by Bas Vodde (HTML)
* Project “Post Mortem” Review Questions by Michael Greer (HTML)
* A Review of Small and Large Post-Mortem Analysis Methods by Mauri Myllyaho1 et al. (PDF)
* Agile Retrospectives: Making Good Teams Great by Esther Derby, Diana Larsen and Ken Schwaber (Book)
Fall 2007 Issue of Methods & Tools published
Published September 24th, 2007 Under Methods & Tools, Software Development | Leave a Comment
In this issue you will find an article on how to measure the progress of your agile projects, a framework for the transition to lean configuration management, practical advice on how to implement retrospectives at the end of you software development projects and a presentation of Microsoft’s Software Factories concept.
Fall 2007 issue’s content:
* Measuring Integrated Progress on Agile Software Development Projects
* Lean Configuration Management
* Refactoring Your Development Process with Retrospectives
40 pages of software development knowledge.
Download page for the PDF issue http://www.methodsandtools.com/mt/download.php?fall07
Doctor Beck and Mister Dilbert
Published September 12th, 2007 Under News, Software Development | 2 Comments
Following a dzone.com link, I reached an article accompanying a presentation made by Joe Rainsberger at the Agile 2007 conference. This article, “My Greatest Misses: XP 2000-2007“, is an honest experience report on the many issues and failures met by Joe Rainsberger as an agile change agent during these years, trying to teach others the merit of the extreme programming approach created by Kent Beck.
Seeing an agile coach admitting publicly its weaknesses dealing with people is an ironic situation that makes it an easy target to criticise agile approaches. If I would have like to add an additional “dark” humour remark, I would have said that the advantage of agile approaches above other processes is that they at least recognise their difficulties to deal with the “people factor”, as I never saw this kind of report from a RUP consultant. But I am not so bad. Or am I? ;o)
More seriously, I found that this presentation is a very courageous step from Joe Rainsberger. It is not easy to admit and talk about the problems he met as an agile coach, as it is always difficult for us to recognise our mistakes, without even thinking to make a public presentation about them. Joe Rainsberger does this very sensibly, as he does not blame other people for its own failures, a practice we too often follow. In my opinion, the main message in this article is not about the agile approach, but about changing software development people and organisations. This paper summarises very well the problems we could all face when we try to implement a new approach or a new tool in an organisation. We would like to find enthusiastic people who want to improve their work context and believing in the solutions that we are offering them to achieve this goal. The truth is that we work more in a dilbertian universe as describe in the Waterfall Manifesto, than in an agile paradise. In the reality, there are many reasons for developers to prevent change, to choose other solutions that the one we provide or simply to change at a different (read slower) speed that what we would like them to do it. I am always dubious when people advocates a “big bang” and “all or nothing” change strategy as this has in my opinion many chances to fail (we could have another interesting discussion about the differences between the “appearance of change” and the “reality of change” in an organisation…). There are some situations (very serious crisis, above average people) where change can happens more easily and quickly. However, in medium and large size organisation, you will found that change could only happen gradually and often “imperfectly”.
Joe Rainsberg’s paper should remind us that it takes many iterations to implement change… and to become an agile coach. Thank you Joe for sharing openly this experience with us, keep on your work and I am looking forward to read in 2014 what you will have learned again in the past seven years.
Jamie Against Steve
Published September 4th, 2007 Under News, Software Development | Leave a Comment
Goliath died long time ago and David did not survive much longer, but we can still watch some uneven battles between “normal” humans and (corporate) giants. Jamie Cansdale is the developer behind TestDriven.NET, a unit testing add-in for Microsoft Visual Studio. Apparently, Microsoft, whose CEO is Steve Balmer, is not so happy that a little self-described ” hobbyist .NET developer” propose a product related to Visual Studio. First they gave him a MVP award, and then they chased him with their lawyers to prevent him to distribute his product, without explanations about what they would like to change. You can read and follow the complete adventures on Jamie’s blog, but it looks to me that some companies are taking steps in the wrong directions as far as their image is concerned in the developers community.