Tag Archive for: agile teams

Navigating the Storm: Overcoming Teamwork Challenges Together

Teamwork is an indispensable element for achieving success in any organization. However, the path to effective collaboration is not without its challenges. From conflicts and communication breakdowns to poor management and a lack of trust, teams often face numerous obstacles that can hinder progress and the realization of business goals. But don’t worry, because in every challenge lies an opportunity for growth and improvement.

Continue Reading

Cross-Functional Teams: A Comprehensive Guide

In today’s rapidly evolving and complex business environment, diversity, collaboration, and innovation are more critical than ever. When departments work in isolation, this can lead to communication breakdowns and a lack of shared vision, as well as inefficiencies that hinder growth. Enter cross-functional teams, a dynamic approach to project management and problem-solving that is transforming the way businesses operate.

Continue Reading >

Everything I Needed to Know About Agile Product Development I Learned from Dark Souls

There are two activities in my life that have filled the years with a roller coaster ride of celebration and depression –  periods where I had to rely on grit and determination slogging through unending drudgery punctuated with moments of delight –  developing software products and playing Dark Souls.

I realize that not everyone who reads this blog may be familiar with the Dark Souls games. Luckily, I can sum it up with one image – the screen that players see more than any other:

A screenshot of the computer game, Dark Souls, with the text "you died" in bold red lettering across the centre.

Dark Souls has a reputation as a brutally challenging game. As I start playing Elden Ring, the latest game in the series, I’ve been thinking about what I’ve learned playing these games and how similar it is to Agile product development. Below are four of the things I’ve learned about Agile Product Development from Dark Souls.

1. It’s All About Learning From Your Mistakes

While Dark Souls may be unforgiving, it’s not a particularly complex game. Even the most challenging enemies have big tells for their attacks and are fairly predictable in their behavior. Despite how frustrating it may feel after the tenth time dying to the same enemy, the game’s developers want you to succeed. If you’re paying attention, each level teaches you how to beat it. Easier enemies teach you the skills needed to beat the harder ones. Every time you see the “You Died” screen, you should be asking yourself, “what did I do that got me killed, and what should I do differently next time?”

This might be the most important lesson in Agile product development that so few people learn. Most of the products we build are not simply copies of another product. We’re solving new problems or old problems in new ways. Missteps will happen. Success comes when we learn from those missteps and find an innovative solution.  

Related reading: How Dungeons and Dragons prepares you for being a Scrum Master

2. Take Small Steps

Nothing leads you into disaster like over-committing. In Dark Souls, a wise player will take the game one enemy at a time and always check their corners. This lets you re-evaluate your surroundings and take the best strategy for that moment, even if that strategy is to run back to safety to regroup and rethink.

Agile Product Development is no different. We take our development one small feature at a time. This doesn’t mean we don’t have a larger context in mind, but we also know that each completed feature could show us a fundamental flaw in our thinking. This gives us a chance to take a step back, regroup, and rethink.

Whether you’re playing Dark Souls or building a product, if you don’t want to end up in over your head, take it one small step at a time.

3. You Will Fail. Often.

While it is true that each failure is an opportunity to learn, that doesn’t mean that failure won’t hurt. Whether you’re throwing yourself at the same enemy for the 28th time or you bomb a feature you were sure would be a slam dunk, you will get frustrated and it will kill your motivation. The best players and Agile teams know how to recognize that frustration and recover from it. 

Find out what works for you to recover and re-energize. Do you need a break? A small win? Do you need the support of your team to rally and push through the problem? Too often, teams just resign themselves to the frustrating task, which rarely leads you to a successful outcome. 

4. Sometimes, Your Princess is in Another Castle

OK, I’m mixing game metaphors, I know, but the lesson holds. Sometimes hitting a wall in Dark Souls is an opportunity to double down and persevere. Other times, it’s a sign you need to go spend a little time tackling other challenges in another level. This can help you unwind the frustration, build new skills, and build up your character. You may find that when you come back to the challenge, it will be easier to overcome.

In Agile development, you will encounter technical challenges and business challenges. You may need to buckle down and work through them, but other times, turning your attention to other feature areas will help you make progress and get your team unstuck. Often, that shakes loose new ideas and new solutions. When you return to the earlier work, you’ll be armed with new ideas and a fresh perspective.

Conclusion

It may seem strange to compare two things that seem so different as playing video games and building products, but in the end, a challenge is a challenge. The ways we work through them carry over across our personal and professional activities. I hope some of these lessons resonate with you. 

Want to learn more about Agile? Contact us

Being a Dungeon Master Prepares You To Be a Scrum Master

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.

Ain’t No D&D Party Like an Agile D&D Party

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.

The Basics of D&D

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.

Photo by S L on Unsplash

Scrum, Meet Party

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:

  • The Scrum Team maps to what in D&D is called a “Party”. 
  • A Party typically comprises one DM and three to six Player Characters (PCs). The goal of the Party is usually to complete a story. The story can vary in length, but any given story will at least take several sessions, with an average session lasting two to four hours.
  • In this analogy, the DM is a Scrum Master (and, if I’m being honest, a Product Owner between sessions). The PCs are Developers.
  • The story is the product. The product’s Definition of Done is that everyone felt included, the story resolved to their satisfaction, and that everyone had a good time. To Quote master storyteller Neil Gaiman (@neilhimself): “It’s that simple, and it’s that hard.”
  • A session is equal to a Sprint.

Learn more about Scrum basics in our online short course, Scrum Foundations

Scrum Master, Meet Dungeon Master

So, how are the roles similar? Let us enumerate the ways.

The DM’s Job is to Continually Deliver Value Every Session

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…

A Good DM Identifies the Strengths and Weaknesses of Their Players

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.

A Surprising Amount of the DMs Job Is Tracking Metrics and KPIs

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 Wise DM Encourages Innovative Solutions (and Gets Failures Out of the Way Early)

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.

Photo by lilartsy on Pexels.

A Smart DM Encourages Multiclassing

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.

The Best DMs Know Planning is Good, But Being Prepared is Better

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.

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.

This Sounds Hard

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.

Agile Leadership in Today’s World

