The team performance commonly rated by the Velocity Chart is a valuable tool for both the development team and sponsors as it reproduces faithfully the team performance and its evolution.
Commonly it’s expected – and it happens – that the team performance increase as the project unfold since the uncertainty of tasks become lower and the team maturity about all the project’s domains become higher, the interactions are fine-tuned as well the collaboration and etc.
However, It’s inadvisable – i mean it’s wrong – the team performance being predicted based on external factors like, previous projects historical facts, each member experience individually, since “each case is a new case”. A single project has in its essence sufficient variables to turn the future unpredictable, who will say then when evolving another projects for comparison .
The past is the real that gone. And it’s not anymore, so, therefore, it isn’t.
Clóvis de barros in epaminondas: the explanatory cat (in a free translation by this author)
Understand it! each project has a different sponsor’s mood, budget e flexibility, team experience and expectations, geographic, climatic, psychological, political, and many others factors that prevent that two projects has total equivalence as similar they are.
Time is finite. Treat it as such. Split your work into chunks that could be completed in a short, regular, and well defined time frame – preferable between two and four weeks. If you have been contaminated by Scrum, call these periods Sprints.
Jeff Sutherland in scrum: The art of doing twice the work in half of time (in a free translation by this author)
It’s not my intention to cover all the potential of the (realistic) monitoring of team velocity. My desire here is to heads up for the only reliable way to predict if the next sprints performance tending to increase or not. The only way is looking back.
Of course i didn’t create it but inspired myself in what Jeff Sutherland and his sun wrote. I tested and confirmed it over my professional experiences both as a developer and manager.
The map is not the terrain! You already heard it and if you’re a software developer you know that is true. The planned and the done could be really different from each other, thus, trust the terrain, not the map. Accept and interact with the project’s reality and not with was though and planned for it.
The WIP restrictions identify bottlenecks and problem areas within the process, supporting team to take decisions to solve it.
MARY Provinciatto e paulo caroli in sprint a sprint mistakes and successes in the cultural transformation of an agile team
Work with as much Work in Progress (WIP) as possible and increase it whenever the team is capable. Generating a WIP greater than what the team has historically practiced and greater than the team’s perceived capacity will only increase the pressure and consequently the number of errors, bugs, refactoring and wear and tear on each of those involved and among them.
For this reason, looking back, monitoring the team’s ramp-up, the natural evolution that the terrain allows and defining rational growth and achievable growth, in addiction to creating a realistic expectation for sponsors about the future of the project, increases the engagement, creates – a delightful – feeling of obtaining results, makes the team even more willing to obtain better results and improves management.
Velocity increases and decreases. Each sprint is a singular sprint. Follow each reality individually and learn together with your team what the project allows. An engaged team will always delivery the best possible, always! Believe in the team and resolve impediments, the performance is a consequence.