Most of the time, when I hear about “agile change,” someone in management has decided that Scrum (and maybe XP engineering practices) will improve quality and time to market for the company’s software products.

I’ve heard some success stories. And I’ve heard about many failures.

Why do these efforts fail?

Some people blame the failures on mis-understanding Scrum, or not applying it with sufficient rigor. Both of these may be true. But I see a different thread running through these failures. Often the failed change initiatives nibble at the edges, without changing the way work flows through the organization. And that’s a management problem.

What if the change–not just the directive to change–started at (or near) the top?

Here’s are six management practices that will improve the way work flows through the organization.

1. Get Middle Managers Working Together

Many organizations make it difficult for middle managers to work together by structuring goals that foster local optimization and competition. For example, a development manager might be rewarded for meeting a date, while test managers are rewarded for releasing a product with few bugs. It’s easy for the development manager to meet his goal if he doesn’t care about the test manager’s goal.

Other companies are organized so that managers for different products must vie for scarce development resources to meet their goals. The winner isn’t always the organization or its customers.

If you current organizational goals foster conflict or competition, fix them. They take the focus off the real goal, delivering valuable products to your customers. Optimize for the organization’s success, rather than focusing managers on goals that detract from the end result.

2. Decide What to Do and What Not to Do (At Least Not Now)

Ray Cummings said, “Time is what keeps everything from happening at once.” The laws of physics say it can’t happen all at once. So why do we keep trying to do everything at once in our companies? I’ve spoken with several development managers who have a personal policy of never saying no to a request from the business. That keeps the conversation happy for a while—until it becomes clear that it’s not possible for the development team to do everything.

One of the biggest problems in companies is trying to do too much at once. That drives multi-tasking, context switching, and wasted mental cycles. It slows down delivering value to customers and realizing revenue.

But if you want to focus, you need to …

3. Manage Your Product Portfolio

You probably know which products are valuable to your customers and the company. But do you know why? Go and find out. (For some ideas on learning how your customers view your products, see Know Thy Customer.)

Make a retirement plan for products that are waning in value to the customer or the company. Those products will suck up both intellectual and monetary resources.

For the products you will produce, determine which features need to be delivered and in what order. A Kano analysis can shed light on which features have to be there to make the sale, which enhance attractiveness, and which are clear differentiators.

4. Realize the Benefit of the Team Effect

Establish stable cross-functional teams to work on software products. Groups of people who are assigned to one project but report to different functional managers are less likely to jell as a team. When those same people are assigned to more than one project they are extremely unlikely to become a high performing team. Groups of people who have a clear membership and a clear charter jell into teams.

It takes time to build the communication, trust, and commitment that foster high performance. Many organizations rearrange teams every few months to meet the needs of current projects. That obviates the benefit of the team effect. Rather than bring the team to the project, bring the project to the team. A given team may need to add a new member for a particular skill–which is more effective than breaking down, re-staffing, and restarting whole teams.

5. Embrace Adaptive Planning

Don’t use deterministic planning for projects that aren’t deterministic. For most software projects, detailed plans only give the illusion of predictability. Further, they encourage managers to shift the blame for missed dates to the team.

Instead, use adaptive planning. Chart a course, knowing that the competitive landscape and internal factors (e.g., the capability of the team, viability of technologies) may drive the need to adapt and re-plan.

Find a way to measure progress that’s meaningful and reliable enough to let you extrapolate into the future. You won’t find perfect measures of progress or capacity–and if you could they’d probably be too expensive to implement. You need something good enough to make decisions about planning and promises. Gaging team capacity using story points, along with establishing a common definition of done are reasonable starting points.

Adaptive planning works better in the real world of software projects. But it does put responsibility for tough decisions squarely with management.

6. Continue to Improve

Once you have stable teams focused and working on the most valuable products, congratulate yourselves—you are ahead of many companies. But don’t stop. Create a culture of problem-solving leadership though out the company.

Examine policies, procedures, and structures that may have worked at one time, but don’t support the emerging pattern. Some of the first places to look are training policies, hiring practices, differential pay and rating practices, formal approvals, budgeting, and audit policies. Make sure your policies and procedures are working for you and not against you.