In the fast-changing environment of our modern world, building and maintaining a thriving organization is a huge challenge, no matter if the company is big or small. It’s always been necessary for managers and leaders to understand the business itself very well, but today there are new challenges too. Organizations need to be adaptable, innovative, and engaging for people. In order to be successful in the new environment, a leader not only needs to learn a lot, but unlearn a lot too. There are new and different behaviors, skills and tools needed to nurture successful teams and organizations. This is where Agile leadership can make a meaningful impact.

To become an exceptional leader in a volatile and unpredictable world, join our webinar on 29 August: Top Challenges Facing the Modern Leader (and How to Overcome Them)

Contents

  1. What is Agile leadership?
  2. Agile leadership principles
  3. Agile leadership styles
  4. Agile metrics for leadership
  5. Servant leadership
  6. Emotional intelligence in Agile leaders
  7. Lean Agile Leadership
  8. Agile Leadership Training

What is Agile leadership?

The term “Agile leadership” is made up of two key terms: agile and leadership.

Agile is an adjective, not a verb. It is not something you do, implement, or deploy: it is rather something you are. It is a property of a system, whether an individual, a team, or an entire organization. There’s a reason the word is exemplified by an athlete: being agile is about flexibility, and the ability to respond quickly to unforeseen circumstances. 

The Oxford dictionary defines leadership as “the action of leading a group of people or an organization”. From this perspective, leadership is not something connected to a formal role, and nor is it something people are either born with or not. All of us can be leaders and followers in different contexts. Leadership is simply an ability to build.

How can we define Leadership

Photo by Randy Fath on Unsplash

Agile leadership is the ability to be flexible, use different approaches, and adapt to the context and the people involved. Because of this dependence on context, expectations and relationships, there are no leadership behaviors that are inherently positive or negative in and of themselves. Rather, there are leadership behaviors which are more or less appropriate within the context. 

Agile leadership is about the ability to make sense of the circumstances and adopt behaviors which are coherent with what the group of people you are leading in a specific context feels comfortable with. Incoherent behaviors are those that are not helpful within a specific situation and might be perceived negatively in the given cultural context. For this reason, Agile leadership is useful for any organization hoping to succeed in today’s climate, not only Agile organizations.

Coherent vs Incoherent Leadership

Like a sportsman needs to master many techniques to be really flexible, a true Agile leader has to master multiple leadership styles to be able to adopt the one that fits the specific context. That is quite a challenge, since we all feel more comfortable to adopt one or two specific leadership approaches and generally find others harder. If you do not practice the ones you are less comfortable with, the risk to propose an incoherent leadership is very high, which can be more harmful than you think.

In my coaching, I have observed the following pattern many times: People in a given organization are used to being told what to do. They have learned to be comfortable with it, because they are rewarded to follow directives. One day the manager comes and says, “Now we are Agile, so you are self-organized and empowered to do what you think is most appropriate”. People stare at each other wondering what this might mean, thinking “just tell us what to do and we will do it”. 

This is an example of incoherent leadership. The resulting frustration and dissatisfaction are known as Motivational Debt. Even if a specific leadership behavior seems appropriate to a situation, it needs to fit the cultural expectations of the people involved. If it does not, it will very likely cause a negative emotional response and potentially increase motivational debt. In some cases, the impact can be so severe that people decide to leave. The “Great Resignation” all companies witnessed between 2020 and 2022 is a great example of what can happen in the extremes of incoherent leadership.

So, while it is true that Agile organizations are built upon autonomous and self-managed teams, this shift cannot be pushed onto people overnight. Individuals and teams need to be gently guided over time into becoming more autonomous and Agile, by adapting the leadership and the environment iteratively and incrementally, in the service of making people the best version of themselves.

Agile leadership principles

In the last 15 years, I have had the chance to talk to a lot of leaders involved in efforts to create more agile organizations. Many of these leaders shared a sense of frustration for the many “don’ts” they were prescribed – and too few “do’s”.

These leaders were constantly hearing things like, “Don’t assign tasks to people!”;”Don’t tell the team how to do something!”; or “Don’t take decisions the team can take on their own!”.

The most common consequences of this frustration and uncertainty are two and both potentially harmful: the leader backs off and starts not to do anything or the leader keeps doing the same things as before exactly in the same way as before.

How do we address this then? How does effective leadership work in a 21st century organization?

Leadership in the 21st Century

Photo by Yan Krukov on Pexels

Five Key Principles of Agile Leadership

Individuals and organizations are not machines, but living organisms who need to learn and adapt. This means that we cannot always have pre-programmed rules to follow. Pre-programmed rules and predefined processes work well in a stable environment where we are able to predict all possible scenarios and prepare in advance to handle them. But what about the scenarios or disruptive changes we cannot predict? 

In such a context, it is more effective to learn and rely on principles instead of rules. First we need to incorporate those principles into our decision-making and leadership styles. Then, when new circumstances unfold, we can define appropriate practices, aligned with those principles, to make use of.

A good analogy for this is parenting. When kids are small, we can give them specific rules to follow, which work well in the safe space they live inside the family: “Don’t put your fingers into the plug! Sit well! First, finish your homework and then you can use your mobile phone!” However, if we want them to grow up and be equipped to face the unexpected events of adult life, we need to stop giving them rules and start teaching them principles (e.g. “Be honest”). Only then will they be able to apply themselves in different situations.

So what are useful Agile leadership principles to incorporate?

1. Manage the environment, not the people

Research and empirical evidence tell us that we can’t change people: we can hardly change the person we see in the mirror every morning. But we can change the environment and people’s experiences so that the behaviors and the results we expect come to life naturally.

Every organization has a vision and sets goals and metrics to monitor on the way to that company vision. Those goals are achieved (or not) through the results that every single person in the organization accomplishes. Some of them are exciting, like bringing an innovative product to the market, and some of them are just necessary, like filling in tax returns. But all results come from actions and behaviors. And going one step deeper, actions come from decisions, which in turn are informed by beliefs: we decide based on what we think is right or best in the moment. 

Our brains are connecting machines, which create wired patterns through which we interpret the reality around us and decide what is right or wrong. These patterns are created through the experiences we have lived all our lives. Existing patterns cannot be broken: the power of one to one conversations is therefore overrated. But new patterns can be created through novel experiences. 

