Scrum Archives - Practice Agile

04 Dec 2020

Scrum Guide 2020 updates (compared to 2017)

2020 Scrum Guide is out and we thought of sharing some insights with you so you are aware of the changes. Scrum and it’s essence is the same and that means the core elements of the framework are still relevant. Here are a few things for you to remember –

Highlights of changes –

Less prescriptive
Introduction of Product Goal
One Team (no sub-teams) and One Product focus
Simplification of language (IT references removed) for wider audience

Prescriptions Removed –

Few prescriptions are removed. It doesn’t mean that those details are not relevant anymore. If your teams find these valuable, continuing with them is a good idea. However, if you want to experiment with different alternatives, give it a try.

Events:

Optional “three questions” for Daily Scrum removed
Sprint Retrospective commitments are no longer required in Sprint Backlog
Typical 10% capacity needed for Product Backlog Refinement (not a formal event) removed
Prescriptive elements about the events are condensed or removed (activities mentioned in 2017 guide are still valid, but teams can take up alternative approaches toward achieving the purpose)
Optional meeting after Daily Scrum for in-depth discussion

Artifacts:

Attributes of Product Backlog Items (Description, Order and Size) are optional
Monitoring progress towards the goals section
Product Owner decides when to release Increment

Product Goal –

It describes a future state of the product which can serve as a target for the Scrum Team to plan against. The long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next. Read more.

Artifacts Commitment –

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured. These commitments exist to reinforce empiricism. Read more.

Artifact		Commitment
Product Backlog		Product Goal
Sprint Backlog		Sprint Goal
Increment		Definition of Done

Updates –

Development Team to Developers: There is no separate (Development) Team within the Scrum Team, thereby promoting ONE Scrum Team focused on the same objective.

From Roles to Accountabilities: This change has been introduced to stress on the accountabilities and not job titles. Scrum Team consists of three different sets of accountabilities – Product Owner, Developers and Scrum Master.

From Self-organize to Self-manage: “Scrum Team is self-managing, meaning they internally decide who does what, when, and how.” This change in term is a way of calling out that more empowered your Scrum Team is, the better their chances of success. Read more.

Introducing “Why” in Sprint Planning: Along with “What and “How”, Scrum Team discuss “Why is this Sprint valuable?” This provides the answer to decide the Sprint Goal. In essence, we would recommend starting your Sprint Planning with Why. Read more.

Other changes –

Suggested Scrum Team size of 10 or fewer people
Multiple increments can be created within a Sprint
Along with Empiricism, addition of “Lean Thinking” as a foundation of Scrum framework
Replacement of term “estimate” with “size”
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint

19 May 2020

“Patience” is the sixth Scrum value.

*Covid is a fictional character based on my imagination that represents the strain of CoronaVirus that is causing the disease Covid-19. This article discusses Business Agility and why some organizations are not able to reap the benefits Scrum has to offer. […]

15 May 2020

Only Trust can save millions of lives.

*Covid is a fictional character based on my imagination that represents the strain of CoronaVirus that is causing the disease Covid-19. This article discusses how Trust can bring transparency an absolutely essential ingredient for empiricism. […]

04 May 2020

Hiren’s secret conversation with Covid

*Covid is a fictional character based on my imagination that represents the strain of CoronaVirus that is causing the disease Covid-19. This article discusses the Scrum framework and empiricism.

Covid-19: Knock! Knock!

Hiren: Who’s there?

Covid-19: Covid.

Hiren: Covid who?

Covid-19: It’s me, the Corona Virus of 2019. These Homo sapiens have nicknamed me as Covid-19. I like it. Hiren, you can call me Covid. How are you?

Hiren: Oh boy…COVID!! Err… I am doing well, but what do you want from me? Are you here to get me?

Covid-19: Oh no. I am just here for general chitchat with you. Tell me, how’s your Scrum training business?

Hiren: Are you kidding me about the business? You have single-handedly paused the entire world. Every person on this planet is scared of you. Why don’t you just disappear?

Covid-19: How rude. Why should I disappear? I love this beautiful planet too. It is equally mine, and I have been in existence here for a long time too. Let’s co-exist.

Hiren: Co-exist with you? Nonsense. I don’t want to argue with you. Tell me how may I help you?

