Category Archives: Blog

What Does Your Product Do?

When it gets dark, I turn on a light.

I can work, cook, read—long after sundown. I can see where I’m going, avoid the dog toys on the floor, and not run into furniture. If I need something that’s in the house, I can find it. The simple flip of a switch makes many things possible and solves many problems.

Light SwitchWhen I ask developers and engineering managers what their software product does, often, they don’t tell me. They regale me details equivalent to explaining the production of electricity, starting from mining coal until the switch closes a circuit. It’s all about the technical how.

Your customers may be interested in the technical how. They certainly want to know the what—what is possible on their side of the metaphorical light switch when they use your product.

It’s useful for the team to know, too. A short statement that answers three questions clarifies purpose and focuses attention:

  • What benefit does our product create?
  • What problem does our product solve?
  • For which group of people?

This clarity informs priorities, and helps people defer non-essential features. It helps keep focus on who will use the software, and how it will help them. When every member of the team can articulate the answer to these questions, they can make better decisions—and that almost always results in a product that is a better fit for function.

Assessing Team Improvement

I understand that managers who have invested effort and money in training teams in Agile methods may want to see how much those teams are improving.  There are a handful of reasonable measures to look at to see whether the organization is improving over all (which I’ve written about here and here).

You can apply some of those measures to team improvement.  Are defects trending down?  Is the ratio of value work to fixing work improving? Are teams improving their practices?

But, teams don’t exist in a vacuum.

Part of team improvement comes from the way a team works together, their approaches, and skills. Another part comes from how well the environment supports their efforts:

P=f(p,e) where P= performance, p=people, e=environment.

Teams can only improve so much, unless the environment also improves.

So, rather than look only at team results, also evaluate whether the environment that supports the team’s work is improving.  When teams aren’t improving as  hoped, this is where I start looking.

Team composition and stability. Are the teams appropriately cross-functional? What is the frequency of membership changes?  If the team isn’t well designed, or isn’t a really a team, don’t expect team-level improvement.

How work flows into teams. Are teams pulling work, or is management pushing? Are stories/features well-formed and customer facing? How much new work gets added during a sprint?

Trends in dependencies between teams. Are POs working to reduce dependencies in the way they shape stories and order the backlog? Are the teams organized to reduce hand-offs and dependencies?

Clarity of the product visions and team mission. Is it clear what problem they are solving/benefit they are creating for which people? Are team missions articulated and independent?

Adaptive planning.  Are POs and Management adjusting their expectations based on team capacity?

I expect team performance to improve with agile methods. But if you really want high-performance you need to  improve the entire system–and that is management work.

Seven Agile Best Practices

Someone I don’t know offered to teach me Agile Best Practices recently.

I tend to think there are “generally good practices,” some of which are broadly applicable.  In my experience, the search for Best Practices is often a search for Silver Bullets, and a reflect a desire for easy solutions to complex problems.  It would be nice to short circuit the difficult work of seeing and evolving a system, building capacity–but I seldom see it succeed.

And, one of my practices is to challenge assumptions. So I challenged my assumptions that there are no best practices.  And I came up with some, which I suspect are not what the dear fellow who offered to school me had in mind.

#1 Think deeply about the problem you are trying to solve.

First,  understand which problem you are trying to solve, for which people, to create which benefit.  If you don’t understand this, you are relying on luck for your chosen “solution” to work.

#2 Question your assumptions about the causes of the problem.

Assumptions about how work works and how people work will determine the solution space you explore.  For example, if someone assumes people aren’t finishing stories by the end of sprint is because they are not sufficiently accountable, he or she will probably not consider the way work flows into the teams, or dependencies between teams.

Notice that I wrote the causes, not  the cause.  In a complex system, there are likely multiple, entangled influences that result in the problem you observe. Everything touches everything, change one thing and you’ll change many. You can’t anticipate all, but you can predict some, which may change your choice of action.

#3 Understand your current system and how it contributes toward the problem, and in what ways it might contribute to solving the problem.

Systems drive behavior.  The patterns you observe emerge from the system you have. Sketch what you know about the system, using CDE, DOE, influence maps, reward maps, value stream maps… what ever set of diagrams will help you reason about the system. Use these diagrams to consider which which factors you can change, and what effects they might have.

#4 Research at least three candidate actions to improve the situation. Don’t rely on claims by people who are selling “solutions.”

If you can’t think of at least three different possible approaches, you haven’t thought enough. Identifying more candidate approaches almost always improves your understanding of the situation.

