Command and control isn’t just a mindset and a style of management (though it is both those things). What we don’t often talk about is the power that rests with people in management roles.

Traditional managers have power, and that power comes from different sources. Part of what rankles people in traditional organizations is the way managers wield power. I’m not suggesting throwing out all managers or eliminating all controls–controls help ensure a system is functioning within appropriate boundaries. That’s the case whether we are looking at the financial system, training system, administrative system or any other system in the organization. But controls are different from keeping people in line through positional power–which is the essence of Tayloristic management.

The notion that managers must keep people in line assumes that those people are neither responsible nor intelligent–that left to their own devices, they will make irresponsible and stupid mistakes. In many organizations, managers say they want people and teams to be responsible and accountable, then treat them like children. Let me give a concrete example. One manager I know exhorted people to take responsibility for their professional development. Then when a developer asked to attend training, the manager grilled him on the nature of the training. After the grilling, the manager asked the developer to produce documentation. Finally, the manager rejected the developer’s request because the no one “responsible” in the company had vetted the training. This is an extreme example, but one that makes the point. When managers tell people to take responsibility, then force them to ask for approval, they are sending a mixed message. You can guess which part of the message people believe. They hear, “you are not capable of making a wise decision, I must exert my authority to prevent you from doing something irresponsible or stupid.”

One way to dis-aggregate power is to delegate some power to teams. For example, you could delegate authority for a portion of a training budget to a team. Establish guidelines, (e.g., training must be relevant to current or future projects, or must increase capacity in some other relevant way). Then let team members assess what training they need to improve their capability. Guidelines act as controls, within which the team has autonomy. Both are necessary. The team exists within the context of the organization. Managers do have a fiduciary responsibility. But managers don’t have to force other adults to come as supplicants to fulfill that responsibility. Other areas that are easy to delegate are tools used within the team, books and periodicals, and conferences.

People in management roles can share hiring decisions with the teams who will work with the new person. Rather than have individual managers make decisions about promotions, have a panel. Place professional and career development with mentors, instead of with the manager who evaluates or supports the team.

When power isn’t concentrated with a group of people (managers), there are many more possibilities for creativity, partnership, and empowering leadership.

(This is an excerpt from an interview in Lean Magazine, published by Softhouse.se)

Agile methods depend on effective cross-functional teams. We’ve heard many Agile success stories…at the team level. But what happens when a product can’t be delivered by one team?  What do you do when the “team” that’s needed to work on a particular product is 20 people?  Or 20 teams?

There are no simple answers. But there are design principles for defining workable arrangements when the product is bigger than a handful of agile teams.

Some principles and practices to guide scaling Agile teams.

When I was promoted to a management role, I realized that the skills that made me standout as a programmer were not the skills I needed in my new role. I started reading. I found a mentor. I applied for a graduate program in leadership.

But I was something of an exception. Many managers feel too busy to read. Many don’t have good role models within their companies. I meet many people in management roles who have never picked up a serious management book. Some managers I meet express relief that they no longer have to keep up with evolving technical trends–they can relax and stop learning.

I find this puzzling. But I see it all the time.  Why might that be?

My hypothesis in another snippet from my interview with Softhouse.se for Lean Magazine.

LM: Could you give examples of ways in which we can create a organisation where constantly managers get better at being lean/agile managers and where there is a “learning culture” even for managers?

E: In the US (and I suspect some other places) we face a trifecta of obstacles in creating a learning culture for managers.

FIrst, when someone is promoted to management it is a sign he’s “made it,” proved that he is “management material.” When you’ve made it, asking for help can signal that you weren’t “management material” after all. 

Second, in many organizations, it is more acceptable to be sure and dead wrong, than admit uncertainty and be approximately right. In such organizations it’s a sign of weakness to ask for help or show uncertainty.  That slows the learning curve for new managers.

