7 Steps to Reclaim Your Scrum Master Super Power

Over the years, we have trained, mentored and coached hundreds of Scrum Masters. As we reflect on our experience, one truth seems to stand out - many Scrum Masters we meet are driven by a purpose.

Being a Scrum Master is not just a job for them. It is a calling to help others. It is a calling to live by principles and values higher than the principle of survival. The Scrum Master is accountable for the Scrum Team's effectiveness and they are most fulfilled when they are truly honoring their calling.

Unfortunately, in some organizations that claim to adopt Scrum, a Scrum Master is not always fully respected and they are only responsible for scheduling meetings, typing up notes, and being a management enforcer to deliver on-time, on-budget and ever-increasing scope projects. Being trapped in such roles can really affect the morale of purpose-driven Scrum Masters and they are unable to really utilize their super power of supporting the Scrum Team. But what can Scrum Masters do to avoid this pattern? If you are interested in the answers to this question, please join us in this webinar.

In this webinar, Professional Scrum Trainers Nagesh Sharma and Ravi Verma will share seven concrete steps that purpose-driven Scrum Masters can take to avoid and escape this trap while reclaiming their professional scrum master superpower.

Speakers

NAGESH SHARMA

Nagesh is very passionate about causing change and improve business results. His mission resonates with Scrum.org's mission of helping people, teams, and organizations solve complex problems. He has been engaged with many Large Enterprise transformations to a Lean and Agile approach, organizational dynamics, and creating high-performing teams.

His Agile knowledge & experience, along with his coaching and training abilities, offers him the perspective needed to guide people, teams & organizations to harness Agile as a competitive advantage.

Nagesh is a certified Intelligent Leadership Master Executive Coach by John Mattone, ACE Certified Coach by David & David. Managemen t3.0 facilitator and collaboration superpowers facilitator. Nagesh is also licensed to use Everything DiSC, STPI 360, Agility Health, AlDente, and Leadership Agility360 assessments.

He is an active speaker at various international conferences like Scrum Day Europe, Scrum Deutschland, Scrum Day India, Agilitytoday, Scrum Master Podcast, and Regional Scrum Gathering. Nagesh loves building communities and has been a track curation for Scrum Master Summit 2021 and Lead Official Scrum.org community meet-up in India.

RAVI VERMA

Ravi is the founder and Org Whisperer at SmoothApps and a Scrum.org Professional Scrum Trainer. He recently co-founded his second startup - Al Dente, a platform that helps Agile Coach’s and organizations empirically manage and improve business outcomes in tandem with Agile delivery frameworks like Scrum.

Ravi has 20+ year of Software Delivery and Consulting Experience with including Agile Enablement for companies ranging from 10 people to 10,000 people. Ravi is the creator of the Sabotagile Manifesto and Sabotagile Principles , co-creator of Software Code of Ethics, Scrum Pulse Webinars & Scrum Tapas Videos and co-founder of the meetup group Agile DevOps DFW. He is a certified trainer for Sharon Bowman’s “Training From The Back of the Room” courses and integrates brain-friendly learning into his training. He is also a Certified ROI Professional from the ROI Institute and integrates ROI Based Learning techniques into his training, coaching and consulting. Ravi is a Co-Active Scrum Coach and has completed 104 hours of training and 25 intense weeks of certification from the Co-Active institute.

As a grateful immigrant to the USA, Ravi felt a strong urge to give back to the country that adopted him and co-founded a non-profit – Agile For Patriots to provide free Agile training, certification, experience, mentoring and coaching to US Military Veterans and Spouses. Since its founding, Agile For Patriots has helped 44 candidates graduate from the program through 7 cohorts and is now preparing for the launch of their 8th cohort scheduled for Q1 2022.

Resource: https://www.scrum.org/resources/7-steps-reclaim-your-scrum-master-super-power

Read More

What Happens To The UNDONE Work In A Sprint?

Even a well-set team with clear objectives may fail to finish each thing when the sprint ends.

When the sprint was planned, the team might have thought about successfully tackling 6 Product Backlog Items (PBIs). But in reality, they might only address 4 or 5 PBIs. The rest of the items remain undone.

How shall we address the issue of UNDONE items?

DEFINITION OF DONE

To discuss what should be done with UNDONE PBIs, let us focus on the Definition of Done, as stated by professional scrum master training.

The Definition of DONE expresses the situation when an ‘Increment’ matches the quality parameters of the product.

An ‘Increment’ comes into existence when a PBI matches with the Definition of Done.

The definition, in this case, creates transparency for the team. Each team member has a shared understanding of the completed work, a segment of the ‘Increment’.

When a PBI does not comply with the definition, it is a mistake to release it. It can’t be even presented during the Sprint Review. Instead, it is regarded as a future consideration. 