Look at how you could influence different factors that contribute to the pattern.  Don’t limit your self to comparisons of three similar approaches (should we use Tool A, Tool B, or Tool C?).

Learn from what has worked for other people, but don’t follow slavishly. You need to understand enough that you know where you can modify, and where you need to follow strictly.  This sort of learning comes  from studying theory, and practicing theory.

There are no silver bullets.

#5 Develop experiments to move towards a more effective way of working and improved outcomes.

Big changes feel like existential threats. Small changes support learning.

#6 Run experiments, and examine the results. Adjust based on what you observe.

When I took chemistry classes in high school and at university, our “experiments” had an expected correct outcome. Real experiments are about learning.  You may learn that you need to increase some skill or create a different level of understanding in order to apply a particular technical practice effectively.  You may learn that your architecture is preventing your from benefiting from autonomous teams.  What ever you learn, it will help you refine your approach.

Look confirming data, and disconfirming data.  Consider what you’ll do to amplify results if things are headed in a good direction, and how you’ll dampen the effect if it reduces function.

#7 Work incrementally and iteratively to solve the problem(s).

It’s really not very agile to choose one big bang solution and then roll it out.  Try something, learn from it, see how the system changes.  You’ll learn more about the issue, have a chance to observe side-effects. Be open to the different possibilities and opportunities that emerge.


These best practices are likely to lead you to an approach that fits your context, your organization, your people.  Which will be the best practice for you, not something that worked for some other group in some other context, to solve some other problem.  And, since you and your people refined the approach it will be theirs, and they will support it.


Agile and The Chasm

Someone posed the question:  Has Agile Crossed the Chasm?, a reference to Moore’s work on marketing.

Agile is no longer the prevue of pioneers and visionaries.  Agile shows up in the popular business press. PMI is all over it.   The big accounting/consulting firms are marketing agile. Clearly (at least the term) agile is reaching the mainstream.

According to Moore’s model, people on the other side of  The Chasm, the  Early Majority, want to improve existing processes. They are not interested in a radical change in operations. They want something that works out of the box.

This makes sense if you are talking about a technology product.  But agile isn’t a product. It’s a set of practices, built on values and principles. Agile relies on the ability to inspect and adapt.

Many people want to lose weight, but don’t want to change their diet or exercise habits.  We know what happens.

Many managers in organizations with traditional functional hierarchies want the benefits of agile –without disrupting the status quo. Not going to happen.

Still no silver bullets.

Lessons in Self-Organizing Social Systems

Last week, I had a chance to reflect on eleven years of the Retrospective Facilitators Gathering.

A bit of background on RFG: I started the Gathering in 2002 with Diana Larsen and Norm Kerth.  Each year, the different set of volunteers organize the Gathering.  Continuity comes from linking the immediate past organizer, the current year organizer, and the next year organizer as part of the organizing group.  Most years that’s worked reasonably well.

We’ve used light weight planning and a market place for sessions from the start. But over the years, I and other organizers learned more about self-organizing systems.  We lightened our planning even more. We planed the parts that need planning– the venue, and supplies, for example. Those aspects that don’t need close planning emerge organically.  But what emerges depends on setting the initial conditions, and attending to containers, differences and exchanges.

Based on a decade of experiments and experience, some considerations for setting the conditions for self-organizing social systems.

1. Initial conditions shape interactions for the life of the group.  Small actions can have a big effect, particularly those that amplify the sorts of differences that create division.

2. When structures and espoused values contradict each other, people sense the incongruity–and respond, often in incongruent ways.

3. The more people in implied (“organizers”) leadership positions take responsibility for the decisions and welfare of the group, the less responsibility the group will take for their own decisions and welfare.

As you think about the teams and groups that you work with, how do these factors show up?  How might you apply them now?


The Elements of Improvement

Improvement requires three factors:

  • Information. People need information about the context and how their work fits into the big picture. They need information from the work so they can self-correct. Without this information, systematic improvement is impossible.
  • A desire to improve. Most people want to do their best and learn to do better–until that impulse is squashed. One-sided evaluations, organizational hurdles, relentless pressure strangle the desire to improve.
  • Time to reflect and learn. People need time to design and implement new processes, and  practice new skills. Relentless deadline pressure makes this impossible. People under pressure are less likely to try something new, or think clearly about anything.

When one of these factors is missing, individual and systemic improvement goes out the door.

Self-Awareness Matters: Finding Your Filters

