Category Archives: Blog

Using Data in Problem-Solving

Several years ago, I was called to help an organization that was experiencing system outages in their call center. After months of outages and no effective action, they appointed an Operations Analyst to collect data and get to the bottom of the problem.

Once they had data, the managers met monthly to review it. At the beginning of the meeting, the Operations Analyst presented a pie chart showing the “outage minutes” (number of minutes a system was unavailable) from the previous month. It was clear from the chart which system the biggest source of outages for the month.

The manager for that system spent the next 40 minutes squirming as the top manager grilled him.  At the end of the meeting, the top manager sternly demanded,“Fix it!”

By the time I arrived to help, they had many months of data, but it wasn’t clear whether any thing had improved. I dove in.

I looked at trends in the total number of outage minutes each month. I plotted the trends for each application, and created time series for each application to see if there were any temporal patterns. That’s as far as I could get with the existing data. In order to hone in on the biggest offenders, I needed to know not just the number of minutes a system was down, but how many employees and customers couldn’t work for when a particular system was down. One system had a lot of outage minutes, but only a handful of specialists who supported an uncommon legacy product used it. Another system didn’t fail often, but when it did, eight hundred employees were unable to access holdings for any customers.

Though they had data before I got there, they weren’t using it effectively. They weren’t looking at trends in total outage minutes… the pie chart showed the proportion of the whole, not whether the total number was increasing or decreasing over time. Because they didn’t understand the impact, they wasted time chasing insignificant problems.

When I presented the data  in a different way, it led to a different set of questions, and more data gathering.  That data eventually helped this group of managers focus their problem-solving (and stop  pointing the roving finger of blame).

As a problem-solver, when you don’t have data, all you have to go on is your intuition and experience. If you’re lucky you may come up with a fix that works. But most good problem solvers don’t rely on luck. In some cases, you may have a good hunch what the problem is. Back up your hunches with data. In either case, I’m not talking about a big measurement program. You need good enough and “just enough” data to get started. Often there’s already some useful data, as there was for the call center I helped.

But what kind of data do you need?  Not all problems involve factors that are easily counted, like outage minutes, number of stories completed in a sprint, or number of hand-offs to complete a feature.

If you are looking at perceptions and interactions you’ll probably use qualitative data. Qualitative data focuses on experiences and qualities that we can observe, but cannot easily measure. Nothing wrong with that. It’s what we have to go on when the team is discussing team work, relationships, and perceptions. Of course, there are ways to measure some qualitative factors. Subjective reports are often sufficient (and less costly). Often, you can gather this sort of data in quickly in a group meeting.

If you are using quantitative data, it’s often best to prepare data relevant to the focus prior to the problem-solving meeting.  Otherwise, you’ll have to rely on people’s memory and opinion, or spend precious time looking up the information you need to understand the issue.

When I’m thinking about what data would be useful to understand a problem, I start with a general set of questions:

What are the visible symptoms?

What other effects can we observe?

Who cares about this issue?

What is the impact on that person/group?

What is the impact on our organization?

These questions may lead closer to the real problem, or at least confirm direction. Based on what i find, I may choose where to delve deeper, and get more specific as I explore the details of the situation

When does the problem occur?

How frequently does it occur?

Is the occurrence regular or irregular?

What factors might contribute to the problem situation?

What other events might influence the context?

Does it always happen, or is it an exception?

Under what circumstances does the problem occur?

What are the circumstances under which it doesn’t occur?

How you present data can make a big different, and may mean the difference between effective action and inaction, as was the case with the call center I helped

In a retrospective—which is a special sort of problem-solving meeting—data can make the difference between superficial, ungrounded quick fixes and developing deeper understanding that leads to more effective action—whether you data is qualitative or quantitative.

Here’s some examples how I’ve gathering data for retrospectives an other problem-solving meetings.

Data TypeMethodExamples Notes
QualitativeSpider or Radar ChartUse of XP practices.
Satisfaction with various factors.

Adherence to team working agreements.

Level of various factors (e.g. training, independence)

Shows both clusters and spreads.

Highlights areas of agreement and disagreement. 

Points towards areas for improvement.

Leaf ChartsSatisfaction.

Motivation.

Safety.

Severity of issues.

Anything for which there is a rating scale.
Use a pre-defined rating scale to show frequency distribution in the group.

Similar to bar charts, but typically used for qualitative data.
Sail boat (Jean Tabaka)Favorable factors (wind), risks (rocks), unfavorable factors (anchors), Metaphors such as this can prompt people to get past habitual thinking.
TimelinesProject, release, iteration. events over time.

Events may be categorized using various schemes. For example:

positive/negative

technical and non-technical

levels within the organization (team, product, division, industry).
Shows patterns of events that repeat over time. Reveals pivotal events (with positive or negative effects).

Useful for prompting memories, showing that people experience the same event differently.
TablesTeam skills profile (who has which skills, where there are gaps)Shows relationships between two sets of information. Shows patterns.
TrendsSatisfaction.

Motivation.

Safety.

Severity of issues.

Anything for which there is a rating scale.
Changes over time.
QuantitativePie ChartsDefects by type, module, source.

Severity of issues.


Shows frequency distribution.
Bar ChartsBugs found in testing by module + bugs found by customers by module.Frequency distribution, especially when there is more than one group of things to compare.

Similar to histograms, but typically used for quantitative data.
HistogramsDistribution of length of outages.Frequency of continuous data (not categories).
TrendsDefects.

Outages.

Stories completed.

Stories accepted/rejected.
Shows movement over time. Often trends are more significant than absolute numbers in spotting problems.

Trends may point you to areas for further investigation—which may become a retrospective action.
Scatter PlotsSize of project and amount over budget.Show the relationship between two varianles.
Time SeriesOutage minutes over a period of time.

Through-put.
Show patterns and trends over time. Use when the temporal order of the data might be important, e.g., to see the effects of events.
Frequency TablesDefects

Stories accepted on first, 2nd, 3rd, demo.
A frequency table may be a preliminary step for other charts, or stand on its own.
Data TablesImpact of not ready stories.Show the same data for a numberr of instances.

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.