Third, people have been taught that a manager’s job is to get other people to work hard.        Most people are motivated when they start a new job. But motivation drains away when people must work hard to overcome obstacles in the form of procedures, rules, and organizational hoops rather than value-adding work.  Managers need to focus on creating an environment where it’s easy to do the right thing and do valuable work. Then people will work hard on their own.

All these work against learning.  So we have some hard work to shift manager’s perception about their role.

I have seen organizations where managers hold their own retrospectives, to see how well their decisions and actions are working out. This is a critical feedback loop that’s missing in many organizations.

I know many managers who are learning to admit mistakes, and realizing that failing fast applies to management, too.

Finally, managers have to examine their own assumptions, and start figuring out “what they know that ain’t so”  (to paraphrase Will Rogers). This is difficult, no matter who you are, or where you sit in the organization. But it is a key to learning.

Most companies have policies that govern the selection and hiring process for new employees. Not a bad thing.  But I’ve noticed that in many of the companies I visit–especially the big ones–the guidelines put far less rigor around hiring people for dev teams than for management roles. (Occasionally, I see the opposite. Might write about that at some point in the future.)

I agree with the need for due deliberation in hiring managers at any level.  Managers can have a big impact, and it makes sense to hire carefully.  Many companies take a broad stripe approach to hiring managers. They look at management skills–but also assess psychological make up, interpersonal skills, and ability to work with others. At senior levels, the candidate often interviews with the other people he or she will work with. They gauge the candidates style, fit, and personality–and gain commitment from the work group, not only the hiring manager.

But when hiring technical people, many of these companies take a narrow stripe approach. They look only at technical skills and domain knowledge.  Both are important, of course.

But there’s an assumption there that personal qualities and interpersonal skills don’t matter as much, and team buy-in is irrelevant. There’s also an assumption that people developing software work independently as individual contributors, and they are relatively easy to replace if they don’t work out.

But, if you want to develop strong, creative, capable teams, you need to up the hiring game at the dev team level.

Here are four reasons why:

1)  A person working on an agile team is not  an “individual contributor. ”  He or she is expected to work interdependently.  In agile teams, people collaborate, negotiate, make trade-offs, handle conflicts.  These interactions require a high level of interpersonal skill and emotional intelligence.

2) Even junior members (in terms of experience, age, or skill level) are expected to exhibit a high degree of self-management.  They make commitments to other team members, follow through on commitment, manage their own work level and task completion. They need to know how to ask for help, and be comfortable admitting when they don’t know something.

3) People on agile teams need to have excellent problem-solving skills–beyond those needed by an “individual contributor.” An individual contributor needs to solve problems that are bounded by his task assignments. Problems of coordination and dependencies are often someone else’s job.  People on agile teams work together to solve technical problems, handle issues, and interface with other teams.  The manager isn’t doing the bulk of the integrating work between tasks and solving problems–team members are.

4) People on agile teams need an exceptional ability to learn and apply that learning–both in growing “generalizing specialist” skills and in improving team processes.

You can learn a lot about these factors in an interview if you use behavioral interview questions.  But not enough.  But it is very difficult to assess how someone will fit into the team, unless the entire team has a chance to meet him and interact. It’s hard to assess how people code, test, problem-solve, unless you see them in action. That’s why auditions are so useful.

Further, the broader the interview team, the more people will be invested in the new hires success.  They won’t have the cop-out of saying “your problem, I didn’t choose him.”

For some ideas on a hiring process for agile teams, see my article Hiring for a Collaborative Team.  And buy yourself a copy of Hiring the Best by Johanna Rothman.

I recently did an interview with the nice folks at Softhouse.se for their Lean Magazine. The interview was a lot of fun, and made me think (which is fun).

The full interview will be in their special anniversary edition, schedule to be out by Christmas.  (Information on obtaining the magazine here.)  In the meanwhile, some thoughts on the role of managers….

LM:  We notice a lot of confusion when we meet managers. 