Traditional leaders tend to focus on managing people’s actions. This approach addresses just the tip of the iceberg, and it only works well in a very stable environment. In such a state, the rate of change is so slow that we can afford to have only a few people (the managers) in control of decision making and the rest of the workforce simply executing.

When the rate of change is high, the reaction from hierarchical management is too slow and  can create bottlenecks. Here, decision-making power must be distributed and given to those closer to the problem. To avoid the risk that everyone takes their own direction, this distributed decision-making power needs to be coherently funneled towards the company goals and vision.

Organizational culture is so much more than a value statement on your website: it’s the sum of the experiences and beliefs of the people involved. The organizational culture can be measured through its living manifestations, such as rituals, stories of success and failure, habits, and unwritten rules. 

Today, an effective leader does not create superficial compliance to company values, but leverages approaches such as mentorship and coaching to create new experiences, which will then result in new stories, new rituals and new behaviors.

Agile leadership focuses at the bottom of the pyramid to manage the environment and create those experiences for people to build coherent beliefs, which will in turn determine coherent decisions.  

2. Build autonomy and trust

Modern-day organizations benefit from decentralized decision making. To be more resilient and equipped to face unexpected circumstances, they must be built upon autonomous and self-managed teams.

But as we said above, the shift from a fully hierarchical chain of command to autonomy cannot be pushed onto people overnight. Individuals and teams need to be respectfully guided over time to become more autonomous and agile, by adapting to the leadership and the environment iteratively and incrementally.

An Agile leader carefully selects those leadership behaviors that can act as a bridge in the gentle transition towards higher levels of autonomy with minimum disruption and resistance.

This process of transition and discovery will be shaped by bringing diverse perspectives together, for instance by asking people to share stories of success and failure. Some questions you could ask include:

  • Do they associate stories of success and failure with the same leadership approach or with different ones?
  • What behaviors from the leader do they associate with success or failure? 
  • Is the group uncomfortable with higher autonomy at a given moment or do they favor it? 

A transition towards a higher level of autonomy while building trust (instead of harming it) is based on adopting iteratively and incrementally more of the behaviors that are associated with the desired state and less of the ones that are not. 

At the same time, it is necessary to build the teams’ skills to sustain high levels of autonomy, for instance the ability to navigate conflicts, collective decision making, and the ability to give each other constructive feedback.

3. Model the behaviors you want to see

As Agile leaders shape the environment to create the experiences which support the right culture and make higher levels of autonomy accepted and affordable by the team, they realize they are themselves part of that environment.

This means that they need to own and model the culture they want to see around in the organization, to avoid an incoherent clash between what they preach and the leadership they demonstrate. Such a clash can undermine people’s trust and willingness to take on more responsibility.

If Agile leaders are serious about improving their organization, they should be even more serious about improving themselves.

4. Lead based on the context

The ability to make sense of the circumstances in a given situation and adapt your approach to fit the context is a key characteristic of good leadership. As expressed by Dave Snowden in the Cynefin framework, different circumstances can be organized into different domains. The domains, in turn, are characterized by different approaches to decision making, acting and leading. 

Cynefin Framework

Situations in ordered domains show causality, meaning there is a clear relationship between cause and effect. This means that we can plan and act, based on the characteristics of the situation and the context in which it is happening. In some cases, the appropriate action is self-evident: it is sufficient and effective just to tell people what to do or establish guidelines and checklists to follow.Other cases require analysis. In these situations, expertise plays a very important role: the leader will ask experts to analyze the situation, and provide possible solutions. Establishing expert peer review can improve the quality of what is decided and executed.

In unordered domains, the lack of causality makes planning and the direct reuse of existing approaches very difficult, if not impossible. When the situation is complex, the relationship between cause and effect can only be discovered in retrospect and therefore actions might have unintended consequences. In those cases, expertise is not of much help, and it is necessary to run multiple parallel probes (some of which will fail). These allow the identification of repeating patterns and show us how to affect the system and address the problem. The leader’s ability to involve cognitively diverse people will affect the quality of the experiments and the decided actions.

In a chaotic situation (such as an emergency), the leader’s ability to act promptly is what will make a difference. Waiting and trying to analyze the situation is useless when volatility and uncertainty are very high.

Understanding the context and the situation allows leaders to act effectively in a given cultural context. For example, in a hierarchical organization people will expect the leader to appoint experts and make the final decision in a complicated situation, while in a more collaborative organization, the group will feel comfortable to appoint experts and options on how to move forward will be vetted and discussed by the group. Agile leaders are aware of the context and the situation and how to appropriately shift their behaviors and modulate the actual course of actions.

5. Incorporate agility into change

All changes, even with the best intentions, can create motivational debt by introducing gaps between expectation and reality. People are complex and there is only so much change each of us can handle at a time. However, many organizations try to take a “fail-safe” approach to change. An example of this could be buying a big model from a consulting agency, marketing the concept internally, and setting milestones. There’s so much money, ego and expectations attached to the change project that it will simply not be allowed to fail.

Agile leaders, on the other hand, know that effective change in a complex environment can only work with an evolutionary approach. Here, the focus is on leveraging the potential of the present and the natural predispositions that already exist in a team or an organization, instead of pushing towards an unrealistic ideal state.

Again, it is like parenting. If we want our kids to learn collaboration, we don’t describe what good collaboration looks like and create a plan towards it. Instead, we might encourage them to apply to a football or basketball team or to join a music band. Through these experiences, they will build collaboration muscles and learn what collaboration feels like.

In order to reduce the risk and side effects of change within organizations and deal with unpredictability, effective leaders know to instill change through diverse experiments with small continuous adaptations. This removes the burden and risk of maintaining different co-existing systems of work (i.e. the old way of working, and the new one) for long periods of time: small changes are easily understood, quickly piloted and rapidly integrated, minimizing the uncertainty, confusion and loss of effectiveness inherent in change.

Incorporating Agility into Change

Photo by Linus Nylund on Unsplash

Running different parallel experiments enables leaders to validate assumptions and hypotheses in a safe-to-fail environment. Through multiple safe-to-fail experiments they recognize repeating emergent patterns that can be replicated to catalyze change in other parts of the organization.