But the question remains – how to estimate the unfinished PBIs? Is it possible to re-estimate them, and is it valid? Shall the team calculate the velocity for the tasks they have already completed? Let us dig deeper, starting with the concept of Partial Credit.

A Team should calculate the velocity for the Partially DONE work – YES or NO?

It should be clear at the very beginning – there is practically nothing as partially done.

When a team completes a segment of a PBI, the members receive partial credit or points, accounting for the velocity.

For example, if the team finishes half of the five-point PBI, the count is approximately 3, accounting for their velocity.

As far as I see it, the idea is not good. The velocity should be calculated only in cases of completed PBIs, which comply with the Definition of Done. It fulfils two objectives:

The velocity for the team becomes more relevant (not just a cosmetic parameter).

There is no cutting of corners. The UNDONE work again enters the PBIs and is re-estimated.

A prevalent question from the Management that a team has to address is reporting on the percentage of work yet to be done.

It isn’t easy to calculate the exact percentage. But, in most cases, there is an overestimation.

It happens because teams generally have a wrong notion that they are ahead of schedule. As a result, they over-estimate while calculating the velocity. One reason is the false expectation from the Management. I addressed this myth Velocity is Productivity.

An inflated value of velocity is good only momentarily. It provides a false pride of achievement. But, it is not useful practically. It sends wrong signals about dealing with PBIs in the near future.

Re-Estimation of the Unfinished Work

When there exists an undone PBI after iteration, the standard query of the team is whether it is right to re-estimate it. It is independent of any objective to get partial points.

The team members usually reason that a part of the work has been completed, and it might impact the estimation of the work left to be done.

Keep in mind that the overall size of the PBIs might increase. So, the estimation of the items remaining to be completed could rise, obviously higher than the estimate at the initial stage.

Thus, my recommendation here is shifting of focus from “velocity-driven” to “value-driven” planning.

But again, shall a team consider re-estimation?

Should the UNDONE work be re-estimated?

There are distinctly three valid reasons  that support the re-estimation idea:

After the completion of the work, the team members can estimate better.

It is a priority to plan and design the next sprint.

Finally, it is important to know when the work will be completed or DONE.

It is difficult to argue with pointer one above. So, I will accept it. My main focus is on the remaining two pointers.

The second pointer is about the necessity to plan and execute the next sprint.

Team members will generally be confused about the amount of work they should bring into a planned sprint when the PBIs have outdated estimation parameters due to incompletion.

They could say they would need more work to complete due to the backlog. Also, they could sound that they would resume from the beginning, complying with the current sprint goal.

Now, let us revert to the original query – should it be re-estimated?

My short answer is – YES. There are two reasons I want to put forward.

There might be a change in the complexity of the Product Backlog Item (PBI).

We generally don’t know whether the same team member will work on the Product Backlog Item.

Conclusive thoughts

It is the responsibility of every SCRUM Master to focus on helping a team define their definition of DONE, especially in cases when the team has not defined it.

The Definition of DONE undoubtedly creates more transparency. In addition, it provides shared understanding to each team member regarding the work segment completed as a component of Increment.

When a PBI doesn’t comply with the Definition of Done, the team should not release it or present it at the Sprint Review. Instead, the PBI returns to the set of backlogs to be considered in the near future.

Resource: https://www.tryscrum.com/blogs/what-happens-to-the-undone-work-in-a-sprint/

Read More

5 Ways to Improve Your Scrum Team's Process

How do you work to maximize the benefits of your team to have greater agility by leveraging Scrum?

We know that Scrum is a framework, and the Scrum Team works together to define their own process within the boundaries of the Scrum framework in professional scrum master. This includes their practices, tools and interactions, how they fulfil the accountabilities of their Scrum roles, and how they utilize the artifacts and events.

How does your team determine what to create and how do they create it? What practices (product management to engineering and quality) do they use? Practices can help enable and improve how your team communicates and collaborates to how they effectively use and grow team knowledge, skills, and capabilities. And much more.

There is a lot going on when it comes to delivering complex products in an uncertain and constantly changing world. In this webinar, Scrum.org Professional Scrum Trainer Stephanie Ockerman breaks it down to 5 ways Scrum Teams can discover their opportunities to improve the many different aspects of their process.

Resource: https://www.scrum.org/resources/5-ways-improve-your-scrum-teams-process

Read More

Humanising Organisations with Scrum-Episode # 1

In this Webcast, Mike Cohn answering some of his perspectives on Agile and Scrum.

About Mike Cohn

Mike Cohn is the author of three best-selling books on agile (User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile). He is also a Certified scrum master training, keynote speaker, and an in-demand coach to companies throughout the United States and worldwide. He can be reached at mike@mountaingoatsoftware.com.

