Tag Archives: human system dynamics

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?

 

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.

Pendulum Swings and Oscillating Systems

An effective hierarchy provides enough central control for coordinated action in achieving the aim of the organization. At the same time, the hierarchy must provides enough autonomy for subsystems to function, self-organize, flourish.

Yes.  But how to do that? Let me walk you through a scenario that describes the challenge.

I’ve seen a number of organizations decentralize control and decision making, only to pull it back to the home office. If you watch long enough, many of these companies after experiencing centralized control for a while, go back to decentralized control–like a pendulum swinging back and forth.

Here’s how it goes.

As a result of centralized control, decisions are slow.  Slow decisions and top down plans that require an act of god to change lead to poor financial performance, and customer dissatisfaction. Because people are effectively denied discretion, creativity plummets. Rigid plans and targets don’t allow people to take advantage of new opportunities.

When the financial results start to trend down, senior management notices.  They want faster decisions, and front-line people who are responsive to customers. They want creativity, innovation. They want to seize emergent opportunities and respond nimbly to change.  They want better financial results.  Who wouldn’t want all those things.  So they decentralize.

After the initial flush of enthusiasm, they start noticing problems. Visibility decreases. Decision making and spending feel out of control. Some subunits make inappropriate decisions. Subunits optimize at their level, forgetting the overall goal of the organization. Some subunit managers go rogue, and strike out in directions that make no sense for the overall company strategy. Financial results dip.

And the managers want a return to clear lines of communication and authority. They want visibility, coordinated action. They want predictability, consistency. They want CONTROL. So the pull decision making, planning, budgeting back to the center.

While the supposed solution seems to be swinging between two poles, the organization and the people in it experiencing an oscillating effect.


In truth, the company doesn’t want either end of the pole.  They want the upside of both centralized control and decentralized control.  They want enough control to effectively coordinate actions of the various parts of the system to achieve the goal of the organization,  And they want enough autonomy so that all parts of the system can flourish, self-organize and respond to opportunities and change.


Why do systems oscillate?  Delayed feedback and an over-vigorous correction.  This happens on the organizational level, but it can also happen on a smaller scale anywhere in the system where feedback is slow and well-intentioned people over-correct when they do get feedback on system performance.

In order to achieve the upsides, organizations need to manage the downsides.  And that requires faster and more robust feedback loops. Those feedback loops will provide information about system behavior sooner, and allow smaller more nuanced adjustments.

I’ll write about some of those feedback loops next.

Team Trap #3: Failing to Navigate Conflict

“The absence of conflict is not harmony, it’s apathy .” Eisenhardt,  Kahwajy and Bourgeois

“(….or acquiescing, or avoiding).” Esther Derby

Conflict is inevitable at work. Sooner or later, people will disagree about what to test, how to implement a feature, what “done” means, or whether “always” means 100 per cent of the time or some thing else. If team members can’t muster the involvement for a disagreement, you’ve got problem. failure to navigate conflict

Conflict holds the possibility for building trust or tearing it down. How team members choose to approach conflict will affect the outcome, relationships, and ultimately the ability of the team to function.

Conflict often feels personal–but often it is not.

Structural Conflict

Systems and structures drive behavior, and in almost every organization structures create conflict.  Misaligned departmental goals, reward systems, emphasis on functional roles , and differing priorities can all engender conflict

But often people don’t recognize the structural source of the conflict. When the structure  behind the conflict isn’t visible people personalize the conflict.  I hear this when developers talk about how stupid the marketing people are or when testers complain that devs don’t really care about quality.

Communication Misfires and Mismatches

Once structure is ruled out, the most common source of conflict in groups stems from communications where language is misunderstood, mis-construed or data is missing.  These sorts of conflicts are usually easy to fix.

Many English words have precise meanings.  But there are plenty of common terms where definitions vary between professions or among people. When I worked in a mutual funds company the term share price was used to refer to the monetary value of an individual investment vehicle (a share of stock), and the monetary value of a share in an mutual fund.  If you didn’t know which area a person worked in, it was pretty confusing. Confusion can escalate to conflict when people don’t recognize that they are using one word with two (or more) definitions.