By asking volunteers to help define and run the experiments, they achieve wider acceptance of the change in the organization and increase transparency because everyone can see small things happen and facilitate work in that direction: people hate it when a big change is unexpectedly announced by management and they cannot relate to the rationale and the implications of the change.

Agile leadership styles

Agile leadership is the ability to master multiple leadership styles to be able to adopt the one that fits the specific context, and work with the expectations of the team. We can define six different leadership styles (or behaviors) that can be developed and applied in different contexts and cultures:

  1. Directing
  2. Demanding
  3. Conducting
  4. Envisioning
  5. Coaching
  6. Catalyzing

Because of the dependence on context, expectations and relationships, there are no leadership behaviors that are positive or negative in themselves. Rather, leadership behaviors that are more or less helpful within a specific situation and might be perceived positively or negatively in a given cultural context. 

Read more: Agile Leadership styles

Agile metrics for leadership

A question on many Agile leaders’s minds is, “How can we know how well we are doing as leaders?” Most people would tell you that we need to measure the impact that our leadership has, the level of autonomy of our team, the culture, and the level of resilience of our organization. However these are all lagging indicators, which we can evaluate only in retrospect in the future: sometimes leadership is about planting seeds of a tree we will never enjoy the shade of. 

Agile Metrics for Leadership

However we could look at a few leading indicators to understand whether we are going in the right direction and get feedback. In this way we will be able to improve by leveraging on our strengths and acting on our improvement areas. 

Leading indicators for Agile leadership 

A first leading metric could be around how we are doing as servant leaders. If we are demonstrating good servant leadership, we are likely to be strengthening people’s skills and building leadership as a diffused organizational capability, so that everyone can be a potential leader. A few questions can help us self-reflect on the different servant leadership virtues and their impact on the people around us:

  • Do people believe that I am willing to sacrifice my own self-interest for the good of the group?
  • Do people believe that I want to hear their ideas and will value them?
  • Do people believe that I understand what is happening in their lives and how it affects them?
  • Do people come to me when chips are down or when something traumatic has happened in their lives?
  • Do others believe that I have a strong sense of awareness for what is going on?
  • Do others follow my requests because they want to as opposed to because they “have to”?
  • Do others communicate their ideas and vision for the organization when I am around?
  • Do others have confidence in my ability to anticipate the future and its consequences?
  • Do others believe that I am preparing the organization to make a positive difference in the world?
  • Do people believe that I am committed to helping them develop and grow?
  • Do people feel a strong sense of community in the organization that I lead?

Once you identify your biggest strength and your biggest improvement area, meet with a peer and:

  1. Share a story when you demonstrated the servant leadership virtue you believe represents your biggest strength
  2. Ask for a suggestion about what you could do tomorrow to become one inch better at practicing the virtue you feel you are most struggling with right now

Another useful leading indicator could be about our ability to master multiple leadership behaviors. If we have the agility to adopt the appropriate leadership style in each of the contexts we are dealing with, we can reduce the Motivational Debt and build autonomy and resilience in the organization. A leadership behavior assessment again could help us self-reflect and get the inputs necessary to strengthen our leadership muscles, around the style and the behaviors we feel less comfortable in adopting.

Our leadership behavior assessment is based on SenseMaker® technology developed by Dave Snowden and The Cynefin Co. Both the leader and their followers capture and interpret situations in which the leader demonstrated a certain behavior. Multiple perspectives on the same situation help the leader realize how well they master different leadership behaviors and how coherently they apply those to different situations and contexts.

Try agile42’s Leadership Assessment for free or level up with the full-featured assessment.

Servant Leadership

The future of work, especially after the pandemic, seems to be a place where individuals closer to the problem are best-placed to make decisions. Teams are self-managed, which means they decide what to work on, as well as when and how to best achieve the requested outcome. 

Leaders that are effective in building such an environment create the conditions for the individuals and teams to perform at their best, and meet what people seem to expect from employers in 2022. This includes a focus on removing impediments, aligning stakeholders, building trusting relationships, coaching, providing feedback, developing people’s skills and building the capabilities of the organization. Ultimately, they cultivate the virtues of servant leadership.

What is servant leadership?

Robert K. Greenleaf first popularized the term “servant leadership” in The Servant as Leader, an essay published in 1970. It​ is a leadership philosophy and set of practices in which the leader puts the needs of the employees first and helps people develop and perform as highly as possible. A Servant Leader should be asking themselves, “Do my actions help those I lead grow as persons? Do they, because of my actions, become healthier, wiser, freer, more autonomous, more likely themselves to become leaders?”

Dive deeper into Servant Leadership

The 11 virtues of servant leaders

  • Awareness
  • Calling
  • Community
  • Conceptualization
  • Empathy
  • Foresight
  • Growth
  • Healing
  • Listening
  • Persuasiveness
  • Stewardship

These virtues are maybe even more essential now than they were when they were first published in 1970. In the current world, leaders simply can’t be effective without trust from people they are supposed to lead. 

Emotional intelligence in Agile leaders

Practicing the virtues of servant leadership helps build good leadership in this fast-changing world. But what other qualities does an effective agile leader have?

Well, if you want to become the kind of leader who masters multiple leadership styles and is able to read the situation and apply a coherent approach to the context, you might want to work on your emotional intelligence.

Daniel Goleman was the first to popularize the idea of emotional intelligence and demonstrate evidence of its impact within organizations. He passionately argued for recognizing the relationship between someone’s emotional state and the actions driven by it, and how those actions in turn impact others and the organization (essentially the people they work with), whether positively or negatively.

Emotional intelligence consists of four fundamental skills: 

  • Self-awareness
  • Self-management
  • Social awareness
  • Social skills

Read more: Emotional Intelligence in the Workplace

Emotional Intelligence

Lean Agile Leadership

The phrase “Lean Agile Leadership” is something of a buzzword at the moment, although if you unpack the concept there are a lot of useful principles behind it. 

The term “Lean” was coined by James Womack, Daniel T. Jones and Daniel Roos in their book, The Machine That Changed the World: The Story of Lean Production, in 1990.

