Category Archives: Worth Taking Note

Blog posts worth noting

/Estimating/ is often helpful. /Estimates/ are often not.

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/ is often helpful.

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.

/Estimates/ are often not helpful.

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.

But are they working hard?

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.

  • pairing
  • mentoring
  • informal lunch and learns
  • looking for patterns of problems in the code
  • convening discussions about standards to address code quality
  • initiating coding katas
  • modeling good engineering practices
  • task walls and a pull system for tasks
  • delivering working code each iteration
  • examining the teams practices and looking for ways to improve

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.

Command & Control: Let’s talk about power

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 Teams at Scale: Beyond Scrum of Scrums

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.

Trifecta of Doom: How Expectations for/about Managers Stymie Learning

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.

Hiring for an Agile Team: 4 Reasons to Up Your Hiring Game

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.

New Roles for Managers: Interview with Lean Magazine

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

ScrumMasters and Agile Coaches: More than a Title

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

QualityR/DPreferenceR/DSkillR/DDemonstrated UnderstandingR/D Elimination Factors
InitiativeRWorking in a team environmentRTeam coachingRAgile values, principles, methods, practicesRDirective
FlexibilityRFinds satisfaction in helping others succeed.RFacilitationRTeam and group dynamicsRDefensive
OptimismRAgile practicesRWorking thru influenceDJudgmental
ResilienceRAbility to explain the "why" behind agile practicesRLow threshold for frustration
DeterminationRInterpersonal skillsR
DetachmentRInfluenceD
DiscernmentRTeam dynamicsD
SupportiveRSystem thinkingD

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:

Who interacts with this person?Team members
Product owner
Manager(s) associated with team members
Other coaches
Primary roleCoach
Secondary roleFacilitator
Secondary roleIntegration with other agile teams
Secondary roleOrganizational change agent
Management componentManage 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.
ActivitiesCoach 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
Identify impediments
Use influence skills to remove impediments
Transfer knowledge and skills to team members so the team becomes more self-sufficient.
DeliverablesIntangible
Up-to-date team radars
Impediment backlog
Knowledge transfer
Essential Qualities and PreferencesInitiative, flexibility, optimism, determination, resilience
Working in a team environment, supportive, not cowed by authority
Desirable Qualities and PreferencesDetachment, discernment
Able to navigate conflict
Essential non-technical skillsCoaching, interpersonal skills, Agile practices
Desirable non-technical skillsFacilitation, influence
Essential technical skillsDepends on which team the coach will work with
Desirable technical skillsDepends on which team the coach will work with
Minimum education
Minimum experienceOne 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 factorsThis 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 factorsPreference 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.

Peck, peck, peck

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.

Why not velocity as an agile metric?

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.