Covid-19: I have heard the scientist communities from these Homo sapiens are using some framework called Scrum to eradicate me. Haha… Is this true? Please educate me. How?

Hiren: Correct. Well, we humans are the most intelligent race on this planet Covid. Over the years you must have heard from your friends Polio, AIDS, Ebola, Nipah, Influenza, and others how we handled them and we will handle you too.

Covid-19: But right now I am handling the entire Homo sapiens race. Haha. What do you know about me?

Hiren: Using the Scrum Framework, we have been continuously experimenting. Everyday iteratively and incrementally we are learning more about you. And with regular inspection and adaptation and through empirical scientific evidence we have identified many facts about you Covid.

Covid-19: Like?

Hiren: We know your Genome sequence. We know what you are made of now. We conduct Daily Scrums to put a solid plan for 24 hours and check the progress towards our goal, Sprint Review to get feedback from the key stakeholders and Sprint Retrospective to improve ourselves. We have about 80 fast paced heavily funded projects going around the globe and we will find a vaccination to destroy you soon.

Covid-19: Why is your race always angry and looking to destroy everything that comes their way? Have some respect and compassion for other organisms too.

Hiren: Why should I have respect for you? Because of you, we have lost many precious lives. And only because of you the world’s economy is in shambles.

Covid-19: Honestly, I have more reasons to get angry with you. Your race is very greedy and in that greed, you all have destroyed this beautiful planet. As a virus, I only have the ‘need’ to find a host to survive. But in your race, even after you meet your basic ‘needs’ you have unlimited ‘wants’ and these never end. Everyone always wants more… So I am equally angry with you. But I have respect for you Homo sapiens.

Hiren: You are joking right?

Covid-19: Not really. Let me prove it to you. Your innovative race came up with a new concept called “Social Distancing”, correct?

Hiren: Yes. What about it?

Covid-19: Our race self-organized and we have agreed to not bother Homo sapiens who practice “Social Distancing” sincerely. In fact, we have extended our respect to stay away from anyone who is going to wear a mask and follow the hygiene guidelines from W.H.O. Makes sense?

Hiren: Wow Self-organized. Huh? I am glad to hear this and I will pass this message around. So are you suggesting that we both can co-exist in this ecosystem and over time we will get used to each other and maybe even complement each other?

Covid-19: Yes, of course. And Hiren…

Hiren: What?

Covid-19: Show humility.

Hiren: I will work on it Covid. In the meantime, please stop bothering and hurting my people.

Covid-19: Sure Hiren. Stay healthy and I will come to meet you soon to learn a bit more about Scrum. Bye.

Hiren: Meet me for chitchat only 🙂

[…]

24 Apr 2019

Scrum is driving us crazy!

Quite a few teams in organizations implementing Scrum depict their frustration in statements like “Scrum is driving us crazy!”, “It’s too chaotic!”, “As if we didn’t have enough meetings, now we have to deal with a ton more!”, “So many metrics we need to improve upon?!?”. With the discussion that follows, it becomes fairly apparent that problem lies elsewhere.

After discussing with people, it turns out that their frustrations are primarily surrounding complimentary practices which are not part of Scrum. Few examples –

User Stories
Velocity
Planning Poker
Story Pointing
Burndown charts
JIRA tool
Information Radiators

These practices are meant to be leveraged when they help the team; if they aren’t helping, gladly skip them to avoid carrying unnecessary baggage. By avoiding these (if needed), you will be able to relieve the teams from most of the issues. Some of the problems I have witnessed – Maintaining separate virtual Sprint Backlog in JIRA as well as physical board [a classic Lean waste]; write every requirement and feature in User Story format [people are forced to do this and abuse the format]; forcing teams to increase their velocity sprint-over-sprint [read more on this here]; Burndown charts have to look smooth so we know that we are delivering value continuously [not true and unfair to the delivery teams].

Now let’s talk about what Scrum is about. For delivery teams and management, core of Scrum lies in these aspects –

