Agile Management

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

Get this book in Print, PDF, ePub and Kindle at manning.com. Use code “MSDN37a” to save 37%.

This topic contains the following sections.

• More Shepherding, Less Directing
• Creating a Team with an Agile Mindset
• Key Points
• Copyright

More Shepherding, Less Directing

Do you remember a commercial for a company named BASF a few years ago? Their slogan was, “We don’t make a lot of the products you buy. We make a lot of the products you buy better.” This is true of the Agile manager.

An Agile manager never writes a line of code, never documents any requirements, and never tests a feature. Instead, an Agile manager does the following:

• Helps the development team track true status

• Encourages the automation of redundant, repeatable tests

• Mentors the team on Agile processes and demonstrates their value

• Helps the team break their work into small chunks that can be delivered quickly

• Ensures that the work being delivered is in tune with the customer’s needs

• Acts as a buffer for outside interruptions and limits team distractions

Jim Highsmith offers a good explanation of light-touch leadership in an Agile environment:

While Light-Touch Leadership may be “light” in terms of decision making, it’s heavy in articulating goals, facilitating interactions, improving team dynamics, supporting collaboration, and encouraging experimentation and innovation. These characteristics of a leader are more critical to success than delegation of decision-making authority, but decision making is still an important piece of the leader’s role. When a good Light-Touch Leader is working, she or he is nearly invisible. Things seem to happen smoothly and the teams operate seemingly without a leader.

An Agile manager provides leadership without using formal power. Instead, the manager leverages the respect they earn from the team as they establish a history of working together to successfully deliver projects.

What does a manager need to do to establish a record of successful project delivery? Let’s start with the soft skills.

Soft Skills

If you look up soft skills on the United States Air Force website, you’ll find, “A set of skills that influence how we interact with each other. It includes such abilities as effective communication, creativity, analytical thinking, diplomacy, flexibility, change-readiness, and problem solving, leadership, team building, and listening skills.”

This definition is an excellent prescription for the behaviors an Agile manager needs to subscribe to:

• Effective communication, to ensure that the team is synchronized on information

• Analytical thinking, to help the team brainstorm solutions when they encounter a challenge

• Diplomacy skills, to ensure tactful communications that don’t offend or touch on sensitivities

• Great listening skills, to not only ensure accurate understanding but also enhance relationships with others

In summary, the manager should behave in a way that enhances human relations (see Figure 7.2).

Diane Ehrlich, PhD, of the Human Resource Development program at the University of Illinois, defines soft skills as “[t]he skills needed to perform jobs where job requirements are defined in terms of expected outcomes, but the process(es) to achieve the outcomes may vary widely.” This is a good description for Agile development in general. You have a desired output (a project), and the way to achieve that output may vary wildly depending on the specific needs of the project.

Now, let’s discuss how soft skills are used.

Figure 7.2 An agile leader brings their soft skills together to shepherd the team versus directing them.

Working with Other Managers

Let’s look at team management from the perspective of the person who spends the most time with the team: a project manager or ScrumMaster. These individuals usually lead a group of people who are not their direct reports. In order to do this, the project manager or ScrumMaster must have the respect of the line managers who own the functional teams. The key is to ensure that the line managers buy into Agile concepts before asking the project team to.

The line managers need some level of training before you pursue an Agile migration. This training can come from any resource, internal or external; but during this training, managers need to normalize on their support of the principles. You don’t want to ask the manager’s team to buy into the process before the managers do.

You must also consider roles when working with other managers. Although everyone is flexible in the tasks they perform in an Agile environment, everyone will have areas of responsibility.

Consider the development team. The development manager usually acts as a technical mentor and also assigns tasks to the development team. Historically, the development manager may have been in charge of reporting status for the team, too. This changes in an Agile environment. Agile teams perform a 10-minute daily stand-up meeting that allows the entire team to discuss what they did, what they will do, and any roadblocks they have encountered. Team members speaks for themselves, and status isn’t passed to a go-between manager. Traditional managers will need to learn how to provide value and interact in this open atmosphere.

Working with Stakeholders

Stakeholders are also vital to your project success. Stakeholders are those who have interest in or influence on the project. Typical stakeholders include senior management along with indirect customers such as support teams, maintenance teams, help desks, third parties that integrate with the system, and other related product groups within the company.

All the soft skills mentioned earlier are useful when you’re working with stakeholders. The stakeholders may not be the project’s main customers, but you want them to feel valued. You should demonstrate good listening skills and make sure they know you understand their needs. You also need to demonstrate diplomacy and not upset the stakeholders by consciously providing information in a way that will inflame or incite them.

Demonstrating Value