They see a new behavior in their development teams that have started to work according to lean/agile principles and usually the development teams are happy with the change. 

But as a manager the questions comes up ñ what should I do now? how can I support this? how do I avoid to destroy the good things? 

What is your message to these confused managers? What can they do?

E: Don’t tamper if things are working.  Ask what is getting in the way, and go fix it.  Ask what the team needs, and obtain it for them. Ask what you can do to help. If the team says “nothing,” don’t inflict help.

The truth is, when teams are working well, managers don’t need intervene. The hard work is in establishing a real team and ensuring enabling conditions are in place. When managers of self-sufficient teams feel like they aren’t doing much, it’s a sign they’ve succeeded. But managers shouldn’t abandon the team. Teams need support and a connection to the organization.

Managers still have an important job to do, working at the system level. Collect metrics that will give a window into the system. Start by tracking the ratio of fixing work to feature work. Then, find out what is driving the fixing work, and start working to improve those issues.

LM: Are there individual managers that will not fit into this /new/ management? 

E:  People who cannot manage themselves should not manage others. People who can only work through telling, selling, and yelling won’t be successful in companies that embrace lean and agile philosophies.

Some companies find they don’t need as many managers. Some people who are in management roles find they are happy to go back to technical work.  But, to me the new roles for managers are exciting and full of promise–developing people, seeing and steering the system, creating environments where people can build products and services that delight customers, satisfy stakeholders, and empower employees.

LM: Can everybody change their behavior or do we need to move some people? To where?

E: Not everyone is capable, and not every one will want to. Some of those people will leave of their own accord.  If there is a place in the organization where people who can’t or don’t want to change can still be of service within the organization, support them to find it, and then let them be.

We can never be 100% successful when we expect everyone to change. Don’t spend your precious energy trying to change people who don’t want to. Work with the people who want to change, and most often, when a critical mass has moved to a new way of working, most will come along.

If there are some people who are acting in a way that is destructive to people or the organization, help them find the door. (This advice applies whether you are using lean, agile or any other method known to man.)

As I said in an earlier column, it’s not enough to slap the tile of Scrum Master or Agile Coach on a project manager, manager, or whatever other warm body happens by.  It’s also not enough to look for the keywords “CSM” or “coach” on a resume.

If you are serious about helping teams learn and thrive as self-organizing Agile teams, get serious about ScrumMasters and Agile Coaches. Start thinking about the work, the role, and the job–not just the job title.

Here’s my initial take on a job analysis of the role (using the job analysis template from Johanna Rothman‘s very useful book, Hiring the Best.)

First, I considered the qualities, preferences, and skills. Second, I thought about the sort of knowledge and understanding that’s essential for the role.  Then, I thought about elimination factors, patterns of thought and behavior that would eliminate a candidate from consideration.  Of course, you can’t just ask yes/no questions for any of the characteristics on this table. You have to do behavioral interview questions and auditions (see Hiring the Best if you need a refresher on interviewing and auditioning candidates).

After I had a handle on the skills, qualities, and characteristics, I considered the interactions, activities, and deliverables for the job. I summarized it all here:

Of course, what you look for in an agile coach or Scrum Master will be somewhat different. Each team has different needs for coaching. A given team may need more (or less) help with specific engineering practices. Another team may need more help with retrospectives or planning. The key is to think of this like any other job. ScrumMaster or Agile coach are not a plug-and-play roles. You need to look for fit–with your culture and with the needs of the team.

A participant in one of my workshops of my workshops declared that in every team there is pecking order….and every one knows what the order is from one to n.  Since this is the case, he reasoned, it follows that ranking people in organizations is a reasonable management practice.

This is not the first time I have heard this assertion.

It often comes up when I talk about performance reviews, annual evaluations, and the harm done by stack ranking.

This assertion rests on tired analogies from sports or the animal kingdom.

I’m not buying it.

