Ron Jeffries has started writing a series of fictional stories based on his observation of real teams. The first story (Kate Oneal: Productivity) focuses on the character Kate O'Neal (CTO) and one of her teams "Rimshot". In this episode Ron explores achieving and measuring Productivity improvements without formal metrics.
Aside from "Agile" itself, "Business Value" may be one of the most widely used buzzwords around the floors of any fresh agile project. But, how many of these projects actually have a good understanding of what they really mean when they're saying it? Joe Little presents his thoughts on this very question.
Some believe that, if you write a large enough cookbook, there will always be a simple recipe to solve our programming problems. Taking it to an extreme, some want programming languages to limit developers to safe constructs and clean style. Reg Braithwaite skewers this idea, and challenges teams not to give up accountability for style, asking "Whatever happened to code reviews?"
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.
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.
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.
A recent article in The Economist pays tribute to three of the finest graphics from the last two centuries. What can be learned from these graphics to improve the display and the quality of agile development metrics?
In this talk, software thought leader Mary Poppendieck reviewed 20th century management theories, including Toyota and Deming, and went on to talk about "the matrix problem", alignment, waste cutting, planning, standards and other topics including the role of measurement: "cash flow thinking" over "balance sheet thinking". InfoQ presents video of this popular talk from the Agile2007 conference.
"A fundamental premise of the 'train-wreck' approach to management is that the primary cause of problems is 'dereliction of duty'" said Peter Scholtes in his 2003 book on leadership. Mary Poppendieck's recent article on process, people and systems asked: "Which is more important - process or people?" and showed how Lean is an alternative to certified process improvement programs like ISO 9000.
"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.
Amit Rathore questions the value of real time task based estimates in the planning and execution of software projects, taking a lean stance on what they bring to the software delivery party.
Code metrics are a way to mathematically calculate the complexity of code. There are several ways to do this, 5 of which are included in Visual Studio Orcas.
Matt Heusser has written a new piece about the problems inherent with excessively detailed systems and processes, and - perhaps unwittingly - how this relates to agile software development.
At Agile2006, Ron Jeffries told InfoQ that tracking "Running Tested Features" is the essential element of Agility, from which all other practices and activities necessarily follow. Ron who took to the whiteboard to explain how RTF benefits customers, by helping helps teams deliver consistently and reliably.
A goal of agile methodologies is to improve the productivity of software developers. Unfortunately, productivity can be difficult to measure. In a recent blog posting, Lidor Wyssocky argues against focusing too closely on quantifiable metrics, encouraging us instead to look at "soft evidence" for productivity gains.