Resource: https://www.tryscrum.com/blogs/humanizing-organisation-with-scrum-episode-1/

Read More

Is it worth it to become a Professional Scrum Master

In March 2021, I was conversing with a CTO of a Product based company. He asked me a question that if it was worth employing a Scrum Master. We discussed the topic by exchanging opinions, and I explained my viewpoint.

Through discussion, another question came up. The question was, how do we create the career roadmap of a Scrum Master? Is it truly worth it to become a master? How can we address this doubt? Certain factors like slow economic recovery and stuck wages are essential in the said matter. But in my opinion, the answer is straightforward. It is not a crystal-clear process to design one’s career when lasting fulfilment is a target. My advice and viewpoint are as follows regarding the worthiness of the professional scrum master career path.

Seek satisfaction and expertise

How can we determine the value of our work as a Scrum Master and Coach? For addressing the question, I need to tell you my experience as a Scrum Master when I started my career as a Scrum Master in 2013.

My approach was to ask myself if I can create a positive and long-lasting impact on the concerned team or organisation. I was not into making a short-lived impact. My mentoring aspects would have been negative if applied as a short-term one. How did I recognise if the impact that I created was long-lived? There is no direct answer. You would at least require three different organisations, four identical teams, and a total of three to four years of experience, to quote the least.

Treat your career course as a trial

In my opinion, those people who try to find a meaningful purpose in their successful careers have an experimental approach.

You need to find quicker ways to confirm your career hypothesis to reach a fulfilling level. It is unnecessary to join a new job in a new industry to identify if it suits you. The first concrete step towards finding it is to have the will to experiment with different opportunities in your existing company. Be straightforward and determined to ask your employer about playing the role of a Scrum Master of the concerned team. Seize the opportunity to learn more about the line of work and research online. Take up voluntary projects and engage in conversations to learn more. Joining a community would help you see the glimpse of promising lands.

Asking a Coach or Mentor

Do not undervalue a mentor’s power in any way. For example, when I first took my career decisions, I knew I required expert assistance. Thus, I went on to learn better by connecting to the mentors.

If the mentor is an expert, you will attain valuable guidance to boost your confidence level. Additionally, several studies on this profession validate this fact:

Glassdoor provides specific predictions with the recently released report, 50 Best Jobs in America for 2021. The report says that Scrum Master is one of the best careers to consider, for which they ranked it at the 40th position among the top fifty jobs.

40th position: Scrum Master:

·       Rating for job satisfaction: 4

·       No. of job openings: 2331

·       Median Basic Salary: $105,000

To specifically comprehend India’s career opportunities, you should know that there are 843 jobs listed on Glassdoor. The stated update is valid at the time of writing the article(July 2021).

Bonus

LinkedIn Data Reports claim that the Job role of Scrum Master is one of the most Promising careers in 2019.

Trust me, that finding the career of your dreams is not at all an easy task. The path that follows in finding the dream job is a bit scary. I can vouch for it from my experience. But keep in mind that you should not back out from the process for the scare factors. A frightening process does not imply its unworthiness.

Avoid Rushing

Consider the time that you will spend in your work in hours. It is 90,000 hours in a lifetime for an average person. Thus, you only have to ensure that the time you spend is worth it. It should align with your talent, values, and passion. Only then can you achieve a promising career. You have the

right tools and power to reach that place, so why should anyone else decide on the worthiness of the chosen career? If you are ready for it, get started now!

I have shared my perspective, and I am sure it is worth it to become a Scrum Master. What are your thoughts? Would you please share in the comments?

About Author

Venkatesh Rajamani has more than 15 years of experience delivering working software in short, feedback-driven cycles. He loves to humanise workplaces. He founded tryScrum.com in 2018 to execute his mission of Humanizing Organizations.

Resource: https://www.tryscrum.com/blogs/is-it-worth-it-to-become-a-scrum-master/

Read More

How to Use Scrum in Human Resources

Scrum and Human Resources (HR) - how do they work together? And what are the implications of using Scrum within HR?

In this webinar, Professional Scrum Trainer Martijn Magermans and Agile HR Expert Astrid Karsten, author of Toolkit for Agile Talent Development, will take you with them on a journey through agile HR from a Scrum perspective. This webinar is for both HR professionals with an interest in Agile & Scrum and for Scrum Professionals with interest in HR. Martijn and Astrid will explore how Scrum can be used in areas such as professional scrum master performance management, rewarding and compensation, the employee journey and more.

During this webinar attendees will:

- Get a clear understanding of what Agile HR is

- Learn how the Scrum Framework works in HR

- Learn how to make the first step towards increased agility within HR

About Astrid