Entrenched Positions

Advocacy isn’t bad in and of itself. But when advocacy proceeds without inquiry, it can become a position conflict.  Position conflicts are often easy to recognize. Each person (or party) argues forcefully for a preferred solution without reference to the problem they are trying to solve.

When neither party is willing to explore the other option, examine assumptions, and  generate additional candidate solutions, advocacy turns into conflict.  Once people frame advocacy as win-lose, it’s hard to back down. Doing so might look weak, feel like giving in, or imply that one was*wrong.*  Most people will go to great lengths to avoid admitting they were wrong, especially when eating crow is part of the bargain.  Backing down from a strongly held position can feel like eating crow, especially when the other person crows over his victory.

At a recent workshop, a participant asked “Why wouldn’t you start by advocating your own idea?”  It’s an understandable question; in the US we grow up on in a system where the best argument (or at least the loudest one) wins, where competition is valued and zero-sum game thinking is the often the norm.

The first reason not to advocate is that when you advocate, you are not learning.  You’re defending and pressing your idea, not examining the problem and seeing different points of view. You aren’t learning about another possible solution or seeing improvements for your own.

Different Values

Arguing points of view and potential solutions is one thing; some times a conflict goes deeper and touches basic beliefs about what is valuable, true, and good.

This sort of conflict can look like a position focus conflict.  The difference is that each proposed solution seems as if it could solve the issue or be a reasonable approach. But either or both may leave out key elements of what the other party describes as “reality.”

Different Preferences and Styles

Differences in how people process information, make rational judgements, and plan their day can provide the fuel for conflicts.  So can differences in boundaries, social needs and styles, times-sense and ideas about ownership.

We find other people difficult when they don’t meet our expectations of “appropriate” behavior. The trouble is that each of us has a different definition of “appropriate.” To further complicate matters, some areas of mismatched expectations are easy to see and comment on, but others aren’t.

All Roads (May) Lead to Personality Conflict

Some times conflict does get personal–usually when a string of smaller unresolved conflicts fester.

From the outside it may look like two people plain don’t like each other.  At it’s worst, it looks like the warring parties are out to destroy each other, no matter what the personal cost to career prospects or the productivity of the team.

It starts with one interaction that goes off track, an irritation that’s not addressed, or an action that’s interpreted as a slight or attack.  When these situations aren’t checked an corrected, one person starts making up stories, stories about himself, and the other person.

The story he tells about himself portrays him as someone whose motives are pure, and bears no responsibility for the situation.  The other person is portrayed as the perpetrator, the one who is insensitive, crass, or down right evil.

Once you have some idea about the source of the conflict you can apply different strategies to steer back towards productive discussion.  Conflict isn’t bad, and it doesn’t have to be painful or confrontational.  Conflict–handled well–is an opportunity for learning, creativity, and building trust.

Shifting Organizational Patterns

I’ve been talking about (and using) Human Systems Dynamics tools lately–Rally Success Tour, OTUG, Practical Agility and Retrospective Workshops in Stockholm.

I find Containers, Differences, Exchanges offers my clients (and me) a useful way to see past events and see structures. Working at the level of structures gives both insights and opens up opportunities for action.

My slides (or the March 16 variation of my slides):

And here’s my talk at the Rally Event in February:

Bridging Structural Conflict: Same and Different

No two people or groups are the same, but their differences don’t have to force them apart.

I recently talked to two groups who were feuding. On one side were the development teams, tasked with delivering new functionality every two weeks. On the other were the operations folks, who were charged with keeping the environment stable and available. Simmering resentment was getting in the way of working together. People were talking through proxies and hurling insults.

This is not the first time I’ve seen development and operations at odds.Conflicts like this are almost always structural. For example, the conflict may arise from the way the company is organized to accomplish work, different and conflicting goals, and different professional points of view. But, when people don’t realize the source of the conflict, it tends to get personal. People on each side of the conflict start talking about “those people,” as if the people on the other side are stupid, bad, or wrong.

