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

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

Announcing the Scrum Foundations Course

tryScrum believes in impactful education and experienced trainers to teach them. We support people wherever they are on their learning journey, from beginners to highly experienced practitioners, helping them grow over time with ongoing learning opportunities and resources. As one of the popular agile frameworks, certified scrum master training is simple to understand but difficult to Master. To help you on your agile journey, I have created an introductory Scrum Foundations video course. This series of short videos introduce you to Scrum’s terminology and concepts as a framework.

Get Started with the Scrum Foundations Video Course

The Scrum Foundations video course is great for those who want to understand the Fundamental concepts that might have been difficult to grasp at first. This Introductory Course is for anyone who wants to get a good overview of how agile and Scrum work.

Click here to access the online course.

Resource: https://www.tryscrum.com/blogs/announcing-the-scrum-foundations-video-course/

Read More

5 Scrum Myths–Busted

Myth 1 – Scrum is a Methodology

To bust this first myth, I would prefer to differentiate between the concepts of methodology and framework clearly.

Methodology 

A specific methodology is a well-defined set of principles, concepts, tools, and associated practices that guide processes to meet a focused goal. The methodology is fundamentally more prescriptive.

Framework

On the other hand, a framework is a flexible yet incomplete structure that leaves space for different practices and related tools requisite for the overall process. Thus, a framework is, practically, less prescriptive.

People often refer to Scrum as Methodology.

Scrum is, from a practical point of view, not at all a methodology. Instead, professional scrum master focuses on the scientific implementation of empiricism. As a result, it strikes the chord between well-defined principles and associated practices in a balanced manner.

Self-Managing teams and their dedicated, collective intelligence form the basis of Scrum. The teams solve varieties of complex problems through a series of adaptive solutions.

Myth 2 – Agile is equivalent to Scrum

50% of people I interact with using the terms Agile and Scrum interchangeably. When they say something like ‘We are performing or doing Agile’, they mean they are doing Scrum. On a practical note, these two things are not the same. 

Scrum is invariably a technical, lightweight framework. It strategically helps teams and organisations generate value via adaptive solutions suitable to solve various complex problems.

Agile covers a larger arena with a well-defined set of values, concepts and principles. Scrum does fall under the expansive umbrella of Agile, but there are many other concepts like it.

In addition, implementing Scrum never means you are agile. To become agile, developing an agile mindset is extremely important. Implementing Scrum doesn’t guarantee that you would become Agile but certainly helps build habits that can enhance Agility.

Myth 3 – Cross Functionality means each team member should perform every task

A cross-functional team is an efficient group of people who have a clear goal, representing various disciplines under the concerned organisation.

The combined efforts of the team are meant to add value to the process. Scrum teams are, by nature, cross-functional. This does not mean every team member would display every kind of skill. It means the cross-functional attribute of the Scrum team would benefit the team and organisation from an overall perspective.

It is impractical to expect each team member to be well-versed with all the available technologies and skills in the current competitive world. Instead, a top-class Scrum team knows how to value team members with multiple skills.

Myth 4 – Velocity is an intrinsic element of Scrum

Most of the Scrum teams use the concept of velocity for forecasting the probable completion dates. But it is technically a purely complementary practice within the realm of Scrum.

There is no need for the Scrum teams to leverage velocity as one of the metrics. This is because Scrum Framework does not consider velocity as one of its intrinsic elements. Still, many Scrum teams continue to do so. This is reasonably good when velocity is not regarded as a commitment.

Myth 5- The Product Owner decides the sprint goal.

Scrum tells that Sprint’s single objective is the Sprint Goal. It is specifically a commitment by the developers. I frequently hear that the Product Owner is responsible for determining the Sprint Goal during Sprint Planning. It is not at all true.

The Product Owner has a particular Business Objective. He coherently communicates it to the self-reliant Scrum team.

Fundamentally, the Sprint Goal is rigorously and strategically a collaborative effort involving the whole Scrum team. Scrum guide never says that the Product Owner decides the Sprint goal.

Any Other such Scrum Myths you have heard?

In this write-up, I have busted five myths related to Scrum. In your organisation, have you come across any other myths? You can share whatever thoughts you have in the comment section below.

Resource: https://www.tryscrum.com/blogs/5-scrum-myths-busted/

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

Winning Office Politics-3 Tips That Scrum Masters Can Use

The term Office politics is taboo for many professionals, as it is pervasive at any workplace.

