Chapter 5

Thinking Like An Agile Team

By now you should have a good understanding of some of the challenges you will face when trying to convince your company to implement agile. Once your company has agreed to take the plunge, the people within the agile team need to start working differently. They need to give up the old roles and start taking on new roles and responsibilities as part of a team.

The developers, the product owners, and the ScrumMasters are simply called the team. This makes sense because Scrum is a bit more abstract than extreme programming. Team members may also include marketing specialists and sales analysts. In extreme programming, the developers are primarily software developers and testers.

Since the developers are responsible for estimating and completing the work, it is usually a good idea to have a development team with a generalized skill set. This will create a team that doesn't have to be overly dependent on resources that are outside the team.

If no one on the team knows anything about setting up computer servers, it would be very risky to create an estimate about how long it would take to install a web server. If the team is more generalized, they will be able to create accurate estimates for a much wider range of tasks. It is also better to keep all of the work inside the team. If there are outside contractors, then the team becomes disconnected from their work. The team will still have accountability but no ability to complete the project.

Don't Depend On Superheroes

In the 1940s, there was a very popular radio show called Superman. Invariably, someone in the show would be in a dangerous situation. Lois Lane or Eddy would be caught up in some sort of trap with little hope of escape. Then the radio announcer would start, “Look up in the air! It's a bird! It's a plane! No, it's Superman!” Then in a flash, Superman would swoop in and save the day.

As strange as it may sound, that's not much different from how many organizations view their projects. They will try to hire their own superheroes for the team. Typically these superheroes will have some knowledge or experience that is meant to save the day. Instead of lifting locomotives, they work long hours. Instead of leaping tall buildings, they leap milestones. The superhero is the developer who will drive the team to deliver the project.

There are a few challenges with this approach. The first challenge is that when one superhero drives the work, it becomes increasingly difficult to maintain the product. The second challenge is that if one person is responsible for more of the work, then that person becomes a bottleneck for the rest of the team.

Agile tries to break away from this superhero model. For the project to succeed, the responsibility for the delivery of the product is distributed to the entire team. There is less need to find one person to drive and deliver the product. An agile team should try to share knowledge and share responsibility.

That's why agile places so much emphasis on communication and collaboration. One of the best descriptions of how an agile team works comes from the world of extreme programming.

Extreme programming is one of the earliest agile frameworks. The framework preceded The Agile Manifesto, so it started out with its own list of values. These values were designed to help an agile team work in harmony.

The five core values are communication, simplicity, feedback, courage, and respect. These might sound like the refrain of a country-western song, but when viewed as a whole, you can see agile work patterns.

Communication: Agile puts a high premium on communication. This is the reason behind the use of a shared workspace, user stories, pair programming, collective code ownership, and daily standups. The team has a dedicated ScrumMaster whose job is to notice when people aren't communicating.

Simplicity: Agile teams put a lot of emphasis on simplicity. The output should be the simplest solution for the job. Over-engineering can be a big problem in software projects. The team should “do the simplest thing that could possibly work” (DTSTTCPW principle), or “keep it simple” (KISS). You might hear an agile team use the term YAGNI or “you ain't gonna need it.” An agile team will try to deliver the simplest solution and improve it over time.

Feedback: This core value is really a subset of communication. The team needs to give feedback to one another. The product owner should give feedback to the team. The team should collaborate with the product owner and make changes. There should always be someone giving you feedback or getting feedback from you.

All this feedback requires a lot of communication. When the team is working, it should be quietly active. A good agile workspace should have the feel of a newsroom and not a library.

Courage: In a way, this value gives insight into how an agile team interacts. It takes courage to communicate and accept feedback. Many developers have spent most of their career solving problems on their own. It takes a lot of courage to solve problems in a group setting.

They also need the courage to improve working code.⁶ Agile teams build and improve products a little at a time. Not all the daily work makes it into the final product. The developers need courage to throw away working code. That means that the small simple solution created earlier might have to be redone or improved. This is called software refactoring and is a continuous effort by the team.

