Some good summary information here, Dave. One note about not needing specialized software is that you use a white board with post-it notes. Using a Kanban board (or similar) with Scrum makes a lot of sense if you are colocated. If you are a distributed team, a tool like scrumy.com might be a good way to do the "whiteboard with post-its." In anycase, I would content that a distributed team does need automated tools, although as you mention, they do not need to be dedicated to Scrum.
We use trac and export to Excel at times for various purposes. One of the key tools I am not getting from this handily is a burn-down chart, which I think is potentially an excellent tool for the team to see our progress as we go through an iteration. If we switch our iterations from monthly (and I'm not doing a good job with that) to weekly, the burndown might be quite irrelevant, so it is good to know you are not even doing them and still consider it a Scrum approach. Thanks. --dawn On Mon, Oct 19, 2009 at 8:53 AM, David A Barrett <[email protected]> wrote: > Just to be clear on this. Scrum and XP aren't particularly related. Scrum > is a project management methodology and doesn't speak to how the > programming is done. XP directly relates to how the development is done. > Three of the 12 XP practices have overlap with Scrum (Planning Workshops, > Small Releases and Testing), but that's pretty much where it ends. A lot > of the thinking, obviously, comes from the same place. > > You don't even have to be building a system to use Scrum. You could use > it to manage any other project that isn't a "defined process"; something > like planning a vacation would work well with Scrum. It doesn't work well > for things like building a house, because those kind of projects are less > exploratory in nature. > > The reason that Scrum works is because it embraces the one concept that > tradition PM methodologies dread - the fact that the act of starting to > build a piece of software changes everyone's understanding of the system. > It is inevitable that as both the programmers and customer see the system > come together they learn things about the system and their understanding > about it should work to best fit the business needs improves. Any > methodology that bases all of its detailed planning on the flawed > understanding that everyone has before the coding has started has got a > big leg up when it comes to failing. > > Scrum works because it defers virtually all of the decision making until > the last possible moment. No feature is build until it bubbles up to the > top of the priority list, and the specifications for it aren't finalize > until it's ready to be coded. This means that every decision is made in > the light of the greatest possible knowledge of the system possible for > that decision. And then all of those decisions are reviewed and > re-evaluated by the customer a short time later. > > The biggest stumbling block that people have is, "How do you do the > strategic planning?". The truth is, as I'm sure everybody already has > figured out, is that traditional strategic planning is either a joke, or > at best delivers a product that misses the customer's goals by a wide > margin. Traditionally, "done" is defined by identifying at the very > beginning of the project a set of features that the software must have. > But since this by definition based on an incomplete understanding of the > system, is usually pretty flawed. So you think you've done strategic > planning, but what you've really done is locked yourself into delivering a > flawed design. You don't lose anything with Scrum, except you acknowledge > at the beginning that you can't really tell when you'll be done because > you can't know what "done" means at this point - call it the "Heisenberg > Uncertainty Principle of Software Development". On the upside, with Scrum > you know that you won't waste time building features that nobody wants, > and the programmers will always be focused on writing the code that the > customer has identified as the highest priority - so it's almost a > certainty that you'll get to "done" faster than with a Gantt Chart. > > Finally, you don't need any dedicated software to manage Scrum. Our > Product Backlog is held in a Lotus Notes database. For reasons I won't go > into here, I'm not doing burndown charts anymore, but when I did I just > used an Excel spreadsheet. Most of our planning and tracking is done > using Post-It notes on a whiteboard now. It works better than anything > electronic that I've seen. > > > 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