To put it simply, workplace politics centres on differences within employees at the workplace, differences in views and opinions, conflicts on various interests and perspectives, etc. Everything boils down to communications and relations in-between humans.

You don’t have to be intimidated by office politics. Great professional scrum master who have swiftly mastered the delicate art of convincingly winning in the field of office politics.

Here are 3 distinct tips that are helpful to make you victorious at your workplace:

Are you having a Choice?

An intelligently common reaction to any kind of office politics is either fight against it or resort to flight. It is a usual human reaction for surviving in the wild and has been in practice from the days when people were hunter-gatherers during prehistoric times.

If you want to be victorious, then you have to consciously select an apt response according to the situation you face. You have to recognize that irrespective of how bad the situations are. You do have a choice of how you actually feel and then respond accordingly. I know very well that this thing is easier said than actually done. So, how are you going to select? This leads to the next crucial point…..

Interpreting Self

Whenever there is a conflict, it is very easy to get completely immersed in it with a tunnel vision, and concentrating on prevailing differences. Such an approach is self-defeating. There is a high probability, in this case, that you will invite ever further resistance, by keeping your focus on differences in positions or views of people.

I would positively recommend the approach of self-interpreting. In this manner, you are able to successfully mitigate the existent risk, without appearing as if you are desperately fighting to win the conflict.

In order to achieve such a focus on various business objectives, you need to gauge the positive and negative attributes of each of the choices or options. Eventually, each employee wants the organization to be successful. If the business is unable to win, then no individual in the organization wins.

It is practically easier for a person to taste a piece from the humble pie and then immediately back off after realizing the selected approach is the most appropriate one.

When you gradually learn to steer the dynamics of the discussion in this specific direction, you would be also able to learn to disengage yourself from a barrage of petty differences, positioning yourself as an individual who is keenly focused on getting the right things done. Your boss would certainly appreciate you as a mature and strategic person who can be bestowed with responsibilities.

Concentrate on Your Arena of Influence

There are many issues, frequently, at the workplace, on which we don’t have any control. It is not an uncommon phenomenon to get entangled in corporate policies, mandates of senior management or client demands that affect the personal interests you have.

Such events are marked by gossiping/complaining, beyond our control. But think for a moment – other than venting out emotions in short term, what are the actual tangible results of gossiping? In most cases, there are none.

Instead of becoming frustrated or feeling victimized about the particular situation, you need to seriously focus on ways to influence the circumstance – here lies the importance of your arena of influence. I want to cite an example. I face such a situation in my company. I tackled it by shifting my focus in adding more value to community meetups, locally. I concentrated on creating a healthy community of different Scrum Masters, productively shifting my focus. Even though it is not a part of my job, it provides me with a platform to shift my attention and focus on my bright spots.

This technique is empowering, as it overcomes the feeling of sheer helplessness. It removes any kind of victimized feeling. It also shows you in good light, where other employees see you as an individual who can efficiently operate within the given limitations, with a self-motivating approach. At times, it is an incredibly effective way to strongly prove one’s mettle.

You may be not in a position to alter or determine the eventual result but, it is always possible to walk away by becoming aware that you have delivered your best in the given situation.

The workplace is full of constraints. With a balanced approach, your boss would admire you as a positive and insightful individual.

Resource: https://tryscrum.com/2021/05/08/winning-office-politics-3-tips-that-scrum-masters-can-use/

Read More

When the Professional Scrum Master as a Teacher Becomes a Preacher

About five years ago I published the paper “The 8 Stances of a Scrum Master”. Although it definitely needs an update, the core of the paper is still relevant. In the paper, I describe the misunderstood and preferred stances of a Scrum Master. One of the misunderstood stances is the teacher. It often gets fulfilled in such a way the Scrum Master becomes Scrum police. A recent meet up in The Liberators Network triggered an interesting conversation between a couple of Scrum practitioners. Within their organization, Scrum Masters are not teaching but preaching. At first sight, the difference doesn’t seem significant. But from my own experience, I’ve learned that it can have a big impact on how Scrum is used within your team or organization. In this blog post, I’ll describe the difference between Scrum teaching & preaching, why it matters, and what you can do to improve the situation.

The Scrum Master as a Teacher