Respect: This value was added a few years after the first four. It means respect for one another and respect for your own work. This is the anti-superhero value. Every team will have varying degrees of experience and expertise. The developers will know more than the customer. Some of the developers will be more experienced than others.

For the team to work well, the team needs to share their knowledge and respect their coworkers. They need to accept that there is no one superhero and that the entire team deserves respect.

An agile team will always strive to have greater transparency. In many projects, there is a steep penalty for making mistakes. There's a lot of incentive for developers to hide and quietly cover up their errors. Agile developers need to have respect for their own work. They should only deliver clean working code. If the code is ugly or buggy, they need to share that challenge with the rest of the team.

Good training in agile will help ensure that your team does not have any “supermen” and that everyone is focused on working together to deliver the software.

Training The Agile Team

Ideally, the training should happen before the work begins and should have two main goals. The first goal is to give everybody a good understanding of the rules surrounding agile. Team members need to understand the new roles and expectations. The team should also know how to participate in the activities and how to make estimates and plans within the agile framework.

The second goal is to try and give the team a forum to discuss their doubts and concerns. An agile transformation is a big undertaking. It's a journey the team shouldn't take lightly. Many organizations aren't ready for this transformation. If the organization isn't ready, it will come out in the training.

There are also organizations where agile is not the best fit. The training shouldn't present agile as a sort of magic dust that you can sprinkle on your projects to make everything better. It shouldn't be an agile sales pitch complete with promises and sizzle. Instead, the trainers should present how agile can improve the team, and then discuss how this might work for the organization.

One way to avoid this sales pitch is to make sure that your trainer is not the same person who is selling other agile products. A good salesperson will never want an open forum to discuss whether the product is a good idea.

Instead, try to find agile trainers from a local university. You can also find certified agile trainers on certification websites like the Scrum Alliance. A good trainer shouldn't be afraid of challenging questions.

Often, agile transformations are the result of top-down organizational changes. Many times, executives in the organization are the only people who can drive significant change. The downside is that not everyone in the team has a sense of why the change is happening. Then, before you know it, everybody's working on the change without understanding the benefits.

The trainer should understand this and should set aside enough time for everyone to express their views. This doesn't mean that the training should start to look like a town hall meeting, but there should be enough time for the team to talk to one another about what they're doing and why they're doing it.

If possible, you should try to have everyone on the team attend training at the same time. This is especially true for product owners. Often a product owner is the last person identified. That doesn't mean that they should miss out on the training. In fact, product owners are usually one of the greatest beneficiaries of the training, since they may be the least familiar with agile.

Letting The Team Self-Organize

Think about the majority of jobs in the early 20th century. They were the autoworker, retailer, and construction worker jobs. People used to migrate to the great hiring centers like Chicago, New York, and Detroit.

Today, these show-up-and-work jobs are increasingly difficult to find and even more difficult to hold.

Most of these early jobs followed a clear hierarchy. There were employees and managers. The managers would manage the employees. And the employees, if they wanted to stay employed, listened closely to their managers.

Most workers at that time were hardworking, but replaceable. They were not always hired for what they knew, but for their ability to put in a hard day's work. The managers were the ones with the skills. They were the ones being groomed and developed.

Now fast-forward to a modern agile project. An agile team may have graphic designers, developers, and database engineers. The team will have members who have spent years developing their skills.

The designers will have attended design school and have access to sophisticated software. The developers usually have engineering degrees and will have mastered several programming languages. The database engineers will have certifications from Oracle or Microsoft.

A manager cannot be expected to have this level of expertise. They can't have all the team's degrees, the knowledge of dozens of software packages, or the understanding of multiple programming languages.

This makes it difficult to manage these employees in the same way managers did 50 years ago. The team usually has a lot more knowledge than their managers.

Because of this reality, an agile team is best qualified to make many of the decisions for the project. That's why an agile team is self-organizing.

Self-organization is a loaded term for project managers who have spent their careers managing teams. It often conjures up images of unicorns sliding down rainbows.

