© derby for Insights You Can Use, 2012. | Permalink | One comment | Add to del.icio.us
Post tags: management, teams

Feed enhanced by Better Feed from Ozh

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)

© derby for Insights You Can Use, 2012. | Permalink | 13 comments | Add to del.icio.us
Post tags: empowerment, leadership, management, power

Feed enhanced by Better Feed from Ozh

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.

© derby for Insights You Can Use, 2011. | Permalink | 6 comments | Add to del.icio.us
Post tags: agile, management, teams, work system

Feed enhanced by Better Feed from Ozh

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.

© derby for Insights You Can Use, 2011. | Permalink | 3 comments | Add to del.icio.us
Post tags: management, organizational culture

Feed enhanced by Better Feed from Ozh

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.

© derby for Insights You Can Use, 2011. | Permalink | 6 comments | Add to del.icio.us
Post tags: agile, hiring, management, teams

Feed enhanced by Better Feed from Ozh

“The beginning is the most important part of the work.” Plato, Greek philosopher and writer, 429–347 B.C.E.

I’ve written several articles about a manager’s relationship with a team that has already formed. A manager’s relationship with a team as they work is essential for cultivating a self-organizing team and maintaining a link with the organization. But a managers role in growing effectives teams starts long before the work actually begins.

The 60-30-10 Principle

J. Richard Hackman, has been studying teams for decades. One of his most significant findings is that 60% of the variation in team effectiveness is attributable to the design of the team, 30% to the way the team is launched, and 10% to leader coaching once the team is underway. By “design of the team,” he doesn’t just mean picking the best people. You also have to think about the nature of the work, articulate a goal, and plan for enabling supports.

Aim for Flexible, Long-lived Teams

You can call a group of people a team the first day they come together. But that doesn’t mean they’ll achieve teamwork right away. People need time to understand each others strengths, weaknesses and work styles. They need to agree on, try, and adjust the way they work together to find their groove.

In many organizations, managers from cross-functional teams to meet the needs of a specific project. In some cases, that means the team will be together for a long time. More often, it means teams will be disbanded after a few weeks or months. That’s barely enough time for a team to gel and gain the benefit of the team effect.

Analyze the work that’s in the pipeline. Aim to organize the work so that teams have “whole” work–creating a product or service that has meaning from a business perspective. Look at the trade-offs and tensions inherent in the product. Make sure people who represent those aspects are part of the team. Look for dependencies and to the extent possible, keep them within a team boundary. Form teams that have the breadth of skills to handle a broad range of work.

Then, bring work to the teams, rather than reforming teams for each new project. You won’t find a team that’s perfect for all the work in the pipeline. When teams lack a specific expertise, keep the core team in tact and add expertise.

Articulate a Compelling Goal

An effective goal statement does two jobs. First, it focuses the attention and effort of the team. When the team has a shared understanding of what their task is, they pull in the same direction.  When teams have don’t agree on the goal–or the goal is so vague it’s open to many interpretations–team members waste time and brain cycles arguing, working at cross purposes, or doing the wrong work.

Second, a well-formed goal engages the team in a meaningful challenge. An effective goal provides a sense of purpose to the teams work. The goal might be solving an important problem, enabling business, launching a new product, or meeting a  customer need. State the goal in a way that taps into purpose.

Take the goal handed down to the FinCore team: “Maintain the FinCore Product.” That goal isn’t enough to get someone out of bed in the morning. It talks about a process (maintenance), but leaves out the purpose. It misses the opportunity to tap into pride-in-work.  A more compelling goal might be:

Sustain the FinCore product by adding necessary functionality and ensuring the technical integrity of the code, so we can provide uninterrupted service to 40,000 customers.

Not all work is exciting and sexy, but all work should have a purpose. Making that clear will help people focus and engage.

Pillars of support

The right people and a compelling goal are a good start. But if you neglect the pillars of support, the team may still wallow. The pillars of support are:

Information related to the situation, domain, problem and technology. These reinforce the goal, and provide the context for the team to make good decisions.

Material support, such as machines, tools, facilities, adequate budget, and supplies. Adequate material support communicates that the work of the team is important. Starving a team for resources undercuts the goal and creates cynicism. Paradoxically, providing too much isn’t good either. A certain level of constraint can drive creativity (and over constraint kills it).

