In this blog post, Matt Archer shares his definition of the Agile Test Lead role and what he thinks they should contribute to Scrum teams. He says that behind the practical aspects of the Agile Test Lead role, there are also subtle connotations of coaching in this position. In his opinion, it is this coaching element that makes many Agile Test Leads valuable for the Scrum team they belong to.
Thom Roach shares with us in this blog post the metrics that he includes in iteration summary reports. The three main statistics he uses are Iteration Statistics summary, Iteration Cumulative Flow and Team Velocity Chart.
Short cycles provide us with a wealth of benefits in terms of fast feedback, minimal design in process and increased flow. Plan driven sprints however stress the system, force good people to make bad decisions and is built on the faulty belief that capacity utilization is the main problem in high variability environments like product development.
Estimating and planning are critical to the success of any software project, also in the case of distributed agile development. Research has acknowledged that conventional agile methods need to be adjusted when applied in distributed contexts. However, we argue that also new tools are needed for enabling effective distributed agile practices. This article presents eConference3P, a tool for supporting distributed agile teams who applies the planning poker technique to perform collaborative user story estimation. The planning poker technique builds on the combination of multiple expert opinions, represented using the visual metaphor of poker cards, which results in quick but reliable estimates.
This video contains an interview about lean procrastination, which is the postponement of decisions to the latest responsible moment. Olaf Lewitz explains the idea and how it might help larger companies becoming more agile.
This podcast interviews Rini van Solingen about scrum and agile software development in distributed settings where the team is spread across different locations, different buildings or even different countries and continents.
Epics are used to get a bigger picture of user stories, but we need another level of abstraction. We need to bring together the various Epics that describe how our solution will evolve to its final endpoint, and how different functional teams and specialists will interact.