They often see self-organizing as an unfulfilled promise like self-cleaning ovens or self-watering plants. They will think self-organizing is all happy talk. At some point, you are going to have to clean your oven or water your plants.

But self-organizing is not about taking the manager out of the team. Instead, it's about making the people who are doing the work responsible for scheduling the work.

The self-organizing team takes on a lot of the responsibility that was previously left to the project managers. In an agile project, the team does the estimating. The team breaks the work down into chunks and works to improve their performance.

Agile recognizes that the estimation dance puts project managers in an unfair position. They're responsible for the outcome even though they have little knowledge of what's going into the estimate. Project managers can thump everyone's desk, but they can't write the software and they can't design the graphics.

Self-organizing isn't about taking authority from the project manager. Instead, it's about breaking down the inefficiency of being responsible for the team's work. This problem is only increasing as teams get more skilled and the work becomes more complex.

Despite this, self-organization is still one of the hardest obstacles to overcome with the team. It's just not how teams are used to working. Managers are used to managing teams. Teams are used to being managed by managers.

Of the two, it's usually much easier to get the team to accept responsibility for delivery. Managers usually have a much more difficult time accepting the idea that the team doesn't need to be managed.

The ScrumMaster might also be an impediment to self-organization. This is especially true if the ScrumMaster comes from a management background. Sometimes it's hard to get rid of old habits.

If you're a ScrumMaster with a management background, then you need to be keenly self-aware when you try to manage the team.

Delivering Like An Agile Team

In traditional projects, there is often a rift between the team responsible for delivery and the customers using the product. This rift makes it difficult to see how the customer views the product.

Many projects create very detailed specifications. The problem with this approach is that not every customer knows everything they want before the project begins. This is especially true with software projects.

Agile addresses this challenge by changing the way the customer views the deliverable. The product owner doesn't try to know everything about the project. Instead, they focus on the highest-value items first, which get ranked in the product backlog (a list of items and functions to be developed). This product backlog is always being updated by the product owner.

The hunt for agile value is part of a story that started a century ago. An Italian economist named Vilfredo Pareto was getting peas from his garden when he noticed that roughly 20% of his pea plants produced about 80% of his peas. That meant that 20% of his pea plants produced 80% of his overall pea harvest. This 80/20 rule stuck with him.

He later noticed the same distribution when he looked at economic data. He saw that around 80% of the land was owned by 20% of the people. Modern project managers have found the 80/20 rule to be true in a lot of scenarios. Managers often refer to this as the 80/20 rule or the Pareto rule: Eighty percent of your value comes from 20% of your product.

Pareto would never have guessed that, years later, his rule would also prove true for software. In 2002, the Standish Group published a chart that showed how functions and features broke down in software products.

This chart showed that, on average, customers never used 45% of the functions and features delivered in software, 19% of the functions and features were sometimes used, 16% were rarely used, 13% were often used, and finally 7% were always used.

If you look closely at the chart, you'll see Pareto's rule. Only 20% of the software was often or always used. The customers were primarily using 20% of the same functions and features. This was very interesting when you consider that they were paying for 100% of the software.

Agile projects take advantage of this Pareto rule. If only 20% of your effort is giving you 80% of your value, then the product owner has a responsibility to deliver that value first.

So if you were the product owner, where would you start development?

With an agile project, you always start with the 7% of functions and features that the customers will always use. Then after that 7% is finished, you start working on the 13% of functions and features the customer will often use.

Once those high-value functions and features are complete, you can start working on the lower-value items. These are the functions and features that are sometimes used.

If you think about it, the Pareto rule will probably hold true for you as well. Think about the software products you use. How many different features do you use on your smartphone? There are probably some features you'll never use.

Now, imagine that you are a CEO of a software-development company and you have a limited budget to create smartphone software. Where would you start? You would probably start by hiring a product owner who understands smartphone software. That product owner would work closely with the customer to see what they always use on their smartphone.

