Risk Management in Agile vs Predictive delivery models

You must have noticed that scrum do not provide any direction or inputs on the process of risk management. It must be understood that risk management is intrinsic to any project and risk management follows its own life cycle to exploit opportunities and manage the threats.

Risk management is integral part of the project management and irrespective of a delivery framework or methodology it needs to be managed and looked at proactively.

During predictive model of development, we typically perform Risk Management weekly and considerable amount of time is spent on the process to identify the unknown risks. I’ve experience of spending minimum of 3 to 4 hours every week on risk management along with the team itself and whole team hated performing this activity as it never provides direct value to teams. In predictive model, project manager’s stakes are higher than team and this team has lower or no motivation to have a risk management meeting.

In my experience at any point of time we had 50+ item on our risk tracker and team performs analysis, identify response plans for each one of them every week.

In that risk register some items were present and no one had a clue on what they are only date of mitigation changes. Did you have any such items on risk tracker?

Risk Management in Predictive delivery model

PMBOK Six step process

PMI suggests The Six-Step Process of Project Risk Management as depicted in below diagram, please refer PMI  website for more details.

 

Generally large programs maintain risk register with a weekly cadence and capture various attributes of risk, below is a typical format to capture risk and monitor them at a cadence. For more details please do refer PMBOK® Risk Management Process.

There is various risk management template but following is the most common way of capturing information.

https://docs.google.com/spreadsheets/d/1IZP_XXlpt3BZdQuwGkvvhxl-1GqXvTaOKLon2wpX1xY/edit?usp=sharing

Risk Management in Scrum

Fact

Like I said in above paragraph, Risk is always associated with things we do, and they need to be managed irrespective of delivery approach.

Get shredded with Risk log

Scum is founded on empiricism and lean thinking and we need to change the mindset of performing risk management, we need to be light and easy unlike risk management process followed in predictive delivery models.

Some of the key characteristics of scrum help us shred that THICK risk management log

1. The entire Scrum Team is accountable for creating a valuable
2. The Scrum Team is responsible for all product-related activities
3.  The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint.
4. Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

The use of lean principles will also support in shredding the risk log, I’ll suggest to follow the 6S Lean principle which is Sort, Set in Order, Shine, Standardize, Sustain and Sort to get a slim risk inventory. 

Cancel the explicit risk response meeting

Teams are working hard and focused on delivering sprint goal via navigating with various  scrum ceremonies and events, I must say “they are busy”, and we do not need to have any other formal meeting during the sprint to address risk responses. A risk meeting within the sprint will make you move towards traditional model of development.

Identify, Capture, and derive risk response with-in the scrum framework. 

Not scrum master, not product owner but let teams own the risks

In a predictive delivery model, project managers were responsible and accountable for project delivery, they drives the risk management meetings but as we move towards scrum, self-organizing teams are empowered and take responsibility of risk register or risk mitigation plan. 

Scrum Ceremonies and Risk Management

In following few paragraphs, we shall review the support of risk management in scum events and ceremonies.

1.      Daily scrum

Each day team focuses on delivering sprint goal. This is one of the first spot to monitor risk, identify risk and create a response strategy to manage risk related to sprint goal 

2.      Sprint Planning

While team is answering following three topics in sprint planning, team will come across various risk which needs to be logged and need to be monitored as part of daily scrum.

• Topic One: Why is this Sprint valuable?
• Topic Two: What can be Done this Sprint?
• Topic Three: How will the chosen work get done?

The above topics will enable team to freeze the sprint goal, support conversations to understand impediments and risks before the event concludes.

3.      Sprint Review

This event is a working session and ideally must avoid any presentations. Team demonstrate the outcomes and highlights the risk, issues, and any impediments towards the product goal. These risks could be business or technology. Together along with key stakeholder’s team identify the response strategy to mitigate risk or identify a resolution/workaround for the impediment. 

4.      Sprint Retrospective.

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The team engages in the conversation and looks back to identify the areas of improvement and things team may continue to increase productivity and outcome of sprints. The responses and outcomes are added to product backlog and team adopts to the outcome.

Scrum manages risk more efficiently, because of the three Pillars of Empiricism and its underlying agile principles which focuses on Individual and Interactions, working software, customer collaboration and responding to change.

