A while back, I posted a little mind map about business costs of a struggling team. But what about the benefits of the team effect? What does a business gain when teams thrive?
A while back, I posted a little mind map about business costs of a struggling team. But what about the benefits of the team effect? What does a business gain when teams thrive?
Recently, I tweeted, “/Estimating/ is often helpful. /Estimates/ are often not.”
Several people asked, “How can this be?” Let me say more, in more than 140 characters.
Estimating helps when the process of estimating builds shared understanding among the people who want the work done and the people doing the work..
Collaborative estimating gives the best results. Diverse experience yields a broader range of perspectives and questions. Questions and perspectives build understanding of the what, why, and who related to the request. That’s helpful.
Group estimating reveals differences in knowledge and understanding. Finding those gaps early is helpful.
Group estimating surfaces assumptions. When we are aware of our assumptions, we can verify–or debunk– them.
When the group knows enough about the “what” to think about the “how,” they can analyze implementation. Working out implementation details reveals more assumptions, and generates more questions.
Sometimes estimating reveals you only know enough to reason by analogy. The best you can do is posit that the desired functionality is about the same size as X.
But sometimes, estimators realize that they don’t know enough to think about size or effort in any meaningful way.
This situation calls for discipline. Discipline to resist guessing and speculation. Estimates born of ungrounded guesses are worse than useless. Rather than guess, experiment, interview, model, sketch designs or do some activity to gain more clarity about needs and context. Then try estimating again.
People turn estimates into targets. Meeting the target becomes the de facto goal and the de facto method. Meeting needs fades in priority.
People construe estimates as promises. No one can predict the future, but many people treat estimates as guarantees. Failed predictions fan blame. Trust and openness suffer.
People construe estimates as bids. Bidding usually involves some calculation of profit. That implies a margin. However, managers discourage margins in estimates. Managers view “padding” as a moral failing–but it’s really a contingency for the unknown (or compensation for bosses who are known to cut estimates to fit wishes. See below).
Inappropriate precision in estimates implies that people know more than they do. When expectations and reality meet, people may feel disappointed. More likely, they feel deceived. Trust and openness suffer.
People game estimates. How many of you developers out there have thought long and hard about an estimate, only to have a managers say, “That estimate X is too high. The estimate should be X – Y.” Me, too. Fudging estimates to fit wishes sets off another round of deceit and disappointed expectations. Trust and openness suffer.
So please, estimate. But don’t get caught up in estimates.
Recently, I met with a group of managers who work in an organization moving towards agile methods. People seem to be happy working on cross-functional teams. They solve problems and work things out without management intervention. Best of all, they produce working software that the customers like. This makes the managers happy.
But the managers have a lingering concern: How will we know that senior developers are doing senior level work? How will we know they aren’t slacking off?
I hear variations on this question in many of the larger organizations I work with.
So let’s unpack what might be going on here.
It could be that these managers have no experience how teams work together to produce results. They don’t have a visceral understanding of what it feels like to say, “We can’t single out one person’s contribution. We did this together.” Their own experience as managers in the organization reinforces the individual focus. In many organizations, management rewards and incentives leads to local optimization at the expense of over all goals–which obscures the interdependency of their work.
“Manager think” is shaped by emphasis on individual achievement in formative institutions such as schools, and by HR policies within their organizations. For example, individual ranking/rating systems ignore interdependency. Finely differentiated job grade levels reinforce the notion that its possible to put a neat box around each person’s contribution. Further, they focus attention on “doing my job” –or not doing a job that a more senior (or more junior) person should do–rather than on accomplishing a broader goal–such as delivering customer value. Narrow functional descriptions (automation tester, exploratory tester, front end tester) have the same effect.
Some people in management believe that if people aren’t pushed, pressured, and held accountable, they’ll slack off.
I have observed that many people are motivated by following through on commitments they themselves make. Many people find time boxes and deadlines useful to prioritize and organize where they spend time and attention. Commitments–made by the people doing the work–and time boxes can be useful structures.
Pressure, pushing, oversight work in a very different way (or, more likely, don’t work).These managers might be worried that people won’t do senior level work if no one is looking.
I actually find the opposite happens more often–people engaged in their work strive and go above and beyond. OTOH, sometimes people create the appearance of striving (and doing senior level work) when they are pushed, pressured, and “held accountable.”
Here are some of the “senior level” things I would expect to see on a thriving team.
Managers don’t need to be involved in the day-to-day tracking of technical tasks to observe that these activities happen.
Senior people don’t have to initiate these activities.
I’ve seen many teams where junior people–both in terms of time on the job and technical skills– lead in these areas. If only senior level developers initiate good practices, I worry that they’ve created a pecking order on the team, and junior people with good ideas don’t get a chance to contribute. (Its a variation on the HiPPO problem–deferring to the Highest Paid Person’s Opinion).
Sometimes I try thought experiments. I might say, “Suppose we formed four teams. After the teams have some time to get their legs under them, they’re producing results. They are getting software out the door, and the customers are happy. But you don’t know exactly what each team member is contributing. Could you live with that?” Most people say they could live without knowing. When they can’t, that’s indicative of a bigger problem.
Very often, the notion of social loafing comes up. Then we’ve reached the crux of the matter.
The original experiments on social loafing looked at uninteresting physical tasks. Some of the experiments involved people working under compulsion. But we aren’t talking about odious work done under compulsion–at least I hope we aren’t.
Remember the old saying, many hands make light work? People talk about social loafing as if it is morally wrong for one person to reduce his effort because others are working at the same task. I hear the same logic when a well-functioning team makes work look easy. Someone inevitably complains that if they aren’t struggling, they must not be working hard.
When people hold beliefs like these, the systems they build tend to be self-reinforcing, dysfunctional–and difficult to dislodge.
When people are in small teams, and engaged in meaningful work, social loafing is rare and working hard is common. But it might not look that way to someone who hasn’t see a thriving team.
No matter the name, the intention of the role is to help teams learn new skills, continuously improve, and make the transition to a new way of working.
Some people say it’s a technical role, others claim that the role is primarily facilitation. I say, there is no one-size-fits-all when it comes to hiring an agile coach or ScrumMaster.
Understand the Needs of Each Team
Every agile team is alike in some ways and different in others. Agile teams are alike in that they strive to work cross-functionally to deliver working software. Most of them work in iterations. But from there, differences abound. Some teams need to learn solid engineering practices. Others need help with a specific skill such as automated unit testing. Still others need coaching to become a functioning team. Many need help making the mental shift to working in feature-slices that fit into sort iterations.
If your company is just starting out with agile methods, you may not know yet what teams need. Rather than hire a generic coach who may or may not fit the needs of the team, look to an expert help you. “Help” doesn’t have to be a prolonged and expensive contract. It can be a short assessment to gauge the areas where teams need support to make a successful transition to a different way of working.
Consider the Qualities, Preferences, and Style for the Role
What exactly are you looking for in an agile coach? Understanding of the agile method you are using is obvious. What about the personal qualities, preferences and other skills needed for the role? I’ve worked with teams that needed a field marshal personality–someone who won’t be cowed by the alpha-geeks on the team. And I’ve worked with teams where a subtle touch was all that was needed, and the only thing that would have worked.
When you consider the qualities, think about disqualifies, too. I would disqualify someone who believed that there must be no deviation from canonical sources on agile methods. People are more like to accept a change when they have a hand in shaping it. So allow for shaping, but hire someone who can keep an eye on the why. That way, the team will retain the intent and essence of a practice as they adapt it to fit their unique circumstances.
I would also disqualify the coaches who have only one style, or have faulty ideas about coaching and change processes. One self-proclaimed coach bragged about making people cry in his prior assignment. Cross that one off!
Put the Two Together
Once you’ve considered what the team needs, you’ll have a list of technical skills, agile method knowledge, collaboration skills, and qualities. You will not find the ideal candidate. So note which ones are required, which are desirable and which ones are will definitely disqualify a candidate.
Consider the interactions, responsibilities and deliverables. These factors highlight the primary relationships, expectations, and integrating aspects of the role.
Consider using a role analysis such as the one I did for a ScrumMaster/Agile coach role.
Treat this Like Any Other Job Opening
Whether your are seeking internal or external candidates, treat this as any job opening. Create a job description, screen the candidates, use behavioral interview questions and auditions to find the best-fit candidates.
When you find a candidate who has the skills, desire and potential to fill a servant leader role, make sure that the organizational incentives are aligned to support the new role rather than holding the old behavioral patterns in place.
Changing a Title is Not Sufficient
Some managers decide that changing a persons title from “project manager” to “coach” is sufficient. It is not. Supporting a team and helping them up a learning curve requires a very different set of skills and preferences than those essential for project management.
Some project managers can make the transition. They understand how to create the enabling conditions for a team, how to set appropriate decisions boundaries, when to step back and when to step in. But even good candidates for the role will need role models, coaching and support to make the transition.
Don’t count on the unreliable “flip the title, flip the switch” method to fill the need for coaching new agile teams. Discern who has the potential to adapt to role that relies on personal effectiveness rather than positional authority.
Agile coach is a critical role and the person who fills it needs to be up to the job. A competent coach will help the team learn how to work cross-functionally, fit their work to short iterations, and help them avoid adapting their way back into waterfall. A coach who is a good fit will have the specific skills and qualities to help a specific team. If you are serious about realizing the benefits of agile methods, be serious about filling the role of agile coach.
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)
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.”
(This article originally appeared on Gantthead.com)
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.
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.
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.
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.
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.
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.
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.
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|
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:
|Who interacts with this person?||Team members
Manager(s) associated with team members
|Secondary role||Integration with other agile teams|
|Secondary role||Organizational change agent|
|Management component||Manage his/her own impediment backlog|
|Job grade level (consider pay and message to the organization)||For purposes of pay level, look at interactions and scope.|
|Activities||Coach one or more teams.
Ensure team enabling conditions are in place.
Create or advocate for those conditions if they are not in place.
Facilitate team meetings (e.g., sprint planning, sprint demo, retrospectives, decision making meetings, etc.)
Ensure that information radiators are up to date.
Develop additional team radiators to address issues unique to the team.
Advocate for the team (e.g., block unnecessary meddling)
Help the team see their own process and improve their processes.
Coach on agile practices
Guide the team in adapting process to fit the local reality w/o losing the intent.
Coach on interpersonal and collaboration skills.
Coach on technical practices
Use influence skills to remove impediments
Transfer knowledge and skills to team members so the team becomes more self-sufficient.
Up-to-date team radars
|Essential Qualities and Preferences||Initiative, flexibility, optimism, determination, resilience
Working in a team environment, supportive, not cowed by authority
|Desirable Qualities and Preferences||Detachment, discernment
Able to navigate conflict
|Essential non-technical skills||Coaching, interpersonal skills, Agile practices|
|Desirable non-technical skills||Facilitation, influence|
|Essential technical skills||Depends on which team the coach will work with|
|Desirable technical skills||Depends on which team the coach will work with|
|Minimum experience||One year coaching a team. Two years working with an agile team|
|Demonstrated understanding of:||Coaching
Agile values, principles, methods, practices
Team and group dynamics
Working through influence
|Cultural fit factors||This is in some ways a cultural change role. The candidate must fit the desired cultural pattern, but not be so far from the current culture that he's rejected.|
|Elimination factors||Preference for directing others, defensiveness, judgmental attitude, low threshold for frustration|
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.