Astrid started her Scrum and Agile journey as a frontend developer in several teams. By then she was already most intrigued about the “human” factor in development and high performing teams. She continued her career as an Agile Consultant, mainly focusing on agile in infrastructure and non-IT. Since two years she has taken a deep dive in the wellbeing of humans from different perspectives; leadership, HR, personal agility and of course the perks agile and scrum could give in those areas.

About Martijn

Martijn's mission is to connect people, processes and technology, putting people at the heart of the business. As an Agile Coach and trainer he helps clients effectively apply agile ways of working to increase business value, employee happiness and customer satisfaction. He's been passionate about agile product development ever since I was asked to head the development of a technologically advanced track and trace service used in hospitals. As a Product Owner he learned the benefits Scrum offered in controlling complexity and driving continuous improvement.

Resource: https://www.scrum.org/resources/how-use-scrum-human-resources

Read More

Certified Scrum Master Training - Question Should Ask Their Teams to Get Up To Speed

TL; DR: 20 Questions a New Scrum Master Should Ask

Twenty questions for you — the new Scrum Master — that fit into a 60 minutes time-box. Start learning how your new Scrum Team is currently delivering the product and get up to speed: from Product Backlog forensics to metrics to team challenges and technical debt. Download a printable template for your convenience.

Start Learning the Ropes as a New Scrum Master

I was recently asked to participate in the Product Backlog refinement of a team that was looking for a new Scrum Master. I was skeptical in the beginning. I had only limited knowledge about the project—a commercial website based on a CMS—, the refinement session was time-boxed to 60 minutes, and I hadn’t met the team members before beyond a very brief “hello.”

So, I prepared a questionnaire comprising team-related topics. I wanted to learn more about and listened to the Scrum Team, refining several work items. When appropriate, I asked one of the prepared questions. Surprisingly, the insights turned out to be much more qualified than I expected. Particularly, I could identify the low-hanging “Scrum fruits” to improve product delivery relatively easily. Remember that as a Scrum Master, the stakeholders will always judge you by whether “your Scrum Team” can deliver a valuable, potentially releasable, “done” Product Increment regularly.

The questionnaire I used as is available as a download for your convenience:

Let us get into the questions for a new professional scrum master training at tryScrum:

How large is your Product Backlog?

I do not believe in Product Backlogs that are larger than what the team can handle in three, maybe four Sprints. If the Product Backlog exceeds this threshold, the Product Owner might be in need for some support.

What is the typical age of a Product Backlog item?

A Product Backlog item that has not been touched in five months is obsolete. Cluttering the Product Backlog with ideas, reminders, or other low-value items increases the noise, thus probably impeding the value delivery of the Scrum Team. (Admittedly, I am a fan of Product Backlog forensics.)

What is your average lead time from an idea being added to the Product Backlog to its delivery?

No one could answer that question in the before-mentioned session. But it is actually one of only a few metrics that can provide some insight on whether Scrum has been successfully adopted by your organization. (Read more: Agile Metrics — The Good, the Bad, and the Ugly.)

Does your Product Backlog contain work items none of the current team members is familiar with?

If so, the Product Backlog items in question may no longer be valuable. Consider re-refining or deleting them.

How often are you refining the Product Backlog?

That should be a continuous process. As a new Scrum Master, however, I would love to have a Product Backlog refinement session once a week with the whole team.

On how many Product Backlog items are you working in parallel during Product Backlog refinement?

Ideally, a team should not be working on more work items than it can handle within the next two or three Sprints. Otherwise, the risk of allocating resources on work items that may never make into a Sprint Backlog becomes too high.

How long does the refinement of a typical Product Backlog item take?

The refinement should not be taking more than one to two Sprints. Otherwise, the Product Owner might need some support in preparing ideas properly for the refinement sessions.

How are you creating Product Backlog items? (Is it a joint team effort with the PO, or is the Product Owner writing the work items and the Development Team estimates them?)

There is a tendency to observe that Product Owners become more a kind “technical writer” of Product Backlog items which then get estimated by the team. I suggest, however, to turn Product Backlog item creation into a joint effort of the whole team. Remember Ron Jeffries’ CCC: card, conversation, confirmation?

Where are you discussing Product Backlog items? (Only during refinement sessions or also on Slack or via comments on tickets, for example?)

Every team has its own habits and maybe commenting in Confluence, Jira, Github, or utilizing Slack is an effective means of communication in your organization. As long as this happens before a work item is selected for a Sprint Backlog, this should be fine. Discussing its essentials afterward is a problem, though, as the Sprint Goal might be compromised.

Who is writing acceptance criteria and in what format?

It should be the Product Owner in collaboration with the Development Team following the Definition of “Done,” thus creating a shared understanding of what the team needs to build.

How are you estimating the likely effort of a Product Backlog item?