Plan your first sprint

You kicked off your agile journey and I bet you prepared adequately before starting your first sprint. The first sprint was labelled as failed, you (including team) took pride in that failure as you must have noted down few learnings. You accepted the fact as you rely on the practice of fail fast and scrum’s imperial approach.

You continued on the journey and notice even after few sprints; successful sprint is a dream. Team is demoralized, and scrum master has a burden of guilt because of the accountability of outcome.

It is evident that, inspection and adoption which is embedded in Scrum Ceremonies are not working for team. During product launches: tight deadline, financial implications and reputation is at stake, not everyone in the organization is open to failures and there could be serious implications of failed sprints.

Every environment is unique, and dynamics of each environment plays a vital role, so it is important to prepare before you actually start sprinting.

When I think of Sprint, I directly co-relate this to sports (from were scrum was originally derived from).

You can relate executing scrum sprints to 100 meter most common running competitions either at school or at an Olympic competition. I personally associate this to 100 m hurdle race; were sports person runs in a rhythm between hurdles keeping their reflexes action right and react instinctively.

Everything in hurdling is a matter of quickness and agility but not speed, because there’s not enough room between the hurdles to really be “fast” in hurdling. So, 100 meters hurdle races are set of rhythmic events, not a speed event.

Like, sportsmen start preparing for race much ahead of the actual race day, similarly a scrum master and stakeholders should come together and plan the “must haves” before rushing to kick off the Sprints, you got to do some planning before starting the sprint right. Remember: the mantra is minimum planning.

Remember the MoSCoW Prioritization, you need to list down what are the Must haves before you are tempted to get the first sprint kick off.

Before you take off follow the below listed basics and it might be easier. Let’s take a few steps back and visualize the preparation of a sports person for 100 m hurdle race, You will be fascinated the relationship of this analogy with teams starting to work on new product launches.

Here are the things which a sports person does before actual race, agile sprints are no different and hence a co-relation.

Train for the race 

Like an  athlete will train to enhance the overall cardiovascular system, in similar way the team has to go through training to get all the system in synchronization.

·     Have your team

o   Baselined on culture, terminology, way of working, know your stakeholders

o   Perform basic training on Agile software development

o   Build agreements among leaders and key stakeholders

o   Define and agree to the roadmap and plan for releases

 When I say team, it is not just the scrum team, the whole eco system has to be trained and enlightened by the new normal and new ways of working.

 A sports person will improve overall athleticism by these trainings, similarly the scrum teams with basic training will improve the overall mindset to deliver results as outcome.

Set a goal

Like all project have timelines and milestone similarly an athlete has to set a goal of running race, the goal of the athlete is to Win 100 m hurdle race. This goal has meaning and follow S.M.A.R.T., a mnemonic acronym

 

Similarly, Agile teams while working on scrum must set a goal by each sprint, each increment and so on.

Before a race is won an athlete visualize the way she passes each hurdle by agility and envision to win the goal. Similarly, a team has to start visualizing the goal and see the light at the end of the tunnel.

Preparation for the race

Before you train or participate in the race, it is important to prepare shopping list of tools to acquire, which will contribute to success. Athletes wants to run multiple successful sprints and for this most precautions must be taken to safeguard from any injury. For sports person it is OK to fail in trials but not on the day of Event or Olympics.

 Like: A good pair of shoes will give them comfort and safety, foot blocks help them propel with maximum force and certainly the coach in the team must have a clock, stop watches, and heart rate monitors to keep track of performance indices.

Apart from this, you have to identify a track which is safe and will enable athletes to practice and run efficiently.

 In agile development, you might have come across words like Spike and Enablers, we adopted word “Enabler” from Enable, which relates to any piece of work, tool which supports the upcoming business requirements. These could be:      

•        Create platforms or accelerators for faster developers.
•       Build initial backlog with validated clarity of execution.
•        Collaborate with partners, vendors, team to list down working agreements
•        Write your Definition of Done or Definition of Ready
•        Hire people with aligned skills
• To perform a prototype and activities to develop enhanced understanding of actual deliverables.

 All of this could be part of your initial backlog, which you can pick up in sprints iteratively. The goal is to have meaningful outcomes each sprint and we must have a laundry list of things before we start.

 

Eat healthy diet and stay hydrated

