Good job and thank you for writing that up. I've been trying on the scrum front, after having some past project successes with various agile techniques, but I do not feel like I'm particularly successful on the Scrum front.
We have our "tickets" for requirements (user stories) and tasks in Trac, so we attempted to get http://www.ohloh.net/p/agilo-scrum installed, to no avail. I am now attempting to use scrumy.com, which I like but it has no cross-reference to trac so that dual entry doesn't quite work for us and we haven't yet gotten into the swing of it. Of course the tools do not make Scrum, but it is difficult to do Scrum without at least a burn-down report. Additionally, there are a few best practices we do not have, such as all developers being remote (each typically being many states away from the next) and most work just a few sweat-equity hours each week on the project. I asked for suggestions on an agile list a while back and they suggested going to a weekly sprint, which I have tried a few times. The good news is that even with the few techniques we are using from Scrum, such as switching from a daily to a weekly Scrum meeting, and from having a "stand up meeting" to a skype conference call, but asking the same Scrum questions, we continue to move forward, even if at a very slow pace. We are not standing still, spinning or digging a hole as software projects can sometimes do. We are simply failing to use some of the key aspects of Scrum and failing to move fast, things I suspect might be related. I "feel like" I could do better, so any suggestions, given our constraints (no one co-located and no one getting paid, for example) would be much appreciated. Thanks. --dawn On Thu, Oct 15, 2009 at 3:01 PM, David A Barrett <[email protected]> wrote: > 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 > -- Dawn M. Wolthuis Take and give some delight today _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
