In this presentation filmed during ThoughtWorks’ Quarterly Technology Briefing, Dave Robertson and John Johnston explain what the Agile and User Centered Design’s (UCD) common denominators are, common values being the most important one in their opinion.
Earlier Scott Ambler posted an article of how to measure productivity on agile teams by utilizing acceleration. Recently he followed up with another post where he answers some frequently asked questions related to agile productivity and acceleration. Specifically one question answers how to measure the amount of $ saved by an accelerating team.
Developers commonly break user stories into tasks to facilitate distributing the implementation work across the team, and allow tracking of progress at a finer level of granularity. Unfortunately, a story can explode into a list of non-trivial tasks so large that the story is not deliverable by the end of the iteration. Ron Jeffries suggests: "Do stories as a unit, not broken into tasks."
In this presentation filmed during Agile 2008, Dave Nicolette and Karl Scotland try to introduce non-technical managers to one of the most popular Agile development techniques: Test-Driven Development (TDD). The presentation intends to be a primer for managers who want to understand the value of TDD, and of Agile in general, in software development.
In this presentation filmed during Agile 2008, Michael Mah analyzes the development process in 5 companies: 2 Agile (one of them BMC) and 3 classic. He measures the development progress and effectiveness and compares the results with industry averages. He also presents the factors which contributed to the success of BMC's Agile adoption.
Return on Investment is a critical factor for decision making pertaining to following a particular software development practice. The post summarizes the ROI benefits of Agile and the inexpensive practices which lead to highest return on investment.
Many of the Agile community have chimed in on a recent popular discussion regarding success rates of Agile transitions. Responding to Niraj Khanna's question on the subject, Kent Beck, Ron Jeffries, Alistair Cockburn, Chet Hendrickson, and many more debate the value and risk of establishing such statistics.
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.
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?