In this presentation filmed during Agile 2008, Wes Williams and Mike Stout share their recent experience with a large distributed team, the planning hurdles they encountered and how they passed them, and their recommendation: avoid large distributed teams.
Choosing the right features can make the difference between the success and failure of a software product. Mike Cohn presented 'Prioritizing your Project Backlog' at Agile 2008 on how a project backlog should be organized and prioritized and non-financial techniques for prioritization such as kano analysis, theme screening/scoring, relative weighting and analytic hierarchy process.
Some teams use a Sprint 0 to prepare their product backlog, the infrastructure (development environment, CI server), ... .Is this part of Scrum? Is it useful?
Having difficulty prioritizing the backlog? Luke Hohmann has described a method to make quantitative decisions about which backlog items should be considered first. In addition to the usual attributes such as implementation effort, Luke suggested adding attributes to measure stakeholders needs, strategic alignment and to ask whether the item is driving profit.
TargetProcess has released a free 5-user Community Edition of its Agile project management software. The Community Edition contains the same features as the full edition of the product with two limitations: a maximum 5 users, and no support.
On April 15th Thoughtworks will release Mingle 2.0, nine months after the initial release of Mingle. InfoQ got some time with product manager Adam Monago to talk through the new functionality provided by Mingle 2.0.
Danube Technologies has just released the 3.0 Release of ScrumWorks Pro, last mentioned in August 07. ScrumWorks Pro is an Agile Project Management tool that help track team(s) progress through individual iterations and whole releases. In this release changes focused on two areas: usability improvements and the use of MySQL as the backend database.
The involvement of customer in an Agile project is taken for granted, however in many situations, intentionally or unintentionally, the customer may not follow the Agile practices. An interesting discussion on the Extreme Programming group tries to decipher the situation and find possible solutions.
Johanna Rothman is an organizational consultant, coach and co-creator of the AYE conference (Accelerate Your Effectiveness). Deborah Hartmann interviewed her at Agile2007 about her third management book - and discovered that there are names for some of the the scheduling games that cause us to spin our wheels, including: Bring Me A Rock, Queen of Denial and Pants on Fire!
It's easy to agree with "anything more than 'barely sufficient' in is waste," but it's more complicated when we actually need to customize a process for a particular project. At Agile2006 Todd Little shared a model to help leaders choose the right flavour of Agile based on project and team attributes, and he emphasised the need to actively steer projects as development progresses.
A recent discussion on the Scrum Development list looked at: “How does a customer measure the success of an Agile project?” Emphasis on: “measure”. The discussion seemed to agree that clients do need a way to track success in their terms, and various metrics were suggested, though it was agreed: it depends on the situation and the customer.
VersionOne recently announced Release 8 of their agile project management and team organization tool suite. This new release features an all-new user interface, introduction of a release forecasting toolset, and additional plug-n-play integrations for some popular open source tools.
Michael Dubakov recently expressed warning against the measurement of individual velocity and individual estimate accuracy. His view: measurement of these metrics not only provides no more useful information than is already available with their team-level equivalents, but may also have a tendency to encourage teams into behaviors that reduce effectiveness.
Although many people consider iteration to be a key characteristic of agile software development, some question whether or not they're important, and add value to an agile method, or if they're superfluous, or even wasteful. InfoQ has assembled a roundup of arguments on the subject, to help agile teams decide if iterations are important for them.
What value do teams get from measuring velocity, beyond the ability to reasonably estimate commitments for the short-term future? J.B. Rainsberger proposes that teams spend less energy scrutinizing velocity and more energy thoughtfully identifying and eliminating areas of waste in their projects.