Recommended reading: Lean Agile Leadership in more detail

Seven Lean principles 

Later, in 2003, Mary and Tom Poppendieck published the book Lean Software Development: An Agile Toolkit. In this book they identified seven fundamental principles to take the concept of lean thinking from production, and apply it to software and product development. I believe these principles can be applied to any creative work. 

The seven Lean principles are: 

  1. Eliminate waste
  2. Build quality in
  3. Amplify learning
  4. Defer commitment
  5. Deliver as fast as possible
  6. Respect people
  7. Optimize the whole

Three dimensions of Lean Agile Leadership

There’s another important thing we can learn from experiences of organizational transformation and Lean management in the manufacturing sector. In my coaching, I have pinpointed three key dimensions worth considering as a leader. For each of these dimensions, I will offer one or two coaching questions to facilitate the reader’s personal reflections.

  1. Visible problems do not exist: they have been solved already. To help leaders move forward, you can ask: “How many clearly visible problems are you still stuck with in your organization?”
  2. The most efficient way becomes the standard, and the standard must be improved every month. Here, we can ask, “How much are you still striving to find one-size-fits-all “best practices” to make you move quickly to the next rigid and comfortable status quo?”, and “What are your managers accountable for?”
  3. Measure organizational capacity for solving impediments to generate trust. Here, it can be helpful to ask, “How seriously is your organization taking the fixing of impediments for teams?” and “To what extent do you think you are living the values you’re preaching?”

Agile Leadership Training

In a post from 2011, consultant and writer Esther Derby explains how insufficient training and mentoring can be damaging for leaders. She says, “Most people in management roles receive little or no training on how to do the job. Many organizations promote people who excelled as individual contributors doing technical work into management roles […] The skills required for management are often vastly different. […] A lot of the management training out there is crap. Few organizations have robust and confidential mentorship programs.

As we discussed in the chapters above, an effective way to become a better agile leader is to self-assess your servant leadership skills, understand how good you are at mastering multiple leadership styles, and grow your emotional intelligence index through journaling, self-reflection, and feedback.

However a solid education is extremely important, especially if you are starting the journey or want to deepen and practice your Agile leadership skills. In this context the industry standard and most widely recognized program in agile leadership is Certified Agile Leadership Essentials for Team and Organization Leaders, also known as CAL-E+T+O training. This class will help you discover how your natural, cultural dispositions might affect your teams, and learn how to create a safe-to-fail environment that fosters a culture of transparency, inspection, creativity, and adaptation.

Agile leadership styles

Agile leadership is, at its core, the ability to master multiple leadership styles to be able to adopt the one that fits the specific context and the team’s expectations. Because of the dependence on context, expectations and relationships, there are no leadership behaviors that are inherently positive or negative. It is more helpful to describe leadership behaviors as either more or less helpful within a specific situation. The way the leadership behavior is perceived by those affected is important in a given cultural context. 

Being an agile leader does not mean using a coaching leadership style in every circumstance since this can be unhelpful, (or even harmful) in certain situations. An example is a crisis situation, or working with a team of people that expect clear directives. In both of these examples, a leader using a directive or demanding style can be a gold example of servant leadership. This is because they are intentionally adopting that behavior in a specific moment in the service of empowering them to be better and more autonomous.

Leadership Styles

Photo by Jason Goodman on Unsplash

How do you know which leadership style is most appropriate?

When you think of switching between leadership styles, it may seem like a tough challenge and even a little overwhelming at first. Agile leaders use emotional intelligence and are conscious of their own and other people’s emotions and perspectives. This helps them to adopt the appropriate leadership behavior in different circumstances. They are able to gently and iteratively shift their primary leadership style from directing towards coaching and catalyzing, in order to build agility and autonomy in their team and organization. This is a skill, and like any skill, it can be learned, practiced, and mastered.

Recommended for you: Master various Agile leadership styles in our online course on Agile Leadership Foundations 

Six leadership styles to master

We can define six different styles (or behaviors) that can be developed and applied in different contexts and cultures.

Directing

The leader acts, and is perceived as, an expert and an authority. It is considered one of the more traditional leadership styles.They are therefore in charge of assigning and controlling work while being held accountable for the results of the group’s work. Discussion or negotiation is not usually welcome when leading in this way. Instead, the leader expects compliance from their followers. 

When it works: This style is essential in a crisis or when people expect clear direction
When it doesn’t: In the wrong context, for instance, when people expect a certain degree of autonomy, a directing style can be stifling and cause frustration.
What holds the group together: The direct relationship with the leader, as well as a shared awareness of the possible consequences of failure

Demanding

The leader is perceived and acts as someone with extremely high standards. They are competitive and focus primarily on performance, leading by example. The followers focus on their targets. 

When it works: When followers perceive the work as focused on results, a constant push from the leader can be motivating in the short term.
When it doesn’t: When used long-term, this style can cause a high level of stress.
What holds the group together: Meeting targets successfully as well as the leader’s conflict-solving skills. 

Conducting

The leader coordinates and encourages collaboration, believing that collaboration is essential and increases quality. While the leader is responsible for enabling the collaboration, the followers feel responsible for their individual contribution. They can rely on help from their peers.

Conducting Leadership Style

Photo by cottonbro from Pexels

When it works: When followers know that they need to deliver the work, but expect the leader to retain the overall responsibility for delivering value, conducting can be effective.
When it doesn’t: This style can cause problems when people do not feel comfortable to organize their own work, or when they are not skillful enough to handle disagreements that emerge from cooperation.
What holds the group together: Clear roles and group dynamics

Envisioning

The leader motivates people by providing a compelling and challenging vision of the future. They inspire collaboration and a sense of shared responsibility. They have faith in their followers’ abilities. The followers value collaboration and they are motivated by their feeling of being able to learn and achieve more together.

When it works: This style is great for when the team believes that quality work can be achieved only through collaboration and collective agreement.
When it doesn’t: If the team does not have sufficient skills in collaborative decision making, this can cause difficulties.
What holds the group together: A team identity and a shared purpose

Coaching