***

Some people say Agile could never work–it’s just the latest silver bullet. Agile may be reduced to silver bullet status, if managers expect to solve significant organizational problems by working only at the engineering team level.

But if mangers address the way work flows through the organization, it will make a real difference when development teams start to use Agile Methods. No software development method can solve problems of throughput, quality, or product fit unless management also changes.

As a manager, your job is to organize people and work for success. That includes work design–figuring out whether you have a group or a team and creating an environment where people can do their best work. I don’t know about you, but work design wasn’t part of my training as a technical person, and it’s not explicitly included in many business and management programs.

The default belief seems to be “teams and collaboration are good,” and in a previous column I wrote about the benefits of collaboration. But is collaboration always possible? Is it even the right thing to do in every situation?

In this article, I’ll show different levels of collaboration and lay out the questions that managers need to answer to decide whether they have a group or a team.

Connection

Josh and Julie work in a tech support area. The primary responsibility of the unit is to configure, tune, and support servers. The workflow is controlled by a ticket system, in which the requestor submits an order with basic requirements and most of the work is handled first in, first out. Of course, there are exceptions when there’s extra lead time to order a special server or establish the configuration for a new product, but those orders are the not the rule.

And though different people excel in different areas and each brings unique talents, most server installs in their company require a core set of skills.

Josh, Julie, and their coworkers have a connection. They share professional skills, hold each other in high regard, and let each other know what they are working on. They help each other when asked, but they don’t really collaborate. The workflow in their department isn’t conducive to collaboration, nor does the work require it. They may call themselves a team, but they aren’t engaged in teamwork, and that’s just fine. There’s nothing wrong with being a workgroup if that’s what the work needs.

Cooperation

Deb and Doug report to the same manager and run test labs for two different products. Because their respective products are on different release schedules, there are times when the equipment in each lab isn’t fully booked. They cooperate with each other by loaning resources when it’s possible and makes sense to do so. Deb and Doug are working together to meet organizational goals, but they aren’t a team.

Coordination

Frank and Frannie work in a product development group. Each has responsibility for a distinct product aimed at a different consumer group. They meet on a regular basis to keep each other abreast of release schedules. They consult with each other about market trends as they prioritize features. It is necessary to coordinate, but given the product mix in their company, it’s not necessary for Frank, Frannie, and the rest of the group to collaborate with each other to achieve their goals. No team here.

Conglomeration

Ellen and Eddy work on a large project–over one hundred people. Their manager calls it a project team, but they wouldn’t recognize each other if they passed in the hall. Their project is too big to truly be a team, though there are subgroups within the larger project that function as collaborative teams. Groups larger than twelve or so almost always break down in to subgroups–which may or may not be teams.

Collaboration

Abby, Alec, and their four teammates work on a software development team. They have overlapping skills, all of which are necessary to build the product. They jointly commit to a goal and work very closely to deliver working software in two-week iterations. They also share mutual accountability. If they don’t work together, they won’t succeed. They are a team.

So, as a manager, how do you determine how to organize people to accomplish goals?

1. Consider the work goals. Are people committing to a leader to achieve individual goals, or are group members mutually committing to each other and sharing accountability?
2. Examine the skills needed to do the work. Does all of the work require the same (or similar) set of skills, or does the work require a broad range of skills?
3. Analyze the work. Does it consist mainly of projects that one person can complete from start to end (e.g., individual products)?  Or does the work of several people need to integrate to create a coherent whole (e.g., collective products)?

If you answered yes to the second question in each pair, the work is probably best suited for a team. On the other hand, there’s nothing wrong with workgroups that aren’t teams. If you answered yes to the first question in each pair, the work is probably best suited for a workgroup. Your management job is to determine which will best meet the needs of the work. Then, create the environment that best suites the needs of the group or team.

Building a team doesn’t happen by accident, and your job as a manager of a team will be different from the manager of a workgroup.  More on that to come.

This column originally appeared on stickyminds.com.