There are plenty of practices on estimating a work item if your Scrum Team estimates at all. (Think of #noestimates or creating similarly sized work items instead.) The emphasis should be on creating a shared understanding among all team members what shall be created. An estimate is a side-effect, not the primary purpose.

Are you estimating in man-hours or story points?

Estimating in man-hours is better than not estimating at all. However, I prefer story points, particularly if the application in question is burdened with legacy code and/or technical debt. Predictability and stakeholder communications become easier this way as story points have a built-in buffer.

How are you practicing the estimation process, if the team shares different opinions?

Preferably, you should observe the team’s estimation process in real life. But in case you have to ask: is it a typical vote-discuss-revote cycle? Or: when and how do you pick an estimate? (Examples: 50:50 split, e.g. 3*3 and 3*5 – which one do you take? Or a majority split: 2*3 and 4*5. Or the estimations cover a range, e.g. from 2 to 8?) It is a good way to learn more about the team building state, too.

What is a typical distribution of work item sizes in your Sprint Backlog?

This question tries to figure out, where the productivity sweet spot of the team is, based on the Sprint Backlog composition. In my observation, Scrum Teams often work more successfully when a Sprint Backlog comprises one or two larger Product Backlog items, some medium-sized stories, and a few small ones.

Are you re-estimating work items at the end of a Sprint? If so, under which circumstances are you doing so?

That should always be done if a Product Backlog item turns out to be way off its original estimation. Re-estimates make good data-points for Sprint Retrospectives, too.

What was your velocity for the last three Sprints?

A Scrum Team should know its velocity or productivity, how could it otherwise possibly improve?

How many user stories are typically not finished within a Sprint and for what reasons?

If the team is bullish and picked more Product Backlog items than it could probably handle at the beginning of the Sprint, so be it—nothing to worry about if the Development Team meets the Sprint Goal nevertheless. If the Development Team, however, is regularly leaving work items on the board and not meeting Sprint Goals, this should be a major concern for the new Scrum Master. See also: Scrum: The Obsession with Commitment Matching Velocity.

Are you changing Product Backlog items once they become part of a Sprint Backlog? And if so, under what circumstances?

Making work items smaller if the Development Team runs into a problem is certainly not great, but acceptable—if the work item in its reduced form still delivers value and the Sprint Goal is met. Extending it after the Sprint Planning, however, would only be tolerable if the Development Team agrees on the extension, and the Sprint Goal will not be compromised.

How would you consider the level of technical debt?

As a new Scrum Master, you want to know everything about the current level of technical debt and dependencies on other Scrum Teams or external suppliers. These issues are directly responsible for your Scrum Team’s ability to deliver product Increments. (Read more: Technical Debt & Scrum: Who Is Responsible?)

What are the three main challenges the Scrum Team is facing today?

This closing question is by design an open-ended question to get some ideas for the next Sprint Retrospective.

Conclusion

The New Scrum Master and the Scrum Team

What is your preferred technique to get familiar with a new Scrum Team as soon as possible? Where do you start? Please share your experience in the comments. 

Resource: https://www.scrum.org/resources/blog/20-questions-new-scrum-masters-should-ask-their-teams-get-speed

Read More

Valuable Coaching Tips for Certified Scrum Master Training

In this Scrum Tapas video, Professional Scrum Trainer Stephanie Ockerman provides tips for Scrum Masters while in the coaching stance. Stephanie discusses 6 different tips that you can take start applying immediately. The Scrum Master course is for anyone involved in Improving the software development using the Scrum framework. It is particularly beneficial for those people within an organization accountable for getting the most out of Scrum, including Scrum Masters, Managers and Scrum Team members. In this course, you’ll explore what it takes to MASTER the art of being a Scrum Master. The most exciting part is the practical guidance & Mentoring from Venkatesh Rajamani offers to support you on your own path to greatness.

Know more: https://tryscrum.com/scrum-masters/ 

Read More

52 Challenging Cases for Scrum Practitioners with Professional Scrum Master Training

The Scrum Framework is a lightweight framework to solve complex and adaptive problems with others. Although it looks easy on paper, it’s often much harder to do well in the messiness of the real world. Where do you make trade-offs? How can you model the Scrum values? How can you work empirically in an environment that isn’t suited for it?

To encourage Scrum practitioners to explore these questions during professional scrum master training at tryScrum, we created 52 real-life cases. These cases are inspired by our own experiences and those of the people we frequently work with. Use these cases for your community of Scrum Masters, as conversation starters in and around your Scrum Team, or put your own understanding of Scrum to the test. And no, there is no “right answer” :) The learning is not in knowing the answer, but in jointly deepening your understanding of the Scrum principles and values through reflection, dialogue, and putting new ideas into practice.

    