Moving away from long-term plans and working towards common, yet shared goals
Delivering products iteratively through short, high value Sprints
Be empirical in your approach by regularly inspecting artefacts, processes, tools, etc. and adapt based on evidence in your hands
Engaging stakeholders often to gather valuable feedback about the product to assist in tactical change in direction, if needed
Shifting from project mindset to product mindset
Focus on delivering value to your customers rather than ‘keeping people busy’
Help improve productivity of the team by removing impediments that stall them from meeting their goals
Give control to the delivery team rather than managing or ‘micro-managing’ their tasks
Building trust by living the 5 values of Scrum
Looking for every opportunity to improve upon yourselves as a team and as individuals

Remember Scrum does not solve your problems, it just surfaces the dysfunctions that exist in your ecosystem and sometimes it can be overwhelming. So it will mean you need to unlearn some of the old habits (most of them die hard!) and will surely drive you crazy till you start reaping the benefits of Scrum.

09 Oct 2018

Attributes of Professional Product Owner

In Scrum, Product Owner is responsible for maximizing the value of product being developed by Development Team. This implies that a product’s success relies heavily on the Product Owner role. I have consolidated the attributes from Mike Cohn’s book “Succeeding with Agile” with few more must-have attributes for this role:

Visionary – Product Owner must have a solid vision on what (s)he would like to deliver to the customers. This would require the person to understand the business, market conditions and should be able to weigh in the risks and opportunities. Without this quality, Product Owner may struggle to envision the product which (s)he wants to build for the customer. In large organizations with lot of legacy systems, I recommend having Product Owner to envision product that delivers something of customer value. This product may touch upon multiple internal systems. Product Owner would need to work with Subject Matter Experts from each system to build Product Backlog which maximizes value delivered to customers.
Minimum Viable Product (MVP) mindset – At times, Product Owners fall for the budgetary trap. They get tempted to build more features since there is still budget left for consumption. Studies have proven that on an average more than 65% of developed features are never used. This is a case of adding waste into the system. Instead of consuming the budget, focus on only delivering the most valuable features.
Understand the competition – We live in a highly disruptive market where new products are launched quite often. Product Owner needs to have his/ her eyes and ears on the ground to understand where opportunity arises and take swift decisions.
Communicative and Collaborative – As a Product Owner, the person will need to communicate with diverse set of stakeholders including Development Teams. The person should collaborate with everyone to bring them onboard with the product vision.
Negotiation skills – Collaborating with various stakeholders and Development Teams would need excellent negotiation skills. This will also help avoid delays in decision-making. When stakeholders skip Sprint Reviews, it is a classic sign of dis-engaged Product Owner.
Release frequently – Business value perceived by Product Owner is only a hypothesis unless it is released to the market. By not releasing frequently, you will just lengthen the feedback loop from the customers and miss the opportunity to take necessary tactical decisions about the product.
Empowered – If Product Owner is not having authority to take decisions related to the product, it may cause delays in actual work as Scrum Team will have to wait for decisions taken by the ‘right authority’. This will happen when Product Owner role is being performed by a person that serves as a “proxy” between the Product Manager and Development Team.
Available – A Product Owner must be available for Development Team. In general, person performing this role has other non-Scrum related tasks at hand and makes it difficult to find a right balance between those tasks and Product Owner’s accountabilities. This becomes more challenging when working with geographically distributed teams with limited time-zone overlap. Scaling this role when you have multiple Development Teams working on same product makes the matters worse. I usually recommend having Product Owner office hours to ensure that teams get necessary time with Product Owner to get their queries answered.

All-in-all Product Owner is a leadership role which requires the attributes mentioned above so Scrum Team has an edge to build a product that customers need.

03 Jul 2018

Big Room Planning / Nexus Sprint Planning

Consider this post as a first step in learning about Big Room Planning, or a refresher to those who know about it already or a toolkit for those who have it planned on the cards.

Complex, cross-team projects often pose challenges to Stakeholders as to who is going to do what, when, and how. What is my dependency on others and how accountable I am for the dependencies faced by others? Over the years Agile has managed to ease the life of many involved. The concept of Big Room Planning / Nexus Sprint Planning or BRP helps break big goals into smaller manageable chunks, enables business and technology alignment, and makes elephantine problems seem feasible to solve.

