...
The same report says that the rate of success, 34%, is twice as high as it was ten years earlier. The Standish Group attribute the growth to the agile techniques we're using. We believe that, using these techniques, we can reduce the amount of time it takes to build a system, reduce the number of bugs, make the system more generalizable, getting more out of our development time, produce better internal documentation, communicate better with the system stakeholders, and last, but not at all least, create built-in maintenance procedures that will reduce the cost of the system over the years.
We started to work together in Mann Library ITS in 1997. There was no formal process for designing a system. Projects were top-heavy with committee members discussing requirements. Sometimes our colleagues talked about the projects, developing an idea of what they wanted, for months before handing the projects over to us. We sometimes had less time to build the systems than they had spent talking about them. There was very little room for error. Tight schedules led to poor design decisions, numerous bugs. We couldn't go back to make changes easily, even if we thought the changes would produce a better system. We saw systems go into production before they were ready. Morale was low.
We first tried to introduce some better structure into the design process by studying the Unified Modeling Language, UML, and employing the Rational Unified Process in the projects we worked on. We hoped UML would improve communication between the librarians who initiated the projects and the programmers who did the design and coding. It did, but we were still using the UML and the Rational Process in a development process that relied on a lot of up-front planning and control.
We added iterative development to the process. We chunked up the designs we had made into what we thought were coherent groups of tasks that produced systems with growing layers of complexity. We made risk diagrams to prioritize the chunks so that we wouldn't cherry-pick the easy functions. We wrote time-lines to fit the tasks into the weeks or months until the end of the project. Our work and our projects improved.
At about this time, a group of techniques emerged, gathered into what was named the Agile Development process. They became popular topics of discussion on software development and programming lists. We started to talk about them among ourselves, too. We knew we wanted to try them, but they were radical enough that we couldn't easily introduce them into our projects or the programming culture we were working in.
Now, in the final year of the MathArc project, the year planned as being the year for implementation of the system, we find ourselves working together in an environment
Claims about how agile development can help an organization
How Stories work
Decisions of managers
...