There’s a lot of talk these days about Agile methods. They may be called Scrum or XP or a number of other names. And a lot of companies and institutions are trying to make a transition to Agile methods. You may be wondering what the big fuss is over Agile Software Development, which is where the Agile movement began. Let’s review a couple of key things about Agile:
1. It’s not a new technology that came down from an academic institution or from a commercial enterprise. Agile is a set of principles and practices that were codified in 2001 by a group of practicing software professionals with a lot of experience making software products. This alone makes Agile unique, because it is what I call a “grass-roots” movement, coming from the people to whom the methods apply.
I like to say that they got together and said to themselves, “we’ve been so badly managed for so long, surely we can do better ourselves.” Of course they didn’t say that, but I believe they were motivated by the desire to have more productive and happier development teams. And from the business point of view, we can’t deny that software development has a poor track record – most large-scale projects do not deliver working software within the time, budget or quality constraints that were set out at the beginning.
2. To do Agile properly, the development team has to include someone who is in the role of customer or user. By “include,” I mean that a person in that role must be accessible to the software developers all the time – or at least every day for most of the day. The reason for this is to be able to have conversations about what is meant by certain requirements or functions or uses of the software. And conversations are key to the whole process, because we have learned over the years that written specifications and requirements never (NEVER) fully explain the actual requirement for the product. Why? Because often the customer herself doesn’t know what is needed until a working prototype is demonstrated.
3. Working prototypes are also key to the Agile processes. If the team cannot demonstrate a working prototype of the software at least every 3 weeks, then it is not doing Agile. And when the prototype is shown (to the customer on the team), the customer gets to say whether it meets the “story” or specification that was given to the team a few weeks ago. The customer also gets to participate in setting the priorities for the next 3-week development session.
What does Agile development mean for a business person who is contracting for or paying for software development? It means all of the following:
a. You are responsible for designating an authoritative & knowledgeable “customer” to the development team, and making that person responsive to the team on a daily basis. You also have to be willing to accept that person’s decisions on what goes into the product and what is left out.
b. You may set the budget and the time line (deadline for delivery) for the product, and you can make a list of the features or functions you want, in priority order, but you must not insist that all features on your list be included for any one deadline (at the price). Or you can set the features required and the budget, but then you can’t set a deadline for their completion. Why? Because making software – real working software – requires experimentation and trial and error. And that makes the job of predicting the complexity of a particular feature very uncertain. So as the process goes along, you can’t tell how long it will take to make any one feature. In compensation, you get to re-prioritize the features to be built next every 3 weeks or so.
c. Your project managers will probably have to learn that their roles will change with Agile development. They must accept the two new views (a and b) and learn to monitor the development progress without having the control they are used to with traditional project management. Why? Because software development is not like constructing a car or a building. The steps are known, but the “trial and error” part is still needed to find a satisfactory solution to the complex problems posed by software.
I recommend that you accept this, and learn to live with Agile processes. Because the satisfaction that comes from having real working software demonstrated to you every few weeks, along with the higher success rate for overall projects will amply compensate you for learning this new method of working with developers.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.
John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, Get Out of the Way, was published in May 2010.
For more information, please visit his website at https://johnlevyconsulting.com ,
Email him at info@johnlevyconsulting.com , or call 415 663-1818.
About John Levy