Posts for Tag: Management

Shared Risk Management

I wrote this post over 4 years ago while working for Laterooms. The idea was to publish it in Laterooms engineering blog but for some reason or another it never happened. The intention was to document the way we managed risk in an Agile environment and how the technique we describe and experimented with impacted delivery.

Problem Statement 

Our team was finding a great number of unmitigated issues mid-sprint that had not surfaced during sprint planning, not because the planning sessions were not being rigorous, but because risks were not being identified and mitigated ahead of time.

We needed to get a better understanding of what types of issues and to what degree they were affecting our progress. Up until this point, as a Product Owner I had owned our RAID, logging all of the risks and issues, qualifying them for impact and trying my best to mitigating them to the best of my abilities.

The more we got entrenched into Scrum, the more I realised this was an agile anti-pattern, no individual person is able to identify and mitigate a wide range of potential risks that affect a product team. Identifying and mitigating issues had to be made a collective goal, shared and owned by the entire team.

Qualifying Risks and issues

The first step was to make sure all of the risks and issues affecting the team were logged, by collaborating with the team, using our Systems Context diagram to map out all of the different systems surrounding the team we quickly realised that we had a lot more risks that we initially thought.

We now needed a way to qualify the risk and issues, so we decided to use a common scale that would allow us to overlap risks and issues with velocity, providing the a full picture of how RAID impacts the teams progress.

Improved Visibility

Our Risks and issues board is visible to the team at all times, we booked in a weekly stand up where the entire team goes through the risks inventory and assess the impact and probability of each risk.

When Risk Management becomes a shared activity, it is owned by the team and becomes part of the organic process. Teams get used to looking at the information radiator and begin to use it as an indicator of what is ahead.

We use our risk board similarly to what the Dashboard of an airplane, our dashboard gives us a visibility of any potential risks ahead of our journey giving us time and space to make informed decisions on what to avoid any potential obstacles/dangers that lie ahead.

We then surfaced the risk board in a burn down chart where X is the effort required to mitigate the risks, y is the estimated loss should the risk convert into an issue. The key objective is to use this tool to prevent risks from becoming issues that would inevitably hurt delivery. 

Observation

Unsurprisingly, shared risk management clearly showed that we have a lot more issues impacting progress than we thought. Most issues have dependencies that have been identified, since we now know ahead of time are, and how they impact velocity, we now know what areas we need to focus on.

Benefits

  • Made all of the issues impacting the teams progress visible,

  • Surfaced risks that would have gone unnoticed,

  • Able impact of issues and unmitigated risks on Velocity,

  • Highlighted recurring areas where dependencies emerge,

  • Improved sprint Planning – Less unknowns,

  • Increased the efficiency of the mitigation of risks as they are identified when the probabilities still low. 


I highly recommend that you checkout the Laterooms engineering blog, particularly if you are interested in the implementation of Elastic Search
For further reading Elastic, the iCarAsia Engineering team has a great series of posts that cover how use Elastic Search to improve our consumer experience.

The Subtleness of Leadership

It is commonly said that a leader is born, not made, he possesses innate qualities that make him stand out and incite others to follow him, and while I truly believe that there is nothing that is unachievable, as paradoxical as this might sound, I have found that there is some truth to this.

It cannot be acquired through education: There are specific traits that are commonly found in people that are recognized to be leaders. These are not necessarily acquirable through education or even experience, and are usually very hard to pin point. They range from self-confidence, to charisma, character, and sometimes an undefined quality that somehow, despite everything pointing to the opposite direction, just makes someone stand out inspires people.

It’s can’t be given: Leadership is not a position nor is it a role, it cannot be appointment and it’s not a result of a promotion. A leader is born by an organic decision within a group, most of the times informally, other times it’s a conscious decision by a group to elect their leader.

In a highly technical team, you usually find that it’s not necessarily the most technically gifted member that will be the leader, usually it’s the one that understands the dynamic within the group and excels from it by recognizing his peer’s talent, cultivating it, and keeping group cohesion.

It must be driven by example: Respect is conquered, is not a given right, and it does not come with any role or position. If a team of developers has to work late to deliver a project the next day, it is the obligation of the leader to stay with the team , it doesn’t matter if in theory he isn’t adding anything to the project by being there, the reality is that his presence makes him part of the team.

Soldiers will follow to battle a commander that is leading besides them on the battle field, in the end, its not relevant if he is drawing swords or not, his presence is what truly matters and what inspires them