You are hereFeed aggregator

Feed aggregator

How Scrum Created the Greatest Team in the World

All About Agile - Thu, 11/19/2015 - 11:58

The Scrum approach to delivery has produced the greatest team in the world. And the elements behind the team’s success are repeatable, meaning your team could be next in becoming the greatest team in the world. (That sure has a nice ring to it.)


View image |


The team I’m talking about is the All Blacks, which retained its Rugby World Cup crown recently—the first team to do so since the tournament started almost 30 years ago. If you’re not familiar with the All Blacks, in the past four years, the team has only lost three of its 54 matches and the last time it lost consecutive games was in 2011. In fact, the All Blacks hasn’t lost on its home turf since 1994, before some of the current players were born. Yet their captain is from tiny Kurow, New Zealand (population 339), the coach is a former policeman and none of the players has the letters MBA after their names or got on the team through family connections. The team also comes from a country with a much smaller population and lower GDP than its next few rivals, so they’re not the biggest or the richest.

How does a country with more sheep than people produce a team recognized as the world’s greatest, and what does this have to do with Scrum?

Indeed, why are we referencing a sports team when most of us work in teams in urban offices where we chase paper and deadlines rather than an oval-shaped ball? Because high-performing teams, no matter what their domain, share many commonalities. And it’s a happy coincidence that the All Blacks practice the sport that gave the Scrum approach to product delivery its name.  (Very briefly, for those who have just joined us, two Japanese researchers of high-performing teams in 1980s workplaces came up with the term “Scrum” as a good fit for the characteristics associated with high performance, including speed, flexibility and handling uncertainty.)  

Let’s examine a few of the characteristics of the greatest team in the world to better understand how our own teams can become ultra high-performing. Given that rugby in New Zealand/Aotearoa is our metaphor here for high performance, I’ll be introducing a few new words into your vocabulary.

Principle 1:  Be Your Role

People on high-performing teams know their roles inside-out. Knowing your role doesn’t just relate to the bullet points in your job description: It means intrinsically knowing how your skills influence your teammates and how you collectively use these skills to succeed.


View image |


For All Blacks captain Richie McCaw, who has an impressive win rate of around 90 percent from his 140 caps, this meant sitting down with his uncle when he was a teenager and identifying on a scrap of paper what he needed to do to become a “G.A.B.”—a Great All Black—then taping it to his bathroom mirror so he could see it every day. In other words, visual management. Sound familiar?  In your team, what’s the difference between a developer and a great developer, or a product owner and a great product owner? What about for your own role? Probably not characteristics that are bulleted in your job description.

Knowing your role means sticking to the basics, even when things are difficult, and trusting your team to do the same. For example, if you’re leading 8–7 in a tense final against your bogey team (France) you should focus on solidly executing the fundamentals, again and again. Nothing fancy, just K.I.S.S. This is where your 10,000 hours of purposeful practice pays off. Several past and present All Blacks sprint fast enough to compete in the early rounds of the Olympics 100 meters event. They’ve completed years of purposeful practice in order to deliver effectively under pressure.  Keep executing the drills you have practiced in training. Don’t skip your planning sessions or retrospectives because “you’re too busy” or “there’s a deadline.”

Once you know your role, the next step is to elevate it, redefine it and be your role.  For example, number 10 for the All Blacks, Dan Carter, has arguably redefined the role of first-five eighth (relax, that’s as technical as we’ll get with rugby).  In Japanese martial arts, this aligns to the concept of shu-ha-ri.  While many of his contemporaries are content to score points through kicking, Carter is sufficiently cross-functional to play well outside his role and carry the ball across the line, rather than pass it to another player.  Given that several players oin the All Blacks are similarly cross-functional, that makes for a powerful advantage over mono-functional teams. We’ll cover this more in the next section.

Principle 2:  Be Cross-functional

Fundamental to Scrum is the cross-functional team, which means there are multiple paths for work to reach the “done” state. This complements, rather than contradicts, the principle of knowing your role. On a rugby team there are 15 players, each with a specific role. However, a player’s role is superseded by the team’s overall goal of delivering the ball across the try line (or goal posts). This means that a player like Dan Carter, whose primary role is to score points through kicking, has also scored 29 tries (similar to a touchdown) in international rugby because he is T-shaped. Unlike many of his rivals, his jersey is just as dirty at the end of the game as the rest of the team.


View image |


