Monthly Archives: April 2017

Workshop: Safety Scan

One of the four principles in Modern Agile is “Make safety a prerequisite”. The reason for that safety is not seen as a priority is that priorities may change, but safety will always have to be there.

Modern Agile Wheel
If we take a look at Maslow’s hierarchy of needs we can see that safety is the second step towards self-actualization. If we want high performance teams creating software in a way that makes people awesome we need to make safety happen first. Only people that are safe will have the guts to do the experiments needed to create products that really stands out. We must have people that are safe enough to handle a failure, learn from it and then conduct a new experiment based on the new knowledge gained. If we want people to do their best they must be able to bring their whole self to work, without fearing to be punished in any way.

Maslows-Hierarchy-of-Needs.jpg
In order to put this topic on the agenda we have created a workshop called “Safety Scan”. In the workshop we look at safety from several perspectives (psychological safety, technical safety and fail safety) related to your team’s daily work. We will together discuss what safety means in your context and you will also have a possibility to rate the current level of safety in your team by doing a Safety radar. We will not suggest any actions in the workshop. It is your team that must come up and own the actions that needs to be performed. If needed we can of course guide you or facilitate exercises that will increase the safety in your team. When performing the workshop, Vegas rules will be applied (“What happens in Safety scan, stays in Safety scan”). You can be absolutely sure that the content of the session will not be shared with people outside your team.

burst
A made up example of a Safety radar(Vegas rules remember… 🙂 )

Would you like to have us perform a Safety Scan on your team, contact me or Leif Ershag.

Advertisements

Story point rant

I’m no fan of of story points. I have tried it when using Scrum but didn’t really see the benefits. Instead we have used gut feeling to decide on how much to pull into a sprint. That has served us really well. The few times we failed to reach the sprint goal and didn’t deliver what we have promised, we held a RCA to find the real cause of the problem. After putting in counter measures we always come out a little bit stronger. Even without counting story points we have been able to increase the velocity when the team continuously improves.

I think what annoys me the most is that I have noticed teams getting caught in a dirty race to always improve the score no matter what. These kind of measurements should be kept inside a team motivating continuous improvement. Somehow it seems that a lot of teams get measured by outsiders for their velocity. That makes it really tempting to start gaming the system.

I have seen is teams that make advanced formulas to estimate how many points of their unfinished work they should count in this sprint and how many points that are left for the next sprint. The natural thing would really be to only count finished stuff and do some analysis to understand why we failed deliver what we promised. Some teams even count story points for fixing bugs they created in the last sprint. Sad.

Using kanban is always the first choice for me. Creating a flow and don’t have to adjust the work towards the sprint ending. When using measurements I like to choose measurements that balance each other to avoid gaming with the result. A combination of measuring throughput, lead time and defects have I found helpful.