So what are the basics of BRP advantages and how to do it effectively? I will walk you through the basics and how we conducted an effective BRP recently for a major tech organization at Bangalore. It was surreal, 15+ Scrum Teams working across geographies, building a complex software product.

What is BRP

When you have many teams working towards a common goal, we can bring all these together to one room towards one common goal. The goals are then broken down into various scrum teams to identify which team delivers what and how. This can also include teams from various geographies calling in from various locations to provide their valuable inputs or take stock of the situation.

The strategies and effectiveness of the BRP conducted by the Scrum masters, scrum coaches, and stakeholders help decide:

The path from goals to integrated incremental deliverables.
Clear release goals for the next 2-3 months.
The stakeholders are aligned.
Whether to increase release frequency or the agreed deliverables during sprints.

What can BRP help achieve?

But why do BRP? Is the effort worth, so many people are going to share time and effort for two crucial days? The answer is yes. Two days of effort preceded by an effective Scrum coach can make a sea of difference to the project. Some of the top benefits you can achieve from BRP are:

Define the Release Cycle. Plan the work and effort for the next few weeks and months.
Identify and Visualize dependencies and integration points across various teams.
Improve Collaboration. Teams get to see a quick white-boarded view of what each team is doing.
Helps with quick decisions making promoting a feeling of one-unit, making everyone inclusive to the cause. ·
Diverse views help look at angles you never thought of before.
People own their goals since they have planned them together.

What are some insights from my BRP session

In this section, I will sprinkle my own wisdom dust on how you can execute successful and really effective BRPs. These are like ingredients and you can experiment with these but some are necessary to lead to convincing results for all.

Need a strong facilitator – The importance of this cannot be underlined more. Without a good captain, the ship can go astray. The Scrum masters play a pivotal role in clearly defining what the end goals are, what we are trying to achieve, and how we are going to achieve it.
Agenda, crystal clear agenda – A clear Agenda and the outcome desired at the end of the sessions as well as BRP.
Objectives – Need clear and crisp objectives for teams to be aligned. Embed this in the planning, motive, and efforts of the teams
Answers – Availability of Product Owner and SMEs to help with any clarifying questions the teams have in the BRP session.
Alignment – A clear alignment between Product Owners, SMEs, and the respective ScrumTeams.

Different Flavors, Equal Goals

Nexus Sprint Planning is also a flavor of the above that helps plan and coordinate work done by Scrum Teams in the current sprint. Attended by all Scrum teams and all stakeholders, it helps teams look at the Product backlog and prioritize work for the upcoming sprints. All team members equally participate to make adjustments of the work during refinement events, participation from all scrum members helps minimize communication issues. We will talk more about this in the posts to follow.

28 Jun 2018

5 Psychological Aspects for being an awesome Scrum Master

We all understand, every field has a skill quotient that you need to achieve to be able to qualify and deliver. It’s a Doctor of Medicine for someone who wants to practice medicine, be a Doctor, and save lives. An Arts degree for an Artist who wants to paint the town in their colors. Similarly, it’s educational degrees, some authentic time-tested certifications, and real world hands-on practical experiences that qualify us to become Scrum Coaches, Scrum Masters, Agile Consultants and so on.

A Doctor at work

What makes a better artist is the ability to see the world and empathize with the art it requires. Doctors can have a degree qualifying them to be the best in their profession, but would you visit them again if they don’t give you a listening ear? What if they don’t ask open-ended questions from their experience to seek first to understand, then to be understood? What if they prescribe medicine without taking into account your allergies, immunity and actual health conditions?

An Artist engrossed in creation

Similarly, there are some psychological aspects, call it invisible forces, that are needed to be an awesome Scrum Master, Coach or Consultant that you just can’t ignore.

How do you ensure powerful collaborations?

I want to take this opportunity to share the top five values that have helped me to be a better Scrum professional in today’s ever evolving, beautiful, but at times chaotic world.

Empathy: Spend time connecting with people to gain their trust and earn their respect. Respect cannot be demanded with titles. Be positive, keep an open mind, and believe that everyone is doing the best job to his or her potential.
Evaluate how you are practicing these values
Humility: Serve people and teams to make a measurable positive difference in their lives. Don’t be judgmental. Use evidence, data and facts as a compass to help with your decisions.
Compassionate: Be kind, down to earth and practice tolerance. Have faith in yourself and believe in your abilities. Make your own magic.
Authentic: Be honest, be genuine and be real. Copying or imitating is easy, but that’s not you. Use your imagination and creativity and contribute something new and useful back to the community.
Forgive: Everyone makes mistakes. Let go, make peace with yourself, and learn the art of forgiveness and move on. Practice collaboration over competition.

