Adding developers to an agile project disrupts Velocity: Brooks law re-interpreted
This post presents Brook’s law as a systemic issue, and how to interpret it for agile projects.
The Science Behind Planning Poker: Understanding the Theory That Makes It Work
Planning Poker has become the de facto estimation technique in agile teams. Like many agile practices, it elegantly packages theoretical concepts into a practical, easy-to-follow process. This post explores the hidden foundations of Planning Poker by combining three powerful ideas: measurement theory, research on cognitive anchoring effects, and the Delphi estimation technique. Understanding these underlying principles helps teams move beyond just following the process to truly mastering the art of collaborative estimation.
Engineering (Software) Teams: Insights from "How to Design Teams That Don't Suck" and the Team Software Process
Team composition and performance can be engineered. Thereby, the context can be designed so that a group of people can be led into a high-performing team. This context must focus on establishing shared experiences and responsibilities, rather than relying solely on team-building exercises.
Velocity: How to interpret it to improve your agile team productivity. 3 of 3: What-if and FAQ
This is the final article of this series.
his third article contains some Q&A that are commonly asked when dealing with velocity.
Paper of the Month: Interpretative case studies on agile team productivity and management
Paper of the Month: Interpretative case studies on agile team productivity and management.
Three topics that affect productitivy:
* Developer turnover
* Team Design
* Inter-coordination factors
Managing technical resources at capacity
“Only variation can absorb variation”
Software is intangible, is the result of knowledge work, and is very much prone to variation. In this post, variation means anything that changes the nature of work.