When we talk about “T-shaped people” in agile it means people whose deep technical knowledge is complemented by a breadth of skills. This counters situations where a person becomes a single point of failure or a bottleneck, as is so well demonstrated in the agile cult classic book, The Phoenix Project. Teams in the workplace can incrementally increase their cross-functionality over time by creating a simple skills matrix and allocating a few hours per week to upskilling. After three to six months, the team will be quantifiably stronger and have reduced its dependence on a single individual.

As a team member your versatility makes you more valuable to the organization, and that’s something to bear in mind for challenging times.

Cross-functionality goes hand in hand with diversity and high performance. The All Blacks are arguably the most diverse team at the Rugby World Cup, and it’s no accident that in recent decades, as the team has embraced more diversity, it has won more games. Players come from several different cultural, religious and linguistic backgrounds. Harnessed to a strong vision (discussed in the next section), this diversity creates open-mindedness around trying new ideas and synergies that enable team members to be authentic and bring their whole selves to the team. Research confirms this leads to increased creativity, better decisions and harder-working teams.

Your team may be more diverse than you realize. Many workplaces lose their human touch and it’s easy to get caught up in “doing” our work at the expense of building high-performing teams and getting to know the person behind the job title. A half-day investment in effective team-building activities a couple of times per year (which needn’t involve blindfolds, high wires or singing Kumbaya) will pay dividends, create “ba” and directly improve team performance.

Principle 3:  Be United Around a Vision

“We are the most dominant team in the history of the world.” Pretty audacious, huh? Perhaps not.  The All Blacks created this vision before other teams started calling them “the world’s greatest team.” However audacious it is, it would be much harder to become the world’s most dominant team with a watered-down vision that exudes mediocrity, or with no vision at all. There’s no doubt about what this team wants to achieve. So, back to our teams in the workplace: what’s your team’s vision?


View image |


We’ve already talked about being your role and being cross-functional. Perhaps it’s no surprise how well the All Blacks embody teamwork and uniting around a collective vision, given the strong influence of Maori and Polynesian cultures on the team. As the cliche goes, “there is no “I” in team.”

Just as Japanese culture embodies Lean principles, Maori and Polynesian cultures elevate the importance of the team (or family, collective or other group of people) over the importance of the individual. Western cultures, by contrast, often elevate the individual over the team (e.g. individual performance targets) which can lead to local optimization at the expense of the overall system’s performance. Focusing on team performance as the unit of success has a dramatic impact on how the team plays.  

Scrum and SAFe® require a sprint goal and product vision, respectively. Build on that in your workplace and establish a vision for your team. What are its values, goals and outcomes? This fosters a team that is united, focused and aligned, rather than a group of people who “happen” to work together.

Next Steps

Several All Blacks are expected to retire in the coming months. The good news is that there’s now an opportunity for another team to be the world’s greatest. Maybe it will be a team in your organization. How can you elevate your team’s performance so it exhibits the same traits as the world’s greatest team?

  1. Help your team move from doing their role to being their role
  2. Make cross-functionality and T-shaped team members the norm through purposeful practice
  3. Create a compelling vision with your team that encourages high performance

There’s a Maori phrase that concisely sums up these themes:

Ko ahau te kapa, ko te kapa ahau – I am the team and the team is me." Suzanne Nottage

Agile Project Management in a Larger Organisation – Video of my talk

All About Agile - Wed, 11/18/2015 - 05:46

I was recently asked to do a short talk and Q&A for an agile project management meetup in London. You can see the full video here: Lots of great questions, so hope this gives you some useful insight that helps you with your own work. Kelly.

The Scrum Master and Product Owner as leadership partners

All About Agile - Wed, 11/11/2015 - 00:37

Learn more about transforming people, process and culture with the Real Agility ProgramAfter a recent large organizational change that resulted in a number of new teams formed, a product owner (PO) approached me looking for some help. He said, “I don’t think my new Scrum Master is doing their job and I’m now carrying the … Continue reading The Scrum Master and Product Owner as leadership partners →

The post The Scrum Master and Product Owner as leadership partners appeared first on Agile Advice.

Taking Organizational Improvement Seriously – Case Study

All About Agile - Mon, 11/09/2015 - 09:12