Software development teams are not “just like” sports teams. Software development teams aren’t packs, pods, herds, clowders, flocks or clutches.  Groups of people developing software are people in goal oriented social units–often in teams.

Sometimes, on some teams, it appears that there is one person who is obviously the star. Maybe.

In some companies, smart talk substitutes for action. So is the smartest talker the best on a team?

Some times there is a self-proclaimed genius who writes code that is so brilliantly complex that other people struggle to understand it. How does that make him the star? He is making it harder for everyone else to do work.

Then there are the people whose manager declare are top performers (though the basis of their assessment isn’t clear)–even though colleagues and peers  view them no more than average,  brown-nosers or a hindrance.

I observed a team where one person was viewed as the star by many managers.  To those managers, Joan (not her real name) looked like the one who generated ideas and figured out problems. From inside the team, Joan, suppressed contributions from other people through aggressive interruption, belittling others’ ideas, and arguing  until people caved in because it wasn’t worth the fight.

Rarely, there are people who are real standouts.  But not on every team.

What about the people at the bottom? What is the basis of the assessment?  Does the assessment include all of the dimensions of performance? In most cases it does not– it might include one dimension, perhaps coding. But in collaborative work, that is not the only thing that matters. Some times a person with relatively weaker coding skills contributes in other important ways. He or she may excel at  synthesizing information, seeing the software from a customer’s perspective, creating an environment where every one on the team can be more effective.

And the people in the middle? People who ascribe to the pecking order view believe that all of the members of a team could be lined up in rank order. But what is the earthly good of that? What is the basis of the comparison? Does it included the breadth of contribution or just one aspect of performance?

What if people are measurably different on some dimension?  Software is a collaborative endeavor. What matters is how well the team is doing.  Spending time teasing out relative contribution or trying to discern the pecking order does not aid in team performance, and can cause real harm.

As a manager, don’t waste your time trying to figure out the pecking order.  Do everything you can to help the team, as a goal oriented social unit, perform to its full capability.  Treat the true stand outs as exceptions. Promote them, or find other ways to reward them (don’t limit your thinking about rewards to money).  Treat the people whose performance is obviously below par as exceptions, too.  Either get them them help so they can contribute, or get them to a place where they can contribute (which may not be your company).  It is extremely difficult to assess relative contribution to collaborative work. The effort is not worth the benefit, and the downsides are significant. So skip it. And get on with helping the team.

In response to my recent post on Agile Metrics, a reader asked, “Why did you leave out Velocity?”

Even though it’s not perfect, velocity is the best way we have to understand the capacity of teams. It’s the best way we have to bring some reality to planning for releases.  Watching velocity over time and looking at patterns in burn downs can alert coaches and managers that something is going on, and they need to investigate.

Velocity is important. But as a metric for gauging how your agile adoption is going, it’s opens a door to danger.

Here’s why.

Velocity is easy to manipulate.  Want velocity to go up?  Fudge the definition of done and you finish more stories.  Change the scale and complete more points (what once was a 2 point story is now a 5 point story).

Velocity is easy to misuse.  Managers who don’t see organizations as systems can use it to compare teams or punish teams. Neither of which is helpful.

Velocity—as an agile adoption metric—puts the focus in the wrong place. Focus on velocity implies that if velocity isn’t improving there is something wrong with the team. In some cases, that might be true. But I don’t want people to look by default. When velocity isn’t improving or is erratic, it’s often due to factors that aren’t in the team’s direct control.  There might be a problem with the way the work is flowing into the team. Or the team maybe interrupted every hour with production support calls (or what ever). Or the team may not have the tools they need to do their work.  That’s something for the team and team coach to work on or raise up as an impediment (where mangers can work on it at the system level).

For assessing the progress of an agile adoption, I choose metrics that emphasize system performance to help managers make the shift from “work harder” thinking to “optimize the whole system” thinking. Managers after all, are responsible for creating the environment (structures, policies) and enabling conditions for teams be successful. To do that, they need a way to asses how the system is functioning.  Because I presume that the point isn’t being “agile” but delivering valuable software.

