Together The Difference It Makes
This chapter is from the book
This chapter is from the book
This chapter is from the book
The power of one...
Ladysmith Black MombasoToo little process—it takes extraordinary people to do ordinary
things. Too much process—extraordinary people can't do extraordinary
things.
Jim Lee, Hewlett-PackardThere can be no single software development process.
Ivar JacobsonThe impossible we do today— miracles take a little longer.
Anonymous
What can development teams do when faced with impossible demands for more functionality in ever-shorter timescales? This chapter opens with a consideration of the dilemma that many project managers face. We then introduce the model-build-deploy platform, Together ControlCenter, and consider how the new way of thinking about software development processes that Together encourages can provide a framework for dealing with such impossible demands and delivering quality software in short timescales.
We Need It Now!
"I'm sorry David. The TV advertising campaign has been booked for weeks now, and we can't afford to delay launch of the new services by even a day. It must go live in three months time!"
As the marketing manager sat down after his presentation, David, who had been the leader of a small team developing the bank's Internet project for a little under a year, decided not to ask the string of what-if questions that were stacking up in his mind. Like, what if we can't deliver the new architecture, let alone the new functionality, in these timescales? and What if your advertising campaign actually succeeds, and we triple the number of registered users within two weeks of the first screening?
David was proud of his team's achievements. Without much of the hype and hyperbole of other net banks with stranger names but far fewer users, they had built a service that was gaining week by week in terms of the number of registered users and frequency of use. At the current geometric rate of growth, they would outgrow their hardware and software architecture in about 9 months. If the new TV campaign was successful, that window would reduce to little more than 3 months. Meanwhile, they already had a backlog of desirable features that would have kept the team very busy for all of that time, without all these new must-haves from marketing. What were his options now?
In today's speed-driven markets this scenario is all too common. It has probably always been true that time to market and meeting schedule targets are the key drivers determining the success or failure of major investment projects, but software projects in the current decade are likely to find those two drivers override most other considerations. Jennings and Haughton (2001) put it most aptly in the title of their study of the influence of "speed" in the competitive business environment: "It's Not the Big that Eat the Small...It's the Fast that Eat the Slow."
So, if team leaders accept that timescales for delivery of the system are paramount, how can they deal with the fact that what has been asked for is actually impossible? Brooks' Law (Brooks 1974) tells us that putting more software developers onto a late project will make it even later! If David just recruits more staff, he won't solve the problem.
He could say "never mind the quality—just release it." He could, but it is an obvious recipe for disaster, and even in the short term, it will cost his company far more in lost business and tattered reputation than could be compensated by early entry to the market. In banking and many other industries, it could also compromise security, reliability, and safety. Or it might simply be illegal or negligent. Software teams must ensure all software is "fit for purpose," which implies defining measures and standards of quality and then ensuring each release reaches this mark.
One option—one we are primarily concerned with in this book—is transform the processes and the development environment of the software development team to make it radically more productive. We have at this point to declare an interest in the Together platform, which is the principal subject of the book. We both consult and train teams using Together, and one of us (Andy) is an employee of the company that develops and markets it. Whatever our prejudices, our experience does show that Together genuinely accelerates software development projects, so we would certainly recommend that David adopt Together on his project.1
However, even with significantly enhanced productivity, David's team will not be able to do everything the marketing department has asked for in the timescales. David's final option must be to reduce the scope of the project. By discovering what the business imperatives are, the team can deliver enhancements to the current capabilities within the specified period while also preparing for longer term requirements. If the team follows this route, it will need a flexible and lightweight development process with rapid feedback loops to report holdups and roadblocks—and it will need to plan contingencies accordingly. The other implication of this choice is that there will need to be many deliveries of the software, each adding incrementally to the desired functionality. The development team's question to the business team is not so much "Which of these requirements do you not want delivered?" but "Which ones will contribute most to the business now, and therefore, which ones should be delivered first?"
The users and business planners always want all the new functionality delivered yesterday. The financial controllers would like to spread the expenditure of very small amounts of money over very long periods of time. It is the role of the development team to push back against both these pressures to deliver the highest priority features in the shortest possible timescales. Month by month (or timebox by timebox), the team needs to focus on the functionality that is of highest priority and deliver "frequent, tangible, working results."
This iterative and evolutionary approach to software development is the process that runs through the whole of this book. It is a process of which Together is a central part, since it allows us the flexibility to build on existing software and to add new functionality piece by piece. The aim of this first chapter is to introduce: the principles which underlie our approach (regardless of development platform); the essential elements of the Together development platform; and the essential elements of a simple yet generic development process.