Today, Scrum has become one of the most widely adopted Agile frameworks. It enables teams and organizations to deliver value iteratively and incrementally, adapt to changing requirements and foster collaboration and self-organization. The influence of Scrum extends far beyond software development, shaping the way teams approach complex work across various industries. But how did everything begin and what were the main landmarks along the way? Here is a brief summary of the history of Scrum.
Our Scrum courses are dynamic, designed for deeper practical understanding of new skills, and tailored for the individuals in the class. Sure, you’ll pass your exam. But you’ll also walk away with a greater depth of knowledge and understanding that will empower you when taking the next steps in your career.
The agile42 training method has always been defined by interactive Scrum games, group work, and many, many post-its. But as our world changed and shifted due to the Covid-19 pandemic, we had to revise our training model. We didn’t want to fall into the trap of the formulaic video call, with a sequence of slides that flash across the screen while half the attendees are either dozing or distracted. We wanted to design training that kept the interactive, engaging agile42 style. This is how we devised our new training model: that of the “virtual class” with strong doses of interactivity and group activities thanks to the use of Zoom “breakout rooms”, beautiful Miro boards, virtual games, and a Slack channel that is available to the participants before, during, and after the course. Almost all of our Scrum training is available online.
In software development, technical debt is a concept that reflects the extra development work that arises when we use quick or easy solutions. But the concept is useful beyond the world of software too. In the digital world, where new technologies and ideas are emerging just about every day, technical debt is almost unavoidable. So we need to know how to deal with it.
Roberto Bettazzoni has experience as a technical trainer and a software developer. Alessa Leuschen has experience in different Agile roles, including a Product Owner and Scrum master. Together, they share their different perspectives and experiences, outlining some effective ways to deal with technical debt, and how to use it as an opportunity.
Join us for our upcoming webinar about Burnout, or stay in the loop about upcoming webinars by joining our mailing list.
Technical Debt is a metaphor, coined by Ward Cunningham. He explains that when we initially ship a product, we are likely to go into “debt” as we do not have all the knowledge we need yet. This phenomenon happens after we ship an easy or limited solution that may require extra-work or an additional cost later on. Roberto Bettazzoni clears up some misconceptions, saying, “Technical debt is not bad code. It’s not a bad solution. It’s not putting something in production that doesn’t really work. It’s shipping with the quality that we can do quickly and with the knowledge we have now.” Once we have feedback and our hypotheses are verified, we can “pay our debt back.” “This is in the heart of Scrum or any Agile way of building solutions,” Bettazzoni concludes.
The incremental nature of Agile methods allows us to keep technical debt small and deliberate, which can be continuously evaluated. However, it can also be unintentional, and this can show up in a review. In this case, these discoveries will need to be quantified and corrected. Roberto Bettazzoni says that not all types of technical debt are helpful. He explains that, “There’s another way in which it is reckless. So, when you make a big technical debt, you go quick and dirty in production.” And this is something you want to avoid if you are already deep in debt.
Alessa Leuschen uses a metaphor to explain how technical debt can get out of control. She asks webinar attendees to imagine that construction workers arrive at a house to add new features. Upon arrival, they notice that the house has a lot of existing problems: the foundation is missing, there are holes in the wall, and the whole construction is unstable.
The manager asks them to put a window in. The workers realize that this is going to be challenging because of the poor foundations they have to work with. This task will take longer than usual because they need to think about how they can put in a window without breaking the whole house. Of course, their morale and productivity will suffer. A manager might then put additional pressure on the workers to try to increase their productivity. To meet these unrealistic demands, the team might resort to so-called “quick and dirty solutions” that will produce even more technical debt. In this scenario, you can see how technical debt can become a vicious cycle and can be expensive in the long run. Leuschen explains, “In the beginning, you’re not going to feel it that much but at a certain point in time it’s going to grow exponentially.”
Photo by Nolan Issac on Unsplash
Bettazzoni sticks to the metaphor of buildings. “We need to have healthy habits to clean the house,” he explains, “don’t let the dirt pile up.” To keep our technical debt under control, we need to continuously invest in it and pay it back. We can do this by visualizing our technical debt, sharing this knowledge with the relevant parties, mapping out our technical debt, and lastly coming up with a refactoring plan. This may mean allocating a certain amount of time in your Sprint to technical debt or putting it into the product backlog. Plus, Bettazzoni recommends using one of many great tools that can help us to manage technical debt, like Sonarqube.
Our Certified Scrum Master training covers technical debt, and can equip you with the skills you need to manage it.
In today’s volatile world, we don’t have as much time to develop products and bring them to the market. “A way to deal with that is to create a vision, an understanding, and clarity to find out how to serve our customers best,” shares Leuschen, “Agility can help us do this by incrementally allowing us to figure out what the best solution for the market is.”
We often do not know what the solution will look like in the end. By shipping faster, we get customer feedback faster, and we can experiment as we go. This approach means that we may need to use an easy or limited solution. “Acquiring technical debt is not only a technical topic but it’s also a design topic, because we have this uncertainty,” continues Leuschen, “we need to figure out what the solution will look like in the end.”
During the last few decades, several approaches to product development and service delivery have emerged. The level of complexity of products and services is ever-increasing which is why many people wonder which framework or method to choose. Perhaps you are also wondering which framework or method will work best for your team. Below we summarize the key elements of four main agile frameworks and methods, some differences between them, and how they can complement one another.
Scrum is a lightweight framework that helps teams and organizations deliver value incrementally.
The Scrum framework consists of the Scrum team with its three accountabilities, five Scrum events, and three artifacts. Each component serves a specific purpose and is important for Scrum’s successful adoption.
The easiest way to understand Scrum is to read the Scrum Guide. There are three main things that you should realize:
Contrary to popular belief, Scrum is not an approach to estimate and plan what work will be completed in a given time period. Scrum allows teams to create value for their customers and users by letting them focus on one sprint goal at a time, while continuously getting better.
Recommended online course: Scrum Foundations
Nowadays, XP is not used as much as it was in the late 1990s and early 2000s. However, XP, its creator Kent Beck and other people like Ron Jeffries played a crucial role in the development of agile thinking and agile approaches. Therefore we would like to include XP in this list as well.
As the name suggests, Extreme Programming has its roots in software development. The core idea of XP is to develop software iteratively and incrementally while focussing on users’ needs. As such, it is an agile framework that is comparable to Scrum.
While there are many similarities between XP and Scrum, there are also subtle differences. For instance:
The most important and noticeable difference, however, is that XP explicitly suggests development practices such as the following:
These development practices are still being embraced by many software development teams, regardless which agile framework or method they adopt.
Recommended training: Certified Scrum Developer (CSD)
The Kanban method helps organizations, teams and individuals manage their professional services, and enables them to respond better and faster to their customers’ needs and expectations.
The principles and practices of the Kanban method are described in the official Kanban Guide. Here are three important things to understand about Kanban:
In his book “Kanban: Successful Evolutionary Change for Your Technology Business”, the creator of the Kanban method David J. Anderson, tells the story of his trip to Tokyo, in spring 2005. Spring is the cherry blossom season in Japan and he wanted to see the beautiful cherry trees at the Imperial Palace Gardens. There he realized they were using a kanban system to control how many people could visit the garden during peak times of the day. This kanban system, as used in lean manufacturing, inspired the Kanban method for knowledge work.
Related reading: How to create a Kanban board
In knowledge work, a kanban system allows work to flow by limiting work in progress and establishing a pull system. With the Kanban method, you visualize invisible work and how it moves through a workflow. This will help operate your business effectively, as well as understand and manage risks in delivering services to your customers. The Kanban method enables continuous improvement in an evolutionary way.
Because Kanban is almost universally applicable, many Scrum or XP teams use Kanban to improve their way of working, for instance by visualizing their work or optimizing their delivery. Some people call this a hybrid approach and give it a specific name such as “Scrumban”.
Recommended online course: Kanban Foundations
Even though Design Thinking is not really considered an agile framework or method, its principles and practices are popular among agile teams and organizations and complement their toolbox. For instance, the persona is a widely used tool.
Design Thinking emerged much earlier than Scrum, XP or Kanban as it is based on the way designers approach new projects or products in general. Design Thinking has been developed by a number of different organizations (e.g. IDEO, HPI, Dark Horse) that follow slightly different approaches and theories. However, together they define what Design Thinking is.
Here are some important facts about Design Thinking:
A major breakthrough was Jake Knapp’s book Sprint. Design sprints provide a structure that allows teams to prepare themselves for a challenge and solve it by going through all phases of Design Thinking within five days.
Recommended online course: Design Thinking Foundations
We often see teams asking themselves whether they should use one framework, method, approach or another in order to deliver outstanding value to their customers.
The reality is that you shouldn’t choose between Scrum, Kanban, XP, Design Thinking or others; rather, you should discover which practices work best for your team and tweak the system of work accordingly. By tweaking, we mean combining those elements that work best for your team in order to plan, track and manage your work more efficiently so that you satisfy your customers’ needs better and faster.
Ask yourself how work arrives at your team, and how often that work and the information around it changes. The answers could guide you in choosing a paradigm that suits you. You might find that a timeboxed mechanism or limiting your work in progress will help. Can you plan your work and commit to it for one or two weeks?
Scrum, Kanban, XP and Design Thinking aren’t mutually exclusive and complement each other when combined. The bigger challenge that lies ahead for teams is the journey of discovering which practices and structures work best for them in satisfying their customers’ needs in a sustainable and ever-growing way.
Every team, every product and every customer is different. There is no one-size-fits-all approach. By keeping an eye on what agility might offer beyond the methods, frameworks or tools you are already using, by trying out new things and hence continuously inspecting and adapting your system of work, you will eventually find what fulfills your team’s and customers’ needs best.
We hope this blog post made you curious about the idea of an agile mix-and-match approach and encourage you to find the best practices for your team right away:
agile42 offers online courses including Design Thinking Foundations, Scrum Foundations, and Kanban Foundations. We also offer Kanban System Design (KMP I) and Kanban Systems Improvement (KMP II) certifications, as well as coaching, mentoring, and consulting services. Reach out to us if you want to learn more.
When I was a kid, maybe eight years old, something magical happened to me. It was a sunny day. My parents had put a sliding door in our dining room, which lit up the space in gold every summer afternoon. That particular day, the room held my dad and a couple of his students from the high school where he taught Latin. They were limned in bright solar rays, excitedly talking about fighting goblins, looting gold, and casting spells while drinking Coca-Cola and rolling dice, having a grand old time.
Dad was the sponsor for his school’s wargaming club (later renamed to the ‘conflict simulation group’ at the behest of anxious administrators). Occasionally, his students would come to our house to play Dungeons and Dragons on the weekend. There was no satanic panic about the world’s most popular roleplaying game in our home. While my mother and my sister didn’t understand it (and still don’t), my father had caught the bug. He was happy to set up a space to play for the kids who could pay the toll to get across the Delaware River and drive the ten miles to our place.
I tottered in amongst the older kids, big as Hill Giants to me, and tugged at my dad’s sleeve. He looked down through his brown, plastic-framed Coke bottle glasses at me with a smile that was so rarely displayed to kids my age. I asked what was going on.
“We’re playing a game,” he told me.
I could tell he was anxious to get back to it, but I followed up with the obvious question: “Can I play?”
Dad laughed and told me no, I couldn’t. It was a bummer for sure, and he must have seen it in my face because he followed up quickly:
“Come back when you’re older.”
“How old?” I asked. I probably tried to hide my excitement and failed (something I still do poorly).
“I’d say twelve. Twelve?” He looked up at the other kids. I don’t think they were paying any attention, but I was. Because, even for a kid who struggled to pay attention to anything, this I would remember. Because this looked like so much fun.
Neither dad nor I knew that he’d be setting me up for not just the hobby that would define how I spent a large swathe of my recreational time moving forward, but also my experience with Scrum.
Photo by Clint Bustrillos on Unsplash
I could tell you all about my time growing up in the hobby of tabletop roleplaying games (TTRPGs for short) – but this is not a gaming article. Instead, I’m writing about business. I’m supposed to write about goals. And, and, and… numbers. About making hard decisions and leading teams. We’re talking about planning for success and delivering products and value week after week.
And… figh… fighting goblins?
Well, as a life-long gamer, I can tell you that you will be amazed at how much Dungeons and Dragons can prepare you for business. Even more remarkably, how being the Emcee of a D&D game – a Dungeon Master – will prepare you for being a Scrum Master.
Stay with me. I think you’re going to be very surprised.
Before we get too far into the overlaps of Scrum Mastering and Dungeon Mastering, let me bring you in on what D&D (and any TTRPG in general) is, in case you’re in the dark.
D&D is a storytelling game where you and a group of friends take on the roles of adventurers in an elaborate fantasy world of swords and sorcery. These adventurers go on quests like defeating mad wizards or carrying out elaborate heists against tyrannical nobles. Players describe what those adventurers do in the world. A roll of the die determines anything that could be left up to chance (usually using a twenty-sided die or D20). One of the player’s jobs – the Dungeon Master (or DM) – is to set the stage and describe the world to the other players. The DM also takes on the roles of the supporting cast in the story, arbitrates (or throws out) rules where needed, and ensures everyone has a good time.
If it sounds like the DM has a challenging job, you are correct! I speak from experience here – I have been a DM for over thirty years across dozens of different campaigns and rules systems (D&D may be the World’s Most Popular Roleplaying Game, but it’s not the only one).
If it sounds like there are some similarities between the Scrum Master and the Dungeon Master, you are also correct. The similarities don’t stop at just the DM, though, so before we get too far into the similarities of DMs and Scrum Masters, let’s get down to some D&D brass tacks first. I promise not to get too nerdy on you.
Let’s talk about how a game of D&D looks through the prism of Agile (which I’ll refer to as Scrum World). Of course, D&D and Scrum World aren’t precisely one-to-one, so there are some things to map out for the sake of clarity:
Learn more about Scrum basics in our online short course, Scrum Foundations
So, how are the roles similar? Let us enumerate the ways.
At Agile’s core is the principle of continuing to deliver a quality, functional product at the end of every sprint. The DM’s job is no different. If the DM fails, the PCs leave. The party gets together every week to play D&D because they want to tell a story that engages and excites them. If the DM can’t do that, those PCs can do other things with those two to four hours per week, especially when those players are Busy Adults With Many Things To Do. They can get together to play a board game or watch a movie without the pretense of also having to pretend to be a Druid if they’re not feeling it. So the DM has to deliver.
The DM’s product, the story, develops like any Scrum team’s product: action by action and scene by scene over several sessions, just like products are assembled over a series of Sprints. Software code is developed line by line; cars are engineered component by component; devices are tooled part by part. And as each Sprint rolls out, the output should get better and develop into something closer to that big beautiful idea everyone was dreaming of at the outset. As the collective project grows, it gets better, and the DM or Scrum Master makes those little subtle nudges that bring out the best of the project. This brings us to…
The DM has to learn a lot about each PC around the table to put them in the right places at the appropriate times. For example, they know that bringing a Wizard to a knife fight is a bad idea (at least at a low level), in the same way that sending a Fighter to a diplomatic assembly of Archmages is a classic faux pas.
Photo by Artem Maltsev on Unsplash
To be fair, a DM has an advantage that a Scrum Master doesn’t: narrative control. DMs can mold a story around the players that come to their table. But, more often than not, a Scrum Master already has the right people around them if an HR department has done their due diligence. But not all team members will be the same, and those little differences matter. Find out who your Rogues and Bards are (and let them be POs, those interpersonal skills are excellent for stakeholders). Identify Wizards and Sorcerers early (and give them caffeine judiciously). Use each person’s skills and talents and let them shine where they’ll do the most good.
Ask any game fan about its nuts and bolts, and you’ll quickly discover that many numbers are spinning around. Look at pro baseball. All you have to do is flip over a baseball card – stats galore. You can argue about whether or not some of those stats indicate anything, but metrics count to stakeholders, and they hold you accountable to them. To the stakeholders of those pro sports teams, those stats are all Key Performance Indicators (KPIs), and if they dip too far, it’s back to the minors for those players or even farewell from the franchise entirely.
In D&D, it’s different, of course. PCs have a Character Sheet that lists all the things they can do in an even more concrete and non-debatable sense. Most relevant details are listed on that sheet, from how strong or fast they are to how well they take hits to how many spells they can learn and cast in a day.
Fail to keep your party’s KPIs up to snuff, and your PCs could find themselves tapped out of many encounters. Worse still, they could be overpowered more permanently at the end of some nasty critter’s claws. Well, on paper at least (if a character dies, they can always roll up another one or pay a cleric to resurrect them, c’est la vie). But, players are encouraged by an excellent DM to make sure that they keep their PCs moving toward their goals in a way that keeps the story enjoyable for everyone, and that means knowing how to set realistic goals based on capability.
A good DM must know what a PC party can realistically handle in any given situation and set tasks accordingly. They best track that by the Party’s KPIs, which for a PC could be anything from their Armor Class, Damage Per Round, or the number of Spell Slots they have. Scrum World examples will vary, of course, based on the given Devs outputs. But, it maps in more similar ways than you’d think. Speaking of challenges…
A good DM also knows that they often have to put their players in positions where they might just fail. Failure is a part of the game, and it’s why dice are involved.
Any time there’s a chance something could go wrong, the DM calls for PCs to roll a die. The die result checks against a difficulty set by the DM. An easy D&D task is usually a 10, while something nearly impossible is a 30, with most tasks falling somewhere in the middle. And sometimes, even a high-level character rolls a one and botches at something in which they’re skilled.
It just happens. It’s going to happen to your developers in Scrum World, too. As both an experienced DM and a newly-minted Scrum Master, I’ve found that the earlier you can get that kind of thing out of the way, the better.
Case in point: a player in one of my parties had designed their PC as a healer. He chose to play a Cleric, a role traditionally suited to this (not always the case in fifth edition D&D, but that’s a whole other blog article for an entirely different place). When the first battle came around, he decided on the first round to surprise everyone. He waded into the fight and hit the bad guys with his staff. The Party took a beating with their healer tangled up in the melee. They survived though, albeit with more dings and scratches than they signed on for.
To their credit, no one in the Party got upset, but I held an impromptu Retrospective after the session. The big question was: why did the Cleric go in running? The answer was that he simply wanted to be helpful in the moment. The Cleric happened to roll high on his initiative, meaning he went first. No one was hurt yet, and he didn’t want to waste a turn, not thinking about holding his action instead of rushing in.
From that point forward, he knew waiting for the team to move in before committing to any actions was an option, making for a better strategy as a support member of the party. If things went well next time, sure: he could clobber some opponents. But, if he was going to shine as a healer, he might want to hold back no matter how good his initiative rolls were to see if a teammate needed support before going on the offensive.
There is a school of thought among PCs in D&D Parties that staying in your lane is best. You should Know Your Role (in all capital letters) and never leave it. A Rogue should stick only to situations where they pick locks and can benefit from providing sneak attacks. A Warlock should always be in the back and cast Eldritch Blast on repeat into infinity. A Wizard should cast Magic Missile until they’re out of spell slots and then hide under a wagon until the fighting is over.
It sounds reasonable. Players pick these roles because they want to be good at certain things. And those epic, level twenty powers sound cool. Who doesn’t want to max out a class and be the Thiefiest Thief to ever Thief?
I have a secret for you. Lean in close. I will lay some expert DM knowledge on you from my thirty-plus years of experience.
You’re never going to make it to level twenty. I have no intention of letting it go that far. Not in my campaign, at least.
Every D&D game I have ever run has either fallen apart or come to a close well before getting to that stupidly high-level threshold. The highest I’ve ever gotten as of this writing was a tenth-level Party. That campaign had single-class adventurers fighting tooth and nail with low saving throws against conditions that, if they multiclassed, would not have been problematic at all.
Anyone used to working with Scrum will tell you about cross-functionality. Building it into a team is at the crux of agility. A good DM learns this quickly and encourages this in their party. A Barbarian that can clobber a sentry or sneak around them after putting a couple of levels into the Rogue class will be able to hold onto their rages for better use later. A Fighter who can cast a couple of Mage cantrips can get an edge in their encounters without risking their neck quite as often. And the saving throws get nothing but better.
Scrum World Developers similarly get better when a Scrum Master pushes them to develop accordingly, setting them up for success with the right coaching techniques and skills. In Scrum World, technology and science advance too quickly to let team members focus on a single discipline. Overspecialization can set Devs and their Scrum teams up for obsolescence or single points of failure. Coaching new skills and pushing teams to adopt new technologies and methods will keep your team cross-functional in a fast-changing world.
As a DM, I have had an entire story fall apart after a player with a lucky roll took out my villain in a single hit. There was supposed to be a whole arc with that villain as a recurring character. He would keep the party on their toes week after week as a nefarious player in the shadows. Instead, a single die roll ended the whole thing thirty minutes into the first session. Everyone went home, and I was intensely frustrated. I had a plan I worked on for hours, but I wasn’t prepared for a player to pick out the ridiculously overpowered weapon used to kill my bad guy.
There is a difference between having a plan and being prepared. With a plan, you have already committed to a specific course of action. You put things in place, worked out fine details, and estimated the functions of all the moving parts. There are processes and documentation you probably reviewed. You counted on those things to work out exactly as planned and with little deviation.
An experienced DM knows better. PCs – who are ideally the DMs friends and sometimes their family – are only there to have fun. They do not give a damn about any of the DM’s plans. They have their own ideas about how fun happens during the session and it may have nothing to do with a DM’s plan. All a DM can do is know the PCs and prepare based on what they know about the Party. DMs need to have a lot of options available to them, know where they all are, and to only dive into the specifics once they are needed.
PC (and Devs, for that matter) will not be little copies of the DM and will not act the exact way you want. Nor should they. PCs and Devs are human, unique. They bring something to your Party or Scrum team through different ways and means. It’s not something to be beaten out of them or micromanaged. Humans, shared stories, and volatile industries fiercely resist being wrangled in such a fashion.
To approach complicated and uncertain situations with agility, a good DM or Scrum Master should prepare to optimally use their PC’s and Dev’s unique approaches and methodologies. Then, find the right coaching approach to engage them. When a Scrum Master or a DM can engage their Party or a Scrum team, it’s amazing what they can do.
Photo by Charlie Solorzano on Pexels
As a DM, I must sometimes work hard to get in my players’ heads since I love bringing my favorite hobby to new players (new PCs haven’t learned how to be cynical PCs yet). Finding out how they approach the gaming table can be challenging. Do they like to fight, or do they like puzzles? Do they live for drama, or do they just want to help everyone around the table? Is the thrill of adventure something they live for? Or is it an excuse to cook for everyone around the table and see friends? Once I find what motivates them, I find the best way to run a game for that group… and then I can plan.
It is hard—both the DM job and being a Scrum Master. Taking on either role takes serious determination and a lot of practice. But agile42 is here for you. The Scrum Master part, not the DM part! The good news is that everything here works in reverse, too. If you want to be a good DM, being a good Scrum Master is a great place to start! Book an appointment to speak with us at agile42 North America today to learn more about our coaching and training services. And, of course, go to DNDBeyond to learn more about Dungeons and Dragons, the World’s Most Popular Roleplaying Game.
In the final webinar of our webinar series on the Scrum Events, we discuss the Retrospective. The Scrum Guide defines the purpose of the Sprint Retrospective as “to plan ways to increase quality and effectiveness”. That sounds simple, but it’s actually one of the more complex Scrum Events. Watch as our coaches, Pascal Papathemelis and Ebru Yalcinkaya, take a closer look at Retros. They start by walking through the basics, like the basic structure of this event and what the Scrum Guide says about it. Then, while interacting with the audience and drawing on their experiences and challenges, they dive deeper, covering useful formats, common pitfalls, and some tips for making this event truly enlightening and productive for your teams.
Stay in the loop about upcoming webinars by joining our mailing list
Ebru Yalçınkaya describes herself as a change agent when working with teams and organizations. Her Agile journey began when successfully extended Agile approaches to non-tech teams in the company that she previously worked for. These included teams involved in different areas such as corporate sales, customer service teams, and human resources. She also helped establish the Agile Studio, an internal coaching and development centre. Here, she developed training programs for Scrum Masters and Product Owners for her company’s employees and teams.
Since 2014, Ebru has been working as an Agile coach at agile42 and has started Scrum and Kanban pilot programs in organizations. She aims to enhance a team’s agility, and help them to reach their goals. She is able to achieve this through her pioneering and collaborative approach, as well as her knack for understanding people and teams’ needs.
Pascal Papathemelis, is passionate about people, human factors, and agile practices. He started working with Scrum teams in 2005, and he has been an active member of the Finnish agile community since 2012. He is also an organizer of the Helsinki Coaching Circle, organizing regular meetups to chat about Agile Coaching.
Pascal has nearly two decades of experience as an Agile project manager, Scrum Master, and facilitator in a variety of organizations. Software development, telecommunications, and business operations are among them. His background enables him to comprehend both high-level business requirements and technical details to develop effective strategies. Pascal is currently employed as an Agile coach at agile42. Many teams have benefited from his extensive mentoring, coaching, and facilitation skills. He aspires to assist organizations, teams, and individuals in achieving long-term growth, improvement, and efficiency.
agile42 offers Scrum courses, as well as:
The Sprint Review is an opportunity for the whole Scrum Team to stand in front of their users, stakeholders and customers and inspect and adapt the Product. It takes place at the end of the Sprint. The meeting should include an overview of the state of the product in terms of progress, budget and next steps. Usually, there is also a hands-on demonstration of the actual product. The users and stakeholders provide feedback, and then the developers incorporate relevant feedback into the Product Backlog.
The Sprint Review is the third one of the Scrum Events that takes place within a Sprint. The purpose of a Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. It takes place on the last day of a Sprint, and is timeboxed to a maximum of four hours for a one-month Sprint.
The Scrum Guide defines the purpose of the Sprint Review as a chance to “inspect the outcome of the Sprint and determine future adaptations”.
The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review should be attended by the whole Scrum Team (Product Owner, Developers, and Scrum Master) as well as the customers, stakeholders and users.
According to the Scrum Guide, “the purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations”. This is the key purpose of the event, and should be the focus. There are, however, a few other purposes and benefits to the event. Firstly, it enables you to improve your responsiveness to customers or users. Secondly, it helps with quality assurance, since your whole team and various other stakeholders will be present to inspect the product. Finally, it can help with team cohesion, as it’s a chance to get together and run through the various successes and challenges of the Sprint.
Since both events involve inspecting the completed Sprint and adapting for the future, some people get the two events confused. However, there are some key differences:
Photo by Jason Goodman on Unsplash
Below is a sample agenda or structure, which we use at agile42.
The SM, who acts as a facilitator, introduces the event by welcoming the participants. They explain the purpose of the meeting to the participants which can include users, stakeholders and customers. Then they show the agenda for the meeting. (5-10 min)
The PO takes the lead and provides an overview of the state of the product in terms of progress, budget and next steps. They remind everyone of the Product Goal and describe the Sprint Goal the Developers were trying to achieve. (10 min)
The PO leaves the stage to the Developers to demonstrate the Increment. This is not a PowerPoint presentation of what the team has done, but a hands-on demonstration of the actual product. Usually Developers will go through the scenarios described in the acceptance criteria of each PBI. Some teams even let users or customers try the product themselves, while the Developers and the Product Owner observe how they interact with the Increment. (30 min)
The Scrum Team collects feedback on the Increment from all invited participants. (15-30 min)
Users, stakeholders and customers might leave the meeting at this point, while the Scrum Team continues with a working session to incorporate relevant feedback into the Product Backlog. Should the feedback be related to something which does not impact the upcoming Sprint, they can simply take notes to address the feedback in one of the upcoming Product Backlog Refinement sessions. However, if the feedback potentially affects the next Sprint Goal, the Scrum Team will perform a quick Product Backlog Refinement session during the Sprint Review to get ready for the upcoming Sprint Planning. (30 min)
The Scrum Master thanks the participants for their contribution and officially closes the event. (5 min)
In this webinar, we discuss the Sprint Review which is the most challenging Scrum Event according to our community. The symptoms are subtle and the causes deep: teams often fail to invite real customers, or they don’t know how to solicit and manage feedback. Our hosts, Dennis Büscher and Martin von Weissenberg, have facilitated, hosted and coached hundreds of Sprint Reviews, and in this webinar they share their insights, tips, and tricks with you. They begin with the basics and go over what the Scrum Guide says about the Sprint Review. Then they go a step further and share some of the most common pitfalls they’ve seen, as well as discuss best practices for getting the most out of this event. The webinar ends with a Q&A with our live audience.
Stay in the loop about upcoming webinars by joining our mailing list
Martin von Weissenberg is an experienced enterprise-level agile coach who believes that with the right leadership approach and change management tools, organisations can learn to change themselves in a structured and sustainable way. He has worked across the software industry for over 20 years, in startups as well as multinationals. Since joining agile42 in 2012, he has helped a large and diverse number of clients. These include organizations such as Siemens, ABB, Swedbank, Helsinki University, as well as countless shorter training and coaching engagements with companies in the banking, media, educational, telecom and marketing industries.
Martin is always interested in learning new things. So much so that he is currently completing his PhD on how to organize and lead for agility. This coupled with his empathetic and engaging nature, makes him well suited to drive transformations for both teams and larger organizations.
Dennis Büscher comes from a legal, agile project management, and human-centred design background. For more than three years, he has been coaching various companies and institutions in the fields of design thinking and legal design. Dennis worked at the HPI Academy as a project manager and coach for digital transformation and innovation training. Since 2021, Dennis has been a coach at agile42, supporting companies and organisations in the field of agility. He aims to drive innovation and empower teams through his user-centric approach and with the meaningful application of technology.
agile42 offers Scrum courses, as well as:
There is an abundance of articles telling people how to do the Daily Scrum right, but a real scarcity of articles pointing out how to realize when things go wrong. Knowing the common pitfalls of the Daily Scrum and how to spot them can be a real game-changer in your teams. Here are three small, easy-to-observe signs that you need to fix your Daily Scrum.
Recommended online course: Facilitating Scrum
In many, many Daily Scrums you find that the team takes turns to each share their own tasks, progress, and impediments, rather than contributing to the discussion as a team. People normally follow with attention until it is their turn to speak, and they simply disconnect after that. This behavior is often amplified by the common way of running the Daily Scrum, i.e. the famous three questions. These questions are no longer in the Scrum Guide, because they can contribute to this problem.
Further reading: Our comprehensive guide to the Scrum Events
There are two great ways to avoid this common pitfall and get the team to align towards the goal.
One way that works is to keep the same three questions, but change things up a bit by having three rounds instead of one, with each person answering only one question at a time.
This usually gives two benefits. The first is to keep people actively engaged until the end, since they know they will have to speak again. But there’s a more important benefit. It better serves the real purpose of the Daily Scrum: collectively assessing where the team is compared to the Sprint goal and collaboratively deciding what the next most important task is for each person to complete, in order to move closer to the Sprint goal.
Another way (which brings even more benefits in my experience) is to run the Daily Scrum by focusing on the stories in the Sprint Backlog, instead of focusing on people’s tasks. The idea is that the team selects one story at a time, going from the top, and discusses how to make it “done done” as soon as possible. Then you take the next story down and move on, either until you covered all the opened stories or until the 15-minutes time is up. In this way Developers will not focus just on the individual tasks, but will be nudged to look at the Sprint goal as a collective goal to achieve.
When using this second method, sometimes you do not manage to talk about lower priority stories, so people who are working on those might feel a bit excluded. This isn’t always a bad thing: it can provide some social pressure to contribute to completing the highest priority stories first, instead of picking what they like most and spreading the team effort all over the Sprint Backlog.
Recommended online course: Facilitating Scrum
This is the biggest sign that your Daily Scrum has turned into a status report. Remember that this is not the point of this Scrum Event: the team should be updating and discussing the high-priority tasks with one another.
Before the pandemic forced us to rethink the way we work and made remote work the standard, I used the trick to encourage the team to stay in a semicircle, closer to the task board, and I took (or asked the Scrum Master to take) a step back, pretending to take notes. If someone was stubborn enough to turn and try to speak to me, I removed eye contact, so that they felt a bit uncomfortable and were forced to find other eyes to look into: their teammate’s eyes. It worked immediately most times.
I used the same trick also when the team tended to look at the PO or their manager attending the Daily Scrum: I encouraged the team to stay in a semicircle, leaving all other attendees outside. If you want to replicate the same approach in a remote setting, just ask anyone else attending the Daily Scrum, except the Developers, to switch off their camera and mute themselves.
I know that many Scrum Masters tend to interrupt discussions or ask people to continue conversations outside the meeting. This works to a certain extent, but usually, people find it a bit irritating.
I use and teach a different approach to this problem. First, I explain very clearly to the team that the Daily Scrum is intended for the Daily Planning, so that everybody understands and buys into this. Then, when I see that a discussion is taking off, I leave some space for 1-2 minutes. If it is not concluded yet, I ask the following question: How do you think this conversation can affect today’s planning? Most times people admit that it is not strictly relevant and propose to park it.
Of course, the three above and other dysfunctions might be just a symptom of something deeper. If the quick-fix techniques illustrated above do not work, it can be a hint of something more important that must be addressed. Consider taking an online course in facilitating Scrum to help you and your team have functional, useful Daily Scrums and other Scrum Events.
The Daily Scrum is found almost everywhere, even outside of Agile frameworks, but many organizations aren’t getting the most out of them. When run well, the Daily Scrum can be highly engaging, quick, proactive, and focused. Our coaches, Regina Martins and Lothar Fischmann, have facilitated, participated, and coached their way through thousands of these meetings, and share some of their insights with you. In this webinar, they start with the basics, cover what the Scrum Guide says about the Daily Scrum and share some tried and tested formats and methods that they have used. Finally, they answer your questions and share their greatest tips and tricks for getting the most out of this Event.
Stay in the loop about upcoming webinars by joining our mailing list
Regina Martins is an experienced business professional with a demonstrated history of working in the information technology, financial services and telecoms industries. As a facilitator and coach at agile42, she spends time getting teams from across the organisational hierarchies to communicate effectively. As a Radical Collaborator, she also helps people to collaborate better with each other and with other teams.
She also has been involved in the Africa Innovation Summit and the Agile Africa conference, as she is passionate about the Agile community in South Africa and continually strives to help keep it fresh. She also regularly speaks at conferences both locally and internationally.
Lothar Fischmann has a background in marketing and corporate communications. These experiences help him to turn agility into something more concrete and tangible. He is a team player who is passionate about creating supportive environments that foster creativity and learning. He also has a systematic approach that allows him to understand situations and develop scalable solutions that fit customers’ needs when helping teams and organisations go through agile transitions. Plus, Lothar always aims to add energy and humour when coaching or facilitating to keep teams engaged.
agile42 offers Scrum courses, as well as:
This course is an intense introduction to Agile Product Management, requirements definition and the Scrum framework.
Our Certified Scrum Product Owner (CSPO) training class is a learning experience that provides students a full immersion into what it takes to be a great Product Owner. You will learn the theory of the Scrum Framework and then we work through tools to enable great Product Ownership.
The class is presented in a highly interactive and collaborative format with elements of lecture, classroom discussion, exercises, games and simulations, smoothly blended throughout the class. We will approach the class at a sustainable pace and endeavour to take breaks often, to allow our brain to stay focused and our body to recharge when necessary.
Upon completion of the class, students will receive their Certified Scrum Product Owner (CSPO) certification and badges from the Scrum Alliance.
“The training reinforced for me the paradigm shift from the waterfall approach in a monolithic organization to Agile’s concept of servant leadership. Yes, I’m leading the team, but I’m here to enable your success.”
Michael M.
There is no pre-requisite for attending this class.
The Certified Scrum Product Owner course is appropriate for aspiring Product Owners, business analysts, managers, project managers, and organizational team leaders seeking a deeper understanding of the Product Owner role, and how to improve Product Ownership in their organizations
Sofia P.
The Scrum Team’s primary focus is to make the best possible progress toward the Sprint goal, which is the single objective for the Sprint. Within a Scrum team, there are no sub-teams or hierarchies. Rather, the team is a self-organized and self-managing unit of professionals. In contrast to classical project management methods, Scrum doesn’t have a product manager or a team leader. Let’s dive into the different Scrum’s different roles and responsibilities.
Recommended e-learning: Learn about the different elements of the Scrum framework and why it works only in its entirety in our Scrum Foundations online course.
According to the Scrum Guide, the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
This role also holds a lot of accountability, as the name suggests. The PO has three key responsibilities.
Recommended for you: Product Owner Online Short Course
The Product Owner is usually one person who is accountable for effective Product Backlog management. The Product Backlog is an emergent, ordered list of what is needed to improve the product or service. This includes developing and communicating the product goal, creating and ordering product backlog items, and ensuring that the product backlog is transparent and visible at all times. As a result, they often have to prioritize work and backlog items by keeping the product goal in mind.
Often the PO has to “fight on both sides”. The Scrum Team often works within a specific time frame (the Sprint). During the Sprint, the Product Owner often needs to deal with marketing, management, or customers in order to prioritize work and maximize value. The PO must be an excellent communicator, as they must be in contact with all stakeholders, sponsors, and the Scrum team throughout a project.
The Product Owner is also responsible for the return on investment (ROI). They validate the solutions from the end-user’s point of view and verify whether the quality is acceptable or not.
Typically speaking, product managers are strategic and focus on the product’s vision as well as the company’s objectives and the market. Product Owners, on the other hand, are more tactical and focus on fulfilling a product vision by managing backlogs and working in cross-functional teams. A good Product Owner needs to be able to take responsibility, as the name suggests, for the success or failure of a project, which means they need to communicate effectively and juggle people’s expectations.
Photo by SHVETS production
The Scrum Master (SM) is accountable for establishing Scrum as defined in the Scrum Guide. The SM helps to increase the team’s effectiveness by enabling continuous improvement and making sure that everyone understands the theory and practices of Scrum, both within teams and the whole organization.
Recommended Training: Certified Scrum Master (CSM) Certification
According to the Scrum guide, “Scrum Masters are true leaders who serve the Scrum Team and the larger organization.”
The Scrum Master should create optimal working conditions for the team and keep these constant throughout the Sprint. This includes making sure that the team follows the Scrum Framework and understands all the elements of Scrum, including the five Scrum Events. They should have a comprehensive knowledge of Scrum and be able to act as a servant leader by creating the ideal environment for teams to thrive.
A Scrum Master is tasked with creating an environment for teams to thrive. They should aim to get rid of all possible impediments – or problems – that might disturb the work of the team. Usually problems can be classified in three different categories:
The Scrum Master can’t and shouldn’t solve every problem alone, but they are still responsible for guiding the team towards solutions and removing impediments. This task often takes up a lot of time and requires great resilience and the ability to care deeply for the team.
The SM should lead the organization in adopting Scrum. They should help employees and stakeholders enact and understand Scrum so that it can be successfully implemented. They may need to coach and advise in these instances.
Photo by Luca Calderone on Unsplash
The most obvious difference between a Project Manager and a Scrum Master is represented by the name itself. A Project Manager manages the project and sets the tasks, while the SM is in charge of ensuring that the team adheres to the Scrum framework. The Scrum Master does not interfere with the decisions of the team in terms of what they do, but acts as an advisor to the team when it comes to how they work. They only interfere when any participant in the project does not align with the principles of Scrum. A project manager, on the other hand, often gives directions and takes responsibility for the completion of tasks.
The Developers, or sometimes simply referred to as the Scrum Team or development team, have all skills necessary to create a valuable Increment for each Sprint, and they self-manage.
This team typically consists of three to five people and the specific skills needed by the Developers are often broad and will vary with the domain of work, however, they typically share the same set of responsibilities within a Sprint.
The developers do not simply receive tasks from a project leader; they are self-managing and decide how many User Stories they can accomplish in one Sprint themselves. They create a plan for the Sprint, the Sprint Backlog (which is composed of the Sprint Goal, the Product Backlog items selected for the Sprint) as well as an actionable plan for delivering the Increment.
The developers instill quality by adhering to a Definition of Done and work to ensure that they meet that standard. They may need to adapt their plan to reach the Sprint Goal and always hold one another accountable during the Sprint.
Developers in a Scrum Team decide on their tasks and are responsible for the execution of them – the team becomes a manager. The Scrum Master does not need to delegate all the work and plan the project
Scrum is simple to understand, but it can be difficult to master. Scrum is purposefully incomplete: It just defines the rules of the game, like the rules of a sport. That’s one reason why Scrum is hard to master: you need to know so many things outside Scrum to make it work successfully.
And if you need help implementing Scrum in your organization, get in contact with us.