Expertise to supplement the knowledge and skills of the team when needed. Even when the team has all the skills required by the task, they may need an expert eye for consulting or reviewing. Some times there is some aspect of the work that requires scarce knowledge. It may not make sense to develop that knowledge on the team, or it may only be needed for a short time.

Feedback loops that connect the team to the organization. Regular demos of working software allow the sponsor or product owner to see how the team is doing–and allows for course correction. The heartbeat of progress builds trust.

If any one of these pillars is missing, you’ve put the team at a disadvantage.

This Sounds Like More Work for the Manager. Why bother?

Team design is a pay me now, pay me later proposition. It’s a myth that you can throw a group of people together and they’ll gel as a team. Strong effective teams don’t just happen by some magic chemistry. Well designed teams are more resilient. They make better use of the knowledge, talents, and skills of team members. They function and stay on track with relatively little management intervention. You may not always be able to bring together the perfect team. But you can set a team up for success….or failure. It is up to you.

© derby for Insights You Can Use, 2011. | Permalink | 4 comments | Add to del.icio.us
Post tags: agile, management, organization design, teams

Feed enhanced by Better Feed from Ozh

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.)

© derby for Insights You Can Use, 2011. | Permalink | One comment | Add to del.icio.us
Post tags: agile, change, management, work system

Feed enhanced by Better Feed from Ozh

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).

Quality	R/D	Preference	R/D	Skill	R/D	Demonstrated Understanding	R/D		Elimination Factors
Initiative	R	Working in a team environment	R	Team coaching	R	Agile values, principles, methods, practices	R		Directive
Flexibility	R	Finds satisfaction in helping others succeed.	R	Facilitation	R	Team and group dynamics	R		Defensive
Optimism	R			Agile practices	R	Working thru influence	D		Judgmental
Resilience	R			Ability to explain the "why" behind agile practices	R				Low threshold for frustration
Determination	R			Interpersonal skills	R
Detachment	R			Influence	D
Discernment	R			Team dynamics	D
Supportive	R			System thinking	D

R = Required, D = Desirable

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.

© derby for Insights You Can Use, 2011. | Permalink | 13 comments | Add to del.icio.us
Post tags: agile, coaches, hiring, management, teams

Feed enhanced by Better Feed from Ozh

All the research I’ve seen concludes that–for most people–money becomes the primary motivator at work when there are no other salient motivators. What might those other motivators be? Sense of purpose, pride in work, belief in the mission of the company, to name a few.

But many managers assume that money is what motivates people (though they themselves are motivated by more lofty goals). Not so. Most people start new jobs highly motivated. They want to do well. But the organizational road blocks (some of which are thrown up by well-intentioned managers) sap that motivation. As managers, we need to let go of motivation myths, understand what really motivates people, and then stop doing things that demotivate them.

A few key readings on motivation:

Teresa Amabile and Steven Kramer: Do Happier People Work Harder? (may require registration)

Katzenbach and Khan: Money is Not the Best Motivator.

Dan Pink on motivation, in pictures, Drive, (or in print.)

You may also find Pfeffer and Sutton’s book Hard Facts interesting. (Probably my favorite business book.)

© derby for Insights You Can Use, 2011. | Permalink | 2 comments | Add to del.icio.us
Post tags: management, motivation

Feed enhanced by Better Feed from Ozh

However, in many of these companies, the HR systems focus only on individual accomplishment. Individual goals, individual bonuses and merit-pay processes cause real damage when the desired behavior is collaboration and team work. I’ve talked to managers who spend the year building up teams, only to see their work undone by the review and ranking process.

In a small company, managers have the ability to directly change the goal, bonus, and pay systems. In large companies, or in companies where the software group is only one division, changing those policy may seem impossible.

Until you persuade HR to change to more team-focused strategy, take these steps to minimize competitive focus and amplify the emphasis on shared goals.

Amplify the Importance of Team

Make the expectation for teamwork behaviors explicit. Make team performance a significant portion of each team members performance expectation.  By significant, I mean 60% or more. Anything less communicates that teamwork is “nice to have,” but not essential. When people must rely on others to achieve a useful goal, tie the success together in performance expectations.

Dampen the Race for Rankings

Minimize the competitive focus by reducing stratification. Rather than have five or more ratings, use only three categories.

The top category is for people who are truly exceptional. They may out-perform the system, make an extraordinary contribution on a project, or stand out in some other way.  In most organizations, there aren’t many of these people, and most people know who they are and agree on who they are.