As we describe in our paper “Scrum: A Framework To Reduce Risk And Deliver Value Sooner”, it’s up to the Scrum Master to include the perspective of empirical process control and the quality by which transparency, inspection, and adaptation are taking shape in and around the Scrum Team. The Scrum Master is there to make the elements of the Scrum framework come to life in the team and the broader organization. For this, Scrum Masters adopt a number of stances, depending on the situation they find themselves in. These stances are the teacher, facilitator, impediment remover, change agent, coach, and mentor.

As a teacher, professional scrum masters teach and explain the purpose of the Scrum framework as a means to work empirically. They work hard to make sure that everyone understands how the artifacts, events, roles, and principles promote empiricism and agility. A Scrum Master teaches their team and organization how Scrum helps them to be effective in complex environments.

SM as a Teacher

The Scrum Master as a Preacher

The opposite of the Scrum Master as a teacher is the Scrum Master as a preacher. This is a Scrum Master who preaches the rules of Scrum without considering the context of the team, the unique characteristics of its environment, and the dynamics in the wider organization. The rules of Scrum are presented as dry facts that should be adhered to, without explaining why they are important.

It’s quite easy to spot the Scrum Master as a preacher because every conversation about Scrum remains theoretical. Often it’s not even a conversation since the only argument is “because it’s in the Scrum Guide…”

·       Why should a team use a Product Goal? → because it was recently added to the Scrum Guide.

·       Why can’t we talk about Development Teams anymore? → because they removed from the updated Scrum Guide.

·       Why isn’t the Scrum Master a servant leader anymore? → because according to the Scrum Guide (s)he “is a true leader”.

·       Why should we change “self-organizing” into “self-managing” everywhere? → because the Scrum Guide changed the wording

This of course slightly exaggerated, but this is how I perceive conversations with Scrum preachers. It’s not even about who’s right or wrong. The point is that preaching Scrum isn’t helpful for anyone. It’s rarely a good way to engage people in changing their behavior and understanding of how things work. Instead, it’s far more likely that you only create resistance by being pedantic about what people are used to. By doing so, you close conversations instead of opening them. As a result, the team will learn a couple of facts, but don’t understand why it matters, and how it could benefit them. The facts might stick, but that doesn’t mean they’ve learned something.

Three Characteristics of the Scrum Preacher

The Scrum Master as a preacher seems to have three distinct characteristics: lack of experience with Scrum, too much ego, and Scrum as the only tool in their kit. Let’s dig deeper into why lack of experience is a characteristic of a Scrum preacher, first.

Lack of experience

Teaching becomes powerful when you can put your knowledge into the context of a team. If you understand the impediments a team is facing and the environment they’re part of, you can offer a tailor-made approach. However, if you don’t have experience with Scrum, and don’t truly understand the situation of the team, all that is left is simply repeating what the Scrum Guide states.

In all honesty, I’ve experienced this myself as well. When I discovered Scrum about 12 years ago, I did understand the situation of the team, and due to my lack of experience with Scrum itself, my initial approach was to preach to rules of Scrum hoping to convince the team to use them. The result was that they actually followed the rules initially, and because they didn’t understand why it was important, the rules didn’t stick and were only used mechanically.

One of the movements I see in today’s Scrum community is that the Scrum Master role is considered a junior position by organizations and Agile consultancy agencies. These agencies recruit people without any Scrum and work experience, quickly give them a Scrum Master badge, and offer them to organizations as contractors. Although it’s done with the best intentions, the only thing these Scrum Masters can do is preach the Scrum Guide.

Ego

Let’s be clear: there’s nothing wrong with ego. It can be the fuel to get things done and help you achieve personal goals. It can also get in the way. The teaching stance puts you in a position of authority. You have knowledge about Scrum the team doesn’t have yet. So, explaining all the facts about Scrum to the team will feel good. Especially if you don’t have the experience yet, it gives you the feeling that you add value. Before you know it, you’re the companies thought-leader, how cool is that?!

I’ll confess that I enjoyed this status myself as well. Especially when I started to combine my Scrum Master role with being a Professional Scrum Trainer at Scrum.org. But the more experience I gained as a Scrum Master, the less I used the teaching stance. Nowadays, I rarely explain Scrum. I don’t consider it effective. Although there’s nothing wrong with teaching, it quickly becomes preaching. So I started to use a different approach on how to fulfill the teaching stance. Keep on reading if you want to learn more about it.

Scrum, Scrum, Scrum