When managers want to improve financial results, they turn first to trimming costs.  This is the logical first place to look if balance sheets are your primary view into how the organization functions.

Many cost cutting measures do have an immediate effect on the balance sheet.  A layoff reduces labor costs immediately.  Cutting travel, training, and conferences is less dramatic, but also shows immediate effects. There are more targets deep in the budget detail lines:  unplugging the break room coffee machine, rationing pencils, paper, markers.

But the cost of cutting costs rarely shows up on the financial reports.

A small engineering firm axed the company lunch room and eliminated over $200,000 per year in costs. That gave an immediate boost to the bottom line.

One side-effect was visible immediately. Without the lunch room, some people at ate their desks, and some left the building for lunch. That was probably a wash, with the longer lunches canceled out by quick lunches gobbled while catching up on email.

A more insidious side-effect was invisible (at least on the balance sheet) for several months. The lunch room had been a hub of informal, cross-department communication.  People who didn’t meet in the normal course of business ran into each other over lunch.  Someone from environmental remediation might learn about a new potential project from someone working on a run-off project in the mining division.  Someone working on a mine project might learn that one of the landscape architects was looking for more work, and bring him in on a site remediation project.

Middle managers lost the big picture of what was going on in the company—which made it more likely they make decisions that were good for their group, but bad for the company. Specialists lost opportunities to gain the perspective of other disciplines on their projects though informal means.  Formal consultation required a billing number, so they didn’t happen.

That led to poor decisions, and disappointed customers.  It took half a year before the communication gaps started showing up in project cost over-runs. Finally, the company lost a customer.

That captured management attention. The immediate response was to make more cuts—including a layoff.  Fortunately for the company, one of the partners insisted on a systemic analysis to explain what had changed before taking drastic measures.

Focusing on costs almost always increases costs, even if the balance sheet looks better (at least in the short run).

If you want to improve financial results, don’t just look at the balance sheet.  Look at how your company creates value for the customer.

For a start, follow a product from the idea stage all the way to software on a customer’s computer and money in the bank. There are almost always ways to make value creation faster and more effective.

You can start with a simple flow sketch.  As you make the sketch, notice:

How much coordination overhead is self-inflicted?  One organization I know had trouble developing by feature.  The company was organized by component groups. Each group had it’s own set of requests and it’s own schedule—which by some mechanism resembling a miracle—was planned to come together in a working release every six months.  Managers spent weeks negotiating, cajoling, and demanding time from various component groups to get a feature out the door.  Once they gained agreement, it was  full time job to facilitate meetings, track  tasks across multiple groups, and manage dependencies. When decided to try a cross-component team as an experiment, most of the coordination overhead disappeared.

How much rework might be avoided?  Another was developing by feature, but waited until all the functions with in the feature were coded to start testing, usually a period of three to four months.  Then they began the process of discovering misunderstood requirements, infrastructure that didn’t work as anticipated, and errors that started in one part of the feature and were then perpetuated through-out the feature. Most companies can’t afford (and don’t need) a process that eliminates all rework.  But there are methods that can reduce rework and find and fix errors early, before the rest of the software is build on a shoddy foundation.

Where are the delays in the process?  Delays in knowledge work often center on decision making and approvals—involving the wrong people, excessive sign-offs up the chain, processes where the rigor doesn’t match the risk.  (A friend told me about an approval process in this company that cost over $50,000 in management time to okay purchasing a $300 piece of software for one desktop.)

These are just three of the areas for opportunities to enhance value creation. And when you do that, costs will go down. Focusing on how you get products out the door and making that process effective will improve financial results in the long-run more than any one-time cost-cutting measure will.

***

If you are ready to explore value creation in your company, I am here to help. Curious about how we might work together?  Start here.
© 2010 Esther Derby

Questions matter.  The questions we ask open one avenue of inquiry, but close others.  If we want to change the way we manage, we need to change our questions.  And so, here are my slides from my talk at Agile 2010:

14 Essential Questions aimed at refocusing management attention on creating work systems that work–creating products the customers want, returns that are acceptable to stakeholders, and providing satisfying work for employees.

