Leading Agile Teams

Doug Rose

• Publisher: Project Management Institute
• Year: 2015
• ISBN:
  9781628251043
• Edition: 1
• Topic: Business
• Subtopic: Project Management
• Index: Business

Leading Agile Teams is a practical and engaging guide to help your organization embrace a more agile mindset. Most organizations work in large groups when trying to find solutions for big problems. Agile teams are different. They get more done by having a small self-organized team focus on the highest priority items. Each big problem is broken down and solved by a small, stable group of dedicated professionals. This book will give you the knowledge and tools you need to create and sustain strong agile teams. It is written for the developers, project managers, product owners, and ScrumMasters, who do most of the legwork in getting agile up and running.

Chapter 1

The Road Ahead

One misconception about agile is that it is just a collection of new practices that were dreamed up in some multibillion-dollar high-tech company. Many organizations see it as the next big thing. The thought process is as simple as, “We're a high-tech company and high-tech companies use agile, so we need to be agile.”

These organizations tend to see agile as a few new things to do. They don't view it as a widespread organizational change.

You can see this from the feedback about agile transformations. Many organizations are trying agile practices but most are finding it challenging to change their overall culture.

Over the last few years, the agile software vendor VersionOne has put out a survey on the current state of agile. Their eighth version of the survey had about 3,500 respondents.

The respondents skewed heavily toward larger organizations. Seventy-five percent of the respondents came from companies that had between 100 and 1,000 employees. Of that group, about 85% reported that one or more of their agile initiatives had failed.

These findings strongly suggest that it wasn't the projects that failed. Instead, it was the cultural mismatch that caused many of the problems. Eighty-five percent of the organizations simply didn't accept that agile was a legitimate way to deliver software.

If you look at the results, you'll see at least half of the 85% failed because of well-established cultural norms. What this suggests is twofold. First, it seems like a lot of organizations started their initiative before they had a solid understanding of agile. Second, it suggests that after they started the initiative, it didn't sit well with the rest of the organization.

That's a pretty big problem. For one, it means that only a small percentage of agile initiatives are changing organizations. It also means that initiatives that do fail may be creating groups that are less inclined to retry.

Yet, the agile train charges on. A full 88% of the respondents said they were practicing some agile development. Over half of the respondents said they were using agile on a majority of their projects.

This suggests a gap between agile practices and the larger organizational culture. On the one hand, agile practices are widespread and used on many projects. On the other hand, most of the organization's culture seems to be opposed to agile. This causes a majority of agile initiatives to fail.

It is as if organizations are aware they have a problem and accept agile as a possible solution but don't like the taste of the medicine. This is one of the biggest challenges you should be aware of in attempting to change an organization to agile.

I go into some detail about agile practices, but I also try to give you a few examples of agile “choke” points. These are places where you will almost certainly run into trouble. If you are part of the 15% of projects that have the right culture, then you can gloss over these challenges, but this information is crucial for the other 85% who may struggle with agile projects.

Try to keep in mind that the practices in this book are only the first step. Please pay special attention to the “field notes” that show how these practices actually play out in organizations.

Chapter 2

Traditional Projects

For much of the 20th century, many projects worked just fine with a strategy of planning and control. Most of these projects were engineering pretty big things.

These early projects worked with iron, concrete, and hammers. They used physical objects that couldn't be deleted or remixed or easily reused.

These traditional projects typically had authoritative project managers who were an essential part of the project. They were large and in charge—a single source of accountability. Their job was to manage the project from start to finish.

In a traditional project, the project manager's work is deterministic. They help “determine” as many of the pieces of the project as they can. They try to create certainty. Each of the little project pieces is managed and catalogued.

They also divide the work into tasks. Then, they figure out how many people they need to complete these tasks. After that, they figure out how much it will cost to have these people work on the project. Finally, they determine the schedule for how long it will take each of these people to finish their work.

The project managers carefully control for the uncertainties and plan contingencies. Good project managers are judged on how well they plan the future and how well their project weathers the storms.

They use charts and reports that break down projects into smaller pieces. They use Gantt charts for their schedules and spreadsheets for the budgets.

This deterministic approach works very well for projects that can easily be chunked into smaller pieces. Rocket ships, highway systems, and skyscrapers in Chicago were all built using this approach.

This “chunking” is a type of science. It is about observing, guessing, and calculating. That is why it is often called scientific management. The project manager uses a scientific approach to divide the project into smaller pieces. Each of these pieces is catalogued and quantified.