This is the approach most commonly associated with agile leadership styles, however it is not always appropriate. The coaching leader supports team members with their personal growth and supports the team  to become more effective as a whole by being a servant leader. The team shares responsibility and collaborates to achieve their goals. They are motivated by mastering challenges and learning continuously.

When it works: When the followers perceive the work as being self-directed and expect a high level of autonomy in achieving their goals.
When it doesn’t: When the followers do not feel comfortable with autonomy or do not have appropriate skills in giving/receiving constructive peer-to-peer feedback.
What holds the group together: A sense of belonging as well as the challenge of reaching their full potential. 

Catalyzing

The leader amplifies the success of the team, connects them with the rest of the organization and ensures their contribution to strategy creation. The leader provides both praise and challenges and enables synergies. The followers are self-governing, maximize value delivery and incorporate customer feedback autonomously. They are open-minded, curious and adaptive. They are motivated by their contribution.

When it works: When the followers perceive their work as fully self-managed in terms of both the goal and how to achieve it.
When it doesn’t: When people are only focused on their own personal or team success and are unable to see the benefits to collaborate with the larger organization.
What holds the group together: A constant search for new challenges.

Want to learn more about Agile leadership styles? 

Companies are investing more than ever in leadership development, and highly trained, skilled leaders are indispensable to the modern workforce. agile42 offers a number of training, coaching, mentoring and other services. You could start with the Golden Standard for Agile leaders, namely Certified Agile Leadership Essentials for Team and Organization Leaders (CAL-E+T+O) training, which we do in-person and remotely, or contact us for information about our other services. We also offer an online leadership course which will help you explore the various Agile leadership styles in more details. 

3 Signs Your Daily Scrum Sucks (And How to Fix It)

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

1. People are only interested in their own tasks

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

How to fix it

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. 

Daily Standup Meeting

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 

2. Everybody is looking at the Scrum Master instead of at each other 

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. 

How to fix it

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.

Daily Standup

3. People have long discussions, trying to fix problems during the standup 

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.

How to fix it

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.

Do your Daily Scrums need more work? 

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.

Webinar | The Daily Scrum

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.

Watch Now | Daily Scrum Webinar

Stay in the loop about upcoming webinars by joining our mailing list 

Meet your webinar hosts

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.

Browse the agile42Agile Certifications

Facilitating Scrum online courses

agile42 offers Scrum courses, as well as:

How to Use Agile Metrics for Team Improvement

In a dynamic competitive environment, it is important to deliver value to customers quickly and regularly, to react quickly to changes in the market, and to become more resilient. But how do you know you are on the right track or have already reached your goal? As there are so many options available, you can spend days measuring something, on different levels, in different ways. Digital tools such as Trello or JIRA offer metrics for Scrum and Kanban teams, presented in nice-looking dashboards. But which metrics are most important to drive team improvement? Learn where to start and how to make great use of agile metrics as a tool for team improvement in four simple steps.

For some practical strategies to assess your team’s agility, watch the recording of our Webinar: How to Assess the Performance of Agile Teams.

What are Agile metrics?

Metrics in general are qualitative or quantitative standards that you choose and use in order to continuously improve your product, service, organization and team. You do this based on data from previous work cycles. For that reason you continuously measure specific aspects that guide you towards your goal.

Agile metrics typically relate to agile working practices and can cover many different aspects. You can measure productivity, quality and customer satisfaction, among many other things. You might also hear terms such as “agile productivity metrics”, “agile quality metrics” or “agile KPIs”.

Recommended reading: Combine your OKRs with Agile Strategy Map™ for Success

However, they are not about measuring the amount of work done – the output – but rather how much you were able to make a positive impact on the end user – the outcome. As there are so many options available, you can spend days measuring something, on different levels and in different ways. So where do you start and how do you find metrics that are useful in your context? Generally, a good starting point is to understand why and how you want to start measuring data.

Why metrics matter: Inspect and adapt

You have a current state of a product or service for which you collect data. What does this data tell you – what can you learn from it? What changes can you derive from it that could bring you closer to your goal? Will the actions taken have the desired effect?

As Simon Sinek famously says: “It all starts with why”. In this context: Measure for a purpose. You need to understand why you want to measure something and what you will do with the results. The data itself is not the goal. Instead, it is about continuously tracking your journey, testing hypotheses, and providing feedback as you head towards your goal.It also nurtures self-management within teams as communication around metrics can promote openness, transparency, and creativity.

Three agile metrics to start with

Lead time and cycle time to improve service delivery

Lead time describes the time required to complete tasks from the time of commitment. Let’s assume that a coffee delivery service receives a new order. Three minutes pass before the order arrives and is processed at the coffee machine. It takes another seven minutes from the time the coffee is processed to the time it is delivered. The processing time at the coffee machine represents the cycle time.

Diagram showing lead time versus cycle time

Lead time and cycle time provide important details for meeting customer expectations and give indications of possible optimization approaches. For example, it can be determined whether an excessively long processing time can be remedied by optimizing order acceptance or the coffee making process. Lead time and cycle time also improve predictability because they trigger valuable conversations about planning and customer value delivery. 

Recommended reading: Simon Sablowski and Lothar Fischmann describe how they helped a team improve their service delivery by factor 30 using Kanban

Features nobody uses to focus on customer value

Identifying features nobody uses can help to trigger conversations about customer outcome value. Who is the target user and what challenge should the feature solve from the user’s perspective? If the intended outcome is still relevant, you can dig deeper and figure out what needs to be improved to create value. This could also be a starting point for additional research or doing A/B tests.

To measure features nobody uses, you could use digital analytics tools that gather data like click rates or heat maps. In case you are not able to use analytics tools, you could conduct surveys, customer interviews or observe the customer using your product.

Net Promoter Score® as an indicator of customer satisfaction

The Net Promoter Score® (NPS®) is a metric that indicates customer satisfaction and loyalty. It is based on a customer survey which consists of only one question: How likely are you to recommend our product/service to a friend or colleague?

Net Promoter Score Chart

Customers can usually rate on a scale from zero to ten and optionally provide some written comments on why they have chosen a particular number. Customers who rate below 7 are considered detractors who are not satisfied with your product or service and might spread negative word of mouth. Passive customers rate with 7 or 8 and might be receptive to offers from competitors. Customers who rate 9 or 10 out of 10 are considered promoters who are loyal and committed to the product. They might spread positive word of mouth.