The deck is provided as a digital download with 52 cases for a small fee. We also have a free version available that includes 10 cases. In this blog post, we offer inspiration for when to use these cases and give suggestions for what Liberating Structures to try as conversation starters.

Example of the case: “What are good metrics?”

When to use the cases?

Finding a good opportunity to use the Scrum cases shouldn’t be too difficult. You can use them for individual reflection, within your Scrum Team, or the wider organization. Some specific examples to use the Scrum cases are:

During Sprint Retrospective. Share the Scrum cases before the Sprint Retrospective with your Scrum Team. Ask everyone to select the cases they think are the most interesting, relevant, or challenging. Identify the top-3 and bring those cases to the Sprint Retrospective to discuss in more detail.

    

For individual reflection. Select a Scrum case, get your own thinking started, and share your thoughts on LinkedIn. Most likely, it will trigger a conversation in which you can explore the case with other Scrum practitioners.

Within your Community of Practice. Many organizations have a Community of Practice in which participants share experiences and give & get help. Organize a session with the most relevant Scrum cases as a topic. Also, you can learn vast knowledge about product owner certification online.

As a conversation starter with management. Share the Scrum cases with management in your organization. Ask them to identify the most challenging cases or the one that raises the most questions. Simply have a one-on-one conversation with a manager about a specific case. Or host a workshop with more managers to discuss the cases.

During a public meetup. Make a specific Scrum case the topic for a public meetup. For example, your local Scrum user group. The wide variety of experiences will offer many different, fresh, and surprising perspectives.

For a job interview. Use the cases for any kind of Scrum related job interview. Prepare a couple of cases, ask the candidate to select the one (s)he considers the most interesting, challenging, or recognizable and simply have a conversation. By discussing the case you’ll get a good sense about the person’s understanding of the Scrum Framework.

Example of the case: “The technical Sprint Review”

How to use the cases?

We purposefully wrote each case in such a way that there is no clear “right” answer. Instead, there are different sides to each case, different arguments to make, and different solutions — some better than others. Just like the real world …

For the best learning experience, use Liberating Structures to structure the conversation. That way, everyone can offer their perspective. You may even find creative solutions to your own challenges!

 

Some examples of Liberating Structures to try are:

Conversation Cafe. We like to use Conversation Cafe to dig into cases like these. It encourages people to listen and understand each other’s perspectives on a profound, shared topic or challenge instead of trying to convince or persuade others to see it your way. Sitting in a circle with a simple set of agreements and a talking object, small groups engage in consecutive rounds of dialogue. Follow-up with 15% Solutions or 1–2–4-ALL to translate learnings from the case to your own team or environment.

1–2–4-ALL. Only doing a 1–2–4-ALL during a session is already a good approach to explore a case. Start with 1 minute of silent self-reflection. Take 2 minutes to generate ideas in pairs, building on ideas from self-reflection. Create groups of four and use 4 minutes to share and develop ideas that you’ve discussed within your pair. Notice similarities and differences. Take 5 minutes to share insights, ideas, and takeaways.

Impromptu Networking. With Impromptu Networking, you can discuss a case within 15 minutes. Invite the participants to stand up and form pairs. Present the case to discuss. Within the pairs, ask people to share their answers to the case. Signal the end of the first round and have people from new pairs. Within the new pairs, ask people to (again) share their answers. But also ask them to pay attention to similarities and differences from their previous conversation. Do one rounder. After the 3 rounds, gather insights and patterns that the participants noticed.

User Experience Fishbowl. The UX Fishbowl is ideally suited for unleashing the local wisdom of groups of any size. If within your team or organization people have experience (successes or failures) with a certain case, invite them to participate as the “inner circle” of the fishbowl. During the UX Fishbowl, the inner circle shares experiences while the outer circles listen. In alternating rounds, the outer circles generate questions they’d like to ask the inner circle. By focusing strongly on listening and asking questions about experiences, you can use UX Fishbowls to create an environment where people can learn together (rather than get solutions imposed on them).

Conversation Cafe in a workshop with Swisscom and KPN iTV. Conversation Cafe is a great Liberating Structure to explore the cases.

Discovery & Action Dialogue. “Discovery & Action Dialogue” (DAD) exists to help groups invent local solutions to the problems they face. Rather than giving up or immediately reaching to “best practices” that worked elsewhere, it helps groups carefully analyze the problem, potential solution, and how everyone can contribute to both. To use “Discovery & Action Dialogue”, select the most challenging case for your team or organization, download this worksheet, and discuss the questions in small groups.

Wicked Questions. Especially because there are no right answers, the Liberating Structure Wicked Questions is ideally suited to discuss the cases. The purpose of Wicked Questions is not to find a single answer, but to create transparency about seemingly paradoxical realities that exist side-by-side. By accepting both realities, you can engage in deeper strategic thinking and explore new possibilities for the “Wicked Cases” at hand.

              