The project manager overseeing one of these projects will use scientific management throughout the project. For example, the project manager will calculate that five people working eight hours a day can lay one yard of cement in four hours. That means in eight hours, 10 people can create four yards of a new highway. The person is one chunk and how long it takes that person to complete the task is another.

These are just two of the little deterministic chunks that a project manager might define. In a larger project, there might be hundreds or thousands of these deterministic chunks.

All of these identified chunks are then rolled back up into the three project categories—scope, budget, and schedule.

All the little pieces that the project needs to deliver are rolled up into the scope. The cost for all the people, places, and things is rolled up into the budget. How long it takes to complete each of the tasks is rolled up into the schedule.

These three categories are the project's key constraints. Each one is closely related to the other. For example, if you add more tasks, then you need to add either more people or more time. If you need more time, then you have to increase the budget or remove some of the work.

The scope, budget, and schedule give the project form and structure. It's what separates the project from just a bunch of people working.

These constraints rely on the fruit of all of the project manager's deterministic scientific planning. The scope is all the pieces the project needs to deliver. The schedule is all the tasks that need to be performed. Each of these is the sum of all the little pieces that the project manager gathers up about the project.

Pro Tip

The scope is what the project delivers. It is also what the project requires for delivery. This means the scope of a new bridge is both the bridge and the building of the bridge. The project team works with the customer to develop detailed requirements that chunk the scope into smaller deliverables.

This was the Iron Age of project management. Projects were ruled by the rigid “iron triangle.” The scope, budget, and schedule each held a corner of the triangle. You couldn't change one without impacting the other two.

As the name implies, this rigid approach adds structure and inflexibility. Any changes require a rigorous change-control process. Each change impacts the other corners of the triangle. That means that each change request must be documented and balanced against the rest of the project.

The Project Management Institute

Many project managers recognized that although each project was different, many of the tools and techniques that they used were similar. The scope, budget, and schedule were the same constraints that affected every project. It made sense that each of the control processes for these constraints should have some common traits.

These project managers started to create a shared project management framework. This helped define project management as a discipline. Ideally, a project manager was the person who implemented the new project management framework.

One of the earliest contributors to this framework was the Project Management Institute (PMI). PMI formed in the late 1960s to foster professionalism in project management. Soon after it formed, PMI made an effort to standardize project management.

PMI developed and published A Guide to the Project Management Body of Knowledge (PMBOK® Guide), which provides guidelines for managing individual projects and defines project management related concepts. The fifth edition of the PMBOK® Guide is comprised of 5 Project Management Process Groups, 10 Knowledge Areas, 47 processes, and 614 inputs, tools and techniques, and outputs.

Pro Tip

PMI never endorsed one project management approach. They simply tried to create a guidebook for all projects to follow. In practice, the PMI guidebook still encourages a structured, process-heavy view of the project. You can't use 614 inputs, tools and techniques, and outputs without some structure and process.

The PMBOK® Guide views a project like a complex machine with many moving parts. Project managers use common tools to manage the machine. They use the 614 tools and outputs like buttons, levers, and switches to manipulate their project machine.

The tools and the machine help to manage the project's iron triangle. The more you understand the processes and tools, the more likely your project will succeed.

That is why there are more than half a million Project Management Professional (PMP)® certification holders. They work like project machinists to keep the project running smoothly.

Waterfall

The PMBOK® Guide closely follows a traditional engineering approach. These projects use a big-design-upfront or waterfall-style approach. The waterfall approach is still a popular way for engineering projects to work within the three constraints.

The idea behind the waterfall approach is that you have to spend a good deal of time at the beginning trying to understand all the pieces of the project. Only after you've planned the project from beginning to end should the team start working on the deliverable.

From an engineering perspective, it certainly makes sense to understand where the road is going before you lay cement. These assumptions heavily influenced traditional project management and were the reason behind waterfall's widespread adoption.

The waterfall approach breaks the project down into sequential phases. Each phase leads to the next. In each phase, there is a carefully designed set of control processes. First, you plan a project, then you design it, then you execute it, then you test it, and then you are done.

Even if you don't recognize the term waterfall, you'll probably be familiar with this approach. The top of the waterfall is the planning phase. This is when the project team does most of the deterministic project planning. They try to identify all the little pieces of their project.

The planning phase is very challenging. The manager has to predict the project's pieces before any of the work begins. As you can imagine, this usually takes a lot of legwork...