Like we have prescriptions on the kind of food you should consume. Consumption of well-balanced meal and stating hydrated, plays a vital role for a race. Similarly, consumption of useful information will be like celestial for you agile journey.

While working on complex projects with multiple stakeholders, it is likely that scrum masters and team get overwhelmed with the information being exchanged.

 

But for a successful sprint, it is key to focus on

• Goals
• Mission and Vision statement
• Your customer REAL needs.
• Your competition
• List your top Risk and quantify your Risk with monetary impacts
• Coach/Train team members for right alignment

 Re-iterate, discuss, and confirm all the information with your teams and stakeholders, so we all clearly understand the definition of success.

In summary, these are some of my experiences, which helped me start sprinting sooner and focus on creating valuable outcome for the products.  Does this mean we never have unsuccessful sprints? I will let you guess that.

One last thing I want to touch, some of you may vouch to name this preplanning as Sprint Zero, which is usually not timeboxed and have no rules and goals and scrum guide do not mention that at all. Some of my friends, clients and colleagues use this method as a breathing space before sprint 1 is kicked off. I will let you decide the label for this activity.

However, I’ll discourage to use Sprint Zero for any of the activity. I will suggest to start your sprint with as little information as you have, build your tools, gather information, and enhance backlog along with your sprints. Most importantly we as a team must understand and value the outcome of sprints.

 

Do share your thoughts on this post, be safe!

The Four Steps Towards Giving Up Control

 

In one of my previous short notes, I’ve mentioned the importance of autonomy and Agile 5^th principle “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”

Giving Up control is the first step towards building autonomy. It is wise to extend freedom to your team, but it's not easy. The urge to control your people and team’s is irresistible and it echoes continuously to managers and leaders which effects the team morale continuously.  

Empathy and building autonomous team is not something which can be achieved overnight, especially when you have grown up in command and control, carrot and stick or an opaque environment. It is in-deed a journey and a conscious effort has to be made every day to build autonomous teams.

I am listing down few techniques, which I’ve used and has given me success in building autonomous team and give away the control.

Collaborative goal setting

An imposed goal, target or decision is unlikely to be believed and team merely executes that out of fear and most of the time they are not successful. These targets may be a quarterly sales target or a deadline of delivering a product/feature.

A considerable body of researches have shown that individuals are far more engaged and passionate when they are pursuing goals, they had a hand in creating.

So, get your employees and partners together on goal settings and get surprised, often people have higher aims or better alternatives.