Welcome to the fundamental attribution error. Humans tend to explain others’ behavior as resulting from personal characteristics and ignore the role of external circumstances. It’s seldom true that people have evil motives, are intentionally blocking progress, or are as dumb as dirt. The people employed in our field are reasonably intelligent, well-intentioned, and come to work wanting to do a good job.

Some structural conflicts dissolve if people are organized differently or when professional concerns are harmonized for complementary action, such as working together to create a software feature. When testers, GUI developers, database developers, and middleware developers come together in a cross-functional team, their differences can be a source of strength rather than conflict.

But, the structural conflict between the development (dev) and operations (ops) groups I was working with wasn’t going away. Dev and ops do fundamentally different kinds of work, with different rhythms and needing different skills. However, these two groups did (as they do in most organizations) need to find a way to dial back the conflict, appreciate each other, and work together reasonably well.

In cases like this, I find it helps to look at how the groups are similar and different. So, I asked the groups to work together to make a chart listing similarities and differences.  Same and Different Lists

As the list of differences grew longer, I felt a niggling worry that there wouldn’t be a difference the two groups could negotiate. So far, the differences they’d listed weren’t going away; they were inherent in the work. The items in the Same list were important—that’s the common ground where people can land when conflict arises—but this list was very abstract and “Mom and Apple Pie.” There wasn’t enough to bridge a gaping chasm.

Then, one of the ops specialists busted loose. He started listing all the ways the dev teams failed to prepare for production turnover.

And, there it was (with a little reframing to get the blame out)—an area where the two groups could work together. Redefining “done” and making a production checklist gave them a chance to work together on a small, bounded project. Working together on a shared goal would help each group understand the other’s context, know each other as people, and understand how their different concerns added up to a similarity: “Our work is critical to the business.”

There’s some wrangling yet to come before these two groups stand down, join hands, and sing “Kumbayah.” Some people may even be reluctant to give up their belief that “those people” are idiots. It is convenient to have someone to blame rather than recognize that some conflicts can’t be resolved, and it doesn’t imply anything about intelligence or motives. It’s not likely—or desirable—that the two groups become of one mind on all things. They do different work; what’s necessary is that they find a way to cooperate and coordinate in a way that meets the goal of delivery and stability.

If you find your group in conflict with another, you can try this exercise to bring some needed coherence. First, discern that it is a structural conflict. Conflicts of this sort tend to happen when there are different departments or goals, different professional interests, different types and rhythms of work, and when the teams do not have an interdependent goal at the level where they do their work. Everyone in a company may have a goal of “producing valuable products profitably,” but at a department level, groups may be at odds. For example, both developers and auditors want the company to be successful, but they have different roles in meeting that goal, which often feel at odds—i.e., structural conflict.

Here’s another check. Some structural conflicts are self-imposed, as when testers and developers report to different managers and are measured differently. Testers and developers do have an interdependent goal: It takes both testing and development skills to deliver a complete and reliable product. If you bring together both on a cross-functional team, the conflict usually dissolves.

If you feel it really is a structural conflict, find someone neutral to facilitate the session. Get both groups in the room. Avoid recrimination and blame, and establish the following ground rules to keep the discussion productive:

No labels. That means neither group can say the other group is lazy, sloppy, or a bunch of slackers. Positive labels aren’t much better; they don’t give specific information, and they imply that one side is empowered to evaluate the other. The power-difference message comes through whether the labels are negative or positive.

No characterizations about motives or intelligence. Remember the fundamental attribution error? People and groups that are in conflict develop stories about the “others.” Over time, these can evolve into harsh judgments about the others’ motivation, intelligence, and general fitness as human beings. The judgments show up in statements such as “They don’t care about quality,” “They don’t get it,” and worse.

When you catch yourself saying something like “They don’t care about X,” rebuild the sentence as “They have a different perspective on X.” Rebuild “They don’t get it” to “They don’t see it the same way I do”—which might just prompt you to think, “And I bet I don’t see it they way they do. I wonder what they see that I don’t.”

Make the list. Write down all the ways the groups are the same and how they are different.

Consider these questions to help the group process the list:

Which differences can be negotiated or changed?

Which ones are most significant?

Which similarities and differences help us do our work? Which ones get in the way?