I remember sitting in a project meeting back when I worked for a Big Company. The project manager, Ted, announced the top three priorities.  When I offered a different view point, Ted declared, “You’re wrong. We decided on these priorities yesterday.”  He didn’t notice six out of eight people at the table  shaking their heads “No.”  

Ted didn’t notice the responses and reactions of people around him. He also didn’t  notice that he didn’t notice.

We all have filters. That’s a good thing–our cognitive systems can’t process all the data that’s available. But most people filter out useful information as well as extraneous information (for example, the size of loops in the carpet or shoe styles). What any one person filters depends on his preferences for big picture vs. detail processing, intake style (verbal, visual, tactile) and training.

Learning about your own filters builds self-awareness. Knowing what you tend to filter allows you to choose to ignore that information or make a conscious choice to notice it.

Ted deprived himself of the choice to notice people’s reactions. Ted was continually surprised when people “resisted” or “backtracked” on decisions. He didn’t pick up on the fact that after he made a few sharp criticisms, people stopped offering ideas.

People who lack self-awareness don’t realize their own observational biases or notice the impact of their behavior. They wonder why things don’t work well (or work well) but don’t see their part in the situation.

One relatively small action by a manager can send ripples or shockwaves through a system. Ted’s lack of self-awareness suppressed the groups effectiveness. Some people ignored Ted’s dictates and did what they thought was right–which splintered the group’s effort. Others left for positions where they could participate in solving problems rather than carrying out the managers prescriptions, driving turnover. Since hierarchy amplifies biases, it behooves people in management roles to build their awareness and find their filters.

Here are two exercises to build awareness of your own filters.

1. Work with a colleague who has different type preferences or a different sensory intake style. Make an agreement to share observations after meetings or working sessions.  What does your colleague consistently notice that you miss?  What do you miss by missing that?

Work on noticing those things that you have missed up until now.  Notice what insights you gain about yourself and the group.

2. Reflect on a recent meeting.  Did  you notice anything about the flow of conversation?  For example, in what order do people speak? Who interrupts whom, and how often?  Did you notice anything about physical arrangements? Or who is on their iPhone? Did you notice what emotions came up?

Choose an aspect of human behavior that you normally don’t notice. Then, practice noticing it.  Notice what insights you gain about yourself and the group.

If it fits for you, report back here. If you would like some help honing your self-awareness, drop me a note.

Alternatives to bureaucratic hierarchy

I don’t doubt that its possible to have an organization with out traditional managers. I’ve read about Semco and Morningstar Farms. I’ve talked to people who work at Gore. My husband works for a less well know firm that doesn’t have traditional managers.

But those companies didn’t get there by happenstance. They got there by design. People chose, designed, evolved practices and structures to support a specific culture. They didn’t take off-the-shelf models of functional or product based organizational structures.  They didn’t slide into typical  for people management practices, organizational structures, job levels or reporting relationships.

Most companies settle for practices shaped by management thinking of the first half of the last century–without a second thought. The language of this thinking is mechanistic and dehumanizing. It’s the language of efficiency, compliance, hierarchy, rules.

If you want a different sort of company, start with using a different language.

For example, rather than talk about “managing performance,” talk about giving people the information they need to continually improve or sitting down on a periodic basis to examine how we can work better together.  Does that feel different to you?  It does to me. Those words offer a different set of possibilities.

Because we are talking about people and complex human systems, not moving parts in some vast machine.

What do middle managers do?

Last week, someone tweeted that the C-suite “gets agile,” but middle managers “resist” it. I also saw a tweet that the C-suite doesn’t get agile, but middle management does.

I don’t doubt the observations of either of these tweeters.

I have observed situations where both senior and middle managers saw the value in moving towards a team-based organization and iterative incremental delivery. In my experience, it’s a little more common for middle managers to hold onto the existing pattern. And why not? When they don’t see their place in agile they don’t embrace agile. And agile is silent on the role of middle management. Blanket statements that dismiss the need for managers or management don’t help.

Organizations moving to agile still need management, and often still need people in management roles, especially in large complex organizations. In traditional hierarchies, middle managers look up the hierarchy for direction, and focus down the hierarchy to accomplish cascading goals. When teams pull work from queues and self-organize to meet goals, the real opportunity for middle managers is to look across the organization to improve the system and develop people and teams.

So what do middle managers do when they aren’t directing day-to-day work? Plenty.

Now you see some of the things middle managers can do to help their colleagues, their managers, and teams. Do you need help shifting the role of middle managers in your organization?  Give me a call or drop me an email.