The most important role of the Agile manager is to exemplify the Agile principles and live them daily. If you want the team to follow you, you must provide a strong example. There are numerous principles to emulate and follow. Here are the ones that provide the most impact.

“Just Enough” Planning. In traditional project management, you identify features and then specify their requirements. Typically, an analyst wants to answer every question possible in the specification so the development process isn’t impeded by a missing requirement.

In Agile planning, you want to plan “just enough.” Just enough planning to determine which features you want to build. Just enough coding to demonstrate the feature to the customer and verify that you’re on track.

Old planning habits are among the hardest habits to break with a traditional team, and the Agile manager needs to champion the just-enough mentality on a daily basis. You can also emulate this behavior by creating project plans the same way: a plan that has just enough information to get to the next level of the project, not a complete work breakdown structure before development has even begun.

Always Ready to Stop, Drop, and Deliver. Agile development is performed in iterations to enhance urgency and to support early delivery of the most valuable functionality. The project manager needs to infuse this mentality into the project team.

You need to get the team to inject the same urgency into an iteration that they do with a final deployment deadline.

Unrelenting Pursuit of Customer Value. An Agile manager is always thinking about the customer and their needs. All other measurements of a project are meaningless if the product delivered is of no use to the customer. Follow these three steps to ensure that you address the customer’s needs:

1. Clearly define the customer(s). Many projects get underway with an incomplete understanding of who the customer is. Make sure your customers are clearly defined and their specific needs are clear.

2. Develop a relationship with the customer. Get to know the customer well, and integrate them into the project team. Use your soft skills to collaborate with the customer frequently and make sure they can be easily accessed by the team.

3. Be an advocate for the customer at all times. When features are being discussed and the customer isn’t present, put your customer hat on and envision what their response would be to the discussion. Share those thoughts with the team.

Ensure Technical Excellence. The technical skill sets of Agile managers vary. A manager can come from a classic Project Management Institute (PMI) background, can be a former developer, or may have worked as a business analyst in the past. Regardless of technical knowledge, all Agile managers can push the team to pursue technical processes that embody Agile beliefs. Here are a few of the best practices for obtaining technical excellence:

• Create a process for continuous code integration. As functionality is completed, developers integrate their work into the existing code base. The key is to integrate as small pieces of functionality are completed, as opposed to waiting for a complete feature. This practice identifies code issues early and minimizes the complexity of tracking them down.

• Automate testing wherever possible. Work with the team to automate testing wherever possible. This is usually easiest to do with regression testing. You can also automate daily smoke tests to speed up testing.

• Perform a daily build/smoke test. Related to automated testing, a daily build also helps mitigate risk by identifying code issues early. The daily test focuses on ensuring that the application’s critical pieces are still functional.

• Consider scalability. As an application is being developed, the team should consider future growth. What will happen if the application is extremely popular and usage exceeds expected volumes? The team can consider scalability as they design, keeping scalability in balance with simple design.

• Follow the principle of simplicity in design. You should avoid cowboy coding and deliver to the minimum requirement. You should also create the simplest design that will work.

When you’ve learned how to lead an Agile team, you can begin teaching the team how to take part in ownership of the process.

Leading the Team to Ownership

In 1998, Arthur Andersen published a book titled Best Practices: Building Your Business with Customer Focused Solutions. One of the best practices outlined in the book is the ABO Continuum. This continuum identifies a vital element in introducing change to an organization: ensuring ownership of the change.

The continuum promotes the belief that organizational change goes through the following three steps:

• Awareness. In this phase, information about the change is shared early and informally. For example, during a team meeting, a manager can say, “The executives are discussing improvements for our development process.” The manager can also indicate when they think they will hear more, and see what the team reaction is.

The value isn’t so much in what is said as in when it’s said. Every individual has their own timeframe for evaluating a change. The earlier you can make a group aware of a potential change, the better your chances of getting them to buy into the change when you’re ready to roll it out.

• Buy-in. This phase occurs when you roll out the change and begin implementing it. You created awareness earlier, and you’re looking for the team to consider the change and to use it with your guidance.

• Ownership. The team has tried the change, begun to believe in it, and adopted it as a standard practice. They don’t need management to encourage them to use it. They believe in it and will use it without being prodded.

The ABO Continuum is a great approach for rolling out an Agile methodology.

Now that we’ve outlined the characteristics of an Agile management group, let’s discuss creating an Agile mentality within your project teams.

The ScrumMaster

Scrum has become one of the most popular Agile packaged methods. The ScrumMaster is at the heart of Scrum. This individual isn’t a manager but more of a process facilitator and guide. A ScrumMaster does the following:

• Helps the team develop practices that support Agile principles