I don’t claim to have mastered the above values and I honestly feel one lifetime is too short a time to master them. But, by being mindful and by practicing these values it has helped me be a better Agile Consultant and I sincerely hope it helps you too.

Collaborative and Happy Working Spaces

There are many more advances in corporate awareness, organizational development, Agile, and Scrum that are paving way for more values and psychological inputs. As PracticeAgile delivers more and more trainings, workshops, and consulting services, we will share more of our learnings as we walk on this journey together.

We would love to hear your thoughts about this article and what you would like us to cover in our upcoming posts. If you want to collaborate and learn more in our next workshop, check out our training calendar and sign up for the trainings that interest you. Share this with your fellow colleagues and friends to share the knowledge and spread the wisdom!

17 May 2018

Agile Metrics: Velocity

Agile Metrics are meant to serve a certain purpose(s) and can be very useful if leveraged appropriately. In this series, I want to share my experiences of how metrics may be used, abused and effectively become focal point of failure of Agile adoption in an organization.

Velocity is an indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.

There is no such thing as a Good Velocity or a Bad Velocity. Remember, it is based on relative estimations.

Let’s understand with some examples on how a powerful Velocity metric can turn from Good, to Bad, to Ugly.

The Good: Along with other inputs like team capacity, prior commitments, Velocity helps Development Team decide how many Product Backlog Items they may forecast for current Sprint. Velocity also helps Product Owner to gauge how quickly a team may work through the backlog, because the report tracks the forecasted and completed work over several iterations. The Product Owner may revise the forecasted delivery timelines based on the variations in velocity of the Development Team.

Velocity is absolutely awesome and GOOD metric when it is used by the Scrum team themselves to understand their progress, their strengths and how they can improve Sprint over Sprint to become better. Leveraging Velocity for any other purpose by people outside the Scrum Team may quickly result in this metric being abused and making it BAD.

The Bad: I have had instances where leaders have asked me questions like, “If two teams have similar skillset, shouldn’t their velocities be similar?”, “Team A’s Velocity is 2 times that of Team B’s – shouldn’t Team A work on the remaining Product Backlog Items for faster delivery?” This prompts me to explain to them that each team would use their internal consensus to estimate the size of tasks at hand. Such sizing of efforts may differ from team-to-team due to differences in the reference points for these two teams. Size of task ‘X’ for Team A may be larger than its size for Team B, because former may be used to slicing efforts to smaller sizes and thus resulting in ‘larger’ estimates. This may make Team A’s velocity appear higher than Team B’s velocity.

Leveraging velocities for such comparisons will not yield any benefits. In fact, such comparisons make teams very uncomfortable, as they quickly understand that leaders are using this metric to measure the collective team and possibly their individual productivity.

The Ugly: When Leadership decides to use improvement in Velocity as a measure to gauge Development Teams’ performance and teams become aware about it, things become ugly. Now Development Teams will start fudging the sizes of their PBI’s / tasks to ‘bloat’ their velocity, just to ensure they appear to meet (may be even beat) their target velocity. At this point transparency will cease to exist in the team ensuring mechanical Scrum implementation resulting in sub-optimal metrics and delivery.

To sum up, Velocity is a result, not a desire. Velocity is a good metric for Scrum Teams to leverage for its internal purpose with the idea of continuous improvement. At the same time if the Scrum Team optimizes their velocity to be able to deliver value faster, but other teams within the system are unable to consume their outcomes, it will result in waste per Lean principles. Optimization is best done at system level rather than locally.

The moment this metric is used for any other purpose, the teams and organization will lose the benefits that Scrum has to offer. This will result in Zero-sum game for the entire organization and they will lose focus on their Agility goals.

References –

Scrum Insights for Practitioners – Hiren Doshi

Source: https://www.scrum.org/Resources/Scrum-Glossary

Blog