Blog

Reach Us

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.

Artifact Commitment
Product BacklogProduct Goal
Sprint BacklogSprint Goal
IncrementDefinition 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

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.

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 –

  1. Read the Scrum Guide and understand 11 core elements of Scrum
  2. 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.
  3. 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 –

  1. Ensure you have reliable and good internet connection
  2. Stay in a quiet area (undisturbed for 75 minutes)
  3. 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%.
  4. 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.
  5. Do not bookmark too many questions (if possible), as you may not get sufficient time to go through all of them.
  6. 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.

References –

Kanban and Scrum – Making the Most of Both – Henrik Kniberg and Mattias Skarin

http://brodzinski.com/2015/10/dont-limit-wip.html

24 Apr 2018

PSM vs. CSM

PracticeAgile team regularly receive questions from Scrum enthusiasts about which certification to pick for assessing their Scrum mastery. We would like to provide below insights in order to help you take decision on this topic. Hope you find it valuable. Do not hesitate to reach out to us in case you have any queries.

 PSMCSM
Certifying AuthorityScrum.orgScrumAlliance
Training mandated?NoYes
Course materialStandardizedVaries by trainer
Number of questions8035
Time limit60 minutesNo limit
Passing score85%69%
Assessment LevelIntermediateBasic
Certification renewalLifetime validity$150 every 2 years
Number of certificates issued (Mar 2018)138,104450,000+
Number of Trainers200+2,334

18 Apr 2018

Agile Coach Toolkit #7: Straight Feedback

One of the reasons Scrum allows opportunistic discovery is due to its short and fast feedback loops. With the aim to build a high-performing Team and to get the best potential out of each individual and to help them be successful, Agile Coach needs to provide straight feedback to them. But giving straight feedback is a daunting task especially since we are dealing with human emotions. In general, just the utterance of the statement, “I would like to give you feedback” sends the heart racing for a lot of people.

Recommended Steps for giving Straight Feedback:

  • Do not delay too long in giving feedback to the person. Best to give it while the incident/ event is fresh in the mind. My suggestion is to give it within the same day at the latest, if possible.
  • Take the person away from team and work environment, even for a coffee or for a walk to maintain it a bit casual. It helps to have such discussion in isolation to avoid other distractions.
  • Start by saying something on the lines of –

“I would like to give you feedback on … <topic>”

  • Be very specific and do not generalize the feedback as it will lose the essence. It will help maintain focus on the issue.
  • Get the person’s opinion on the matter you want to discuss by Asking Powerful Question –

“How do you think you did in this … <topic>?”

  • Let the person share his/ her perspective on how he/ she believes the issue was handled. This will also serve as a checkpoint for them to introspect.
  • You may choose to then ask the person, “Why do you think you did it that way?” This will help the person to provide their reason for handling things that way.
  • Then provide your feedback on the specific topic. Avoid personalized criticism (“you are useless”) or judgmental comments (“your code is useless”) to the person. Give feedback with great humility, love and respect in mind when having such critical conversations. Remember your goal is to get the best of the person and make the individual excel in his / her role.
  • Then ask below question to the person to see if she/ he is in agreement –

“What do you think about that?”

  • Most likely they will agree with you. You can ask below question to get the person to think about next steps –

“What would you do next time?”

  • If the person disagrees, let him/ her vent a bit. Let the person reflect back on it and ask again, “What do you think about that?” If the person agrees, help chalk out the next steps in above point.
  • If the person does not take the responsibility, acknowledge it (that he/ she will not take the accountability) and say “I’ll take it from here.” May be a good idea to escalate in case the matter needs intervention from HR.

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

References –

Coaching for Performance – John Whitmore

https://www.youtube.com/watch?v=cKTR0hpc_as

11 Apr 2018

Agile Coach Toolkit #6: Building Consensus

Being a Scrum Master of a team with strong personalities can be challenging at times especially when two or more people believe that their approach is right. Such situations may call for Effective Facilitation to build consensus. This will help get the best out of the productive dissent at the same time ensuring that they do not fortify into sub-groups.

There are multiple benefits of building consensus –

  • Better decision-making as discussions would help uncover flaws/ situations which individuals may not have thought of.
  • Assist in better implementation of solution since everyone cooperates as it is a team decision.
  • Maintains team’s working relationship healthy by making everyone feel included.

Before going for a team discussion, it would help if you know the personalities you are engaging with and using Root Cause Analysis in one-to-one conversation to uncover any personality conflicts between the participants.

Steps for Building Consensus:

  • Have everyone understand the meaning of giving consent by encouraging them to think about what’s best for the entire team rather than individuals.
  • Clearly articulate what needs to be decided. It may be a good idea to also layout why the issue is being raised.
  • Before pitching for lengthy discussion, do a quick poll to check if there is consensus. If majority of the team agrees to a solution, listen to the concerns of dissenters. Adapt the popular solution to get their points addressed so we have a win-win solution.
  • If there is a disagreement amongst team members, allow everyone to voice their concerns during the discussion so their ideas can be included. It would be a good idea to list them to ensure these get addressed.
  • List Scrum Values and ask people the follow them throughout the discussion.
  • Leverage Timeboxing to ensure that you curtail lengthy discussions.
  • For final decision, do another poll to see if majority of the team agrees. Dissenter (if any), can serve as critical evaluator of the implementation of team decision. This may help spot issues before rest of the team can see it.
  • Ensure that the team decision is communicated at the end of the meeting.

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

References –

Agile Coaching – Rachel Davies, Liz Sedley

https://www.wikihow.com/Reach-a-Consensus