Better Software - June 2008 - (Page 34)

to users, but sadly, such managers don’t get far in today’s management culture. Even the Big Visible Charts that are designed to make issues visible to the team have little impact. With enough political pressure, the number of critical defects “magically drops” as the deadline to go live approaches, but this does nothing to mitigate risk. As journalist George Monbiot [4] reminds us, “Tell people something they know already and they will thank you for it. Tell them something new and they will hate you for it.” death by a thoUsand cUts What managers often fail to understand is how seemingly minor things can result in project failure—simple things like a few days’ delay in getting access to other required systems. The developers must guess how the other system operates, and a few weeks or months later, that guess turns out to be wrong. Projects fail because a lot of little things go wrong, and by the time these minor things have made their way through the reporting structures and become visible, the project is headed for disaster. Insuring against this requires the invention of a reporting mechanism that will allow the implications of a set of little issues to reach the project decision makers much earlier. of having two-week to one-month development iterations provides an excellent deadline for measuring project progress. At the start of each iteration the team agrees with the key stakeholders about what team members will deliver, and at the end they show that the team has delivered what was agreed. This provides yet another early warning mechanism for all stakeholders about the ability of the team to deliver. leaRning the WRong lessons We hope that organizations could learn through project retrospectives, but in practice few organizations bother to really analyze their failed projects; when they do, they often learn the wrong lesson. There are so many ways to really mess up a project that it is easy to focus on a specific problem in a project and then mandate that all future projects must do something to mitigate that problem. So, for example, we see many companies requiring a requirements document to be signed off (“frozen”) by a senior manager before design can start because one project had a problem with requirements changing during the project. A good example of learning the wrong lessons is the way NASA responded to the Challenger disaster discussed earlier in this article. Yes, there was an inquiry and a report, but it did not fundamentally change the way that people went about their jobs. What is especially tragic about this is that Richard Feynman had to write a minority report to get his findings included, and even then, very few people responded to his key message: “For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.” As NASA has shown, it is difficult to avoid learning the wrong lesson. Yes, there were some specific issues with the technology, but NASA’s main failing was the cultural one of downplaying the risks and trying to sell the idea that spaceflight was becoming routine. Insuring against this is difficult because cultures are resistant to learning new ways of doing things—things can be changed within the existing framework, but changing the framework requires revolution. 34 BETTER SOFTWARE JUNE 2008 Focus on Becoming Flexible and Reactive late-bReaking neWs Insurance also is needed for latebreaking news about project breakage. Typically there is ample early warning that things are not quite as they should be, but normally there is no one thing that is really specific, just a lot of little hints that something bad is likely to happen. Although there is no simple mechanism for early detection of issues, the agile approaches have made it much easier. They have done this by taking the deadline—a much-loved project management tool—and making it a regular part of the day. Living with hard deadlines every day makes it virtually impossible for emerging problems to escape notice. On the micro-scale, many agile teams who are now using test-driven development or a similar practice that ensures clean code have a daily milestone for checking their integrated, tested, working code into the source code repository. With this daily milestone in place, teams can easily see when code quality is decreasing if the effort required each day to check in code starts to increase. Similarly, there is an early warning about progress, or the lack thereof, by the amount of functionality that is added every day. Some teams may ignore this daily feedback, but with diligence, the discipline of the daily deadline constitutes an effective early warning system about declines in code quality and team productivity. On a larger scale, the agile practice www.StickyMinds.com The most important bit of insurance a project can buy, however, is insurance against not comprehending that things are changing. A project needs to be viewed as a learning environment for everyone involved. If new information is not coming to light every day and being acted upon, no one is learning anything about the project’s true status, and the project is likely to fail. Constantly monitoring progress takes much of the drama out of uncertainty, and, therefore, much of the risk out of a project. Variability in project parameters is natural; being continually aware, informed, and responsive needs to be just as natural. Rather than planning for specific, known risks, projects should work from the assumption that something will occur that impacts the project, and create mechanisms that provide for the early detection and response to such events. It is not the known things that cause us problems. It’s the unknown and unknowable that cause projects to crash and burn. As an insurance policy, learning is rare but crucial to project success. Perhaps it was best summed up by Multics wizard Tom Van Vleck [5], who said, “You learn something every day, unless you’re careful.” {end} references: 1] science.ksc.nasa.gov/shuttle/missions/51-l/ docs/rogers-commission/Appendix-F.txt 2] Software Engineering Economics, Boehm, B., Prentice Hall, 1981. 3] en.wikipedia.org/wiki/Slashdot_effect 4] www.monbiot.com 5] www.multicians.org/thvv/ http://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/Appendix-F.txt http://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/Appendix-F.txt http://en.wikipedia.org/wiki/Slashdot_effect http://www.monbiot.com http://www.multicians.org/thvv/ http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - June 2008

Better Software - June 2008 Contents Mark Your Calendar Contributors Technically Speaking eLightenment Code Craft Test Connection Management Chronicles Agile Model-Driven Development The Myth of Risk Management Stop the Insanity! Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.