Would it help us do our work if we were more the same? More different?

Not all differences make a difference, and not all differences can (or should) be eliminated. We need different skills, different points of view, and different professional concerns to create valuable products.

The point is to find something that the two groups can work on together to build a bridge. Then, when conflict arises again (and it will) they’ll have some common ground to land on (the similarities) and at least one experience of working together.

Sometimes, fate intervenes to give two groups a common goal—like a fire or flood in the office. After fighting fire or flood, groups tend to see each other as real human beings, not the sum of misattributed characterizations. I don’t wish fire or flood on anyone, so look around for additional natural opportunities for to work together—but don’t start fires.

This article originally appeared in Better Software Magazine.

Changing to Agile, in an Agile Manner

A while back I was contacted by a potential client who wanted to “go agile.”  But they wanted to do it in a deterministic manner.  They wanted a plan, complete with milestones and dates–mostly indicating that other people had changed their behavior as dictated by management.

Sigh.

One could make a plan for mass training (aka sheep dip), I suppose.  One could   dictate that by June 10, 20XX, all teams will practicing TDD.  Or that all projects will be converted to backlogs and loaded into agile project management software.

But that doesn’t seem so agile to me.  It seems like it misses the point of learning and adapting; of embracing values; of understanding systems and patterns, how the work works, what’s working and what’s not.  Without considering the WHY behind processes and learning as you go, you are only going through the motions.

Start with understanding the current state, and what problem you are trying to solve by “going agile.”  Understand how the current structures and goal alignments are supporting or hindering the goal of delivering products to customers, and identify targeted changes that will improve that ability. Identify where and you can change the pattern and establish structures that will help the new pattern take hold.

Make a Road Map, knowing that you don’t know everything and can’t foresee all you’ll discover on this journey of change. Describe the desired pattern and the steps that you can currently envision to get there.  You won’t be able to see all the steps. If your initial actions are effective, your culture will be changing. Any far-future actions you described from the driveway may no longer be what’s needed when you are 100 miles from home.

It’s impossible to know everything at the outset when you decide to make what amounts to a cultural change. You take some steps, observe the effects of actions, and adapt, learning as you go.

Deterministic planning fails with complex software systems, and it fails with organizational change. Organizations are far too complex, and we need to plan for adaptation, learning, and the fact that the organization will be changing as the plan unfolds.

Eleven things to remember about people in middle management roles.

It’s easy to be critical of managers.  A few things to remember.

0. Most people in management roles want to do a good job, but may not know what to do or how to do it.

1. People in management roles are dealing with incomplete and ambiguous knowledge.  It’s a fantasy that they have all the information and know what to do (which may be held by both managers themselves and people who wonder why their managers do clueless things).

2. Most people in management roles receive little or no training on how to be  good managers.  Many people are promoted into management roles because they excel at technical work.   This is not an easy transition.

3. Many people in management roles are working out of a mental model of management that limits their effectiveness.  (See Don Gray’s Managing in Mayberry for two common mental models and one that’s less common.)

4. Many of the role models new managers have aren’t helpful. If people have never experienced good management, you can’t fault them for a lack of imagination.

5. Much of the management training out there is crap.

6. People in management roles are expected to achieve results over which they have no direct control.  They must work thru other people and create work environments and work systems that support other people to do excellent work. Most managers have no training in how to do this.

7. Most people in management roles face demands from their managers and from the people who report to them. The are pulled from above and below.  These demands are not always aligned and may be mutually exclusive.

8. Middle managers receive little peer support.  Most managers face isolation and competition from other middle managers who are trying to meet locally optimized goals, obtain scarce resources and look good to the next level up.  This is even more salient for new managers. Power difference (not matter how slight) changes the relationship with former peers.

9. People in management roles need to see the system and work on system, but receive little to no training in system seeing/thinking/acting.  Relentless pressure tends to hold their focus on short term events and results, making it difficult to see patterns and connect the dots of seemingly unconnected events.

10. People in management roles need to work on the work system; they are also in the system, and their behavior is shaped by the system they work in. Both top managers and middle managers fall into predictable patterns of behavior.