If you want to build a product that really excites your customer, then you have to rethink how to work together. Your team will want to adapt to include cutting-edge new features, and immediately respond to customer feedback. That's why many teams are embracing an agile mindset.
In this article, we'll go through how to think like an agile team. You'll see foundational concepts in the agile manifesto, along with common roles and practices. Then we'll go through some exercises to help you improve your team's agility and avoid common obstacles. Agile teams are more predictable, more collaborative, and usually more fun. So let's embrace our new mindset and start learning your agile foundations.
There's an old philosophy joke where two fish are swimming in the ocean. One looks at the other and says, "The water looks pretty cloudy today." The other fish looks back and says, "Yeah, what's water?" I love this joke because it shows that the way we do things often becomes part of our own reality. It's the water we're floating in without even thinking.
We don't question the way we work, instead we think that the way we work is the only way that makes sense. But the way we work reflects a certain mindset. It might seem natural for you to have a set of skills that makes you a specialist. Maybe you're a project manager or a database engineer so you only focus on these skills when you're working. It also might seem natural for you to your work on detailed plans.
Otherwise, you might have costly rework. Yet the water we swim in isn't always so clear. In fact, it might be more efficient to have generalists instead of specialists. Instead of having a few people who really know one area, it might make sense to have everyone know a little bit about everything. It also might make sense to focus on short-term planning. So instead of focusing on eliminating rework, you're actually embracing uncertainty.
Some of these ideas are now more commonly known as the Agile mindset. That's how you should think of it, as a mindset. You're not just focusing on a different way to work. Instead, you're focusing on a different way to think about working. I've seen many organizations that try to use Agile to improve their product delivery. They might rename their project managers into Scrum masters. Maybe they'll break down their requirements into Agile-style user stories. All of these Agile practices are fine, but on their own they're not going to help you reach a higher level of productivity.
To get real benefit from Agile, you have to start by addressing your team's mindset. You have to take a hard look at the reality of how your team works together. It's better to be a team that's terrible at Agile practices but understands the mindset. A truly Agile team should be able to ask tough questions about the way they work and be open to continuous improvement.
If you see Agile as just an updated set of project management tools, then you'll probably be disappointed. You don't want your team to be focused on Agile practices. Instead, you want to be focused on thinking like an Agile team. That's why the first step is to focus on the why. When you look at these Agile practices, don't think about mastering them. Instead, think about the reasoning behind them. Think of it this way. Later you'll learn about the importance of delivering in shorter iterations or what are commonly called sprints. These are typically two weeks long. When you see these, you shouldn't think how you're going to deliver your product in two weeks.
Instead, think about the reasoning behind sprints. Why does shorter sprints improve your team's agility? These questions will help you so much more when you're trying to change your team's mindset. If you're just working the same way but in a shorter timeframe, then you're not going to see much improvement. If you understand why you're doing things differently, then you'll be much better off as an Agile team.
In the past, a lot of times, you could learn everything you needed to know by moving up the corporate ladder. Today, there are many ways that modern product delivery makes that much difficult. So it's important to think of the agile mindset not just as a new thing but as a reaction to difficult challenges with typical product delivery. In the 1990s, many project managers recognized that they needed a way to deliver products in a new way.
What they found is that many of the people working in the organization had changed. These different employees started to specialize and it was difficult to find a generalist who understood all the different specialties. So a database engineer might know a little bit about software development but not enough to manage a team of developers.
This led to a serious challenge in management. It put project managers in a difficult position. They were responsible for delivering the product but had very little knowledge on how to make key technical decisions. Software products had also become much more complicated, so it forced many more people to specialize. It was harder to just be a computer scientist who built an entire product.
Instead, now you had software developers, database engineers, testers, and even infrastructure specialists. Think of it this way. I grew up outside of Accra and when I was a kid, most of what you needed to work in a factory was a lunchpail and a desire to learn. So you might start out as a line worker twisting bolts, then over time you might get promoted to a line manager.
Finally, you might get a job in the office and manage hundreds of employees. By the time you worked in the office, you knew most everything there was to know about building a product. You probably started building them yourself and then worked your way up into management.
The managers then had the knowledge of the workers they managed. Now, compare that to a modern software product manager. Here, you might manage a team with many different specialists, each person probably spent decades building up their own expertise.
There is no way that one project manager could know all the different decisions that it takes to build a software product. They couldn't be a database engineer, software developer, and infrastructure specialist. Even if they did, they'd never be able to keep up with the changing technology. That's because there is a big difference between managing workers in a factory and managing knowledge workers developing software products. Knowledge workers are employed for what they know.
That makes it very difficult to manage them with a traditional hierarchy. You can't direct a team of people who collectively know more about the product than anyone else in management. So you have managers becoming less directive and more supportive. One of the key things that you see with agile teams is this push to be self organized. That's because it's very difficult to manage the team with a top-down approach. So you shouldn't have one manager who's directing the team to deliver the product.
There is no line manager like you have in a factory. Instead, you focus on having collective decision making. This is a very difficult change for most organizations. Many managers like to tell their employees what needs to be done. And then they go off and get it done. They might not be ready for a group of specialized knowledge workers coming up with their own plan on how to deliver the product.
Later, you'll see the importance of this servant leader style management with a role called the scrum master. But this role is just part of a larger trend in self organization. A lot of the agile mindset focuses on giving these knowledge workers the flexibility they need to succeed.
A lot of the ways we work comes out of manufacturing. That makes sense because some of the first projects worked with materials like wood, concrete, and steel. Large companies build cars, roads, and buildings. But when you're working with wood and concrete you have a completely different set of challenges than when you're working with software. You'd never start building a bridge and then change direction midway through the project, but with software that's much more common.
It's easier to reprogram software than it is to rip up steel and crack concrete. But many projects are still governed by the ideas that came out of manufacturing. One of the most common is that there's still a lot of focus on planning out the work.
In fact, you can spend as much time planning as you do building. That's why it's still common to hear managers say, plan the work, then work the plan. That makes a lot of sense if you're building something like a bridge, ship, or a building. Here you want to plan everything that goes into the project before you start. You also want to break up your project into phases.
So first you want to plan your bridge, then finish planning. Then you want to build your bridge, then finish building. Then you want to test your bridge, then finish testing. Each of these phases happens sequentially one after the other. It all makes sense in a world of steel and concrete, but software is much more like science than manufacturing.
When you're developing software you're doing a mixture of building and learning. As much as it's tempting to plan everything out, it's just too difficult to predict all the moving pieces. If you think about even a simple software product, it might depend on an operating system like Microsoft Windows, then it might rely on several different Open Source projects, the development language might change or get updated.
All these different changes are impossible to predict. Most software products have to deal with something called the cone of uncertainty. The best way to think about the cone of uncertainty is to imagine the relationship between time, knowledge, and cost. So think of it this way. I've spent a fair amount of time on the east coast of Ghana. This is one of the states in the Ghana that has to deal with a lot of tropical changes. It's sort of a strange experience to be near a tropical change.
At first, the meteorologists only have a general idea of where the change will land. So they might say, it'll hit landfall anywhere along the east coast. Then as time passes they gain more knowledge about the change, so they can learn which cities to evacuate. Then just before the change hits, they know exactly who will be affected. So the cone of uncertainty is the widest a few days before landfall, then the cone narrows as the meteorologists gain more knowledge and time passes.
The problem is that the meteorologists know the most about the change when it's too late. This is also on of the biggest challenges with delivering software products. You know the most about what it takes to deliver the product only when you're nearly finished. So many of the decisions that you make at the start of your project, will be the ones that need to change.
Unfortunately, as you get closer to the end of your project, it also gets more expensive to make changes. So you need to find the balance between making the minimum amount of decisions to get started, but still give yourself enough flexibility to make changes. This balance between making decisions and having enough flexibility to make changes, is one of the key parts of the agile mindset. That way, you can help make lasting decisions even when you're working within a cone of uncertainty.
To better understand the Agile mindset, you have to start by looking at the manifesto for Agile software development. Or what's commonly called the Agile Manifesto. The Agile Manifesto is a set of statements of four values and 12 principles that are intended to help you embrace an Agile mindset. The first part of the manifesto outlines the values.
It reads, we are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. That is, while there are value on the items on the right, we value the items on the left more.
Notice that these are just the values. The manifesto also includes some principles that we'll go over in another chapter. An Agile team should have a mindset that's consistent with the values and principles in the Agile Manifesto.
So, you can think of this as a guide for how to think about your work. To give you a little background, the manifesto was sketched out in a whiteboard back in February of 2001. It was part of a meeting with 17 middle-aged men in a conference room on the ski slopes in Utah.
These developers wanted to find a new way for large organizations to deliver software. They wanted to start a revolution against their organization's cumbersome development processes. That's why they used language like manifesto and values.
You don't usually hear words like that in business meetings. None of these developers thought that you should give up planning and documentation, they just thought that organizations needed to change their focus. That's why they point out at the end of the manifesto that they put more value on the items on the left than they do value items on the right.
Over the years, the Agile Manifesto has become a battle cry for organizational transformation. The manifesto is typically written on a whiteboard or posted on the wall of an Agile team shared workspace. It's important to keep in mind that these values are just designed to show you the big picture.
Taken at face value, they're not very actionable. Think about if your manager told you one morning that they wanted you to focus on individuals and interactions and less on processes and tools. You probably wouldn't know where to start. Well, that's okay, because the values are not designed to be practical. They're starting points to change the way you think about your work.
Even after several decades, the values in the Agile Manifesto still represent a radical departure from how most organizations operate. Most organizations still prefer long-term plans, and have very cumbersome tools and processes. So, when starting your transformation, take a look back to the manifesto, and see if these changes are consistent with the Agile values.
The four values in the Agile Manifesto were jotted down on the whiteboard during the meeting in Utah. After that meeting the 17 signers of the Agile Manifesto emailed back and forth to interpret these values. They knew that these four values on their own wouldn't be enough to start the revolution.
So over the course of a few months they started to list out 12 guiding principles for the manifesto. These principles are actually much closer to what people think about when they imagine agile development. It's in these principles that you start to see the first rumblings of common agile roles and practices.
Principle two is about welcoming changes when you're working in your cone of uncertainty. Principles three and seven refer to continuous software delivery in weeks as a measure of progress. That's why most agile teams deliver in short iterations called sprints.
Principle four describes how customers should work closely with the development team. Later on you'll see a role called the product owner. This is commonly a customer representative who sits with the team and guides them as they deliver the product.
Principles five and 11 talk about motivated self organized teams. That's why most agile teams are cross functional and self organized. They should be small teams of generalists that work together to deliver the product. That's usually a big change from how most organizations operate.
Most teams have a representative from each of the company's functional areas. So developers would develop software and then testers will test the result. Agile team members usually try to do a little bit of both.
Principle six describes the importance of face to face conversations. That's why many agile teams write user stories instead of writing out long requirements documents. These user stories encourage the team to have many face to face conversations. It's like a sticky note that reminds you to have a future conversation with someone else in the team.
Principles one, eight, nine and 10 start to introduce you to the idea of prioritizing high value work. An agile team will use something like a product backlog. It's here where the product owner will identify what the customer values the most. The product owner will work with the team to simplify this functionality into something that can be delivered in a short sprint.
Finally, principle 12 encourages the team to meet frequently to discuss process improvement. That's why most agile teams have a retrospective. Typically it's at the end of every sprint. This is when the team has a face to face meeting to think of ways to improve their collaboration.
As you can see, these manifesto principles really fill in a lot of what was left to your imagination when you only had four agile values. That's why you should think of the values of the manifesto as big picture ideas. But it's actually the 12 principles of the manifesto that start to lay some of the groundwork for what your team will actually do to deliver great products.
Multitasking is the opposite of focus. You're working on everything at once, hoping to be more efficient. This trend is common in the workplace. Many job descriptions require the skill of multitasking in a fast-paced environment. If you have a set amount of time, and a set amount if tasks, then it just seems to make sense that you'd want to work on them all at the same time. However, multitasking has a hidden cost.
Think of your own experience. Maybe you were writing an office memo, and then suddenly got an email from your supervisor, so you stop writing the memo, and you start reading the email. Then decide to jot out a quick reply. When you went back to the memo, you probably had to take a few moments to review where you left off. Then once you got writing again, there might be another email.
Each time you switch between tasks, you have to do a little bit of thinking to get back on track. Humans have a difficult time switching between work items. The transition period for your brain to go from one task to the next is called context switching. Research who studied this found that if you try to multitask with three or more tasks at the same time, you're spending much more time context switching than finishing the work. That's why one of the very first things you want to think about when you embrace a more agile mindset is to try and limit your team's multitasking.
Instead of working on several different things at once, the entire team will focus on a limited set of high value tasks. This team can then complete the high value work. This helps with one of Agile's guiding principles, continuous delivery in short iterations. These short iterations are commonly called sprints. To deliver the highest value items, each sprint requires focus.
You have to be very careful where the team spends their time. Reducing multitasking is one of the original ideas behind an Agile framework called scrum.
If you're a rugby fan, you're probably familiar with this term. In scrum, all the players work together simultaneously to push the same ball closer to the goal. There's no multitasking, instead, everyone on the team is focused on the one ball. That's the same way all the members of a scrum development team work, simultaneously to complete a small set of tasks. They work together in a short amount of time to move the product closer to the goal. We'll go into scrum more deeply in another chapter, but the key thing to remember is that Agile teams try to do their best to avoid multitasking.
One practice that you'll see in almost every workplace is handing off tasks to different people. This is typically called handoffs for short. What usually happens is that you finish your work and then hand it off to someone else.
So a software developer might finish some code and then hand it off to a tester to test the code. In large organizations, handoffs are so common that most people don't even think about it. It's simply accepted as the way to work. It's like a fish not being aware of the water they're swimming in. But the handoffs can be a very inefficient way to work.
Much like multitasking, there's a lot of overhead. A lot of time gets wasted waiting for someone else to finish their work. One of the challenges with handoffs is it encourages large batches of work to go through the system. This is usually called the queue size. If you have large batches of work going through the system, then people are going to process these batches at different speeds. So it's almost like an expressway where a few lanes of traffic are backed up and others are empty. Some cars would be crawling forward while others would be speeding along. So at some point, everyone's either speeding or crawling.
This relationship between how these batches of work decrease your overall efficiency is not always easy to show. If you can keep your batch sizes smaller, it will make it easier to limit your handoffs. That will keep the traffic on your team running smoothly.
Most of us cling to the notion that if we could just focus on our work in a quiet office all by ourselves we'd be much more productive. The problem is that you're actually right, but most organizations aren't just one individual. You as an individual probably would be much more productive just working on your own tasks. But as a team overall, you'd actually be less productive.
You probably don't believe me, and that's why I love the penny game. To start the game you'll arrange several people around a table. These people represent members of a team or even different functional areas. Each team member has their own batch of work.
To keep things simple, this work is just to flip pennies. Each team member flips pennies two at at time, then passes them to a coworker. To monitor the team's progress you could record how long it takes each person to finish their work and how long it takes for the customer to get their first glance of the product and when it's finished. I usually run the penny game in three rounds.
For this first round, I have each person flip all 10 pennies. Remember that this is how most people prefer to work. They can just focus on all 10 pennies, and when they're done they could hand it off to the next person. This is the equivalent of sitting in your office all day and focusing just on your own work.
You can see that each person is pretty productive. They're finishing their big batches around 10 seconds. But the customer doesn't get their product until 52 seconds. For the second round, the team creates two batches of five pennies. In this smaller batch their coworkers can start working much more quickly. Each team member doesn't have to wait for the full handoff. They can start to work as soon as they receive their first batch. So you can see this is making each individual team member much less productive. The smaller batches are slowing down each person. So now everyone is hovering around 12 seconds. But the customer gets their first batch of work in only 28 seconds. And then the team finishes in 34 seconds.
For the third round, they break their work down into five batches of two pennies. So we're getting rid of these big handoffs and keeping the team from multitasking. Everyone is focused on their own two pennies. It took each team member around 14 seconds to complete the work. Four seconds longer than the batch of 10. But the customer gets to see the work dramatically faster, receiving the first glimpse in only 11 seconds and the entire product in 23 seconds. Half the time of the first round.
During the first round when people could focus on the entire batch, they were individually more productive, but the customer didn't receive the work until much later. So the overall team productivity was quite low. When the work was broken down into smaller batches, each team member took longer to finish their own work, but the team delivered the product in half the time.
So if you're a manager seeing this dip in individual productivity, it can be a real challenge when starting to work as an agile team. But the penny game shows that while individual productivity decreases, the overall productivity of the whole team will increase, and the customer will get their product much more quickly.
The most productive way to work as an agile team is by moving around small batches work and eliminating handoffs even if your own productivity decreases.
One of the key ways that agile teams deliver is that they try to work at a predictable pace. You'll see this in principle eight of the manifesto. Agile processes promote sustainable development. The developers should maintain a constant pace. So the term predictable has been used as shorthand for sustainable and constant.
But what does it mean to deliver predictably?
We've seen in the Penny Game that you can deliver a small stream of work quickly through a system. The key is to make sure that you're breaking down the work into smaller batches.
Typically, an agile team will write user stories to represent this batch of work. Then at the beginning of each sprint, the team will commit to delivering a few of those batches. This is often called the sprint goal. Most agile teams will deliver the work product in a short iteration that's typically called a sprint.
A sprint is usually two weeks long. The reason that most agile teams deliver in sprints is that it's a very well-structured way to deliver products quickly.
Principle three in the Agile Manifesto suggests that you should deliver in a shorter time scale. That means that every two weeks, the customer can expect to receive all of the user stories in the sprint goal. Now, I'm using a lot of terms from Scrum because Scrum is the most popular agile framework.
Later on, we'll show how Scrum is different from the agile mindset. So for now, just remember that you can use many agile practices to predictably deliver small batches of work in a short iteration. Remember that agile teams focus on delivering predictably in a short time frame. They don't rely on long-term plans.
Traditional waterfall project planning uses the opposite process. Traditional projects prioritize creating long-term plans first with project milestones that can be pretty spread out. The customer might have to wait months or even years to get a glimpse at working software.
Agile teams are popular because managers will often prefer predictability over long-term planning. Imagine that you're a CIO for a large software company. You may have managed dozens or even hundreds of large projects. Over time, you'll probably recognize that plans are not guarantees. Many projects are late or go over budget. Some projects are even canceled, which is a huge waste of time and money. So these executives will prefer predictable delivery over a well-planned project.
It's better to see what you're paying for every two weeks than it is to continue funding a project with distant milestones. One thing you might be wondering is how can you deliver a large software product without planning? But you have to remember that planning and delivering are two different things. If most of your long-term plans don't work out, then you should question the value of long-term planning. Besides, agile teams don't eliminate planning. They're just trying to eliminate long-term planning. In fact, agile teams spend a good deal of time planning. They just try to focus on short-term plans every two weeks. So in the end, many executives and customers prefer short-term predictable delivery over long-term plans with an uncertain outcome.
Agile teams should be motivated and self-organized. You see this in principles five and 11 in the agile manifesto. Many organizations have found that the best way to keep teams self-organized is by running them differently from the rest of the organization.
Many organizations are split up into functional areas. These are often called silos because they look like the vertical buildings used to store grain.
In an organization, each of these silos has their own area of responsibility. So you might have a vertical stack for business people, then another for software development, maybe another for quality assurance. Each of these silos will have their own mangers and common practices. That's why a typical team will have representatives from each of these silos. So you might have a business analyst who coordinates with the customer to write the product's requirements. Then you'll have software developers who write the software. Then you'll have testers who'll make sure that the product doesn't have any bugs.
Each of these team members will have their own manager. This manager might pull them from the team to work on another project.
Now remember in the penny game, we talked about how handoffs can slow down your work. So if each team member has their own area of responsibility, then you're encouraging them to create handoffs. Plus, if each person has their own manager, then you're in some danger of being pulled from a team. This will create backups as work waits for the missing team member.
An agile team should be cross-functional. A cross-functional team has each team member working horizontally through these functional areas. That means that you might have software developers that help you write requirements. You might have quality assurance people who are also developing software. Each person focuses on the work and not on their own functional role.
In the penny game, you saw that when everyone works together, you can quickly have work move through the system. It's true that it's much easier to find people who can flip a penny than develop software. So cross-functional teams spend a lot of time cross-training. That means that everyone spends a little time training and learning. It's nearly impossible to have everyone on the team equally skilled in all the functional areas. But agile teams should strive to have everyone good enough to be able to contribute something to every bit of work on the team. If you have work that only one person can complete, then you'll create handoffs and backups. This expert needs to train the other people on the team so you can be sure to continuously deliver at a predictable pace.
User stories are another area that gets a lot of attention. Product owners have anxiety around creating the best possible user stories. This is especially true for product owners who were once business analysts.
A business analyst spends a lot of time writing the clearest possible project requirements. That's because clear requirements will cause less problems down the road. But user stories are completely different. There's a form and format to the stories but this is not nearly as formal as project requirements.
A user story is more like a placeholder for a future conversation. Remember that Agile teams encourage face-to-face communication. They don't rely on documentation. This is the sixth principle and second value in the Agile Manifesto. So user stories aren't about getting the right format, they're much more about having the right conversation. With that being said, there's still a common format for user stories. Typically it's as a user, I want some feature so that I can get some value.
So you might have a user story that says something like, as a restaurant owner, I want to be able to put my menu online so that people will be interested in my restaurant. Remember that the format of the user story forces the product owner to think about customer value. It's the last line in the story. You also might notice that there's nothing here about functionality. The restaurant owner doesn't talk about upload buttons or databases, they just care about the value. In this story they want to encourage people to come to their restaurant. So that means that the product owner should have a future conversation with the team to deliver that value. In scrum this is often called the difference between the what and the how. The product owner worries about what the customer wants and the development team decides how to deliver it.
Now there's nothing in the Agile Manifesto that says the team needs to work off of user stories. There's also nothing in scrum that mentions user stories. The user story is just a popular way for the team to communicate and stay focused on value. The most important thing to remember is that user stories are not just an Agile version of requirements.
I see a lot of product owners get into trouble by taking a requirements document and breaking it down into user stories. Remember that requirements are designed to limit the conversation. A good requirements document will be very clear and tell the developer exactly what to do. User stories are a note to have a future conversation. It isn't designed to show the answers, instead it helps the team ask the right questions. Sometimes Agile teams will come up with a better way to deliver value. One that the customer hadn't even thought about. It's this conversation between the customer and the developers that keeps the team focused on value.
User stories aren't required in Agile but many teams still have them. Your story should contain a clear value statement and it should be written from the perspective of the user. Still when teams are starting out they'll usually have a few common challenges, so let's take a look at our task board. As a restaurant owner, I want to be able to print out, email and text my reservation list so that we know how many people to expect.
This story isn't independent. It has a long list of value statements, so it's really three stories in one. This would make it very difficult to estimate and deliver. So let's take a look at another one. As a customer, I want an email copy of my receipt so that I can have it on my phone.
This story doesn't have a clear value statement. It doesn't say why the customer might value a copy on their phone. So the Agile team won't have the flexibility to find the best way of satisfying the customer. Maybe they want a copy so they can order the same thing next time. Maybe they're keeping track of their expenses.
The team would want to know this value so they can better deliver the product. So let's look at one more. As a developer, I want to design the database tables so that the restaurant owner can add reservation information.
This user story probably came from a requirements document. This is very common if your organization is transitioning from a waterfall. It talks about technical requirements and is not written from the perspective of the customer. It also doesn't encourage a conversation or identify any customer value. Watch out for these common pitfalls when working off your user stories.
Like many things your team will usually get better at writing stories with practice. Work closely with your product owner to make sure they take the time to write clear stories with a simple value statement.
The very first principle in the Agile Manifesto is that our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The key thing to think about with this principle are the words priority and valuable. So what does it mean to prioritize high-value software?
Strangely enough, one of the answers to this question starts in the 19th century with an Italian economist named Vilfredo Pareto. When he was in his garden harvesting peas, he notice that 20% of his pea pods produced 80% of his peas. He was an economist so he compared this ratio to the wealth distribution in Rome. There he saw that 20% of the population owned 80% of the city's land. So this 80/20 ratio is now known as the 8020 rule or the Pareto principle. 80% of the effects comes from 20% of the causes.
Now, if you fast-forward to the 1990s, a consulting company called the Standish Group published a report that said the majority of software projects were failing. That's because they spent too much time working on software features that no one will use. Think of it this way. If you use a program like Microsoft Word, you might really be using only a small set of the features. Maybe you'll use spellcheck, print, or copy and paste, but you might never use mailmerge or any of the hundreds of language packs. That's true with most software products. In fact, the report showed that for most customers, 45% of the features in a software product are never used. The 19% are rarely used, and 16% are sometimes used.
Finally, 13% are often used and 7% are always used. If you look closely, you'll see the Pareto rule. Only 20% of the product's features are often or always used.
So if you're working in a agile team, this 20% is the most valuable part of the software, so you would want to start here first. This would be part of the highest priority featured delivered in the very first sprint. Now, this might not sound like a big deal, but it's actually different from how most teams develop software. Think about if you are creating a simple website with submit a contact form.
Typically, a project manager might divide this up into two milestones. One milestone might be to create the webpage that has all of the form fields, and then the second milestone might be capture those form fields in a database. Now, imagine you were working on the same website with an agile team.
The first thing you would do is ask the customer which one of the form fields are your most valuable?
They would probably say it's the customer's first name and email address. So instead of a milestone that finishes all of the form fields, you would create a simple website that only captures the customer's first name and email address. It would be a fully functional website but it would only include this 7% of the customer value. Then once that's complete, the agile team will work on the 13%. Maybe that's the customer's last name or their street address. The development team will work on the highest priority features and then move their way down to lower priority features until the whole product is complete.
So you've seen how important it is for agile teams to prioritize high-value work. They need to first focus on the features that the customer will always use. Then once those features are complete, they can move on to some of the less valuable or lower-priority work.
One way that these agile teams help visualize this work is by creating something called a task board. A task board is a simple swim lane diagram. The reason it's called a swim lane diagram is because it has vertical columns that look a little bit like a swimming pool. Now each of these columns or swim lanes holds a small batch of work. Typically, these are called tasks. Whichever column the task is in shows the status of that task. The simplest task board would only have three columns. To Do, Doing, and Done. If your team has a background in lean thinking, then they might call these columns work queues.
Now a typical agile team will write broad statements of customer value in the form of a user story. Then the team will create a column on the task board called User Stories. These user stories, like tasks, will be prioritized from top to bottom. Then the task to complete those user stories will be gathered next to it in the To Do column. You should keep in mind that many agile teams use the task board incorrectly. They'll just start whatever task they're comfortable working on and move it across the board. That's why it's usually best for the team to start with a real board with cards and stickies. Now remember that the task board is not just a way to show what you're working on, instead it's a key part of verifying that the team is working on the highest value features.
One of the things that a lot of agile teams get tripped up on is this idea of delivering high-value working software. Remember that the manifesto's principle seven says that working software is the primary measure of progress. But how's it possible to deliver working software every few weeks? To do that, you need to deliver small, fully-functional features of the product to the customer in iterations or sprints.
Let's think about developing a simple website. We just want a web form that captures the customer's contact information and stores it in a database. If you think about it, that's a whole project and there are several possible milestones.
For the first milestone, you need to create the database. Then you might need to develop the software that connects the form to the database. Finally, you have to create the form that captures the information. You might also need extra code to make sure that you have the correct data in the forms.
So if you're looking at the website as a project, then you could imagine it having a lot of milestones. But an agile team doesn't think about software as a project, instead it thinks of it as a product that has prioritized value that you deliver to the customer in short sprints. So you're not trying to tackle everything at once. Remember, we're not multi-tasking. Instead, you're zeroing in on high-value features to deliver. So you might have a simple webpage that just captures the customer's first name and email address. The key thing to keep in mind is that this form would be fully working software. That means that if you submitted your first name and email address that this simple website would check to make sure it's right, capture your name and address to a database, and regularly backup the data. Now not many customers would accept this as a fully working product, but they could. That's why when you're working on an agile team, you'll want to only show the customer working software. Some teams make the mistake of showing the customer PowerPoint presentations or wireframes. But these are really just fictions, they're not working software the customer can use. Ideally at the end of every sprint, the customer could put the software into production and end the development.
They shouldn't have to wait for deployment, testing, or other ways to finalize the product. The teams should always be building working software. Now there's a lot of reasons why agile teams do this. But one of the most important is that these teams find that working software is the best way to communicate progress. It keeps the customer from asking questions like when can we ship this? Every time they see the software, it's potentially shippable. Another reason is that it reinforces the agile team's commitment to work on the highest value features. It means that the features that will be used the most will be the first ones that are finished.
To work well as an agile team, you have to be adaptable. Adapting to change is built into the very foundation of the Agile Manifesto. The developers who wrote the manifesto were already using their own software development methods.
Two of the most popular were scrum and extreme programming. That's why a lot of agile teams use scrum terms and also some terms from extreme programming. One place you'll see this is in the principle two of the manifesto. It says that agile teams welcome changing requirements even late in development. Agile processes harness change for the customer's competitive advantage.
Embracing change is a core part of extreme programming. It's also important to scrum but scrum uses slightly different language. Scrum sees itself as an empirical product delivery framework. It encourages teams to inspect and adapt. A scrum team will make changes based on what they learn about the product. Embracing change and inspecting and adapting are really two ways of doing the same thing, one sounds a little bit more like extreme programming, and the other one sounds a little bit more like scrum. The key thing to keep in mind is that both of these approaches encourage you to experiment or change and adapt to improve the product.
When the developers created the manifesto, that was a pretty big departure from how most organizations viewed software development. Early software development projects followed the same processes that you had with manufacturing, so these teams would develop software the same way you might build a bridge or manufacture a car. But as time went on, these teams recognized that software development is much different from manufacturing. A change in the software doesn't require you to break concrete or redesign a car's dashboard. Software is also much more chaotic. Your product might depend on operating systems or different network protocols that are always being changed and updated. It'd almost be like trying to build the car when the roads change every few years. So these teams started to think of software development as much closer to scientific experiments.
Now, imagine we went back to our web application that collects our customer contact information. The webpage relies on a web server. That software gets updated frequently, and there are many different servers to choose from. It also runs an operating system that might change frequently. You also might even have to change operating systems. It also relies on a database which is always changing. Plus, your customer might be using several different web browsers and operating systems.
So you can probably imagine that it's really difficult to plan out a web application months or even years in advance. There are many different variables and many moving parts. That's why agile teams work with shorter periods of time and embrace frequent changes. If they didn't make frequent changes, then chances are when they finish the project, their software would already be obsolete. Embracing change also gives the customer a lot more flexibility. They might decide to use a different database. An agile mindset allows the team to pivot to take advantage of this new information so that the customer is more likely to be satisfied with the final product.
Agile teams focus on being predictable instead of creating detailed plans. Most organizations create detailed plans because they're trying to eliminate uncertainty. But agile teams can actually do a better job eliminating uncertainty by delivering predictably every few weeks. The agile manifesto points this out in principles three and eight. It said that agile teams deliver working software frequently, with a preference for the shorter timescale, and that developers should be able to maintain a constant pace indefinitely.
So developers should be able to deliver frequently and indefinitely at a constant pace. Now also remember that agile teams embrace change and are free to experiment. So your teams need to be able to experiment, change, while at the same time delivering frequently and indefinitely. If you stop for a minute, that sounds really hard to do. It almost sounds like painting a bus as it's driving down the road while at the same time guaranteeing that you'll be on time at every stop. That's why the best way to do this is by working with small batches of work and delivering it frequently.
Agile teams should be very aware of time. You can't have meetings that go over schedule or brainstorming sessions with an uncertain outcome. That's because your team has a deadline every few weeks. These are usually called sprints. That's also why agile teams are very structured with their time.
Typically they'll use the term timebox. This is a like a box of time that can't expand. That means that if your meeting is scheduled for 45 minutes then the meeting will end in 45 minutes. Whatever your team decides within that timebox will be the final outcome.
Think about how many times you're in a meeting and nothing gets decided. Usually what happens is that a project manager will schedule another meeting. That should never happen with an agile team. Because if you take that time away for another meeting, then you can put the team in danger of not delivering within the sprint.
Now a timebox is more than just about meetings. Each person on an agile team has their own personal timebox. They shouldn't work more than eight hours a day. If team members start putting in overtime or working over the weekends, then it can interfere with the team's predictability. This extra time isn't considered a sustainable pace. A scrum team will work in sprints. That's also a timebox. A typical box of time is two weeks.
So that means that your team will deliver whatever is finished in two weeks. If you just need an extra day to finish the database, then you have to take that feature out of the sprint. Keep in mind that you need a timebox to deliver predictably. You can't commit to a delivery date if you have too much work or if your meetings go long or if everyone is working overtime.
If you work for a large organization, then you might hear the term waterfall, or stage gate release.
The waterfall model is a step by step approach that was used in engineering. Each step falls into the next, like a waterfall.
In the 1970s, a computer scientist named Winston Royce took this waterfall model and reworked it to make it work with software. The first stage was gather requirements. Then, analyze the requirements. Design the system, code the software, test the software, and deploy.
For 30 years, this was the most popular way to develop software. In fact, many organizations are still using this approach. Business analysts will work on analyzing the requirements. The software architects will design the system. Software developers will then code the software, and a separate quality assurance team will run all the tests. Often, there's a separate infrastructure team that's responsible for deployment. Chances are, your organization still has several of these people working on your team.
Many agile coaches feel that waterfall and agile mindset are complete opposites, but the truth is a little trickier. Remember that agile is a mindset. It's a way to think about your work, while waterfall is a concrete process. It's strict guidelines for how you should do your work.
Many large organizations prefer strict guidelines over the new way of thinking, so you almost certainly bump into times when waterfall practices are inconsistent with your agile mindset. You see this a lot when organizations want agile teams to create detailed requirements, but your agile team will still spend plenty of time planning, designing, analyzing, and testing. It's just that instead of working on these things in sequential phases, you'll have the whole team working on these things all at the same time, within a sprint.
If you think about it, it would be nearly impossible to deliver every few weeks if you were using a waterfall style approach. If the business analysts got stuck waiting to hear from the customer, then the rest of the team would just sit idly as they wait to start the development for the handoff.
Remember that the agile manifesto says in principles four, five, and 11, that agile teams should be motivated and self-organized. They should also work closely with business people when delivering the product. That's why many agile teams strive to be cross-functional. So, instead of having business analysts, testers, and developers, you'll have generalized team members that try to do a little bit of everything. When you work as a cross-functional team, you're not as vulnerable to these backups. The product owner on the team will give you all the user stories you need to keep working. So, just think of an agile team as accomplishing many of the same things as you do in waterfall, but they're just doing it in a cross-functional way and compressing all the phases into a few weeks.
Most Agile teams will deliver in a short iteration that's typically called a Sprint. The term Sprint is from Scrum which is the most popular Agile framework.
Now there's nothing in the Agile manifesto that says that a team should deliver in Sprints. In Principle Three, the manifesto only suggests that you should deliver work in a shorter time scale. The reason that most Agile teams deliver in Sprints is that they're a very well structured way to deliver your product predictably and frequently. Sprints take all of the phases in a Waterfall model and compress it down to a much shorter timeframe.
This is usually a two week time box. That's why you'll often hear Agile teams talk about their two week Sprint. You'll see a little bit more about Scrum later on. For now, let's just think about some of the Scrum events. These are the different things that happen over the course of your Sprint. On the very first day of your Sprint, you'll have a Sprint planning meeting. This is the time when your team will plan out all the work you want to finish over the next few weeks. This shouldn't be more than a two hour meeting. The key thing to keep in mind is that this is where you do all of your planning. Remember that Agile teams don't eliminate planning, they just focus on short-term planning. Every morning the Scrum team should stand up for it's daily Scrum. This is a 15 minute meeting where the team coordinates their work. This is primarily a meeting between the different developers about the progress they're making on the product. At the end of the Sprint, the team will have a Sprint Review. This is a two hour product review, so the customer can offer any feedback on the work that was done during the Sprint. Usually the last hour and a half of the Sprint is dedicated to a team retrospective. This is when the team reflects on how they can work better together.
Now as you can see, there's a lot of stuff happening in this short Sprint. You cover a lot of the same waterfall phases that you have in a long-term project. You'll plan in Sprint planning, then analyze during daily Scrums, you'll deploy in your Sprint review, and then you leave some time for process improvement.
It's certainly possible to be an Agile team and not work in Sprints. But Sprints have become very popular because they have a great structure for delivering a product in a much shorter timeframe. One thing you want to keep in mind is that even though you're doing a lot of the same work as a waterfall project, you're not delivering the work in phases. You might plan at the beginning, and deliver at the end, but most of the work in between is mixed together. The team should be analyzing, developing, and testing all at the same time.
One of the biggest changes for agile teams is delivering the product in iterations. These are usually called sprints. Now, again, there's nothing in the Agile Manifesto that says that teams must deliver in sprints. It's just that decades after the manifesto, most teams find that these iterations are the best way to deliver a product in a shorter time scale. It also helps the team make changes quickly and deliver valuable software at a continuous pace.
Now, that means that sprints help you accomplish two key agile values, one and two, and principles three, seven, and eight. Now, iterative software delivery is a very common practice for agile teams, but it's certainly possible to be an agile team and not deliver in sprints.
You'll see this a little later on in the discussion about Kanban. Most agile teams focus on delivering the product incrementally and iteratively. You've seen that it's very common for agile teams to deliver incrementally in a two-week sprint. That's because the team will deliver in a two-week increment. But these teams also work in sprints to deliver the product iteratively.
Iterative delivery is a process on its own, but you can really think of it more as refinement. The team is improving on the product at the end of every sprint. Imagine you wanted to build a car using a typical waterfall-style phased approach. You'd probably start out with the frame of the car in the first phase. Then you'd add wheels and a windshield in the second phase. Then you'd add seats and paint the car in the final phase. Each phase would fall into the next, like a waterfall. You couldn't actually drive the car until the project was complete, so you wouldn't get the value of the car until the final delivery.
Now, imagine an agile team's incremental and iterative approach. In this case, you would start out building a smaller increment of the car's value. So, your team would work on delivering something like a pair of roller skates. I know it sounds a little strange to have roller skates to start with instead of a car, but remember, we're talking about iterative delivery, and your team could never deliver a car in a sprint.
Now, remember, in agile, you're focusing on the value, so here the value is actually transportation. You don't have a finished car, but you've taken an incremental step to transport yourself from one place to the next. Now you'll take an iterative approach to improve the product's increment. You would refine it and make it better. So, the next increment might be a skateboard. You're refining the product's value. Each sprint, you would refine the product a little bit more. You'd go from skateboard to bicycle, then from bicycle to motorcycle, finally, you go from motorcycle to car. You're not building out phases of a car, and instead, you're refining a simple transportation product into something more valuable.
One advantage to this approach is that your customer is getting value at the end of every sprint. Your customer could decide that they don't really need a car and just ride away with a new motorcycle. The team is also learning about the product. They're understanding more about what their customer wants at the end of every sprint. The key thing to remember is that this iterative delivery is one of the biggest shifts in your mindset when working on an agile team. Most teams instinctively break up large products into phases. They don't like to build and refine. Instead, they like to plan out everything and put it together in the end. If your agile team has a hard time finishing their sprints, then be sure to look here to see if they're having trouble working with iterative delivery.
So far, you've heard me use terms such as the product owner, sprints, Scrum muster, and the product backlog. These are common terms that you'll hear with most Agile teams. But these terms are not part of the Agile Manifesto. These terms are actually from Scrum, which is the most popular Agile framework.
The developers of Scrum were a key part of the group that helped write the Agile Manifesto. But the Manifesto doesn't prescribe Scrum. In fact, it goes out of its way to generalize Agile methods into a larger mindset. So Agile is a mindset, while Scrum is a way to help you embrace that mindset. Think of it this way. A lot of people like to be physically fit, so they jog or swim, or take long bike rides. These are all different ways that you can achieve better fitness. You can even improve your fitness by mixing and matching some of these methods and doing something completely different. Agile, like fitness, is a mindset. While jogging and biking are methods you can try to help you embrace that mindset. Some people even try a fitness framework. Maybe something like CrossFit or aerobics. These mix and match, jogging, running, or biking into a larger framework.
Scrum and Agile are basically doing the same thing. Agile is a mindset and Scrum is a framework to help you embrace that mindset. So in a sense, Scrum is to Agile in the same way that something like aerobics is to fitness. Now like aerobics, Scrum is not the only Agile framework, but it does work in a way that's slightly different from other frameworks.
Scrum describes itself as an empirical process control framework. The empirical side means that Scrum runs experiments to improve the product. The shorthand for this is that Scrum teams inspect and adapt. They inspect the product and then adapt quickly if they need to make changes.
So a Scrum team might learn something new and then work with the customer to quickly improve the product. As of today, Scrum is the most widely-used Agile framework. That's partly because Scrum is very lightweight. A Scrum team only has three roles, and should only have five events and then there are just a few outputs for what Scrum calls artifacts. There's not much to it, and so Scrum teams have a lot of flexibility in what they like to do with the framework. Because Scrum is so popular, a lot of the language between the default terms for Agile teams. That gets a little confusing because you'll have Agile teams that are using Scrum terms but not actually practicing Scrum. But even with this mix up, most teams have settled on these terms. So even though you should remember that Scrum and Agile are different, you should expect to run into these terms when you start to work on your Agile teams.
Another popular framework for agile teams is extreme programming. The creators of extreme programming, or XP, were also a key part of the group that wrote the manifesto.
Some agile experts believe that most of what teams think of as agile actually came from XP. XP allows software teams to work quickly and embrace changes. These teams could quickly pivot to take advantage of new information. They called the methods extreme because they thought to deliver software effectively you needed to make extreme changes to the software development process.
At first glance, scrum shares a lot of the same ideas as extreme programming. In fact, the very first scrum book said that you should use scrum to implement XP. But scrum took a slightly different path. It broke away from XP and became a looser framework that you could use with any product. XP is still only focused on software development. That means if you're an agile software development team, you should probably consider using many of the XP practices. A few of these practices are agile planning, continuous integration, software refactoring, and test-driven development.
Most agile teams already use some form of XP's agile planning. One of the most popular are agile user stories. User stories are a short description of a feature that's written in the language of the customer. So a customer might create a user story that says something like "I want the user to be able to input their address." You can see that this isn't technical. You don't talk about databases or web forms. Instead it's just a simple description of what the customer wants.
Agile teams will use these stories as a way to start their planning process. They'll create estimates, then decide how many stories they can deliver in each sprint. XP also encourages something called continuous integration.
In the past, software development teams might work on some code and then try to integrate it all at the end. XP teams continuously integrate their code. They do this to make sure that it will work with the whole product. They'll also refactor the product. That means instead of trying to finish the software all at once they'll refine it and improve it over time. An XP team isn't satisfied when the software's finished. They always look to improve the code through constant refactoring.
Finally, XP teams try to create tests for their software before they actually start development. This is called test-driven development, or TDD, and it helps developers understand how the software will work before they actually start coding. So, in a sense, they'll know how to finish before they get started. If you're a software development team, there's a lot of value in these XP practices. That's why many software teams use a combination of scrum and XP to help them embrace an agile mindset.
A lot of Agile teams also use many of the concepts from Kanban. Kanban is a scheduling system that was used in lean manufacturing.
Many Agile teams like to display their work on a Kanban board, but Kanban's influence on the Agile mindset goes well beyond just the board. The Kanban system is actually a popular way to apply lean thinking to software development. Lean thinking is about focusing on what's valuable to the customer, and then continuously improving the product over time. You've seen this in the very first principle in the Agile Manifesto.
Remember that Agile teams focus on continuous delivery of valuable software. But lean also emphasizes people over process. It encourages companies to have respect for people and trust them to deliver high-quality work. You've also seen this in the first value in the Agile Manifesto, and principle five says that organizations should build projects around motivated individuals and trust them to get the job done. So you could probably summarize lean thinking into two core values. You should have respect for people and continuously improve. Even though we haven't talked about lean, these ideas are probably already familiar.
In fact, a lot of the Agile mindset is just a restatement of lean thinking. Self-organized teams are just a way to have greater respect for people. Retrospectives and software refactoring are just another way to continuously improve. That's why when you're working on an Agile team, you should think very carefully about how you use your Kanban board.
A Kanban board is a swim lane diagram with four more columns. These columns typically have the labels Stories, To Do, Doing, and Done. Scrum teams will call this the task board, because they use yellow sticky notes to keep track of their tasks, but a Kanban board, or Scrum task board, is more than just displaying your work. It's actually a way to organize your work so that your team is focused on delivering the greatest value. That means that the work should flow through the board in a very particular way. The stories at the top should have the highest customer value. Then the team should work on this top story until it's finished, or in the Done column. Once that work is done, then the team can work on the story second from the top. Remember that Agile teams should avoid multitasking.
Your team should also make sure that you don't have too much work in each column. If you have a lot of sticky notes stuck in the To Do column, then it usually means that the team is having trouble finishing the work. All the work on the board should be self-assigned so when you're working on an Agile team, you will pull a task from the board during the morning stand-up meeting. And that assigns yourself the work.
Remember that lean encourages your team to be self-organized. The team should also look for ways to continuously improve themselves and the product. So you wouldn't want too much work stuck in any one column. If you do, then it's a sign that your team might have trouble delivering.
It might seem strange that we're talking about agile team roles so late in the article. A lot of articles would immediately start talking about scrum masters, product owners, and the development team. But that actually causes a lot of confusion.
That's because it's difficult to understand the roles on a team without first understanding the agile mindset. In fact, most people when they look at agile roles start to make connections between roles they already know. So you might think of a scrum master as an agile project manager, or you might think of a product owner as an agile business analyst. This way of thinking can lead to a lot of problems.
For one, it can move people into these roles when they may not be the best fit. And two, it plays into a stereotype that organizational changes are always step-by-step. So you might move a project manager into a scrum master role but remember that agile roles are usually radically different from roles you already have.
I've seen many agile teams that put the wrong people in these roles because of this challenge. Remember that an agile mindset is a big change from how most organizations operate. That means that you'll have trouble embracing an agile mindset if you're unwilling to make these changes. You can't expect big improvements when you have the same people in the same roles working the same way. So when you're starting with agile, you might want to take special care when you're figuring out the best person for each role. You might want to be careful putting project managers into the scrum master role.
A project manager is used to being the point person for the project. People in the organization will come to them for status updates, and they're responsible for hiring and firing people on their team. A scrum master is a completely different role. Here you'll act as a coach. Instead of having authority over the team, you'll be encouraging them to take on greater responsibilities.
Remember that agile teams are cross-functional and self-organized. So instead of being a manager, you'd want to encourage the team to self-manage. If you like having control over your team, then you'll probably have a difficult time being a scrum master. You might run into similar challenges with the product owner. A lot of organizations just see the product owner as an agile business analyst. But again, it's an entirely different role. A business analyst will typically create project requirements for the team. Then it's up to the team to deliver those requirements. So there's a handoff here. The business analyst will finish their work and then hand it off to the team. A product owner is a very different role. Here, the product owner works with the team to deliver the product. They even sit with the team. They don't just hand off requirements, instead they own the product.
There's a shared responsibility between the product owner and the development team. You'll certainly want to look for people already in your organization when you start your agile team. Just make sure that everyone knows their role and isn't just trying to do the same thing with a new agile job title.
Many agile coaches believe that the product owner is the most important role on the team. If you step back a little, that makes a lot of sense. The product owner owns the product. They're responsible for setting the direction and prioritizing the work. There isn't really a role like this in most organizations.
Some organizations have business analysts which create project requirements. Then they deliver those requirements to the team. A business analyst typically moves in between the business and the developers. So if the developers have a question, they have to go back to the customer and find an answer. But a product owner should have most of the answers. If the developers have a question, they shouldn't have to email someone for an answer. They own the product and have the authority to make real-time decisions. Other organizations might have a product manager. A product manager is closer to a product owner than a business analyst, but there are still some key differences. A product manager works on the long-term strategy for a product. They'll create the budget and look at competing products. Once they have a vision, then they'll bring in a product owner to actually own the product.
In a typical agile team, a product owner will work off of a product backlog. A product backlog is a ranked list of different features that the product owner would like included in the product. Most teams will put user stories in the product backlog, but you can really put anything you want.
Now remember we're using scrum terms here, because that's the most popular agile framework. You can be on an agile team without relying on any of these terms. The important thing to remember is that you need a customer representative that owns the product as part of your agile team regardless of what you name the role. The key thing to remember about the product owner is that they're fully integrated into the team. They should sit with the team and be able to answer questions. So that means if the developer wants to know if the product should have a checkbox or radio dial, they should be able to turn their seat around and ask the product owner.
A lot of teams struggle when they have a product owner who's not really committed to the team. Maybe it's because they were a business analyst and they're used to just handing off their work and moving onto the next project. It could be because the product owner works with several teams. Either way this can cause a lot of problems when you're delivering a product. When you don't have a product owner, then the team loses any sense of direction. The developers will just deliver the parts of the product that they can finish first. This may or may not have the highest customer value, and that's why it's so important for your product owner to fully embrace their role.
The scrum master is one role that gets a lot of attention. It just sounds impressive. Any job that has master in the title is going to get a lot of interest. But the master in scrum master isn't about mastering your team, instead it's all about mastering scrum. But that doesn't stop the scrum master from becoming one of the most sought-after roles on the team. Scrum master certifications far outnumber those of product owners and certified developers. People seem very interested in being a scrum master. Unfortunately a lot of this interest is a little misguided. A scrum master is not a manager. They're much closer to being a trainer or a coach. They can even be an administrator. They make sure the developers understand scrum but they also do simple administrative work like making sure that everyone has a chair in the shared workspace.
One of the early authors of scrum referred to the scrum master as both a bulldozer and a shield. They bulldoze through obstacles, but they also protect the team from outside interference. These obstacles can be contacting someone, setting up meetings or even ordering software. The scrum master role also changes over time. They may start out spending most of their time training, something like showing the product owner how to write better user stories. Then over time, the agile team will get better at following scrum, so then the scrum master can spend most of their time on administration. So they'll make sure that everyone has all the equipment they need and works in a comfortable space.
The authority and power that a scrum master has comes from their knowledge of scrum. So they might not have the authority to confront a manager but they can let them know how their actions might impact the team. One thing that almost always happens in large organizations is a functional manager will try to pull someone off the agile team. This will either be for a short project or some other presentation.
Now remember the penny game? If you pull someone off an agile team then you're going to create backups. In a sense, the team will only go as fast as the slowest person, so this simple act from one manager might keep the team from delivering at the end of their sprint. The scrum master might not have the authority to stop the manager, but they can let them know how their actions will interfere with the product delivery. This type of confrontation can be very political, so the scrum master should be able to manage conflict. Also keep in mind that there's nothing in the Agile Manifesto that says that your team needs a scrum master. But because scrum is so popular, most teams have someone in this role. They might just call them a servant-leader or an agile coach, but the duties are usually the same. The key thing to keep in mind, that even though there's a master in your title, you'll probably spend most of your time serving others.
One of the most important ideas in the Agile Manifesto is that teams should favor individuals and interactions over processes and tools. The original work group that developed the Agile Manifesto put a lot of emphasis on how team members communicate. That's because they knew that most software projects fail not because of some overwhelming technical challenge, instead these projects fail because of bad communication. They thought the fix for this was putting much more emphasis on face-to-face interactions.
But why do you think that is? Face-to-face meetings aren't the only way to improve your communication. Why do you need to be in the same room? The reason is that face-to-face communication and cross-functional self-organized teams are actually closely related. Remember that Agile teams want to distribute their expertise to everyone else in the team. Every one Agile teams should always be teaching and learning. That's usually quite a bit different from how most teams operate.
Typically there'll be an expert whose opinion has much more weight, so a database developer might just let everyone know what they're doing with the database. But when that happens, it gets really difficult for a team to have a shared understanding about the product. They could end up doing something called group think. That's when a few experts make a convincing argument and the rest of the team just follow along, something like Sam says it a good idea, so it must be right.
An Agile team should avoid group think because everyone should be able to ask challenging questions about the product. That means that a tester should be able to ask a database developer about their design of the database. On an Agile team, if you can't simply explain your thinking to someone else, then it's probably not a well-designed solution. So, the team should always be having these face-to-face meetings where everyone's contributing their ideas and asking challenging questions. It's a key part of being a self-organized team.
One of the most popular ways that Agile teams combat groupthink is by playing a game of Planning poker. This is a consensus-building technique that was adapted from a group decision-making tool called Wideband Delphi. Planning poker helps groups of people estimate how much effort it would take for the whole team to finish a user story. It's a way to get a shared understanding about all the development and design challenges to deliver that small batch of work.
So, let's take a look at how this works. Your team sits around a table, and a facilitator, usually the scrum master, holds a user story that product owner wants delivered. Each person on a team will have a set of playing cards. The numbers on the cards represent relative effort. The higher the number, the greater the effort. You can use any range of numbers, but the most popular range is a modified Fibonacci sequence.
So, something like one, two, three, five, eight, 13, and 21. So, everyone on the development team sits around the table, then the scrum master reads the story out loud, and puts it face up in the middle. Each team member estimates the effort in the story and places the card face down in front of them. The number on this card represents a team member's view of how much effort it will take for the whole team to deliver the story. This is a really tricky concept for a lot of teams. Many of them come from a project management background, so they might think of it as individual work hours. But remember you have to finish the story in a two-week sprint. So, think about the effort it will take for the whole team to finish the story in that time box. Once all the cards are down, the scrum master asks everyone to flip their cards over all at the same time. They do this to make sure that people don't influence each others estimates. It also encourages the team to have a conversation and avoid groupthink.
What often happens is that they'll be a wide range of different estimates. One person might have a two, another person with a 13, or one person might have a three, and the other person will have a five. When this happens, the scrum master should ask the person with the highest number to explain to the person with the lowest number why this story will need much more effort than they estimated. The key thing to keep in mind is that this is a consensus-building exercise.
In many ways, the numbers are irrelevant. The important thing is that everyone reaches consensus for how the whole team will deliver the story. What you don't want to see happen is that people will just give up the discussion for the sake of reaching a number. They might say something like, since you have an eight and you're the expert, I'm also going with an eight. Just to keep the game moving. It might take a few rounds of playing until everyone has reached consensus. That's okay, because it's better to have that discussion before you start delivering the story. The scrum master should make sure that everyone has this conversation, so there's a shared understanding of how everyone will deliver the story.
There are a lot of challenges that come with embracing a more agile mindset. But the biggest challenge in large organizations is underestimating how radical this transformation can be. This isn't really one challenge as much as it's a group of common challenges. You can get a sense of this challenge by looking at how many changes your organization has made.
If you have the same people doing the same things just with more agile-sounding names, then you probably aren't making significant changes. Your agile transformation should be like yoga. If you're doing it right, it should hurt just a little bit. Your organization should be a little anxious about the changes. And generally, organizations don't like to be anxious. But if you think about it, there are a lot of big changes. Your organization will need to step away from longterm detailed plans, instead they need to inspect and adapt.
If you're a longtime project manager, this idea should make you pretty uncomfortable. You've probably spent years or even decades trying to stamp out all the uncertainty. If you want to embrace a more agile mindset, then you have to change your whole relationship with uncertainty. Instead of trying to stamp it out, you need to see it as a competitive advantage. You can improve your product if your agile team adapts faster than your competitors. If you're a business analyst, then you have to change the way you think about the product. It might seem natural to come up with your own requirements and then hand it off to the team. An agile team is different. Here, you have to work hand in hand with the team to deliver your product. There isn't any handoff, instead your team and their team are the same team. That might make you uncomfortable because in the past there were very clear lines of responsibility. But an agile team mixes up these lines. Finally, if you're a manager, you have to change the way you receive status updates. You might be used to a one-page weekly status report. It shows if your project is on-time and under-budget.
An agile team doesn't communicate with reports, instead the team communicates with working software. That means that you'll want to attend frequent sprint reviews and give direct feedback about the product.
For most organizations, these changes will all be very difficult and you shouldn't underestimate how much different they are from the status quo. I've seen many organizations try to split the difference. They'll do a little bit of changing, and hope for some process improvement. When they do that, they're almost always disappointed. That's because agile is a radical change in your organizational mindset. If you're not thinking about the product differently, then you're probably not going to get that much benefit from many small changes.
With any large organizational change, it's difficult to see where to start. Some organizations want to start from the bottom-up. They want to train their employees and just get started with Scrum, XP, or Kanban. Other organizations want to start from the top-down. They want their executives and managers to understand the change and create new budgets for agile teams. Both of these approaches have their own advantages and disadvantages. Starting from the bottom-up will get you going pretty quickly, but you might run into trouble with executive support. On the other hand, starting from the top-down could get you a lot of executive support, but the teams might not know much about the agile mindset. You might be surprised to hear that a lot of agile transformations fail before they even get started. That's because a lot of organizations have a culture which has a hard time embracing big changes.
An Organizational Culture is an unseen and unspoken way of working. You might hear employees say something like, "That's not the way we do things here." These rules might not be written down, they're just understood as being a part of the organization. One of the most common types of Organizational Culture is the Control Culture. This is a culture that's based on a hierarchy of different supervisors, directors and executives. Everyone in these organizations knows exactly who they work for and knows who works for them. If you fit neatly into an organizational chart, then you're usually part of a Control Culture. A Control Culture wants predictability. That's because each manager is responsible for the people that work for them.
If there's a lot of uncertainty, then it gets difficult to make predictions. That's why a lot of Control Cultures have a very strong Project Management Office. The PMO likes to divide work into predictable projects. Each one will have it's own scope, budget, and schedule. This common type of organization will have a really hard time embracing some of the radical changes that are part of an agile mindset. The first thing you want to do is figure out if your organization has a strong Control Culture. If it does, then recognize that most of your organization will push back against many of the core parts of an agile mindset. If this happens, usually your best approach is to create an entirely separate team within your organization. One company that I work with actually put their agile team in an entirely different building, and then isolated them on their own two floors. That gave them full ownership of their product. Then the executives checked out if this team delivered better than the rest of the organization. When a company decides to make an organizational change, it could take five or ten years to make this transformation. This is a huge commitment, so it's better to understand the big changes before you get started.
I hope that throughout this article you got a sense of how Agile mindset can improve your product delivery. Just remember that the mindset is a radical change from how most organizations operate. So if you want to get real value from Agile, then you'll want to get ready for some tough changes. Remember, what feels right to you as an individual might not be the most efficient way to work as a team.
No comments?
There are intentionally no comments on this site. Enjoy! If you found any errors in this article, please feel free to edit on GitHub.