For more about using velocity as a measure, see my post Working Hard or Hardly Working.

“How can we tell how far along we are with our agile adoption?”

I heard this question again the other day.

Usually, the person who asks the question starts to answer it:

Number of teams using agile

Number of people trained in agile

Number of projects using agile

Number of certified coaches.

Metrics like these won’t tell you what you need to know. More likely, they will lead you astray. How? Let me tell you a story.

Years ago, I worked for a company that was “installing” a Big Methodology from a Big Company.  (The fact that they thought they were “installing” a methodology was probably the first warning sign.)

Every one in the department attended Big Methodology training. (This practice is sometimes called “Sheep Dip” training).

The VP mandated that all projects would use the Big Methodology.

The Installation Team audited to ensure that project managers and teams were complying and producing the required “work products” in accordance with the Required Work Products grid in the back of the very large Big Methodology binder.

Of course, there was some grumbling (from the people the Installation Team referred to as “Change Resisters.”)  Eventually, people did comply. Every one went to training. Projects managers filled out the required templates, and checked the appropriate boxes.  The metrics looked grand!

The VP declared, “Big Methodology is now business as usual!”

At the time, I scoffed at that statement. It was clear to me that people were not using Big Methodology, and that the promised benefits were nowhere in sight. The only things that had really changed were some check boxes and some names (documents became “work products” or “job aids,”).

But, now, I realize that the VP’s statement was TRUE!

We had Big Methodology, and things went on as they had–business as usual! Well, maybe a little worse because people were spending time producing the many documents specified on the Required Work Products grid.

The metrics the VP tracked were easy to count. But they only revealed surface compliance. They didn’t say anything about whether the organization was achieving the improvements promised by Big Methodology and hoped for by the VP.

So when you think about assessing how far along you are in your agile transformation, consider what you are trying to achieve.

I often suggest that managers track three metrics to understand how well their organization is functioning, and whether they are trending in the right direction.

The ratio of fixing work to feature work. How much time are people spending developing valuable new features vs. fixing stuff that wasn’t done right the first time? If you can figure out the sources of fixing work and make some progress there, you have a boost to productivity. Agile methods can address some of the sources of fixing work…but not all of them.

 Cycle time. How long does it take to go from an idea to a valuable product in the hands of a customer? Again agile methods can help with delivery. But if it’s the upstream process–planning for products and releases–is broken, you may not see improvement until you address those issues, as well as the development process.

Number of defects escaping to production. This is a category of fixing-work that is a direct indicator that the quality of the development process is improving.

For each of these metrics, it is the trend that is important, not an absolute number.  The trend will tell you if your attempts at improvement are having an effect. Remember, most changes take time to take hold. If the trend doesn’t move in a month, it may not mean you have taken the wrong action and need to change direction. If the trend isn’t moving over time, then, examine what is happening in the development area. But also look at other aspects of the system. There are few one-to-one cause and effect relationships in complex systems and the trend you see may or may not be directly related to your change. One company I worked with was alarmed to see that defects released to production went up after they started using agile methods. It turned out that prior to the effort to measure defects released to production, no one paid much attention unless the defect brought down a customer site. The increase in the defects trend was related to reporting, not a failure to improve quality.

I find that the three metrics above are generally useful for understanding how a software development organization is functioning as a system. But your reasons for adopting agile methods may be different.  Consider the goals you are trying to achieve.  What signals would tell you that you are moving in the right direction?  How might you measure those?  When you think about measures, be wary of target numbers. Measuring against targets almost always causes distortion. That means that people will behave so as to reach the target, perhaps in ways that are counter to the actual goal behind the target. Distortion will keep you from seeing the real picture, and may also cause real harm to your organization.