Say the new smartphone comes out and it has a really terrific feature. You, as a product owner, might push to have this feature included in your software project.

That is why ranking of the items in the product backlog is not a goal to meet. Instead, it's a mindset that will dictate how the work is delivered. Working the ranked list from the top down is an ongoing part of an agile project.

A traditional project forces the customer to do all of the planning before the team starts developing. The stakeholders need to know exactly what the software will look like before a single line of code is written.

Think about how you would approach receiving a long list of work. A very natural tendency is to start with the work that you know how to do. You may also start with the items that you think you can quickly finish. If you know everything up front, you're delivering software based on your ability to finish the product. That could mean that the customer will have to wait until the entire project is finished before they can start to use the software.

The role of the product owner is to keep this from happening. The team starts work on what the product owner ranks highest and not on what's easiest for the team to deliver. This change forces the team to finish the 20% before any other work begins.

Staying Agile With The ScrumMaster

Few roles are as misunderstood as the agile ScrumMaster. Many organizations look to ScrumMasters as their senior managers responsible for the agile transformation. They see them as a throat to choke if things go wrong with the agile project.

An agile team is self-organizing, so thinking of the ScrumMaster as a manager removes the shared responsibility from the team. It is important to remember that the ScrumMaster is responsible for managing the agile framework—not for managing the team. A ScrumMaster administers the project, creates reports, eliminates obstacles, and removes distractions.

But names matter. And any role with master in the title is almost certain to inherit management responsibility. That means ScrumMasters are often placed in an awkward position of trying to reduce their own scope of authority. A good ScrumMaster stands behind the team, not in front of them. ScrumMasters have to stay in the background to ensure the team is self-organizing.

The ScrumMaster's job is to facilitate most of the agile activities, so it's important to understand the difference between facilitating and managing. If a ScrumMaster starts by asking everyone for status updates, then they are managing and not facilitating the activity. That's why it's often best for ScrumMasters to sit off to the side in these activities. They shouldn't communicate management authority.

If two developers start discussing a challenge at the daily standup, then it's the ScrumMaster's responsibility to interrupt them and keep the activity on topic. Again, they are responsible for making sure that the activity follows the agile framework. They are not responsible for the team's productivity.

The ScrumMaster will also create charts showing features completed in a two-week sprint, or a chart to show whether the estimates were accurate.

These reports are not about shame and blame. A ScrumMaster would never put up a chart that says, “Team member of the month.” That is not about the process. That would be about congratulating individual team members and, therefore, outside of their role.

Finally, a ScrumMaster should act as the project's obstacle remover. If a team member highlights an obstacle, then the ScrumMaster takes responsibility for that obstacle. This could mean ensuring that the computers arrive on time or having an awkward conversation with a team member about talking too loudly on the phone.

They will remove barriers that keep the team from reaching peak productivity. This may include finding the team a better workspace or making sure that the customer is involved with the team. It may also include mundane tasks such as making sure that the team has pizza for the pizza party.

There are also several soft skills that ScrumMasters need to develop. An obstacle might not simply be stale coffee or bad office space. It can also be hurt feelings and misunderstandings. For example, someone on the team might feel slighted by less experienced team members. The ScrumMaster needs to be emotionally intelligent about these issues and suggest a resolution.

One way to think about the ScrumMaster is to think of them as the team's sweeper on a curling team. If you have cold winters, you've probably seen the sport of curling. It also shows up every four years in the Winter Olympics. Curling is a bit like playing checkers on a massive sheet of ice. A player will slide a massive stone across the sheet of ice to a target on the other side. They hope to land on the target and knock the other player's stone off their spot.

Each team will have a thrower, the one who sends the stone down the glistening sheet. Once the thrower releases the stone, it is up to the sweepers to remove all obstacles that could slow the stone down. The sweeper will frantically dust away everything in the stone's path. They can't touch the stone, but they can keep everything else out of its way.

The sweeper is a good image for the ScrumMaster. They keep the stone moving forward by sweeping away anything that might slow the momentum. If you ever see an Olympic sweeper, you'll see that it takes a lot of effort to keep those obstacles away.

