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 –

1. Less prescriptive
2. Introduction of Product Goal
3. One Team (no sub-teams) and One Product focus
4. 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.

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. (more…)

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.  (more…)

04 May 2020

Hiren’s secret conversation with Covid

(more…)

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 –

1. User Stories
2. Velocity
3. Planning Poker
4. Story Pointing
5. Burndown charts
6. JIRA tool
7. 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 –

1. Moving away from long-term plans and working towards common, yet shared goals
2. Delivering products iteratively through short, high value Sprints
3. Be empirical in your approach by regularly inspecting artefacts, processes, tools, etc. and adapt based on evidence in your hands
4. Engaging stakeholders often to gather valuable feedback about the product to assist in tactical change in direction, if needed
5. Shifting from project mindset to product mindset
6. Focus on delivering value to your customers rather than ‘keeping people busy’
7. Help improve productivity of the team by removing impediments that stall them from meeting their goals
8. Give control to the delivery team rather than managing or ‘micro-managing’ their tasks
9. Building trust by living the 5 values of Scrum
10. 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.