Integrated Autonomy. Most of the challenges we face in the real world don’t have an easy answer. Different solutions can be true or happen at the same time. This is also reflected in the 52 Scrum Master cases where multiple answers might be true. When discussing the cases, it’s tempting to get stuck in either/or-thinking. But what would happen when we start thinking in terms of ‘and’ instead of ‘or’? What if we can find solutions that are helpful to both sides? Integrated Autonomy will help you adopt a more holistic view of the cases. Instead of steering the group in one direction of possible solutions, it actively invites them to uncover solutions that work across the field.

Wicked Questions combined with Discovery and Action Dialogue and Integrated Autonomy. A string we used during the Immersion Workshop in May 2019 in Amsterdam. The visualization is created by Thea Schukken.

Shift & Share. Especially in larger groups, Shift & Share is an ideal structure to discuss one or multiple cases. Prepare 4–6 stations with each a specific case. Ask the group to form small teams and to pick one station. At their station, the teams discuss the case and write feedback on the flip-over. After 10 minutes, the teams move clockwise to the next station. This is repeated until the teams have visited all stations. Discuss the key-takeaways with the group as a whole.

Improve Prototyping. The purpose of Improve Prototyping is to re-enact a challenging scenario (e.g. Scrum case) faced by a group or an individual and work together to devise different behavioral strategies and interventions by acting it out. The twist that this structure brings is that the person who introduced the scenario becomes the ‘director’, while the others become the ‘actors’. This allows the director to playfully experiment with strategies, behaviors, and interventions. As such, Improve Prototyping is ideally suited to explore the Scrum cases!

What, So What, Now What? ‘What, So What, Now What’ is a foundational Liberating Structures that helps by asking us to step back and consider what is going on. It structures our thinking by breaking our experience down into three steps: “What do we notice?”, “So, what does this mean?” and “Now, where do go from here?”. The flow of this Liberating Structure makes it ideally suited to reflect on the Scrum cases. Considering using 1–2–4-ALL to answer the questions. This prevents a group discussion and allows everyone to reflect and contribute.

Example of the case: “The part-time Scrum Master”

Closing words

In this blog post, we offered inspiration for when & how to use the 52 Scrum cases we created for the Scrum community. We hope it will trigger valuable conversations in and around your Scrum Team, improve your understanding of the Scrum Framework, and grow a stronger Scrum community. The 52 cases are available as a digital download for a small fee. We also have a free version available that includes 10 cases. Enjoy using them!

Want to learn more about Scrum and how to become a more effective Scrum Master? Join our on-site Scrum.org Professional Scrum Master II course or the online edition. We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive, and serious-but-fun. If you need help, feel free to join our user group ‘The Liberators Network’, which is all about learning and growing, together!

Resource: https://www.scrum.org/resources/blog/52-challenging-cases-scrum-practitioners

Read More

Understanding the Kanban Guide for Scrum Teams in Professional Scrum Master Training

It’s been so exciting to hear so much positive feedback and interest in the new Scrum.org Kanban Guide for Scrum Teams and the accompanying Professional Scrum with Kanban class. Creating the class and guide together with Daniel (Vacanti) & Steve (Porter) and then working on getting it to market in a professional way (how else?) with the Scrum.org staff has been a great experience and a major focus area for me in the last couple of months.

As you might imagine, together with the interest come some questions about some choices we made in the design of the guide and the class. Several are emerging as the frequently asked ones. I wanted to tackle a couple of those in this post.

Where are some of the core Kanban practices?

The major one we’re getting comes from people who are experienced Kanban practitioners who notice that how we describe Kanban in the Kanban guide for scrum teams in professional scrum master training is different than the definition they’re familiar with. (Including my Kanban Primer for Scrum Teams blog post for example…) This isn’t an oversight. It’s by design. When we set out to create the Kanban Guide for Scrum Teams/approach we had a specific context in mind. That context is teams using Scrum according to the Scrum guide, ideally professionally.

In the Kanban Guide for Scrum Teams, we focus on helping in this context. These teams already have a collaborative inspect and adapt experimentation process together with a set of explicit feedback loops they’re using. So, we set out to define the minimal simplest set of Kanban practices that these Scrum teams would need to add in order to achieve steadier, healthier, more sustainable flow (I like to say it is like moving from a sprint that looks like a swamp to one that looks like a river).

After some discussion we decided that these practices actually complement what a professional Scrum team is already doing:

 

·    Visualization of the workflow

 

·    Limiting WIP

 

·    Active management of work items in progress

 

·    Inspecting and adapting their definition of "Workflow"

 