Your ScrumMaster will sweep away miscommunication and barriers to change. These are the obstacles that can keep an agile team from moving forward.

Gathering Work With The Product Owner

An agile team maintains a close connection between the customer and the developers. The customer is not seen as someone outside of the team. Instead, the customer is seen as a crucial driver of the team. The customer is the one who directs the team to deliver high-value features every two weeks.

This is a significant departure from how most organizations currently deliver products. There is usually a separation between the customer's department and the group responsible for delivery. In a traditional project, the customer usually throws the request over the wall and waits for something to come back.

The agile approach to delivery is much different. A customer representative sits full-time with the team and works to deliver the project.

As mentioned earlier, this representative is the product owner. In extreme programming, this role is called the customer representative. It is the product owner's responsibility to help create the product vision by helping to develop and monitor the product backlog.

The product owner will maintain the product backlog throughout the entire project and will adjust the backlog if there are new items to rank or if the developers cannot finish a task within a two-week sprint.

This makes the product owner the “North Star” for the project. Product owners keep the team focused and on track to deliver the highest-value items.

The product owner also creates the acceptance criteria. This keeps the developers from guessing what will make the project sponsor happy. The product owner says, “Here's what makes the customer the happiest, now let's do it.”

When developers pull things off the top of the product backlog, this ensures that they are developing the most important parts of the project first.

Ideally, the product owner will have a direct connection to the project's sponsor—the person who is funding the project. The sponsor is usually the final word on the project's deliverable. The product owner will ideally be part of the sponsor's department. Practically, that is very difficult to do because it is a full-time job and the sponsor doesn't always want to dedicate a full-time subject-matter expert to a project.

The product owner is the best resource for mining the talent in the organization. They will be responsible for tapping domain experts and making sure that all the organization's knowledge is available to the team.

The product owner is often referred to as the most challenging role in a Scrum team. They own the product.

The product owner, in conjunction with the product sponsor, will come up with a high-priority task list. The developers take that information and do their best to estimate the effort required to complete the tasks on the list. After the developers create the estimate, it is their responsibility to commit to that estimate and to commit to completing specific tasks within a specific sprint. If the task is too large to fit into one sprint, the developers may go back to the product owner and ask that the task be broken up into smaller subtasks so that the new tasks can be completed in one sprint.

As always, it is the developers’ responsibility to make sure that they are communicating to the product owner what work they will complete within a two-week sprint. It is essential that the developers go back and forth with the product owner to make sure that everybody understands what tasks are to be completed within each sprint.

Protecting The Team With The Project Manager

The project manager plays a central role in traditional project management. When you think about it, this makes a lot of sense. In traditional project management, a lot of emphasis goes into creating the plan. In an ideal project, all the work will closely follow the plan. Project managers are the people who help execute the plan. They don't usually do the work, but they make sure that everyone doing the work is proceeding according to the plan.

In an agile project, there is no detailed plan to follow. The work is not completely planned out at the beginning. The plan simply emerges over time.

The role of the project manager isn't clearly defined in any of the agile frameworks. Understandably, this causes some friction with many project managers. It's hard to motivate managers to embrace agile if they feel their role is less than essential. Also, project management has several structural challenges that make it difficult for many of them to see the path to follow when it comes to using agile.

One challenge is the variability that can be found within the concept of project management. Project management means different things to different organizations. Some organizations see a project manager as the key driver. They secure the funding, communicate with the sponsors, and closely manage the team. Other organizations see the project manager as an accountant or coordinator. They'll spend most of their time balancing constraints in tools like Microsoft Project.

This variability makes it difficult to make any widespread changes to project management. Unfortunately, any meaningful agile transformation will require these widespread changes.

Also, many organizations see project managers as a talent feeder into positions with greater responsibility. As a result, many project managers are ambitious and well connected. There are also many directors or senior managers who started out as project managers. They will tend to see the organization from that perspective. This will make changes even more difficult and uncertain.

