Sprint Retrospective, structure and practical situations

Sprint Retrospective

The purpose of the Sprint Retrospective as per sprint guide 2020 is to plan ways to increase quality and effectiveness.

I'll share some practical situations and practices from my experience which may help teams, #scrummasters #agilecoaches

In case you are looking for ways to run a retrospective review the blog here 

In case of challenging situations, the scrum master must take charge of the situation and engage with the team innovatively.  Think out of the box. Experiment to fail because no two teams are the same. 

Do you encounter any of the following questions?

Situation 1. Shall we do a retrospective once in a few sprints or skip it❓

Here are some of the possible reasons:

a. The same old famous three questions are asked repeatedly in retrospectives and the team has lost interest.

b. Team is unable to find improvement areas as we are progressing well.

c. No actions are taken for the past retrospective next steps.

d. Team does not find it safe to raise improvements.

e. Team is overwhelmed with the next steps.

d. Opinions from few dictates. 

I would recommend Scrum Master take charge of the retrospective and perform the necessary steps to have a compelling retrospective and work with the team and focus on the below mindset

a. Why -  Focus on Improvement.

b. What - Focus on Action.

c. How -  Cadance.

2. Do we need to always run the retrospective every scrum❓

a. Don't be a Scrum Police, each team/individual has different dynamics.

b. Build the team first, and give them purpose, mission & goal.

c. Experiment, for example: play team-building games.

d. Improvement is a continuous process.

e. Make it a fun activity.

3. How do some mature teams run a retrospective❓

a. Scrum is an empirical process, the team adopts Transparency, Inspection & Adaptation.

b. Continuous Retrospective is visible during all scrum meetings and outside.

c. Leads (Including SM) challenge teams to identify improvements.

d. Capture improvements and build Transparency to celebrate.

e. Actions do not require follow-up by SMs.

f. Team influences other teams.

What are your top questions ❓❓ or challenges, send me a message or comment below 👇🏼👇🏼👇🏼, and will be happy to engage and learn from your situation.

The Tuckman's Team Performance stages

 

As program managers, project managers, scrum masters, or agile coaches we need to constantly work with teams and help them effectively work together quickly.

Social and Psychological skills which include self-awareness, Empathy & Emotional Intelligence play a vital role in building high-performing teams. Every time we bring new people together to work on a project, we create a new team but just because they are one team doesn’t mean those folks are working as a team.

Everyone wants to be part of high-performing teams and lead them, but these teams do not appear magically. Leaders need to work towards creating efficient teams.

Last year I had a chance to be an agile coach for a few teams, the team composition was 60% existing staff and 40% new staff. In this article, I'll share the application of certain techniques, learnings, and observations.

 The goal I set for myself was to get them to high performing team in 3 months and some of them were already between Storming and Norming state. But I saw them oscillating between Forming & Storming often and we missed consistency.

 Going to the basics was my next step, I planned to get these teams to the Performing state and created a few action items so I could serve the team to get to the Performing state.

While My BHAG was” To get these teams to Performing state in 3 months”, I had to face many challenges as I was also new to the whole team dynamics. The biggest hurdle was to build trust and that took a long time, I had a feeling I might fail but my Emotional quotient, my commitment to fulfill people's promises, empathy towards teams, open communication, and being vulnerable by sharing my fears and slowing down helped me build trust with teams (at least with most of them 😊).

 

The Tuckman model describes four phases that squads go through as they form a team to deliver organizational goals. In the below table, I’ve documented a series of steps that were taken to promote the whole team to the next level.

This may not be a recipe that you could take and execute as is, I will suggest making modifications to the below content based on your team dynamics and environment.

Some of the benefits of Having High-Performance Teams are High morale of the employees and Increased client satisfaction.

I would like to know your opinions and thoughts on my observations and share how I could have pivoted to get faster results.

Product Managers knife to derive and organize Product Increment

Product Managers knife to derive and organize Product Increment

I would like to start with a question. Have you felt frozen, do you procrastinate, panic, get overwhelmed or have felt completely lost by looking at the amount of decisions and tasks which needs to get done by a specific time.

Every one of us face this situation you be in the role of Students, Scientists, Scholars, Researchers, Politicians,  Authors, Project Managers, etc. I'll discuss this from the perspective of Product Managers as I work with them closely and have lived through various product launches, Product Managers are under constant pressure to deliver value in VUCA environment. 

Need not to mention but  Product managers are the foundations of progressive and new edge organizations and they are rewarded by the value created by the crafted product served to the customers in increments and some of the successful product managers have learned the art of dealing this complexity of delivering value to customers in slices, each slice satisfies the customer need.

In-cases when product managers have fair idea of the end product and business case is available it is likely that a thick requirement document is supplied to team who then could pull work for development. Usually in an environment of large and complex product development: multiple tasks and decisions have to be taken by various stakeholders including product managers, project managers and team and they may get stuck and overwhelmed. To deal with this situation product managers and business analysts slice and dice the work in Salami slices  (features/stories) for development team.

These development Salami slices are of various thickness and they should not be sliced and diced in a food processor (at one go with equal size), once each byte of a single Salami is consumed and feedback loop is completed, Product Managers adjust the outcome and are ready for slicing the next Salami slice (feature/ user story), which produces another potential shippable increment. 

Rule 1: Never break your work upfront in equal slices 

Customer feedback loop is plugged along with each slice of delivery and the whole loop only gets completed when the process of Consumption of outcome, Gather experiences, Learn insights and application of feedback is completed. 

Once customer feedback loop is plugged into the process, the original requirement (the original unfinished work - unfinished Salami roll) is transformed into new Salami Slice which is an outcome of MVP and customer feedback actions. This process results in the value creation for all related stakeholders.

Rule 2: Each slice of your work must be plugged along with customer feedback loop, usually a standard documented practice in organizations.

These series of Nano wins build a momentum of series of success which in-turn results in motivation, empowerment, happiness and success across the eco system.

To Conclude

This techniques is one among the popular technique to divide and concur a mammoth task. Swiss Cheese method and Salami Slice method are other popular methods to eat an elephant one byte at a time. These techniques are generally applied for efficient use of time management and is effective in managing product backlog and increments 

Agile Coaches and Scrum Masters must educate, collaborate and work with Product Owners, Product Managers and Enterprise Architects to effectively utilize the time.

History of Salami Slice

Salami slicing tactics, also known as salami slicing, salami tactics, the salami-slice strategy, or salami attacks,^[1] is a divide and conquer process of threats and alliances used to overcome opposition. With it, an aggressor can influence and eventually dominate a landscape, typically political, piece by piece. 

Reference: https://en.wikipedia.org/wiki/Salami_slicing_tactics 

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.