• Acts as a guide in training the team on how to be Agile and use Scrum

• Removes impediments that prevent the team from delivering software

• Shields the team from corporate bureaucracy and activities that don’t add value to software development

• Champions engineering excellence and processes that support the creation

• of shippable software

• Ensures that the team has direct access to the customer

Note

We believe Scrum is a good Agile framework, especially when there is urgency to establish a development process quickly. But we worry that some teams can become too dependent on the ScrumMaster.

Our opinion is based on something we learned when we became certified as ScrumMasters. Our instructor told us that ScrumMasters are the key to Scrum’s ability to transform the organization. He also told us that ScrumMasters are responsible for team health. We understand that not everyone was taught this principle when they became ScrumMasters, but we are still concerned that many people believe the ScrumMaster is the sole owner of team health.

Over time, we’ve come to dislike the thought of one person with so much responsibility. In our experience, leads and managers have shared ownership when we migrated to Agile. Our teams included definite Agile experts and leaders, and we frequently asked those experts for guidance; but we never asked the experts to own the process or team health. We did this collaboratively as a leadership team. We’ve found this method to be successful because we do get expert opinion, but we don’t relinquish ownership of team health or the development process to one person.

Creating a Team with an Agile Mindset

An Agile team comes across as poised and ready for wherever the project may lead them. Agile team members don’t fear uncertainty; they look forward to the challenge and know they will succeed.

Where does this air of self-assurance come from? Does this attitude reflect the type of people who were hired? Or does it reflect the processes that are being used? Is the attitude a byproduct of executive support? Does confidence come from a history of successful deliveries?

The answer to all of these questions is Yes. Each of these items supports the effectiveness and self-reliance that is inherent in an Agile team. In some ways, creating an Agile team is like baking a cake. You can obtain the ingredients exactly as the recipe requests, bake at the suggested temperature, and let the cake cool the specified time before applying the icing. But what happens if you’re at high altitude and you forget to make the necessary adjustments? The cake rises too quickly and then turns out too dry. Or what if someone jumps up and down in the kitchen while the cake is baking? The cake collapses and never rises.

In this section, we’ll give you the ingredients for creating your Agile team.

Culture and Roles

We find it hard to describe Agile team culture in a sentence, but we can easily describe it with several words. The words that come to mind are collaborative, open, passionate, courageous, honest, lighthearted, driven, synchronized, customer focused, funny, responsible, innovative, and successful.

The culture is one of low politics and high transparency. Words are honest but not abrasive. Status is discussed in matter-of-fact terms. The team focuses on the situation, not the person.

Estimates are honest. There is no padding to make the work easier to do. There is no lying about how long it will take, in order to appease management.

Another nuance of an Agile environment is the roles the team members play. Other than as suggested by Scrum, Agile doesn’t specify what team-member roles should be. In our experience, this hasn’t been an issue. The teams we’ve worked with didn’t change their roles after they migrated to Agile. We still had developers, testers, project managers, product managers, customers, DBAs, and operations personnel.

What did change for those teams was attitude. After we migrated to Agile, we rarely heard a team member saying something like “development isn’t responsible for that” or “quality determines when the code is acceptable.” We saw many more team decisions and much more collaboration around problem solving. A problem wasn’t tied to one role that had to solve it. Instead, it was tied to the project, and the team had to solve it. An Agile team focuses on the goal, not their job descriptions.

The last item related to culture is diversity. If you don’t have a diverse team, your Agile process can lead to groupthink. Groupthink happens when team members want to get along with each other so desperately that they won’t voice their opinion when they disagree with an idea. This is a definite danger with Agile. People assume collaboration means harmony and always getting along. They think that if they start agreeing with each other all the time, they’re being collaborative. In fact, good collaboration often includes disagreement.

The reciprocal of groupthink is diverse opinion that is spoken freely. This is what you want in your Agile environment. A good example of this occurred during the Apollo 13 space mission. In this instance, an explosion occurred aboard the spaceship while it was on its way to the Moon. The ship and crew were saved with a little luck and some spectacular collaboration.

Note

A Classic Groupthink Example: The Space Shuttle Disaster of January 28, 1986

The space shuttle Challenger was preparing to launch on a cold day—the weather was colder than it had been for any other space shuttle launch. One of the engineers from a company that supplied parts to the space shuttle warned that there could be risk in launching. He was concerned that the O-ring seals his company provided might fail in the low temperatures because they had never been tested below 53 degrees Fahrenheit. The engineer shared this concern during a teleconference with NASA, and NASA urged him to reconsider his recommendation to not launch. The pressure from NASA persuaded the company to acquiesce to the request and overrule their engineer’s warning. Subsequently, the O-rings failed just after launch, leading to the death of the entire Challenger crew (Griffin 1997).