(Presented as an accompanying case study to Part 4 in the Scrum Alone is Not Enough series.) In the previous post, we discussed how it’s not enough to practice Scrum at the Team level and expect that it will solve all problems. Senior Management has to get involved for real Agile change to happen and high performance to be achieved. An important aspect of that is Systemic Problem Solving, which we’ll look at closer using the World’s Smallest Online Bookstore as a case study for examples. Systemic Problem Solving Most teams that I encounter are very good at solving specific problems locally (at the team level). What is missing is a bigger picture, holistic view. Systems thinking (pdf) is a tool that helps you take a Systemic – or bigger picture – view of whole systems. Let’s look at a couple of common organization problems as examples – namely “Long Regression Cycles” and “Product Owner can’t seem to stay focused on the big picture”. Long Regression Cycles Hereafter: LongRegressionCycle The Org Team recognizes that it has a problem with the regression cycles as illustrated: When long regression cycles are an issue, without a systemic approach the organization might first try adding more people to do regression testing. As a second step, they might try automated testing through the browser/GUI using a special team who has access to an expensive tool. Unfortunately, as we see below, this will likely lead us down the wrong path: This is a simple causal loop diagram –it’s intended to help us look past the initial problem and see deeper causes. Variables create cause and effect within a system. In a causal loop diagram, you start with a single part of the system that you can already identify and just keep asking “what influences this part?” then draw links between the interconnected parts using arrows pointing in the direction of influence. Once you can no longer think of additional parts or influences to add, you have a closed loop. In this example, we can envision what may happen by playing through the loop, starting at “Features added” and following its influence to the “Regression Cycle Length”. Keep going, and we can see that the often-used simple fix of asking a special team to automate regression tests through the Browser/GUI influences many variables and eventually exacerbates the problem that it was intended to solve. The diagram makes it clear that GUI based automation is fragile, and having all the work done by a special team is creating an island of knowledge. These two problems combine, increasing the time it takes to find bugs and eventually even increases the number of bugs themselves. To solve the underlying initial problem, we would have to also find an approach that doesn’t recreate these same issues! Instead of a special team doing all of the test automation, the work should be done by every team. Instead of doing all the automation through the browser, do most of it through public api’s (or their equivalent) that exist at the boundaries of the system. Before making any change, the team creates a new version of the causal loop diagram to see if their proposed solution is an improvement on the original. Product Owner Can’t Stay Focused on the Big Picture Hereafter: UnfocusedProductOwner In a second example, the Team sees a Product Owner making frequent revisions to the Team’s work in Sprint. We can talk to the PO about this, but we can’t just expect the PO to change unless we also identify and fix the underlying problem. As this image illustrates, we can see that the real problem is that the PO is under daily pressure from stakeholders to solve real and perceived customer problems. The challenge is how to set aside enough time to deal with those issues, while still making progress in the bigger goal. A causal loop diagram like this should help the organization discover the need for Portfolio Management, which would give the Product Owner some boundaries on how much short term work they should accept from the Team. In each case, the key point is that the Org Improvement Team must make sure that they’re solving the systemic – and not just surface – problem. So let’s look at how the World’s Smallest Online Bookstore teams might do that, using a Scrum-like framework to achieve it. Our World’s Smallest Online Bookstore Organizational Improvement Team is working in two-week Sprints to stay in sync with their Development Teams. As we learned in this post, the Org Improvement Team operates in a manner similar to a regular Scrum Team, just with a few slightly relabeled components. Let’s see how the Organizational Improvement Team will tackle these problems. Organizational Improvement Queue (aka Product Backlog) Since the causal loop diagrams above showed us that creating special teams for test automation and simply asking the Product Owner to change weren’t going to solve the problems. The Org Team can avoid wasting time on ineffective, localized solutions and focus the Improvement Queue on finding specific things that will contribute positive systemic results. Such as: LongRegressionCycle – Involve more members of each Development Team in test automation; LongRegressionCycle -Find alternate means to test automation that don’t involve the browser; UnfocusedProductOwner – Support the Product Owners in saying no to more expedited customer requests… Organizational Queue Refinement (aka Product Backlog Refinement) After discussion with the Development Team representatives and the Team level Product Owners, it is agreed that the pressure that the POs feel to respond to all customer issues within two days is getting in the way of the Teams delivering on both quality (which leads to more customer issues) and the big picture. They also identify the need for site license JetBrains IntelliJ and “Reducing Product Build Times from 15 minutes to 5 minutes”. Sprint Planning The Org Improvement Team commit to running several experiments to resolve the UnfocusedProductOwner challenge. Since this problem will need several months to address completely, they decide to do the following: […]