The NPS® focuses on customers’ satisfaction with existing products or services and focuses on an outcome. Detailed responses or comments can be used to identify concrete improvements. As the NPS® is a widely adopted metric, there are many options available to organize and run a survey. It is also possible to compare your product’s or service’s results with an industry average.

Common pitfalls with using metrics

In modern knowledge work, no two tasks are exactly alike, no two teams work together in exactly the same way, and no two project contexts are similar. Numbers might appear to be a solid, reliable standard of judgment and create a feeling of safety, when dealing with complexity. However, when you abstract complex situations into numbers for metrics, they inherit the same complexity.

Perhaps you have experienced that metrics are used because it’s simply expected from a team. Unfortunately, unfocused measurement and comparison undermine the foundations of agile approaches: They create a climate in which teams try to optimize for metrics rather than delivering the best product or service possible. This usually happens when an organization focuses on measuring output instead of outcome. Metrics that are supposed to promote orientation then cause undesirable behavior and thus poor results.

An example of this is the comparison of story points different teams have “delivered”. These are not comparable because each team uses their own sizing. The number of story points can easily be manipulated by splitting or estimating items differently and has nothing to do with the actual value delivered to the customer. Eric Ries, author of Lean Startup, calls these metrics vanity metrics because they look good and make you feel good but represent no real value.

“Tell me how you measure me, and I will tell you how I will behave.”

– Dr. Eli Goldratt

It is not surprising that some people react negatively to metrics. People will be more committed to metrics if they meet the following criteria:

  • They are purposeful and focus on continuous improvement
  • There is a clear connection to your goals
  • A team focuses on a few important metrics

Metrics are only useful if they drive continuous improvement. Being able to select the right metrics is crucial.

Four steps to use metrics as a tool for team improvement

Step 1: Determine your goal

To ensure that you collect appropriate data, you should first know your goal of measuring something:

  • What do you want to achieve?
  • How will you know later that you have achieved my goal?
  • Which things influence it?
  • For what purpose do you want to measure what data?
  • Whom does this affect in each case and how? One team, several teams, the entire organization, specific products?

Often the goals relate to the following six areas:

  • Value: Are you meeting the customers’ needs? Are you serving internal needs and values as well?
  • Predictability: The ability to plan and deliver customer value
  • Productivity: Delivering more value in the same time or with the same resources
  • Quality: A product or service that is free of defects and problems and meets customer expectations to the best of its ability
  • Consistency: The ability of a team to maintain this pace indefinitely
  • Growth: Is the team growing and learning?

Have a common goal

By tomertu on Canva

Step 2: Define metrics based on principles

Choosing the right metrics requires an understanding of the target and its influencing variables. All relevant people must be involved so that the connections are clear.

Some of the principles worth following in setting the agile metrics for your team include:

  • Each metric should be specific to the project, product or service and should give meaningful information to team members and other relevant stakeholders
  • Team members should understand the value of measuring each metric, so they can use and apply them in their self-improvement efforts
  • Metrics should be considered in conjunction with one another, and not as standalone indicators. This also ensures that metrics are not used as an end in themselves and may encourage undesirable behavior.

Additionally, ensure that metrics address not only negatively associated symptoms, but a positively associated change in root causes. This can be done with the help of leading and lagging indicators. A leading indicator is a predictive measurement that can be used to influence change, whereas a lagging indicator is an outcome measurement that can only record what has happened.

Here’s an example: Based on its ongoing measurements, an e-commerce team has noticed a decrease in recent sales numbers. The hypothesis is that there are defects in their checkout process that prevents some customers from placing an order. For this purpose, the bug rate is to be measured. The bug rate shows as an actual state that something should be improved.

Assuming that the team measures the occurring bugs in a certain period of time, it can also see a positive development. However, it cannot prevent the occurring bugs by this – This is why the bug rate is a lagging indicator. It would be better to additionally measure the test coverage, so that bugs do not occur in the first place, e.g. through the use of automated tests. These “target” states are referred to as leading indicators – They show the extent to which the target state has been achieved.

Step 3: Use metrics as a trigger for conversations

After defining what you want to measure, why, and how you measure, the real work begins: What does the data tell you? What can you learn from it? To use metrics as a tool for positive change, it is critical how you incorporate them into your communications and actions.

  • Ask curious questions and go deep: Think of metrics like signals. They don’t mean much by themselves, but they indicate what we should look into more. If your team’s delivery rate is low, ask the team if they’re struggling with something that prevents them from completing work.
  • Encourage the team to put metrics into context and let them tell stories about what has happened: “Do you see where our number of bugs starts to drop? That’s where we changed the way we test our code.” is more meaningful than “The number of our bugs is going down – We were able to increase quality.”

To make this kind of communication a habit, positive experiences are particularly good as a starting point for further improvement: What did we change to improve? What have we learned that we may apply in another context?

  • Prefer trends over raw numbers: Good data is not available in all cases but even if the numbers are inaccurate, trends can tell us something. Is the team’s delivery rate erratic? Is the number of errors decreasing? In many cases trends matter, even when exact numbers are hard to get. Trends can also be helpful early warning systems.

Step 4: Create a good habit

By being honest and transparent about what and why you measure, you can support your teams by thinking long-term about values, intentions, and purpose. The measurement then is followed by value-oriented discussions and focused on actual steps towards continuous improvement. Incorporating these conversations about metrics into your already existing meetings ensures continuous improvement. Usually, retrospectives are a great environment to do this.

Recommended online course: Facilitating Retrospectives

Conclusion

To make great use of metrics as a tool for team improvement, there is no “one size fits all” solution available to identify the most important metrics. Cultivating a good conversation about metrics, testing hypotheses and focusing on continuous improvement is a journey and you can start this with any simple measurement. It’s not about numbers, it’s all about impact.

 

Webinar: Human Factors in Agile Transformations

Are we paying attention to the important human factors of coherence, psychological safety, and trust that connect us in the virtual and physical spaces where we gather? In July, agile42 coach Michèle Twomey, alongside our special guest Sonja Blignaut from More Beyond, explored this question and some of the hybrid models we are testing that enable essential human contact during agile transitions.

