Author Archives: Sampath Prahalad

About Sampath Prahalad

Agile and Scrum practitioner and evangelist. Certified Scrum master and among the first 50 PMI-Agile Certified Professionals in India. My firm belief is that each of us have something to share and teach which makes us a Guru. So, ScrumGuru refers to each of us who mutually exchange ideas and thoughts thus making it mutually enriching.

Risk Management in an Agile world

1 Reply

With the craze of many companies and organizations, big and small to jump onto the Agile bandwagon, a few areas of traditional Software development get ignored or trivialized. More often than not, these come back to bite us late in the cycle. In true Agile fashion, teams then scramble to do the best they can to get the product over the line.

One such area of Software Development that sometimes gets overlooked is Risk Management. Traditional Risk management had projects following either the qualitative or the quantitative approach to Risk management. Detailed risk mitigation would be then put in place to ensure that the Risk was well handled. Many times, this placed a considerable overhead on the team.

Agile teams following the Scrum or XP model inherently embed Risk Management. Risks would typically be identified when the team throws up impediments in the daily standup OR fails to meet its Sprint commitment (because of a story being more complicated or having a dependency that failed to fall in place). Whatever the reason may be, Agile teams are pretty good in throwing up Impediments quite early. These impediments could turn into significant risks, more so when they involve external stakeholders and other teams.

In view of keeping the processes light weight, Agile methodologies are not prescriptive about how the risks can be made visible or managed. From a management perspective, the PMO or Senior Management might see this as a flaw in the Agile methodology since they do not get enough visibility about the risks and hence unable to step in at the right time to clear the path.

In such a scenario, here are some tips that would help.

  • If using an electronic tool like Jira or Rally, raise a work item of type ‘Risk’, provide a severity rating to it and put a Blocked status onto it. Assign them to the right stakeholder and publish a weekly list of these risks to the management. Note: Make sure that the key stakeholders have access and are watchers to these risks.
  • If using a physical board, create a 3 x 3 Risk matrix (Probability(L,M,H) vs Impact(L,M,H)) on the physical board, put up the risk and assign the stakeholder’s avatar to it. Take a snapshot on a weekly basis and send it out to the management stakeholders.
  • Report your blocker in the Scrum of Scrums meeting, explain the potential consequences and nudge the management to take action (mitigate, avoid or accept).

In short, the key to an effective Risk management in an Agile world is to make it highly visible, accountable, time bound and easy to action upon.

Are there other light weight and effective Risk management practices that your Agile team follows ??
Do let us know..

Banish long Sprint Planning meetings

3 Replies

In the Agile world, a Sprint Planning meeting would typically have the Business / Product Owner listing and explaining each story to be delivered and the team goes about doing their best to understand each story based on questions and discussions. The team then estimate the effort needed for each story and commit to whatever they think is feasible within the Sprint duration. For a 2 week Sprint, this typically takes around 3-4 hours.

In many cases, discussions on stories unearth scenarios that need further Analysis by the Product Owner before they can be ready for development. These stories cannot be picked up for development even if they are of highest priority since there are some unknowns about them. This means that the Sprint backlog could consist of stories that are not of highest priority. Also, this results in a long Planning meeting due to more discussions and more stories to discuss.

Is there a way to change this and ensure that the Sprint backlog is filled with stories of highest priority and value? Also, is it possible to have a shorter planning meeting?

Fortunately, the answer is Yes…

The key is to remove the discussions and visit all possible scenarios up front.

The answer is to have an Elaboration session for the next Sprint in the middle of the current Sprint. The Scrum Master gets the team and the Product Owner together for the Elaboration session. Here, the Product Owner presents the stories for development in the next Sprint and solicits questions and feedback. The team and Product owner discuss all possible scenarios and get a complete understanding. There is a huge possibility that some stories might not be ready for development. The Product Owner then has the time to action these before the actual Sprint planning meeting a week later.

This way, the team is fully aware of the stories coming up in the next Planning meeting, the Product owner has time to fine tune his high priority stories and many stories can be committed to and taken up for development without much discussion at the planning meeting. All this leads to a short planning meeting and a less stressed out team. The additional meeting that is added would provide value by unearthing issues up front thus providing enough time for resolution.

I strongly encourage management and teams to try this option out. Do let us know how this worked for you.

Product Management by Committee

Leave a reply

One of the key issues that plagues a delivery team is having no Product Manager to guide the team. However, something that is more troublesome is having multiple Product Managers for a single product. This is what is sometimes referred to as “Product Management by Committee”. I am reminded of a scenario where a boat in a race had 5 people managing it and 4 people actually rowing.

Did you say “Oh, Come on..!! it can’t be that bad” ?

I personally feel that if you want to set a team up for failure, this is one of the things that you could definitely do.

Let us take a closer look at what the problems could be, with having multiple product managers.

Same goal, different priorities: Each PM tries to push his Agenda. Many times, each PM might have the same overall goal, but different priorities. They don’t want to contradict / confront each other. Often, they end up talking to some key resources in the team and pushing their items / enhancements without letting the other PMs know.

Collective knowledge or Collective confusion? There is a possibility that each PM has a different understanding to a scenario in the Product domain. For example, 2 PMs might have varying understanding of how an Insurance claim is to be handled when a car being driven by a person less than 25 years of age gets into an accident at a roundabout with a car driven by a drunk person. In such a scenario, the team would be chasing a moving target if they have to listen to both PMs.

Personality clash: PMs come in all shapes and sizes. Some are more technically oriented than others, some more forceful, some more knowledgeable and some more articulative. When you have a mix of such people providing directions, the team would be torn apart and staring straight at failure.

remix-monkeys-dance-clan-by-same-cc-by-sa-3-0

When Ted, my colleague took up the role of the Scrum Master for one such Agile team, this was one of the things that he identified as a failure factor. He set up a meeting with all 4 Product Managers and told them that henceforth the team would be happy to take inputs from all of them, however, all decisions and directions only from one of them. The PM committee now had to decide who that would be. They nominated Dave ( one of the key stakeholders within the PM committee) to be that person for the duration of the current release. This meant that

  • Dave would set priorities for the team and define the Acceptance criteria for each story.
  • Dave would resolve any conflict of ideas within the PM committee and provide direction to the Delivery team.
  • The Delivery team is not faced with various personalities with different agendas providing conflicting requirements. The team and PM have an opportunity to understand each other well and compliment each other for a successful delivery.

The team is now slowly increasing their iteration velocity, meeting most iteration commitments, gaining the trust of senior management and is able to enjoy their work. I believe this change has been the major factor in causing this turnaround.

Let us know what you think…

@SampathPrahalad

(Pic: Thanks to Remix Monkeys (A new creative look and Style on Urban Dance))