It takes a very open-minded project manager to accept some of the key tenets of agile. The self-organized team, the product backlog, and the role of the ScrumMaster are all significant departures from traditional project management.

Despite these challenges, it is still possible for project managers to add value to agile.

There are usually two routes that project managers can take. They can travel upstream to the portfolio level or they can continue to work at the team level.

Portfolio project managers don't work on any one project. Instead, they work with a group of projects, or a project portfolio. Instead of enforcing any single project plan, they work on a group of projects to make sure that the projects all coordinate with one another.

Let's say that a company is making a web application and a mobile application. A portfolio manager might make sure that both of these applications have a similar design and color scheme. They won't do the work, but they might recommend that each project use the same designer.

If possible, it is much better for project managers to travel upstream to the portfolio level. The Scaled Agile Framework, or SAFe, is a useful method to help facilitate this transition to the portfolio level. SAFe is designed to introduce agile to larger organizations. This framework has a lot of roles that will be familiar to project managers.

In SAFe, many project managers become portfolio managers. They'll own the relationship with stakeholders and work with a familiar release schedule. Then they'll coordinate this work into an agile release train.

But not every project manager has the ability to self-promote to the portfolio level. Also, not every organization has a project management office. It's far more common for project managers to continue to work with the team. This requires a lot more effort to change. Project managers need to rethink the way they approach projects.

Project managers can help the team by translating agile work into something that's digestible to a traditional enterprise. That usually means working with the team to create milestones. They can also take the agile reports and charts and convert them into more traditional weekly status reports and schedules.

In this new role, the project manager will be protecting the team from sliding back into traditional project management. It will take a high degree of professionalism to work against what many project managers have done their entire career. It's almost like when a company hires a computer hacker to be its security expert.

To be effective, project managers will have to see a lot of value in agile. They'll have to drink the Kool-Aid and keep others from spiking the punch. For many project managers, this is a long journey.

There are a few things that project managers need to keep in mind during the transition to agile. The first and foremost thing to remember is that agile is a significant departure from traditional project management. It's all too easy to see new things as “more of the same with a new name.”

Many project managers don't accept that agile is a significant change. They'll say that two-week sprints are just project phases. They'll say that they've never micromanaged and so have experience with self-organized teams.

If you're a project manager and you're working with an agile team, it should feel very different. It's like starting out with yoga. If it doesn't feel uncomfortable, then you're not doing the move correctly. Try to accept that agile is a significant change. Then you can decide to work for or against agile in your organization.

Spreading Agile

The best way to start agile in your organization is to start small. Begin with a small core agile team and make sure they follow the framework. If you work for a smaller organization, that team could have as few as four people.

Then you can expand it in your organization through conversion-by-contagion. The conversion is successfully converting one team. The contagion is getting that team to sing the praises of agile to the rest of the organization. To get there, you need to focus on the team and make sure they're well trained.

Work closely with the team to make sure they know what they're doing. Try to keep this core team as happy as possible. If they like agile, then they'll be your strongest advocates for change. This small team will be the ones talking in the lunchroom with the rest of the organization.

Give them time to be successful. They should see the benefits of the change. Don't spend a lot of time trying to sell agile to the team. Instead, put all of your energy into making agile work well.

To get the team to work well, you need to work with your optimists and your skeptics. There is an old story about a drill sergeant who marched his troops for miles. They would plead with him to finish and the sergeant would yell back, “We'll be done when the slowest one finishes.” Your first agile team will be the same way. It won't be finished until the entire team is agile. This will include the team members who were excited right from the beginning and the ones who were very skeptical.

This core team will be your ambassadors for agile, so you need to make sure they are correctly following the framework. If the first team doesn't understand agile, then they will likely spread a lot of misinformation. In an organization, misinformation is usually much harder to stamp out than facts. A well-trained core team will keep you from having to do a lot of retraining in the future.

---

⁶ The Agile Manifesto Principle 9 states that “Continuous attention to technical excellence and good design enhances agility.”