The bottom category is likewise small and for people who are exceptional. This is for people who clearly are unable to perform, due to lack of skills, poor fit for the job or some other reason. Note: Before you put someone in this category, check the manager’s contribution to the problem. Most performance problems are not the sole fault of the employee. When an employee is in the wrong job, or clearly lacks the skills, that points to problem with the hiring process, not the person. Of course, it doesn’t make sense to keep someone in a job they cannot do. But let’s not blame the individual when a management process has failed.

The middle category is the big one–for the people who are doing their jobs well and performing within the bounds of the system. Many companies waste an enormous amount of managers’ time arriving at fine-grained but spurious distinctions between employees contribution. Such distinctions are meaningless in collaborative and interdependent work. Managers’ time would be better spent working to improve the system so everyone does better.

A three-tier strategy based on normal variation and exceptions reduces the unhealthy effects of ranking individuals against each other. As a bonus, it frees up a great deal of time that managers would otherwise spend on suspect differentiations.

Don’t Treat People as Fungible

Don’t waste time comparing people as part of the evaluation. Comparing people within a team or group fosters division and competition. Comparing people across teams or functions is irrelevant–except when considering promotions.

Emphasize Interdependent and Collaborative Work

Eliminate individual performance bonuses. Some companies give team bonuses to recognize a team that has solved a particularly difficult problem, saved the company a huge amount of money, or launched a successful product. Since the bonus goes to the team, in most cases, the team members divide it equally.

Even without formal team bonuses, you can use the pot of money HR allocates for individual bonuses in this way.

Aim for Policies that Focus Improving the Organization

In the long run, consider some form of profit sharing or gain sharing based on the over-all performance of the department. Couple this with a clear emphasis on improving team and system performance and meeting business goals. This reduces the likelihood that people will skew their effort towards meeting individual goals at the expense of unit wide business goals.

Take a Stand

Many managers tell me that HR forces them to act out harmful policies related to annual evaluations, ratings, and rankings. HR is there to support performance, not disrupt it. Talk to them about the detrimental effects you are seeing. Share the research. Decline to participate in the ranking mess. If HR insists, distance yourself from the mess and have an HR manager communicate the ratings/rankings.

I have talked to many managers who have opted out of the rating and ranking madness and none of them have been fired. And several of them–through their action–started the conversation and change towards policies that support rather than hinder team work.

© derby for Insights You Can Use, 2011. | Permalink | 4 comments | Add to del.icio.us
Post tags: agile, merit pay, policies, teams

Feed enhanced by Better Feed from Ozh

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.

© derby for Insights You Can Use, 2011. | Permalink | 13 comments | Add to del.icio.us
Post tags: collaboration, management, ranking, teams

Feed enhanced by Better Feed from Ozh

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.

© derby for Insights You Can Use, 2011. | Permalink | 20 comments | Add to del.icio.us
Post tags: agile, management, metrics, velocity

Feed enhanced by Better Feed from Ozh

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.

© derby for Insights You Can Use, 2011. | Permalink | 16 comments | Add to del.icio.us
Post tags: agile, change, management, metrics

Feed enhanced by Better Feed from Ozh

That’s a risky road.

One manager was adamant. In his view, making managers ScrumMasters was the best course of action. According to this fellow, managers already know people’s strengths and weaknesses. They know the domain, and the organization. So, he reasoned, the managers are already equipped to tell people what to do.

Errr. Not so much.  Coaches and Scrum Masters rarely tell people what to do. Usually, they work by different means–modeling, coaching, teaching.

But it begs the question, can a manager be an agile coach or ScrumMaster?

Here’s what I look for in an agile coach/ ScrumMaster.

Experience. If your company has used serial life cycles or ad hoc methods changing to agile methods is not a trivial matter. Nor is it simply a matter of adopting a few engineering practices or using time boxes.  Succeeding with agile does require engineering practices and time boxes. But the real change happens between peoples ears. It’s a shift in thinking–and not just by the development team. Some people change the way they work by changing their thinking. But many more change their thinking by changing the way they work.  Book learning and training is good, and it’s no substitute for experience in the agile way of working.

A deep understanding of agile practices and methods. Coaches need to know the why and when, as well as the how. They need to understand how practices fit together, the intent behind practices. People do need to adapt methods to local conditions.  Without understanding, adaptation is risky. I’ve seen teams and companies “adapt” themselves right back into the situation they were trying to fix because they didn’t fully understand the “why” behind some agile practices. An agile coach needs to be able to think through what adjustments maintain the essence of a practice, and which adaptations sustain the current pattern.

