Agile – Page 3 – Moss and Lichens

I was walking the streets of London near Fortnum & Mason. I came across this posh Italian tailor who had this on his walls “Slow fashion”. He was selling slow fashion for those who could afford it and explain why it added value to who you could be when you are dressed right.

I was walking the streets of Munich near Pasinger Arcaden. I came across this coffee place where they had on their walls “Slow coffee”. I was intrigued. I ordered some coffee and I was in for a wait. They let it drip and asked me if I wanted cake while I waited. I don’t have a sweet tooth. I have sweet teeth. I said “YES”. Got myself a cake and ate it slowly for over 12 minutes when my coffee was ready. It was coffee that had dripped slowly and I enjoyed every drop of it.

Fashion has gone slow. Coffee brewing has gone slow.

Does our Agile transformation need to be fast?

Not really, I think a slow and steady transformation is what a team needs.

Why?

A fast agile tranformation assumes a team is ready. Very often teams are forced to work Agile because it is the “way to go”. We don’t drop a kid in the deep end of the swimming pool before the kid is trained to swim in the shallow end.
A fast agile transformation assumes a leader is ready. Leaders are good in playing the company dynamics and can drive Agile transformation for their teams. Can they drive it for their teams and organization without training?
A fast agile transformation assumes an organization is ready. Very often one well meaning team goes Agile and assumes that the teams surrounding it will go Agile when they see the light. We don’t add a rookie swimmer to a relay team till the rookie swimmer is trained to swim a distance in a particular speed.

I think an Agile transformation is going to be successful when we can slow it down to the speed that is right for the team and organization. When we can ensure that the team, leader and organization are trained right, they are ready to enjoy that slow cup of coffee.

If you are interested in Agile training for you, your team or organization, look here: Training – Moss and Lichens

Velocity and Throughput based Forecasting

Photo by Ross Sneddon on Unsplash

How many times do you struggle as an Agile Stakeholder to get a forecast from the team?

And if you get a forecast, can you trust it?

How many of us trust the weather forecast?

We look at our Weather Apps on the phone daily or before a week for planned events or before a few months for planning vacations. The Weather forecast helps us plan our day, week or vacation.

Likewise the forecast for an Agile team helps the Stakeholders decide on budgets and size of team (add or remove members) in the short and long run.

Very often Forecasting is dismissed or not discussed actively in the context of Agile projects.

Here are two simple ways to forecast in Agile projects

Velocity based forecasting

All you need for velocity based estimation is the Velocity of the team for the last 3 to 5 iterations and the Capacity of the team in the past and future. With these numbers and the technique defined in the article (Agile Forecasting with Focus Factor (scrumalliance.org)) one can easily forecast.

2. Throughput based forecasting

Sometimes velocity based estimation is used incorrectly by teams to compare across teams and increase motivation to do more points without increased value delivery. Throughput based estimation excludes estimation from the picture and just uses the number of stories completed in the last 3 to 5 iterations.

I like the discussion comparing the Velocity based and Throughput based forecasting by Troy (

Story Point Velocity or Throughput Forecasting – Does it matter? / Troy Magennis | Observable (observablehq.com))

And for those who want to try out Throughput forecasting using an online tool, this one from Rodrigo is a great start:

Project Forecaster (rodrigozr.github.io)

If a team can use either velocity based or throughput based forecasting to give a forecast to the stakeholder on what can be achieved in the next iteration or next quarter it greatly helps in planning and budgeting.

Infact with throughput based forecasting, one can also on a high level judge how long will the product backlog need to get completed with the current team size. This can also help the Stakeholder plan to increase the team size and take up new projects in the future.

How do you forecast in your teams?