Agile 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. […]

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.

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

03 May 2018

How to prepare and pass the PSM I Assessment

We, at Practice Agile frequently get this question from budding Scrum Masters, “How can we pass the PSM I assessment?” This made it imperative to jot down this blog based on the inputs we received from our students who cleared the PSM I assessment in first attempt. Hence this is tried and tested by people with diverse background and experiences.

Preparation –

Read the Scrum Guide and understand 11 core elements of Scrum
Read this excellent book “Scrum Insights for Practitioners” by Professional Scrum Trainer® Hiren Doshi as it has a lot of case studies based on practical experiences.
Clear the Scrum.org Scrum Open assessment with 100%at least once.

Attending a PSM workshop is optional to write your assessment. In most likelihood, by following the above 3 steps you will clear your PSM I assessment. However, attending the PSM workshop is highly recommended as it provides with much needed depth of knowledge to not just clear the PSM I assessment, but it also prepares you for intermediate PSM II and expert level PSM III assessments. In addition, we have enough data to make a claim that PSM workshop has prepared our students to face tough Scrum Master interviews and have also given them enough confidence to practice Scrum at their workplace. Also by attending it, you get 2 free attempts towards the PSM I assessment and significant discount for PSM II and PSM III assessments.

During Assessment –

Ensure you have reliable and good internet connection
Stay in a quiet area (undisturbed for 75 minutes)
Assessment is for 60 minutes with 80 objective type questions. You need at least 68 answers correct to meet the minimum passing percent of 85%.
Since this is a race against time, do not spend too much time on tricky questions as you will get conscious about the time during the assessment. If unsure about the answer, select the best option you can think of and bookmark the question to revisit later.
Do not bookmark too many questions (if possible), as you may not get sufficient time to go through all of them.
At the end of the assessment time-box, the answers will automatically be locked in, hence it is important to ensure you have selected the answers from your end in case you do not get time to review the questions again.

27 Apr 2018

Agile Coach Toolkit #8: Limiting Work-In-Progress

Do your team members have a tendency to pick up the next task to work on in case they get stuck with current task because they are measured for ‘utilization’? Such multitasking isn’t just bad, but also has harmful effects and causes stress on the person as proven by a study at Stanford University. Here’s a sample of Scrum board with no limit on WIP items –

Few issues with above view –

None of the Product Backlog Items are done as there are lot of tasks in progress. In case of any outage or downtime towards the end of the Sprint, most likelyno value will be delivered by the end of the Sprint.
This may also reflect a dysfunction that team members are working in silos, as everyone is busy working on something, but just not focused on delivering the most valuable story together as a team.
The flow of value delivery is constrained as the cycle time to complete anything valuable is impeded due to multitasking.
There is a high probability that the motivation and the morale of the team members might be low and in addition there might be a psychological pressure on the team to finish all the Product Backlog Items selected for the Sprint.

Recommended steps for Limiting Work-In-Progress:

You will need to have a buy-in from the team regarding issues with no limiting WIP items. Discussing above issues would be a good starting point to educate them.
Have them focus on the outcomes rather than ‘being occupied’. If any of the team members is stuck because the task he/ she is working on is blocked due to external dependency, instead of picking up a new task, review other WIP items of the team and assist the team members to get it done. This may mean learning new skills along the way and also help break down silos among the team.
When picking up work from the Scrum Board, always work backwards to ensure that tasks closest to Done is tackled first before moving backwards towards selecting next item to be worked upon. Such approach will also assist in reducing the Cycle Time.

Above steps will eventually lead to a Scrum Board that will look like the one below where value is continuously delivered to stakeholders during the Sprint –

Have you used this technique? If yes, please share your story.