I’m a big believer in 1:1 meetings on manager-led teams. It’s a way to connect with people, stay in touch with progress, learn about problems early, coach, work on career goals, offer feedback.

But if you are the manager for a self-organizing team, you need to adjust the way you do 1:1 meetings.

First, unless you are coaching someone on task accomplishment, do not ask about progress and status of tasks. On self-organizing teams, team members organize the work and make commitments to each other. If you as a manager insert yourself into this, you are communicating the the commitment is still to you, not to other team members. If you want to know about task progress, walk into the team room and look at the task wall or burn down chart.

You will probably have less visibility into the day-to-day workings of the team and team members. That means you are less likely to have useful feedback to offer on a regular basis. Ideally, much of the feedback on a team should be peer-to-peer. You need to get involved when the team has tried (using effective feedback techniques, not hints, not vague general statements), there hasn’t been a change, and the behavior is impeding the team. Getting in the middle of a feedback between team members when you don’t need to only creates problems and erodes trust on the team. When someone comes to you hoping you’ll carry a message for them, coach them on how to offer effective feedback, so the situation gets handled where it lives, between the team members.

Don’t meet every week, unless you are coaching on a specific issue (that you are qualified to coach on), or unless there’s a “get well plan” that you need to manage. You do need to stay connected to people; there are lots of informal ways to do this with out meeting every week. Meeting every week sends the message that you still want people to look to you for answers, help, and guidance. You may want that, but consider the effect on the team and their growth and capability.

You may still have a role in approving vacation (work on changing that, since it implies that the company doesn’t trust people very much). Keep that to a formal sign-off role. The first negotiation needs to be with in the team. I talked to a manager who approved a vacation request right after a team had committed to work for an iteration. (Who knows why the person didn’t mention it to the team, but he didn’t. That’s a separate problem.) The manager approved the vacation, then asked the team to cover the guy’s commitments while he was sunning himself on the beach. The team rightly refused, and insisted on renegotiated with the product manager to reflect the fact that they weren’t going to be able to accomplish as much with one team member gone for the entire iteration. The manager realized much later that he’d set the team back in mutual trust and accountability by not sending the guy back to work it out with the team.

Work on professional development, but remember that the team member you are mentoring needs to negotiate tasks and roles with the team. For example, if someone wants to learn more about project management, you don’t get to say “start managing the iteration as a project.” That breaks down the work the team has done to organize their work and erodes shared commitment.

Ask about impediments and blocks outside the team, those that need management action to fix. You can’t fix everything, but you can investigate, look for patterns of blocks mentioned by multiple team members. You can create an impediment backlog and post your burndown to the team.

Ask about HR concerns. For many agile teams, traditional job descriptions, career paths, and other personnel systems don’t fit agile work very well, so you want to know when there’s dissatisfaction and understand when and how policies are getting in the way of teamwork and team work.

Your job with a self-organizing team is to establish conditions for success, make sure the team has appropriate resources and appropriate boundaries, to remove impediments and improve the work system. It’s not to give task direction and hold individuals to account (except as noted above) . The team is responsible for organizing their work, tracking progress, and communicating to you when there’s a problem. You job is not to inflict help–that keeps the team from learning, and keeps them dependent on their manager.

Hierarchy acts as an amplifier, and manager’s actions are always under scrutiny. If you want the team to self-organize and reach their potential, don’t send them a confusing message that they still need to turn to you for day-to-day task guidance, status reporting, and problem-solving.

This article first appeared on stickminds.com.

(c) Esther Derby 2004-2010

Many years ago, psychologist Kurt Lewin reduced the mysteries of human behavior to this simple statement:

B = ƒ(P,E)

Behavior is a function of the Person and the Environment

Of course, it’s not that simple. But I still find this notation useful, because it reminds me that the skills and abilities of the person aren’t the only factors that contribute performance.

Much of the time, organizations focus on the Person part of the equation. That’s important, because our work requires intelligent people with a wide range of functional skills, technical and domain knowledge, and appropriate interpersonal skills. Most managers work hard to hire the right people. Managers also provide coaching and feedback to help people hone their skills and develop their capabilities.