Michéle kicked off our two-part series on "Human Factors in Agile Transformations". In her video interview, Michéle gave us her take on Gerald M. Weinberg's statement: “all problems are people problems”. She also delved into what human factors one needs to consider in agile transformations as well as her sources of inspiration in her own journey of understanding human factors.

Let's automate what needs to be automated and let's start thinking about where that human magic can really become valuable.

- Michéle Twomey

Next up, Sonja shared her insights on human factors within the realm of "complexity". She addressed the notion that, if we force too much change on people, we compromise their sense of coherence. Ultimately she believes we need to think about limiting the change in progress, the same way we limit work in progress within agile transformations. Listen to Sonja's video interview HERE.

Michéle and Sonja joined forces in our webinar on the 28th of July. The session raised many pressing issues we are currently facing, particularly around the expectation of always being available, always being online, and the important element of trust within the workplace. The audience had the opportunity to engage with their own questions, some of which included:

  • Given a new team who can only work remotely, what would you suggest to build trust?
  • I miss the spontaneous corridor discussions that have in the past been the space where the most impact has been made. Have you seen anything that could substitute this space in the current situation when we're all remote?
  • What do you think helps some people handle digitisation better than others?
  • How is the link between the personality type of the leaders vs the human factor taken into consideration or not?

In the same way you put in place WIP limits, you need to put in change in progress limits. It's like a dam with sleuths - if you don't think carefully about how much water you let out, you flood the downstream.

- Sonja Blignaut

If you missed out on the live session, we have the recording for you here - please feel free to share around with your network. 

Join our free agile42 Community and gain access to thousands of agilists from all over the world to share experiences, challenges, and ideas. A safe and moderated community of like-minded people, who share a passion for all things agile - organizational culture, lean and agile methods, coaching & more!

Please do get in touch with us should you have any questions - we would love to hear from you.

Follow us on our social media platforms:

LinkedIn | Facebook | Twitter

 

Tag Archive for: agile teams

CAS-SA1 Training

New certification

Certified Agile Skills – Scaling 1 (CAS-S1) training

Our Certified Agile Skills – Scaling 1 (CAS-S1) training class is a brand new Scrum Alliance certification. There’s an unprecedented demand for companies to deliver more in the  contemporary business landscape. CAS-Scaling 1 provides a solid foundation to ramp up the results of your agile efforts and take production to the next level. Scaling agile requires focused collaboration, coherent objectives, and appropriate change management practices to ensure that the flexibility and responsiveness that make agile effective on a team level can be sustained on a much larger scale.

  • Duration: 16h
  • Delivery: Remote / Face-to-face
  • Certifications: CAS-S1 Certification (Scrum Alliance)

Overview

In CAS-S1 you will learn different approaches that need to be taken when working agile with multiple teams. Unlike prescriptive scaling frameworks, the course will equip you with the skills and knowledge to identify principle-informed patterns that apply to your organization’s unique and evolving context.

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 endeavor 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 a CAS-S1 Scaling certification.

Who should attend CAS-Scaling 1?

This course is ideal for change agents—managers, executives, coaches, and anyone participating in scaling within an organization who needs adaptable guidance and a tailored approach to the core aspects of scaling.

The CAS-S1 course is right for:

  • Managers guiding the change
  • Executives who believe in the change
  • Agilists who embody the change

You can supercharge your skills even if you’re in the middle of an evolving scaling transformation or have never attempted scaling. This course is designed to meet you and your organization wherever you are in your journey to expand the benefits of agile teams.

Training topics

  • What is Scaling and Why is it Necessary?
  • Approaches to Scaling (Principles-led, Practice-led, Pattern-led)
  • Principles of Organic Scaling
  • Introduction to Complexity and System Thinking
  • Value Delivery and Unnecessary Synchronizations
  • Organizational Culture and Decentralized Control
  • Scaling Patterns
  • Change Management in Scaling
  • The Role of Agile Coaches in Scaling
  • Scaling Case Study Deconstruction

Included in the training

  • Certificate for Certified Agile Skills – Scaling (CAS-S1) + two-year membership to the Scrum Alliance
  • Slack channel to continue collaborating with your classmates after the class and access trainers to ask questions
  • Option to join the agile42 Community and get access to a number of free learning resources, like books, articles and videos
  • Life-long warranty on the course: e-mail access to the trainers

Why train with agile42?

  • Experience: Over the years, agile42 has delivered Scrum & Agile training to thousands of professionals worldwide. Our instructors have decades of experience using and coaching Scrum in hundreds of organizations large and small.
  • Excellent ratings: We consistently receive excellent ratings from our participants. 
  • Techniques: In all of our classes, we use techniques from Accelerated Learning and in particular principles and concepts from Training from the Back of the Room.
  • Engaging: Our courses are highly interactive and fun – not a PowerPoint assault, and our participants stay engaged throughout the class, learn by doing, and have fun along the way. When learners talk and teach, they learn. – Sharon Bowman
  • Practical and Memorable: Participants learn through hands-on exercises, creating high knowledge retention.
  • Sustainable: We are contributing to a greener planet by decreasing our carbon footprint by not having people travel to the venue, and less paper usage in terms of flipcharts and post-it notes.
 
Mitchell F., Program Management Consultant

Your virtual environment

In order to ensure a collaborative, engaging and fun environment even virtually, we are going to use a number of digital platforms.

  1. We will use Zoom as a video conferencing platform. You can access Zoom through your browser or download the desktop application. We recommend you access through a PC/laptop with a webcam and mic or headphones.
  2. We will use Slack as an additional messaging channel. You will get an invitation to our class Slack channel. If you do not have a Slack account, please go to https://slack.com and create one using the same mail address you used to register to the training. If you already have a Slack account with another email address and you want to use that one, let us know.
  3. We will use Miro https://miro.com as an online whiteboard for digital collaboration. You will soon also get an invite to access the platform. The access is included in the training fee you paid, so it will be free of charge for the 2 days of the training.

You will receive further information and specific instructions before the training.

 
Michael M., Senior Project Manager

Upcoming training