Personally, I highly recommend the use of PI-planning in SAFe ( for collaborating goal settings and alignment of teams and management. Use noncontrolling language and pressure words.

Use noncontrolling language and pressure words

In my experience, uncountable times, I’ve heard and read emails at school or work which directed me to finish an activity by certain time or ASAP. You might have similar experience as well. Think about your true feeling at that point of time. Next time you are using pressure or controlling language (should, must, have to) consider using collaborative words with right intent. Anxiety and Anger are the common outcomes of a controlled team.

Some of the common pressure words used at workplaces are listed below:

·      I need this ASAP
·      We have to do this…
·      I need this by 11 am tomorrow morning
·      We’re counting on you to do this

Every time we have used similar sentences, we made our people stand on the edge, teams or individual feel more constricted irrespective of your intent and thus resulting in low morale of individuals.

Be approachable

I remember my school days when my teachers announce in the class that students are free to visit them in staff room at a specific hour of the day or week to clear any doubts we may have.

I’ve always enjoyed the out of classroom interaction with teachers/professors. We got an opportunity to learn both ways and shared a common understanding on subject.

Similarly, take a cue and have a fixed time slot reserved for employees, so they can walk-in and talk to you. You will be surprised to learn from your team.

Blame a process not person

When something goes wrong, people are punished. We often hear and read in news that a bureaucrat was transferred, or a politician has to resign because of a certain issue. Resulting in shame and low morale.
However, little efforts are made to improvise the process. This whole culture of blaming person restricts the culture of reporting gaps due to fear of being singled out.

Know where you stand

It is remarkable sometimes to conduct an autonomy audit in your team on Task, Time, Team and Technique, refer details on danpink.com and run an autonomy audit in your team, teams or organization.

Scrum Guide revision, Section by Section

Introduction

I bet, by now you know enough about the recent scum guide revision. It has taken us years to adopt to Scrum and some of us are still understanding the adoption process. The new scrum guide is more powerful and provides you more opportunity to derive value from it. Like SAFe, Scrum guide is relatively less perspective and focus is on whole team accountability.

The purpose of this article to highlight the changes on the scrum guide section by section, I'll leave with the readers to articulate the changes. I've attempted to make a section by section comparison on a high level. Please post a feed-back or highlight any changes which needs to be captured here.

Scrum Guides

You can download both versions of scrum from here https://www.scrumguides.org/download.html

How to read

For ease of reference, I have added snippets of 2017 and 2020 guide and color coded them. Here are the legends

Green – Unchanged text

Orange – New Mention

Red- Deleted

Left hand side has screenshot from 2017 guide and 2020 is on the right had side

 

Definition of Scrum

What continues

1.       The focus on scrum being light weight and simple is continued in 2020 scrum guide.

2.       The guide continues to state that it is purposefully in-complete and non-descriptive.

3.       The focus on relative efficacy is continued for the continued improvement.

What is dropped

Scrum 2017 guide mentions scrum as Difficult to master but this is dropped out from the new scrum guide in 2020.

New mention

This section calls out the role of Scrum Master, Product owner, Scrum team and              focus on inspect and adopt process

Uses of Scrum

 

What continues

This content and essence of this section are elaborated in other sections of 2020 guide like “Purpose of Scrum Guide” and “Scrum Team”.

What is dropped

Only the heading “Use of Scrum” is dropped but essence is maintained.

 

Scrum Theory

What continues

Empiricism, Scrum pillars of transparency, inspection, adaptation and iterative approach

What is dropped

Only the heading “Use of Scrum” is dropped but essence is maintained.

New mention

Scrum foundation includes lean thinking along with empiricism.

 

Transparency

What continues

Focus on common understanding and visibility in the processes.

New mention

1.       Emphasis is on increased value and reduced risk due to transparency. Decisions taken with low transparency result in lower value and increased risk.

2.       Due to introduction of Lean in scrum theory, relationship between transparency waste is highlighted.

Inspection

What continues

Continued the emphasis on frequent inspection.

What is dropped

The 2017 scrum guide focused on the (skilled inspector) actors who perform this activity.

New mention

Focus of execution of inspection process is left to the 5 Scrum events unlike an actor or skilled inspector unlike earlier guide.

 

Adaptation

What continues

The code of Adaption is continued and no major changes.

What is dropped

NA

New mention

Scrum guide focuses on Management 3.0 concepts like empowerment to team

 

Scrum Values

What continues

The core scrum values of commitment, courage, focus, openness and respect stay the same

What is dropped

The specific verbiage personal commitment is dropped, and team commitment is introduced.

New mention

Team commitment is emphasized to complete the sprint goal and team’s primary focus is highlighted which is to perform most progress towards sprint goal.

 

The Scrum Team

 

What continues

The structure of the scrum team and its’ attribute of self-organizing and cross functional continues.

New mention

The definition of scrum team is more specific, following details and attributes of scrum team is listed

1.       Size of scrum team and recommended size

2.       Scrum team responsibility for collaboration, verification, maintenance, operation, experimentation, research and development or anything else

3.       Highlighted the accountability characteristic with respect to creating value and useful increment.

 

 

 

The Product Owner

What continues

The overall attributes of the product owner continue and no major changes on the roles and responsibilities.

New mention

In new scrum guide the product owner become accountable rather than just be responsible. For example

1.       The Product Owner is now accountable for maximizing the value rather responsible.

2.       Similarly, product owner is accountable for the product backlog

 

 

The Development team

What continues

The focus on set of people who are committed to deliver values.

What is dropped

The term “The Development team” is replaced with “Developers”

New mention

Developers means the entire scrum team and not just people “who do the work of delivering a potentially releasable Increment of “Done””. The focus of the developers is not only responsible for work but being accountable as well.

 

Development team size

This section is dropped and moved to the Scrum team section of new guide

The Scrum Master

What continues

The scrum master continues to play role of coach to understand the scrum.

What is dropped

The teem “Servant-leader” for the scrum team

New mention

1.       Accountable for the outcomes rather than just responsible.

2.       True leaders for the scrum team and organization

The Scrum Master service to the product Owner

What continues

Accountability and Responsibility to-wards goal, scope, product backlog and empirical product planning.

What is dropped

1.       Facilitating Scrum events as requested or needed

2.       Understanding and practicing agility

New mention

1.       Facilitate stakeholder collaborations as requested or needed, rather facilitation of scrum events.

 

 

The Scrum Master service to the Development team

What continues

Coaching aspect to the team continues

What is dropped

1.       Coaching the development team in organizational environments in which scrum is not yet fully adopted and Understood.

2.       Facilitating scrum events.

New mention

1.       Ensuring scrum events have positivity, productive and productive

The Scrum Master service to the Organization

What continues

Leading, Coaching and planning aspects of scrum adoption and implantation of scrum in organization.

What is dropped

1.       Causing change that increases the productivity of the scrum team and

2.       Working with scum masters to increase the effectiveness of the application of scum in the organization

New mention

1.       Training and advising

2.       Remove barriers between stakeholders and Scrum Teams

Scrum Events

What continues

By and large details about Scrum Events continues with no noticeable changes other than verbiage and details.

 

The Sprint and Cancelling a Sprint

What continues

Sprint duration, goals and details in the sprints follow the previous guide.

What is dropped

New mention

1.       Specific mention of Product backlog being refined during the sprint.

2.       Cancelling the sprint is included in the Sprint section itself, and not calling out separately.

3.       Focus on use of various practices like burn-down and burn-ups.

Sprint Planning

What continues

1.       Collaborative work continues to plan the sprint.

2.       Sprint time-box is maximum eight hours.

What is dropped

1.       Scrum Master make sure that attendants understand the purpose.

2.       Scrum Master teaches the scrum team to timebox the event.

New mention

1.       Product Owner make sure attendants understand the purpose.

2.       The Scrum team may invite other people to attend the Sprint Planning to provide advice.

 

Sprint Planning (Continued…)

What continues

1.       What can be done this sprint?

2.       How will the chosen work get done?

New mention

1.       Why is this sprint valuable?

 

Sprint Goal

What is dropped

1.       This section is moved out and is embedded in product and sprint goal sections in new guide.

 

 

Daily Scrum

What continues

1.       Cadence and time box of 15 mins.

2.       Purpose and benefits of the Daily Scrum.

What is dropped

1.       Specification on following

a.       Examples of the question’s development team may answer.

b.       Development team meetings post daily scrum.

c.       Ensure the development team participate on daily scrum

d.       Training development team on Daily scrum

New mention

1.       If the Product owner and Scrum master are actively working on items in the Sprint Backlog, they participate as Developers.

2.       Developers can select whatever structure and technique they want, as long as their Daily scrum focuses on progress towards the Sprint Goal and produces an actionable plan for the next day of work.

Sprint Review

What continues

1.       Cadence and time box of maximum 4 hours for a one-month sprint.

2.       Purpose and benefits of the Sprint Review.

What is dropped

1.       Various low-level details around following topics are removed

a.       Development team responsibilities during the Sprint Review

b.       Product Owner and Scrum master responsibilities during the Review

c.       Topics which needs to be discussed (like budge, plan, etc)

New mention

1.       Purpose of the sprint review is called out specifically.  “The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.”

Sprint Retrospective

What continues

1.       Cadence and time box of maximum 3 hours for a one-month sprint.

2.       Purpose and benefits of the Sprint Review. 

What is dropped

a.       Scrum team responsibilities.

b.       Scrum master responsibilities.

c.       Topics which needs to be discussed

New mention

Specific purpose is added “Sprint Retrospective is to plan ways to increase quality and effectiveness” rather then just calling out “ Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.  “

Sprint Artifacts

What continues

1.       Product Backlog.

2.       Sprint Backlog

3.       Increment

New mention

1.       Product Backlog, Commitment: Product goal

2.       Sprint Backlog, Commitment: Sprint goal

3.       Increment,  Commitment: Definition of Done

 

Artifact transparency

What is dropped

This section is dropped from new scrum guide.

 

Conclusion

There are quite a few changes on this guide, I will let you interpret the summary, by the way - if you google you will get to know various articles explaining these details.