But that’s only half the equation.

Organizational factors, corporate culture, policies, and the direct work environment influence performance, too. The good news is that you can influence the environment for your group in ways that increase performance.

Are You Creating an Environment for Success?

Let’s assume that you’ve hired bright, capable people who have the appropriate skills and qualities for the job. They have the technical skills the job demands, they know the domain, and they’re familiar with the product. Yet the work isn’t going as well as you think it should. Maybe it’s the environment, not the person. Look at these areas to see if you can improve the environment for success.

People need to know what the priorities are. Managers don’t (and can’t) make all the decisions about how work is done. Managers need to establish clear priorities so that the people closest to the work can make good decisions. Communicate a clear mission and ensure that each person understands his top-three priorities. People perform better when they understand the mission of the group and what’s most important.

People can’t do their best without the right tools for the job. But hardware and tools, of course, aren’t the only resources people need. They need time, access to expertise, and training. No one I know can manufacture time, but setting clear priorities and keeping the workload reasonable reduce the sense of overwhelming demands. When budgets are tight, find inexpensive ways to feed the need for training and expertise. Offer to buy books for a lunchtime study group and support access to content websites and other free sources of information.

People desire respect. Every once in a while I hear a manager assert that people work best when they’re a little afraid. I don’t buy that. Show respect by keeping promises, communicating openly, and listening to other people’s ideas. Don’t take phone calls and pages or check email during meetings, especially one-on-one meetings.

People want challenging work. Make work assignments based on interests, or better yet, work with your team to have them self-organize. That way, people will have a chance to choose work that appeals to them. Now, every group has some scut work. Rather than assign that to one unfortunate person, rotate responsibility for the work no one really enjoys, but everyone recognizes is necessary.

People want recognition and appreciation. I’m not talking rewards here, monetary or otherwise. Humans crave genuine acknowledgement for their contributions at work—both concrete accomplishments and the intangible ways they contribute to the spirit and success of the group. Let people know that you notice and appreciate them every week. I don’t think saying “thank you” or “good job” is good enough. I like to address the person directly, like this: “Don, I appreciate you for shipping that data update on time. It makes a big difference to our clients.”

Are There Environmental Roadblocks Stifling Performance?

Suppose you’ve done all of these things (and more) to establish an environment for success. Your work is not done.

Corporate culture and norms are part of the environment and so are policies, procedures, measures, and reward systems. Examine the organizational environment to see if there are other obstacles that keep people from doing their best.

Are there factors that actually punish people for doing a good job? I once worked with a support group that was having a crisis in customer satisfaction. Support agents were expected to meet certain targets for the length of calls.That worked fine with simple problems, but when a tough problem that took more than a minute or two to fix came along, it was a problem. The measure actually punished people who went the extra mile for the customer and stayed on the phone long past the allotted time. These folks had the knowledge and skills to perform, but an environmental factor (a poorly designed measure) was in the way.

Sometimes policies and procedures are the culprit in stifling performance. One organization I know of requires bi-weekly budget reporting and forecasting. It can take up to seven working days to assemble all the bits of information needed to create a report. The procedure is difficult and frustrating, and the time people spend every month on budgets means they aren’t doing other valuable work. In another group, each team member is required to provide written feedback to every other team member every quarter. It wasn’t so bad when there were five team members, but now that there are twenty people in the group… well, you can do the math.

Pile on enough environmental roadblocks and people become frustrated and cynical. And frustrated, cynical people are less likely to do a good job.

Individual managers can’t always change measurement systems, policies, and procedures. Insulate your group where you can and put the rest in context.

Remember that an individual’s skills and abilities aren’t the only factors in performance. Managers need to attend to both the person and the environment when assessing performance. Don’t wait until the next performance evaluation season rolls around. Evaluate the work environment now. Does the management infrastructure enable high performance? Are you working to remove or reduce the obstacles that are hampering performance? What else can you do to create an environment for success?