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.
Target Process 2.7 has been released. Target Process is an Agile Process Management tool that automates many of the tasks associated with an agile project. Notable features in recent iterations include visual iteration planning, program level release planning, individual velocity reports, and more.
It's not uncommon for an organization to have one group of developers who need to complete multiple projects. In those situations, how should the group be structured, and how should their work be planned and allocated?
Individuals and interactions over processes and tools is the very first of the values of the Agile Manifesto. Tools, however, seem to be a big part of development on most Agile teams. When does a tool help and when does it hinder (Agile) software development?
"Big Visible Charts" aren't unique to Agile - Lean manufacturing also has its Kanban Boards. "Kanban" roughly means "card or sign," and each Kanban card is "pulled" onto the board only when the work represented by an "in progress" card is retired. In this InfoQ article, Kenji Hiranabe proposes using Kanban Boards to track Agile project status (Time, Task, and Team) to enhance collaboration.
Version One recently announced their new release of V1: Agile Enterprise, InfoQ provide an overview of the new functionality in the latest release of one of the more prominent pieces of Agile project management software.
In this fourteen-minute interview, Nils Haugen described "Planning Poker," a simple mechanism for arriving at estimates collaboratively, which has additional team building benefits and improves team estimates over time. Haugen shared his views on why this technique is an important tool for Agile teams in this InfoQ interview.
InfoQ had some time with Mingle project engineer Jay Wallace, to use ThoughtWorks' much anticipated Mingle software and demonstrate to us how it differentiates itself from other products by being a truly agile project management tool.
David Anderson described how his team is using a kanban system for their sustaining engineering (maintenance and bug fixing) activities. Iterations have been dropped although software is still released every two weeks. Work is scheduled, monitored, and run via a "kanban board" and daily stand-up meetings.
Agile methods have achieved a level of success and respect within development teams, but it is not always easy to extend these methods beyond the development team. In Investing in Agile: Aligning Agile with Enterprise Goals, Dan Murphy and Dave Rooney stated that IT project management has evolved with agile methods, but that the enterprise hasn't followed suit.
In a recent newsletter, Scott Ambler looked at why fixed price projects tend to overrun and often fail to solve the business problems they set out to conquer. Scott named the key problems in fixed price projects, identified the bad habits they encourage for customers and developers, and ended with a call to revisit how we fund our IT projects, offering an alternative.