As the Apollo 13 crew experienced various issues in trying to return to earth, the support team on the ground went through days of brainstorming and collaborating to solve the problems. No one team member had more influence than another in suggesting a solution, and “getting along” wasn’t a requirement. When problems were discovered, ideas were discussed passionately until the group reached consensus.

Culture isn’t an optional ingredient in your Agile recipe. The majority of the team must embrace the Agile culture or you won’t be Agile—you’ll just be a team that calls itself Agile and goes about business as before.

Let’s take a moment to look at the building block of the team: the individual.

Characteristics that Influence Individual Performance

Not everyone on your team needs to be competent and mature, but you should put a system in place that breeds competency and helps the entire team become competent over time. But just as in traditional development, competency alone doesn’t guarantee team success. Several factors affect the productivity of an individual. Let’s review a few of them.

Motivation and Reward Structure

A talented, mature individual won’t stick around to work on your Agile projects if their efforts aren’t rewarded. A person who is talented can frequently choose where they want to work. It’s up to the company to create an environment that attracts and retains talented individuals.

In simplest terms, behavior reflects incentives. What incentives can you provide to attract talented individuals to your Agile team?

Consider the following items related to motivating and rewarding the individual:

• Is the mission of your company clear? Has it been clearly communicated to each individual? Employees want to know where the company is going and how their projects tie to the vision.

• How is health of your company? Are you doing well financially? Are you a startup fighting to survive? Company health can tie to motivation in two ways. First, if you’re healthy and growing, you can convey this message to employees and tell them that you offer stability, growth opportunity, raises, and potentially equity. If you’re struggling to survive, the message is the importance of the project and how it affects the destiny of the company. Everyone wants to work on projects that are important.

• The Agile environment stresses the value of the employee beyond their job title. They make management decisions and are responsible for proactive communication. Talented individuals welcome this environment. Employee evaluations should recognize and evaluate collaboration skills.

Another factor related to employee motivation is career stage.

Career Stage

As you migrate to Agile, you must consider various approaches to moving your employees to an Agile mindset. To help you determine the approach to use, consider where each employee is in regard to their career. Here are the main stages and suggested approaches:

• New employees. Employees who are in a stage of rapid learning and trying to understand the company and processes around them. They’re dependent on others to get things done, and they’re working to become independent from support. Such employees enjoy learning Agile because it levels the playing field for them. They’re at ground zero, just like senior employees, and they’re comforted by the fact that everyone is learning Agile together. They should also do well using the methodology because they don’t have a lot of previous experience to bias them.

You don’t have to do anything special with these folks. Just be sure they get the same training as everyone else and that they’re offered the same opportunities as other team members.

Individual contributors. The employees who make up the bulk of your teams. They aren’t new, and they aren’t supervisors or managers. They have a medium to large amount of experience, and they may have chosen not to become managers but instead to become an expert in their functional area.

These folks require the most management, and you must address their needs individually. Some general tips for motivating these employees are as follows:

• Give them an area to own and be responsible for in your migration.

• Give them an opportunity to use and share their expertise.

• Give them a chance to be innovative and unique.

A lot of these employees are looking for growth and embrace Agile. Some of them are just getting comfortable with the way things have always been done and resent having to learn another new thing. Be patient with the “resenters” and remember them when the time comes to criticize the Agile design: their feedback will be valuable.

• Coaches are employees who are motivated by sharing their experience and mentoring others. They’re also looking for an opportunity to renew and revitalize themselves. An Agile migration project is just what the doctor ordered for these employees.

• Give these employees leadership opportunities during the migration, such as resolving design issues or leading the team to consensus. They can also be on the forefront of receiving Agile training and can mentor novice employees on the process.

Key Points

The key points from this chapter are as follows:

• Moving to Agile requires a change in practices and culture.

• Moving to Agile takes time. For optimum results, you need to allow time for your company to digest the change.

• An Agile coach will help you move to a more Agile process by mentoring and training your team.

• An Agile coach will help you assess your team’s ability to increase agility and also help you design a more Agile process.

• Managers need to learn how to lead in an environment with empowered teams.

• Managers will earn their money by knowing when to lead, when to help, and when to let the team run on its own.

• Team members can maintain their existing roles, but a long-term goal for your team is to cross-train and to minimize dependency on specialized skills.

• You must consider the needs of individuals when you move to Agile. Address the needs of the new employee, the individual contributor, and the coach.

Previous article: The Role of an Agile Coach

Continue on to the next article: Feature Cards

Copyright

©2009 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.