It’s a Trap! Agile Lessons from Star Wars

All About Agile - Fri, 10/30/2015 - 09:00

Recently I experienced what was one of the saddest moments of my career when, while re-watching “Return of the Jedi” for the 116th time, I realized I was coaching a company that was basically the Empire.

Surely you remember the movie's very first scene? Darth Vader arrives on the Death Star to help put the long-delayed project back on schedule.

Here’s the conversation that ensues between the commander, our de facto Death Star project manager, and Vader, our business stakeholder. Swap out the titles and you can almost imagine it taking place in a conference room in a company not so far, far away.

Commander: “I assure you Lord Vader, my men are working as fast as they can.”

Vader: “Perhaps I can find new ways to motivate them.”

Commander: “I tell you that this station will be operational as planned.”

Vader: “The Emperor does not share your optimistic appraisal of the situation.”

Commander: “But he asks the impossible … I need more men.”

Vader: “Then perhaps you can tell him when he arrives.”

Commander: “The Emperor’s coming here?”

Vader: "That is correct, Commander. And he is most displeased with your apparent lack of progress.”

Commander: “We shall double our efforts!”

Vader: “I hope so, Commander, for your sake. The Emperor is not as forgiving as I am.”

You know you’re in trouble when Lord Vader suggests he’s the more forgiving of your bosses!

If you’re the commander, then, at this point, you are very worried. Because you already know you don’t have the people to succeed. (You may think throwing “more men” at the problem will make it go away, but Brooks’ Mythical Man Month tells us that adding manpower to a late complex engineering project only makes it later.)

And you know that if you fail, you’ll get force choked.

Fail with a Culture of Fear

This is what you call a culture of fear. It pains me to see this in my coaching, because the problem with a culture of fear isn’t just that it doesn’t work. Nothing shuts down innovation, motivation and collaboration faster than a fear-based culture.

Fear can be persuasive in the short term, but with this tactic you’re going to lose a lot of people over the long term. People will make promises they can’t keep and say things are going well, even when they aren't, to avoid punishment. Fear will exacerbate work delays as people obscure the true status of the work, and, more importantly, it will result in a loss of your workers as they get force choked out of the organization.

Dan Pink has pointed out that extrinsic carrot-and-stick motivation was designed for 20th-century work. In the 21st century, people feel trapped by organizations that use this approach: people often know the best thing to do to get the work done, but they don’t feel empowered to do it because they’re stuck in this systematized culture of fear. 

Empower Your Teams

In a culture of fear, teams don’t feel empowered. Slap their hands a few times and they’ll stop trying. Eventually you’ll end up with a team that waits for directions, that waits for someone else to make decisions for them rather than moving forward. As the president of 3M said,

If you put fences around people, you get sheep.

From a manager’s point of view, this can actually seem more frustrating than it does compliant. I’ve heard managers complain that “my team won’t do anything unless I tell them to do it,” without acknowledging (ironically) that they’ve created this culture by not trusting their teams, or by punishing them for straying outside the fences.

We often think of the military as the epitome of command-and-control management, but in reality even the military recognizes the importance of decentralized decision-making. A military commander might radio his troops and tell them to “take the hill,” but he doesn’t need to tell them HOW to take the hill: he lets THEM decide the best way to do it, based on local information and the situation on the ground. In a fear-based culture, if you tell your team to take the hill, they may very well stand still and say, “How?”

Adapt to Take Out the Death Star

Think about a boss in your life with whom you worked really well. I bet that person had trust and faith in you to get your job done, and had your back if you needed help.

Now think about the Battle of Endor, toward the end of “Return of the Jedi.” Admiral Ackbar has assembled the entire rebel alliance fleet and they’re approaching the Death Star, intending to take it out and save the galaxy. But as they get closer they realize that the Death Star’s shield hasn’t yet been deactivated by the team on the ground with Han Solo and Princess Leia. Then they see the fleet of imperial star destroyers.

At first Ackbar wants to retreat, but Lando Calrissian lobbies him to change tactics—engage the star destroyers in battle, despite being outnumbered, so that Han and Leia have more time to work on the shield. [SPOILER ALERT] Ackbar assents: the fleet spends a little time picking off tie fighters and star destroyers, Solo and Leia get the shield down, and Lando and Wedge Antilles successfully destroy the Death Star. Yee ha!