As the saying goes: “if all you have is a hammer, everything looks like a nail”. So, if the only thing you know is Scrum, it’s likely that this is your number #1 recommendation as well. The Scrum Master as a teacher doesn’t only explain what Scrum is about, but also how Kanban, XP, or Lean can help. The Scrum Master as a preacher focuses on Scrum only. Other frameworks or methodologies are considered as ‘evil’ if taken into consideration at all. To spot a Scrum preacher, all you have to do is spend an entire day on LinkedIn and track the many discussions Scrum fanatics have…

When faced with complex work, Scrum is an excellent framework. But so is Kanban. It really depends on the type of work the team is doing, and their context. Maybe working in Sprints doesn’t make sense to them, and they would benefit to focus on flow only. Maybe a hybrid situation where Scrum and Kanban are combined works best. A Scrum Master should always have an open mind and explore multiple frameworks, methodologies, and practices. That’s what serving the team is about. The good news is that this is even described in the Scrum Guide ;-)

How not to become a preacher?

When I noticed that I became a Scrum preacher instead of a Scrum teacher, I made a couple of changes that I can definitely recommend to you as well.

First, challenge yourself to stop talking about Scrum (or Agile)! Whenever you explain something about Scrum to your team, do so without using any Scrum terminology or other buzzwords. You’ll notice that this prevents you to ramble the dry facts about Scrum but instead helps you to explain why it matters. We used this approach ourselves as well when we wanted to explain the purpose of Scrum in one illustration. The result is a comic that doesn’t talk about Scrum at all but does explain its purpose.

Purpose of Scrum

The purpose of Scrum explained without using any difficult terms or buzzwords.

Second, whenever you hear yourself say “because it’s in the Scrum Guide”, ask yourself why this was your answer. Be brutally honest. It doesn’t mean you’re wrong, it could be a signal of a knowledge gap. Which is fine. But instead of paraphrasing the Scrum Guide, take some time to do more research. Or even better: make it a joint exploration with your team!

Third, practice explaining Scrum to fellow Scrum Masters. Only by explaining something to others, you’ll discover if you truly understand it. Create or join a Scrum Master community in which you can safely practice. Help each other to hone the teaching skills, and to move away from preaching only. Often you need others to become aware of your own behavior. So ask a fellow Scrum Master to be your mirror.

Fourth, make teaching a joint discovery and exploration. Whenever you feel the tendency to teach the team something about Scrum, ask yourself “how can I make this a joint discovery?”. So instead of explaining the Scrum roles, artifacts, and events, use an exercise that helps the team figure this out themselves. Our webshop is packed with exercises that help you do so. For example, “Management in Scrum” creates a better understanding of the roles, “Scrum events & activities” clarifies the events, and the “Definition of Done exercise” shows why a Done increment matters.

Fifth, try other Scrum Master stances. Especially the stances of the coach, and facilitator. As a coach, you help the team grow by asking the right questions and to draw attention to the reasons for an empirical approach. As a facilitator, you help the team find the best way to make work, impediments, and team dynamics transparent. Done right, inspection and adaptation become much easier. So, instead of teaching the concept of e.g. Sprint Goals, make transparent what current happens without a goal, help the team inspect how it impacts them and why it matters, and encourage them to come up with improvements.

Closing

The Scrum Master is responsible to teach and explain the purpose of the Scrum framework as a means to work empirically. A common pitfall is that teaching becomes preaching. In this blog post, we described the difference, and why it matters. Preaching probably will only result in resistance to Scrum. You close conversations instead of opening them. So we offered you 5 ideas to fulfill to role differently. Give it a try, and let us know your experiences.

Resource: https://www.scrum.org/resources/blog/when-scrum-master-teacher-becomes-preacher

Read More

Scrum Guide 2020: Scrum Masters are the True Leaders

Scrum Masters Are The True Leaders

Just take a second to imagine a professional environment where every individual connects and donates their intellectual capacity to the fullest. It’s a place where each person experiences contentment. It’s a workplace that bestows fulfilment too. Then again, the description here seems somewhat booking and way too ideal. Is it possible to create such a working environment? Indeed, it is! If so, then how? With all my experience, I can say that the present leadership archetype can’t do it, even if everything else falls into place. Proper certified scrum master training at tryScrum is an incredibly popular framework, and it tried to fix the problem by returning it unsolved. Sounds confusing, right? The creators tried to fight fire with fire by giving Scrum Master the role of a leader. Now, for ages, many leaders forced their employees through commands, obligation, and conformity. Such leadership strategies won’t work in today’s complex world. So, what is it that requires changing?