Coaching skills.  Seems obvious. An agile coach should know something about coaching. That means helping people learn skills through practice and feedback. It means helping people think through issues and see new alternatives.  It may mean providing answers, facilitating, or acting as a mirror. If often means helping people think about the way they are thinking, and helping teams get unstuck.  (It does not necessarily include “life coaching.”)

Coaching is tricky when a person also has the responsibility to rate and rank individuals. Coaching requires openness and trust. When people fear that revealing lack of knowledge or skill will show up on their annual review, they are less likely to ask for help. I know of several companies where managers are now “coaches” (and managers). Its confusing for the team members.  They don’t know who they are talking to–the person who helps, or the the one who will hand out a rating at year end.

Understanding of teams and team dynamics. Another skill that would seem obvious, but is often overlooked. When the job is coaching a team, the coach needs to understand something about how people behave in goal-oriented social units. He needs to know the foundations and enabling conditions that allow teams to form and thrive. He needs to recognize when problems are related to the design of the team, when they are system patterns, and when there are individual problems.

Interpersonal and collaboration skills. Coaching is about enabling other people to be more effective. The zeroth step is to make contact with people. If a coach cannot do that, he won’t be able to build relationships and trust. I do sometimes meet coaches who are all about “me.” Doesn’t work. Coaches need to be able to work with others, share credit, and let others shine.

Influence and organizational smarts.  It is silly (or worse) to expect a ScrumMaster to remove significant organizational impediments and drive organizational change–even though that’s often the hype. Coaches need to be savvy about the organization and to have influencing skills, so they can help managers understand the costs of impediments.

If you want empowered teams, you need to change the dynamic between managers and teams.  Slapping a new tittle on a manager (or project manager) will not change the dynamic unless the manager’s mindset and actions also change.

Of course, some managers do have all the qualities and skills to make the transition.  And some teams have the gumption to call out their former managers when they slip back into command and control thinking or acting.  Even when the mangers is willing and capable of changing the way he interacts with a team, it will take time for the new pattern of interaction to take hold.

But for many companies, calling managers “coaches” or “ScrumMasters” is really hierarchical control in coaches clothing.

Organizations still need managers.  Call them managers, and have them do management work–improving the organizational system and translating strategy into action. And get a coach to be the coach.

© derby for Insights You Can Use, 2011. | Permalink | 17 comments | Add to del.icio.us
Post tags: agile, coaches, teams

Feed enhanced by Better Feed from Ozh

As a new manager, I was sent to a two-day Basic Management Orientation, where they taught me to how to fill out staff requisition forms in quadruplicate, who got the goldenrod copy, the blue copy, the pink copy and the white copy.

I think I could have figured out how to fill out the form on my own. I suspect that was all they knew how to teach, so that was what they taught. But it wasn’t what I needed to know. I suspect there are many managers in technical organizations who have similar stories.

I set out to learn about working with people and managing in a large organization. I sought mentors with in my organization. Many of the managers had never worked any place else or had only  worked for one other company. They knew a lot about “how we do things here,” and how to work within the system. They didn’t know how to work on the system. And most of them didn’t question the system.

My best teachers were from outside the company–professors in my Masters program, Jerry Weinberg and other folks I met through him. Those people got me thinking, learning, and seeing the system.

So in the interest of helping managers learn how to see and work on the system, I am starting an occasional series on research, references, and resources on management topics. For now, I’ll focus on practices that go unquestioned, but aren’t supported by evidence. I’ll share sources and authors that have shaped my thinking about management, organizations, and teams.

I’ll start some myths about pay and performance. The dominate model in the US is differential pay based on rating or ranking. It’s so pervasive, that many don’t even think to question it.  But as Jeffrey Pfeffer says,”diffusion and persistence don’t provide proof of effectiveness.”

Jeffrey Pfeffer: Six Dangerous Myths about Pay (terrible copy, but free).

Jeffrey Pfeffer:  Congressional Testimony on pay-for-performance systems.

If you are interested (and as a manager, you should be) in the effects of annual performance reviews, click “annual reviews” in the tag cloud.

If you are in middle management, you may think you can’t change HR policy. But if you band together with other managers and document the negative effects on productivity and the ability to meet the organizations goals, you might just get some traction.

© derby for Insights You Can Use, 2011. | Permalink | 3 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh