A while back, I wrote 3 Legs to Standing Up an Agile Project from the perspective of an Agile team just getting started. Lately, I’ve been thinking about the same sort of thing, but from the perspective of a coach or an executive that wants to transform the organization. At first glance, this seems no different. Further reflection, however, reveals that this is less about “how to work in an Agile fashion” and more about “how to introduce change in the way people work.” The earlier post was a description what an Agile project needs. This one is a recipe for creating what an Agile project needs.

Teamwork

The fundamental practice of teamwork remains essential. Agile succeeds in large part by reducing wasted effort, and much wasted effort is the result of various people pulling in different directions. Even slightly different directions will create enough friction to noticeably slow the project. It’s well worth spending some time and effort on building an effective team within the context of the project. The two practices most essential for supporting teamwork in an Agile transition are working with a whole team in a common area.

Whole Team

While collaborative teamwork among all the developers, for example, is beneficial to any project, it’s not enough to accomplish a transition to Agile. At a core, you’ll need high-bandwidth collaboration between your Product Owner, Scrummaster, and Developers. This is the minimum, in Scrum terms. In most organizations, Developers really includes both programmers and testers; in some it includes user experience designers. Yours may include people with other titles, such as architect, database administrator, security officer, system administrator, operations engineer, technical writer….

Your project community will also consist of other stakeholders, such as executives, customers, end users, support personnel, other development teams, facilities maintenance…. There are a lot of people with interest in the project or the things that the project team is doing.

The boundary between the core team and the rest of the project community is rarely distinct. One useful distinction is whether a person is focused principally on the project, or whether the project is just one of many things with which the person is concerned. This distinction is not without peril, however.

All too often an organization will assign multiple projects to people where it would be much better if they were focused on one. If you give your Product Owner, your programmers, or your testers multiple simultaneous projects, you’re likely headed for trouble. You may be headed for trouble if you multi-task in some of the other specialties, but there’s more variation from one context to another. As a rule of thumb, if there is any way to let someone focus on only one project, then you should do so.

Common Area

Building a team, which is different from a mere work group, takes a lot of work. With skill, you can facilitate that teambuilding to help it happen more reliably and a little faster. If you don’t have a skilled facilitator, though, you’re still in luck. People have practiced self-organizing into small groups for their common good for millennia. If they’re working together for a common goal in a common area, distinct from those working on other goals, they’ll likely build a gelled team without an outside facilitator. There are many reasons for this, from trust building to osmotic communication.

“But we can’t do that,” I hear you cry! Why not? Is this project, this Agile transition, so unimportant that you can’t sit together?

“Our Product Owner has an office elsewhere, and needs to attend to other things.” Maybe you’ve chosen the wrong product owner. Maybe the Product Owner can sit in the team room for part of the day.

“Our project team is scattered around the globe.” Don’t do that. While it’s possible for people scattered around the globe to work together, it’s much harder.  The odds of making that work while also making an Agile transition are slim to none. If you must do distributed projects, set up a collocated team at each location and minimize the working dependencies between the teams.

“We don’t have a space that supports that.” Find or make one. Move furniture. Take down cube walls. Set up temporary or movable partitions. If the furniture arrangement is more important than the project, consider canceling the project.

Visible Progress

In order to see whether or not we’re headed toward our goals, we need visibility into the progress. Usually, this boils down to the questions “Are we going to get everything done?” and “Are we going to get done in time?” If the answer to one or more of these questions is “no” then we can make adjustments to how we’re doing things, how much (and which things) we expect to get done, and what time we expect to have them done. We can subdivide this visibility into two simple practices: taking baby steps and getting things done.

Baby Steps

Everything we do, from releasing interim versions down to validating the code we write, we should do in small steps. Working in small steps gives us a much finer-grained view of the progress. It lets us view the initial trends sooner. It lets us view changes in the trends sooner. It gives us more opportunities to make corrections or course changes. It gives us more practice and comparing where we’re going with where we want to go, so we get better at doing that. It requires less work before we see that we’re doing something wrong, or doing the wrong thing, therefore there is less work to be thrown away and redone.

Done

There’s little point in measuring something as progress unless we know that it actually contributes toward reaching our goal. Measuring amount of work done doesn’t tell us that. Consider this scene from the movie, Captain Ron:

Captain Ron: We should be okay. ‘Cause I know we’re near land.
Martin Harvey: Great, Cap. Great. Ya hear that? We’re almost there. Explain to the kids how you know that, Captain Ron. Someone translate for General Armando.
Captain Ron: Alright, now stay with me: When we left, we had just enough fuel to make it to San Juan. And we are out of fuel.

The gap in that logic is immediately obvious, but plan-driven projects attempt the equivalent all the time. We must measure relative to the goal, not relative to the path we’ve taken.

It’s important that we measure functional slices. It’s often tempting to measure tasks that have been accomplished. Sometimes, however, these tasks turn out to be unnecessary, and they don’t contribute to accomplishing the goal. Sometimes, while they look right in isolation, they turn out to have flaws when we look at the bigger picture. Sometimes they don’t quite meet with other tasks, and there is a gap to be filled between the tasks. Such a gap in unknown undoneness.

We need ways of seeing progress that won’t like to us about how much progress we’ve made, or how much is left to do. We want to measure functional slices that go all the way through the system. It’s easy to neglect some of the things that people think of “someone else’s responsibility” after the system is “complete.” These things might include an installation procedure, or deployment to a different computing environment. Sometimes people neglect something so basic as testing that the system works.

We want to see functional progress–something we can demonstrate and test, something we know is desirable. Expending the amount allotted is not such an indication. Getting most of the way to the goal is no guarantee that we’ll get the rest of the way there–particularly when the remaining part is fundamentally different than what we’ve been doing. We want to always, or at least at frequent intervals, be able to stop and have something that can be used, even if incomplete.

Putting these together can be difficult for a team making a transition to Agile. It’s hard enough to get everything working, but much more so when you’re having to do that all the time.

Fortunately there are a lot of well-known engineering practices to support combining baby steps with getting to done at each step. I’m starting with the assumption that the team is already capable of creating working software using whatever techniques they already know. Eventually they’ll need to learn other practices to support this new way of working, and even to get better in general.

Continuous Improvement

Being able to work as a team and measure progress in a visible manner is only the start. At first, we’ll do these things in a rather rough manner. As the system grows in size and complexity, that rough manner won’t sustain forward progress. We’ve got to get better in order to keep moving.

And there’s no limit to how good we can get. No matter how practiced we are, there’s further improvement we can make. If we conscientiously practice our techniques, we’ll see places where we can improve them. We can then practice those improvements, so they become a part of our routine, and we do them even when distracted by the latest disaster. When things go wrong, it’s no time to ease off on the practices that make us more effective.

As a team, we need to take stock from time to time to see the longer term trends, both good and bad, and the issues that only become visible in retrospect. Holding retrospectives at various tempos–each iteration, each quarter, each release–will give us various views into what we’re doing, and result in different insights. We must use these insights to plan ways in which to improve in the future.

From these starting points of teamwork and visible progress, and proceeding with a program of continuous improvement, we can learn all of the practices that support Agile development.