Scrum found the perfect answer to this question by not solving the problem. It lets people solve their own issues. Jeff and Ken redefined and polished the idea of the role of Scrum Master from a “Servant Leader” to a “True Leader” in the 2020 Scrum Guide.

Understanding the concept of a True Leader

What’s the deal with this term, anyway? After all, too many individuals raise their hands whenever someone asks them whether they wish to assume the role of a boss. Who’s the True Leader among them? The only way to answer it is to take a step back and find out: What do True Leaders try to gain? These people only want to help others find a leg to stand on instead of begging others for support. A True Leader won’t try to make others go blind by showcasing his/her brilliance. This person will act as a reflector of light so that we can see ourselves from an entirely new angle.

Everyone must be a leader – The Rebbe

The distinctiveness of True Leaders

Thinking out loud

Discussing what you think is essential in creating all the difference. It’s the only way to become a servant-leader from an information dispenser. We educate people to give voice to their thoughts so that their subordinates at the workplace can’t resort to assumptions. It also brings transparency and makes the leader trustworthy.

Expanding the space of solutions

Among all the intentions of a True Leader, one, in my view, is to let loose collective intelligence. In order to do it, it’s crucial to allow the team to disclose their views, thoughts, beliefs, as well as the things that don’t sit right with them. It’s about creating a safe zone and promoting a continuous buzz of conversation among the members.

Informative authority

Everyone will follow a True Leader without questioning him/her as long as the person manages to present himself/herself as a bona fide executor. By giving people more authority, we create better leaders. These people come up with durable mechanisms to create a paradigm shift.

Undoubtedly, donning the skin of a True Leader is extremely challenging, but achievable nonetheless. As soon as we make our minds to follow the path before us to become a Scrum Master, I think we can make significant contributions to the world by improving our capabilities. In doing so, we yield results that matter and even become whole by discovering and recreating our belief structure.

Resource: https://tryscrum.com/2020/12/30/scrum-guide-2020-scrum-masters-are-the-true-leaders/

Read More

How Tools Condition Our Way Of Working In Certified Scrum Master Training?

This week twitter was full of comments about the latest update from JIRA, the dictator of the way we work, the world's most famous Ticket Management tool. I put Ticket Management because it is what it is. JIRA is super vitamin with plugins but what it does really well is ticket management.

Returning to the topic, I put here the update, sorry because I only found it in English and I prefer to show the speech from the original source.

This is the most impressive thing I have seen in time. We put decimals in the story points. We have gone crazy! Various things here. The first is that in good professional scrum master training the story points are a complementary practice.

From what you see and what I have seen in many organizations that I have helped, JIRA makes you a slave to the way you work. Epics, Story Points, Versions, JIRA is assuming that all teams in the world use story points. Big mistake! I'd like to ask the audience a question. How many people who are going to read this newsletter are comfortable with the story points?

It's more. How many people have had to explain to their hierarchical superior who is in the orbit of the development team that a Story Point is? And finally, how many people in the audience are slaves to these JIRA setups? Unfortunately, JIRA imposes our way of working.

I have been endless times trying to answer these questions. And I have always had to make a break, like the day from Messi to Boateng, to have a kind of board for converting hours to story points…. until I discovered Kanban with Scrum.

Kanban with Scrum gave me what I needed. Go back to talking about days instead of story points. In Kanban, we planted 4 metrics; we planted Work in Progress, Throughput, Work Item Age and Cycle Time.

With these 4 metrics you will not need anything else. The most important thing is that you are going to think again in days and not in points.

I made a video explaining how to ditch the story points and move on to more realistic metrics for team day. I am attaching the video below in case you want to see it. I recommend it to end your "nightmare" of story points. Flow control is basic and strategic for any team. There, conversations change and better decisions are made.

Bottlenecks are better observed from the flow analysis and also with the 4 previous metrics we can better manage future predictability. You do not believe me? I recommend you watch the video that I am attaching to you in this newsletter. Make a game of Twig and you will see how these metrics help you.

As professional advice, I also tell you that your life will be better with JIRA faraway since it is to capture the dictatorship imposed for our way of working in the 21st century.

Resource: https://www.scrum.org/resources/blog/como-las-herramientas-nos-condicionan-nuestra-manera-de-trabajar 

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