To accomplish an epic feat like this you’ve got to collaborate, communicate, respond to feedback and trust your colleagues to do their jobs.

Would Vader have listened to advice, like Ackbar did? Would the Emperor have trusted his team on the ground to pull through, even though they were late? Heck, would you dare to give either one of them feedback on their plan, in the heat of battle? I didn’t think so.

But let’s be honest: not every project is the Death Star. In fact, to act like every project is mission-critical is disingenuous—not to mention demoralizing. And when you do have that project that feels like life or death, everyone already knows: you should all be in alignment already, with everyone on board, eager to work together to get the job done.

Mind the Trap

Ackbar was right to call out the trap. Your trap is thinking that you can have control over everything, and thinking that having control would improve your circumstances. In truth, especially at large organizations, you can’t possibly see everything that’s coming—much less control it.

Agile organizations avoid the trap by reflexively responding to change, delegating decision-making closer to the ground, improving their visibility into the work and making adjustments based on feedback.

To become an agile organization, you have to start by changing your leadership style. Managers: you can coach all you want at the team level, but if your executives still go around acting like Emperor Palpatine, you’ll end up with no change to the business and no improvement in your results.

You also have to change your system. Sure, everyone may have a little dark side in them, but most people aren’t genuinely evil—they’re just a product of the system they’re in. In the same way that carrot-and-stick systems aren’t good motivators for today’s style of work, fear-based systems don’t produce positive long-term results. Change the system, however, and you’ll change the behaviors of the people in that system. Take it from a scoundrel like Han Solo, who, adopted into a system of people collaborating for a better universe, turned himself into a hero.

 (image: Flickr, CC)

Use the Force

We know that fear is the path to the dark side. Yoda tells us that fear leads to anger, anger leads to hate, and hate leads to … suffering. Let’s put an end to cultures of fear and suffering! It’s no way to work, and besides, it’s not going to get your organization where it wants to go. (Unless you want your competition to fly into your core reactor and blow you to smithereens.)

Do not give in to the dark side! You have the power at your disposal to change. Before “The Force Awakens” later this year, I hope you’ll join me on a journey towards greater business agility.

Todd Sheridan

What’s the Pulse of Our Enterprise Transformation? – Part 3 on Transformation Scorecards

All About Agile - Tue, 10/27/2015 - 09:31

I think this is the last post in my series on using metrics to gauge the success of an enterprise transformation.  As an enterprise transformation consultant, one of the key challenges I face is ensuring the steps I recommend throughout the transformation will help the organization achieve their goal, or the business drivers that inspired the transformation. In part […]

The post What’s the Pulse of Our Enterprise Transformation? – Part 3 on Transformation Scorecards appeared first on LeadingAgile.

HBR:: Why Organizations Don’t Learn

All About Agile - Mon, 10/26/2015 - 14:46

A nice article on HBR - "Why Organizations Don't Learn", byFrancesca Gino and Bradley Staats; take a look.They list these reasons:Fear of failureFixed mindsetOver reliance on past performanceAttribution biasThe authors then give some strategies fo...

Red, Yellow, Green or RYG/RAG Reports: How They Hide the Truth

All About Agile - Mon, 10/26/2015 - 08:28