Useful metrics give you a window into how the system is functioning, and whether your change is having an effect. The numbers themselves are neither good nor bad. They are information that signals you to go and find out, investigate and reason about the system.

Every team needs leadership, even self-organizing teams.

When I make this statement, some people assume I mean that every team needs a designated leader.  I can’t blame them, most people are accustomed to thinking of leadership residing in a role or a charismatic individual—a “born” leader.

On self-organizing teams, there isn’t one leader.  Agile teams may have a coach; however, the coaches job is to help the team see where they need to improve and help them learn specific skills.  The coach may lead at times, but the coach isn’t the leader.  In fact, if the team looks at the coach as the leader, they’re in trouble. Holding up one person as leader will hamper team development.

Before we go any further, let’s define leadership: leadership is creating an environment where everyone can contribute to solve the problem at hand.

On teams that function well, every member of the team leads.  Each person takes responsibility for helping the team move forward.

But acting at random or on gut feel isn’t enough. Empowering leaders can be more effective when they work out of a model that helps them make sense of what they see happening on the team.

One such model is the MOIJ model articulated by Jerry Weinberg.

1. Every team needs motivation—and I don’t mean pep talks, cheerleading and extrinsic rewards.  Teams do best when they are intrinsically motivated, when they derive satisfaction from the work and team relationships.

Team members lead when they work for appropriate harmony and consensus—and engage in constructive conflict.  Leaders pay attention to how other team members are participating, so that everyone can use their talents and creativity. Leaders pay attention to how the whole team is working together, and building a team culture that supports achievement and good working relationships.

When only one person on the team pays attention to motivation, the team doesn’t learn how to create the environment for their own success.

2. Teams need organization.  Organization is more than the boxes on an org chart.  Organization includes physical space, time, and structure.

Leaders make sure that the workspace supports the team with appropriate equipment and information. Teams need someone to lead by pay attention to commitments and the ticking clock.  They need to figure out how to allocate the work so that it gets done and there’s a balance between people expanding their skills and relying on experts who can do the work most quickly. Teams need structures that help them work effectively together, for example, working agreements or configuration management.

When only one person pays attention to organization, he comes across as a nag. After a while, people ignore nags.

3. Teams need information.  They need to see a vision, generate ideas, bring in data and analyze and connect the dots.

Along with a flow of ideas, sometimes, a teams need a Devils Advocate.  A Devil’s Advocate challenges habitual thinking, checks solutions against foundational principles and values.  Without a Devil’s Advocate, teams can slip into group think, or miss risks and weaknesses when they consider options. But like the nagging organizer, no one enjoys a habitual naysayer. When there’s only one Devil’s Advocate he’s likely to be marginalized.  Like all the other leadership activities, it’s important to spread this one around.

Team members also need to know when they have too many ideas, and it’s time to slow the flow. We usually don’t think of following as a leadership activity.  But I’ve seen teams where everyone wanted to have his or her way.  I’ve seen teams sidetracked when members keep throwing in new ideas each time they come close to a decision.  Those teams argue and debate endlessly and don’t make forward progress.  Knowing when to zip the lips and follow is leadership, too.

4. Finally, every team needs people who can recognize when they are stuck and need a jiggle.  My favorite jiggle is a paradoxical question: “How can we make the situation worse?” Simply commenting on the stuck-ness can sometimes shake a team out of their rut. Changing position—standing up if the team has been sitting–can jiggle the team into productive action, as well.

***

What happens when only one person on the team—whether a formal or informal leader—tries to do all the leadership?  I suppose there are the rare individuals who can do it all. But on most teams that aren’t sharing leadership, are missing some leadership ingredients.  When teams rely on one individual they flounder when the leader isn’t available.  Worse, they don’t develop their own capabilities and slide into dependency.

Leadership is about making sure the team is functioning well and creating an environment where everyone can do his or her best work.  And it takes a whole team of leaders to make a self-organizing team.