While we agree with the importance of “Improve Collaboratively (Using models and the scientific method” and “Implement feedback loops” we think they are redundant in a professional Scrum context.

Where are some advanced Kanban concepts like Classes of Service, Cost of Delay, Flow Efficiency?

They’re not part of the guide because we don’t consider them part of the “Minimally viable set of practices” a Scrum team should focus on when trying to improve their flow. Having said that, our guide and especially the PSK class provides people with some pointers towards advanced complementary Kanban/flow practices/metrics that at least some can use to continue their learning and improvement journey.

Beyond that - Some of them might be useful in some Scrum contexts, some less so.

Is this an application of the Kanban Method or not?

In my personal view, it is pretty close, as long as you assume professional scrum is your starting point. (see a blog post I wrote back in 2012 about this context). You are starting with the way the team uses Scrum and with respecting their current Scrum process & roles. You are obviously interested in pursuing an incremental evolutionary change to improve your performance and satisfaction with your process beyond what you’re currently achieving with Scrum. There is that argument that limiting your work in process is far from being an evolutionary change but rather a disruptive revolution. My personal take on it is that yes, limiting your work in process and moving to a disciplined pull mode is far from being easy, but it’s still evolutionary compared to changing team structures, roles, process flows. And in any case, this is an argument about the Kanban Method outside of a Scrum context as well. A professional Scrum team should actually have an easier time limiting WIP than most.

Is this ScrumBan?

Depends who you ask. Some people’s definition of ScrumBan is “A way to help teams’ transition from Scrum to Kanban”. This isn’t what we’re talking about here.

Another definition (that I subscribe to) is to see ScrumBan as a way to introduce Lean/Kanban flow into a Scrum context – while keeping the core Scrum process intact. This is pretty similar to our take on the process Scrum teams will typically take to get to an effective combination of Scrum and Kanban.

Finally, a variant on this definition is to see ScrumBan as simply the Scrum+Kanban combination itself, without worrying about your starting point and journey. This, in my view, is indeed what the Kanban Guide for Scrum Teams describes.

Why/When should you add Kanban to Scrum?

The last question I want to tackle is one of the first you might want to think about. Essentially the question is “Why bother? Isn’t Scrum great as is?”

Most of the teams I’ve worked with since 2010 or so find Scrum+Kanban to be the ideal mix. I’ve helped Scrum teams achieve an even healthier smoother flow by adding Kanban to their process. I’ve helped Kanban teams accelerate their pace of improvement by adding cadence/rhythm and clarity. I’ve helped teams look beyond their Sprint at the end to end flow all the way from idea to outcomes using a Kanban system. I’ve helped organizations manage the flow across several Scrum teams using a Kanban system.

When a Scrum team wants my opinion on whether adding Kanban would be a good idea I typically ask them to think about how hard it is for them to Sprint and whether they feel like they have good flow during the Sprint. (And like I mentioned above - do they feel like their process is a swamp or a river). It’s as simple as that. I find most Scrum teams struggle to achieve good sustainable healthy flow and Kanban tends to help them with that.

When is Kanban with Scrum a bad idea?

Some Professional Scrum Trainers asked “When would it be a bad idea to introduce Kanban to your Scrum? What are some indicators that you should stop using Kanban as part of your Scrum?” I can’t think of any team where I thought they should stop using Kanban. If they understand Kanban and do it well, there’s really little that can go wrong. The problems start when they don’t understand Kanban or use it as an escape from the challenges of Scrum. Yes, Kanban can help you make your Scrum more sustainable and healthier, but please don’t add Kanban if you’re looking for an escape from the difficulties. Kanban done well adds discipline to your Scrum. Another bad time to introduce Kanban is when the team isn’t looking to improve. If things are working well or more importantly if the team perceives things as working well, they won’t have the energy needed to successfully add Kanban to their process. So make sure you agree on pains/motivations before you move forward to implementing something like Kanban.

Kanban - A way back to Scrum!

To finish with scenarios where introducing Kanban IS a great idea – It pains me every time I see a team/company using Scrum as a new variant of “project management command and control” focusing more on tasks, story points, velocity and burndown than on empiricism leveraging Done Increments of potentially releasable product.

What I’ve noticed is that introducing Kanban ideas helps these teams/companies finally understand what Scrum really is about and shed a lot of the unnecessary and even harmful baggage and instead refocus on the transparency, inspection, and adaptation brought to life by the core Scrum events, roles, and artifacts. Pretty amazing isn’t it?

Interested to learn more about how Kanban and Scrum make each other better together? Join a public Professional Scrum with Kanban class or request a private training for your team.

Resource: https://www.scrum.org/resources/blog/understanding-kanban-guide-scrum-teams 

Read More