What is Red Yellow Green? Red-Yellow-Green (or Red/Amber/Green) is a status reporting mechanism used to help executives understand the current state of a project. Green means everything is good; we’re on track both with time and budget. In some cases, green means within 5% of budget. Yellow means there is some risk that there are scope or time problems, but with sufficient re-planning we can come back to target. Yellow is usually measured by some number crossing a predetermined threshold. Red indicates the project is in serious trouble. Models RYG is just a model of reality (in truth, all reporting simply models reality). All models hide details with the goal of making the situation easier to read and understand. Some are hidden so much that the truth gets lost. A team’s Task Board, Scrum Wall, or the overall Portfolio Kanban Wall are all first-order models of reality. While not perfect mirrors of the current state of the work, they’re fairly close. They help demonstrate qualitative information; i.e. which stories are complete, not just how much. A Release Burndown Chart, Burnup Chart or Cumulative Flow Diagram are all second-order models of reality. In other words, they summarize information contained on the Walls/Task Boards. They’re useful because they help spot trends. The Cumulative Flow Diagram provides the most information on trends, but it still has less information on it than the Portfolio Kanban. Red Yellow Green Reports are models of the charts, in that they summarize the charts, hiding even more informational details. They assume that a plan’s scope, budget, and time are fixed and unchanging. Models might be adequate in a world where these are true, but in a world that accepts change as the norm, colour-coded reports are dangerous. At best, these reports don’t measure truly done so much as whether a team is on track to make a target. In addition, since RYG reports usually have green as a default state, often there are too few questions that are asked until it’s too late. Charts Even burndowns, burnups, and cumulative flow diagrams are imperfect because they focus on output (# of Stories or story points achieved) and not outcomes (the right features delivered to the customer.) Charts of all forms appear to promise certainty, when there isn’t any, which creates a false sense of security. If we’re going to chart at all, we should use forecasts and not precise lines, and make it clear this a forecast. If your chart just shows the average velocity, then you should provide a forecast that says we have a 50% chance of achieving this rate for the foreseeable future. If you want to get more sophisticated, you can track error bars as well. Measure your best and worst three Sprint’s Velocity in the last six months, and use these as your 20% and 80% confidence bars. Then you can say that you’re 80% confident you will do at least as well as your worst three sprints, and 20% confident that you will do as well as your best three sprints. Even this model has a weakness in that it assumes your velocity will follow normal distributions. The reality is likely that it won’t. However, forecasting with error bars (or lines) usually gets the idea across that we’re forecasting a range of possible outcomes. Genchi Genbutsu Finally, all reports discourage people from leaving their offices. They give us the false feeling of safety. The report seems real and so it gives a good model of what is actually happening. Toyota has the practice of Genchi Genbutsu – go and see, literally. Review the charts but then leave your office and go to the place of the work. Watch, listen, ask, and review the Portfolio Kanban wall with the team(s). This will bring you back in contact with the reality of which features have been truly done. This will help you see if all the Story Points in the charts delivered the value that they claimed. Stop/Do So stop using RYG reports. They hide too much information. Do use Burndowns/Burnups/Cumulative Flow diagrams as a tool to help you spot trends, but don’t rely on them alone as the source of truth. And most importantly, review the Portfolio Kanban Wall with the Team(s) on a regular basis, as this is our best measure of reality. Other have taken up on it as well:

Link: It’s Time to Kill Performance Reviews

All About Agile - Tue, 10/20/2015 - 13:22

Learn more about transforming people, process and culture with the Real Agility ProgramFor many years, folks in the Agile community have been recommending that performance reviews be eliminated from the corporate world.  In 2005 while coaching at Capital One, I remember many discussions on the awfulness of performance reviews.  This was really my first understanding … Continue reading Link: It’s Time to Kill Performance Reviews →

The post Link: It’s Time to Kill Performance Reviews appeared first on Agile Advice.

Remote versus Co-located Work

All About Agile - Mon, 10/19/2015 - 08:37

In the software industry we hear a lot of discussion about the pros and cons of remote work, and a recent outbreak of that finally got me to write my thoughts down. I point out that there's distinct patterns of remoteness, which yi...

Agile Talent Management

All About Agile - Wed, 10/14/2015 - 19:27

Talent Management is the science of human resource planning to improve business value. It includes the activities of recruiting, retaining, developing and rewarding people along with workforce planning. From an agile perspective much of what we do on agile projects...

Assessing Team Improvement

All About Agile - Mon, 10/05/2015 - 11:44

I understand that managers who have invested effort and money in training teams in Agile methods may want to see how much those teams are improving.  There are a handful of reasonable measures to look at to see whether the organization is improving over all (which I’ve written about here and here). You can apply some … Continue reading Assessing Team Improvement →

Busting 6 Common Myths About Agile

All About Agile - Tue, 09/29/2015 - 14:56

As agile has grown in popularity, so have the misconceptions about it. In a recent introduction to agile webinar we asked our audience which of these common myths they’d encountered — here’s what they said:

Do any of these look familiar to you? Let’s dive into these a bit and separate truth from fiction.

Agile = Scrum

Quick: what’s the first thing you think of when you hear the word agile? For many of us it’s a “standup” meeting. Or maybe it’s creating a “backlog” of user stories that get delivered in a two-week “sprint.” Fact is, these are all elements of Scrum, a popular project management methodology used by many agile teams. So Scrum is a framework for developing and managing work, while agile is an umbrella term for approaches like Scrum that share a common set of principles — but this isn’t about the semantics.

Scrum is just one of many methodologies that build on agile principles (others include Lean, Kanban, Test-driven Development, and Xtreme Programming). Simply “doing Scrum” doesn’t make you agile.

To “be agile” means focusing on customer value and quality, delivering value incrementally, limiting work in process (WiP), enabling cross-functional collaboration, and striving to continuously improve. When agile fails to take hold or improve results within organizations, as Rally VP of Product (and former coach) Ryan Polk has discussed, it’s often because it only lives in pockets at the team level or because it’s executed poorly. Sure, scaling agile more broadly means mastering the fundamentals of Scrum, but it also means adopting an agile mindset in how your teams, programs and departments work together and communicate with each other.

If you haven’t already read the Agile Manifesto and its 12 principles, and thought about what “being agile” (not just “doing agile”) would look like in your own organization, there’s no time like the present.

Agile Means “We Don’t Have a Plan”

Equating agile with a lack of planning is one of the more insidious agile myths. We know its likely origins: the misguided observation that agile at the developer level seems allergic to functional specs, and the belief that adapting to change means abandoning whatever plan you did have.

Well, maybe you’ve seen the iconic “planning onion” before?  

While it’s true that agile approaches trade the lengthy, upfront planning process for a more adaptive, iterative process, planning is a very important agile tenet. It’s just that instead of making one grand plan, once a year, and hoping that it’s still on target six months later, you’re dividing your planning (like the work) into smaller chunks and committing to reviewing your plans on a regular basis. Why is it better to plan, and then plan to re-plan?

  • Short-range planning helps you control WiP, which means you can deliver more value, faster.
  • Midrange planning helps you communicate, make visible, and prioritize the most important work, ensuring small iterations add up to high-value increments.
  • Long-range planning lets you take the feedback from your incremental delivery and use it to steer the business in the right direction.
Agile Doesn’t Need Project Managers

This might be one of the most fear-provoking misconceptions about agile — at least if you’re a project manager in a non-agile environment — and it reflects a fundamental misunderstanding about the roles on agile teams, which skills are most valued, and the fact that changing your collaboration dynamic can make people work more efficiently, happily, and productively.

The truth is that agile needs project managers — but it’s likely you won’t be called a project manager (you’ll probably have a title like Scrum Master or Product Owner), and it won’t be your job to tell people what to do or when to do it. That’s because agile approaches value self-managing teams — whose success relies on collaboration, localized decision making, regular communication, and tools for visualizing and sharing WiP.

For example: are you good at working with stakeholders, managing expectations, and balancing competing priorities? Do you have a strong sense for business value? Are you comfortable driving vision and strategic direction, while collaborating with a team to make day-to-day tactical decisions? Then you might be a good Product Owner. Do you understand people – their motivations, fears and desires — and group dynamics (what makes a team better than the sum of its members)? Do you enjoy problem solving for people so they can do their best work? Then you might be a good Scrum Master. (Learn more about how traditional project management maps to agile project management.)

Multiple analyst firms predict that agile approaches will dominate other methodologies in the coming years, and software-driven innovation means agile is gaining a foothold across nearly every industry. The Project Management Institute has found that the use of agile methodologies is up 27 percent from just two years ago, and a PricewaterhouseCoopers survey found that nearly two-thirds of these agile projects are managed by certified agile practitioners. And even though it’s a bit of a misnomer often used by companies transitioning to agile from waterfall practices, search for “agile project manager” on and you’ll see that this is an in-demand role.

Agile Doesn’t Believe in Documentation

It’s true that the Agile Manifesto values "working software over comprehensive documentation." However, this doesn’t mean documentation has no place in agile approaches. It’s just that instead of assuming a project and its associated processes require comprehensive documentation, you should undertake and design project artifacts because they provide value. Rather than drafting pages and pages of requirements and use cases and process rules, for example, think about the minimum viable information that needs to be captured, with whom it needs to be shared, how to document it in a collaborative way, and how that documentation might help you continuously improve.

Think about the roles on a delivery team — how people spend their time and how the tasks they perform correlate to a project’s success — and you’ll probably conclude that success maps directly to the time spent designing, building, testing, and shipping … not the time spent documenting all those processes.

Some roles will rely more heavily on documentation than others: for example, our UX designers do a lot of ethnographic research and customer interviews before they work with teams to design and build features, and their results need to be codified and shared. And when we do sprint or planning meeting retrospectives, we like to document what we liked, learned, lacked, and longed for, because capturing that information helps us improve over the next cycle. The point is that documentation isn’t the point in agile; it’s a byproduct of the actual work, and like the work, it should be designed to deliver value.

Agile Only Works for Developers / Software

Agile may have started out in the technology realm, but like any set of effective practices, it has evolved and taken hold across a much broader audience. From finance and healthcare to communications and manufacturing, non-software companies — now finding themselves driven by software — are using agile approaches to improve their delivery, customer experience, and innovation. Organizations buoyed by the success of agile in their IT or engineering groups also have invested in extending agile principles and approaches into the executive suite.

Agile principles are now being applied to marketing, legal and human resources departments, and McKinsey recommends that companies should borrow agile approaches from their IT departments to build agility into their company DNA. No matter your organization type or your current way of working, wouldn’t you like to be faster and more transparent? Wouldn’t it be great to know that you’re delivering what customers really want? Don’t you want to know that you’re doing the highest-priority work and that you can reprioritize when your competitive, economic, or strategic landscape changes? Agile companies do this.

Agile Will Fix All Our Problems

You know better than to fall for this one, don’t you? No one thing is going to fix ALL your problems. When leaders have problems that need fixing, however, they tend to search for a silver bullet. But pinning all your hopes on a “magical methodology” is going doom you to disappointment. Just as doing standups or buying an agile tool doesn’t make you agile, integrating agile practices into your IT group isn’t, by itself, going to turn your enterprise company into a nimble startup.

If you think of your company as having a fitness goal, then adopting agile approaches is like a workout. Exercising your agile muscles takes discipline and commitment, and if you do it on a regular basis, it can make you much stronger. But to meet your larger fitness goal you also need to change other habits: let’s say, eat well and get enough sleep. And your agile muscles become even more powerful and effective with supportive infrastructure — like the right training, a commitment to change, and engaged leadership.

Bust Your Own Myths

If you’ve encountered any of these myths about agile, it might be time to brush up on what you think you know. We’ve put together some resources for you to do this easily on our Discover Agile Toolkit page. Learn how to make the business case for agile in your organization, hone your agile practices, get the scoop on role-based training, and take agile to the next level. Or check out the Discover Agile webinar recording to get an introduction to agile, Scrum, and the ROI you can expect at your organization.

Jenny Slade

Dependencies Are Evil

All About Agile - Tue, 09/22/2015 - 05:00

It seems inarguable to me that dependencies limit agility. If I am able to make a decision on my own that only involves me, I have full freedom of movement. If I want to go to the local pub for dinner, and on my way, decide that I want to go to a steakhouse, I […]

The post Dependencies Are Evil appeared first on LeadingAgile.

The First Critical Steps Toward Scaling Your Software Organization

All About Agile - Mon, 09/21/2015 - 05:00

I’ve noticed a pattern I want to share with you guys. When a company is small, still probably led by it’s founder, likely around 20-40 people… there is a great sense of camaraderie. You’ve got folks that all know each other, all working toward a common goal, all trying to solve the same problems. To a large […]

The post The First Critical Steps Toward Scaling Your Software Organization appeared first on LeadingAgile.

Agile Awards

All About Agile - Wed, 09/09/2015 - 05:37

hi all, I’m nominated for the Agile Awards ‘most popular online contributor’ this year for this blog. If you have found it useful, your vote would be much appreciated: Many thanks! Kelly.

Scrum Alone Is Not Enough – InfoQ and Agile 2015 Interviews

All About Agile - Thu, 08/13/2015 - 14:32

Mark attended Agile2015 in Washington and, as part of his conference commitments, he sat down with ​SolutionsIQ for an Agile Amped podcast about High-Performance Teams, as well as with InfoQ for an on-camera interview to discuss his Scrum Alone Is Not Enough blog series. InfoQ recently interviewed Mark regarding the motivation behind the blog series and how his experience as an Agile expert has formed his viewpoints. You can read the full interview at And you can view the video from the Agile Amped podcast here. We will post links to the InfoQ video interview as it becomes available.

Teams and their proximity to the final user

All About Agile - Wed, 08/12/2015 - 21:12

Learn more about our Scrum and Agile training sessions on WorldMindware.comA great, simple post from Mike Bowler… Time: Teams that are writing code today that will be used by their customers tomorrow are very focused on what the customers actually need. Teams that are writing code today that won’t be seen by a customer for … Continue reading Teams and their proximity to the final user →

The post Teams and their proximity to the final user appeared first on Agile Advice.