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.

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.

  1. 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

  2. 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.
  3. Compassionate: Be kind, down to earth and practice tolerance. Have faith in yourself and believe in your abilities. Make your own magic.
  4. 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.
  5. 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

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.

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

01 Apr 2018

Scrum.org PSF – What, Why, and How?

Certifications and training courses help establish a fact that the participant knows about a subject and can be questioned to ascertain. The Scrum.org, Professional Scrum Foundation (PSF) is one such course that prepares you for the Scrum world.

Here is a straight-to-the-point short post about PSF. Like our course curriculum, trainings, and our consulting, we like to get straight to it than beat around the idea!

 What is PSF?

Professional Scrum Foundations or PSF helps master everyday Scrum duties and responsibilities. This covers the eligibility needed to appear for the prestigious Professional Scrum Master Credential examination.

 Why should I do PSF?

To lead better, function effectively as a Scrum-practitioner, and be a self-organized Scrum player. Without these, effective deliveries of project leave a lot desired. A Scrum master is someone who has to learn to be active and deliver effective value. The PSF foundation course will enable you to attempt the PSM I assessment and prove your mettle.

How do I do PSF?

We at PracticeAgile.com help train our students to learn and master PSF. The course comprises of expert instructions and team based exercises that help you gain mastery over Scrum nitty-gritties, lead teams to collaborate more. We will cover:

  • Fundamentals of Scrum
  • The Scrum Framework
  • Mastering Scrum
  • Planning with Scrum
  • Getting Started and keeping Scrum healthy

It’s a Hands-on workshop where we do scrum from the trenches. An example case study of an HTML based website is carried out, where we build the Website as a Scrum-project over duration of 4 sprints. It helps get first-hand experience on how to deal with dependencies and integration challenges in scaled environment.

Contact us through my linked in presence or drop us a note at Practiceagile.com. Happy to answer any queries you have about PSF. For folks based out of Mumbai, India and nearby areas, we have a training scheduled next week. Check the training calendar to know more and register.