As a Scrum practitioner in an MV environment for the past 5 years or so, I think I can shed some light on this. First, the "Agile Manifesto":
>We are uncovering better ways of developing >software by doing it and helping others do it. >Through this work we have come to value: > >Individuals and interactions over processes and tools >Working software over comprehensive documentation >Customer collaboration over contract negotiation >Responding to change over following a plan > >That is, while there is value in the items on >the right, we value the items on the left more. The basic idea behind Scrum is that you divide the work to be done into little chunks and they are put in a list called the Product Backlog. Usually each chunk is an individual feature. The customer prioritizes the Product Backlog, usually in a meeting with the Development Team who supply some time estimates. Then the Team decides what Backlog items they can complete in a fixed time period (usually 30 days), called a Sprint. They commit to completing those items. "Complete" means fully tested, potentially implementable code. At the end of the Sprint, the Development Teams shows what they have completed to the customer. Rinse and repeat. Once the Sprint has started, the list of PB items chosen cannot be changed. This is the golden rule. If you need to change it, then cancel the whole Sprint, deliver nothing, and start a new one. In 5 years, we've done that once (and it turned out to be a waste of time). It's a big stick. Really important is the idea that the customer sees completed work each Sprint. This is guaranteed to give them ideas, and let them see where problems may come up. The result of that is that some things in the Product Backlog may move up or down in priority, and new items will be added to the Product Backlog. I am constantly amazed at how poor non-programmers are at visualizing how unwritten software will work. This becomes a non-issue in Scrum. Any non-trivial bug is simply added to the Product Backlog. We don't argue about whether or not something is a bug, a new feature, a change in scope or mission from God any more. If it is going to take the Development Team's time, then it goes in the Backlog and the customer can assign a priority to it. End of discussion. In my opinion, it's a risk free approach to at least try on a project. Worst case scenario, you waste some time working on the stuff the customer thinks is the most important. There's no reason why you need to ditch documentation. Just make it part of the definition of "complete". There are two major adjustments that programmers need to make. The first just happens by itself: The programmers realize they don't "own" the software. I can't remember the last time that we had a fight with the users over how the software should work, or what it should look like or whatever. If they're wrong, they'll see it in 30 days and they'll have to commit more of the development time to fixing it, but they won't be able to point fingers at the Team. We just build what they ask for. The second is that the programmers need to adopt a "just good enough" approach to programming. There's no value in making the code you write bigger than you need it to be, or to build in features that no one has asked for. Write the bare minimum to do the job required and nothing more. This doesn't mean writing crappy code or painting yourself into a corner, but don't go peaking down the project plan building in stuff you haven't got to yet. There's always a chance that you'll never get to that future feature. Our experience is that we've been able to open up a firehose of new functionality on the users with a small team and without building up a massive maintenance burden. There have been a few occasions when we've actually put a project on hold because the customer needs time to digest what we've done, revamp procedures, train personnel and re-evaluate future development priorities. How cool is that?!!! There are some Agile concepts that are a little tough to implement in an MV environment. Test Driven Development, for instance, is tough because you need an automated testing tool, and most MV programs constantly update the database, which means you need to roll back your database in order to reuse the test cases. All of which is tough. Dave Barrett Project Manager, Lawyers' Professional Indemnity Company (LAWPRO®) This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
