“If you don’t know where you are going, you probably won’t get there.” – Yogi Berra

The pager tones sounded at 2 AM. It blared “Squad 86, car accident with personal injuries on Highway 268 west of Pilot Mountain.” I don’t know how much research went into the tones, but when they sound, they can wake anyone from sleep. I quickly calculated that was less than a half mile from my house. I climbed into my turn-out gear and into my car. Off I went! I found the first patient sitting on the road side. Talking with him revealed another victim, somewhere on a side road. Other squad members started arriving. I could hear the ambulance siren headed our way. The goals were simple. Find the patients, stabilize their injuries, and send them to definitive care.

Software development teams need common goals. These goals create focus and form the glue that holds teams together. They answer the basic question, “Why am I here?” Knowing why the team has been brought together provides purpose and identity. Teams need three common goals; long term, mid term, and short term.

Long Ago, Right Now and in the Near Future

Long term goals provide the overall direction and answer the questions: “Which part of the corporate mission statement does the project I’m working on support?” and “What business goal does this completed project meet?” Time in long term goals ranges from several months to years. The long term goals provide direction to keep the team oriented during the mid term goals.

Mid term goals are check points along the project’s path. These check points answer the questions “How are we doing towards meeting the long term goal?” and “Are we done yet?” Mid term goal time spans should be between 2 – 4 weeks. Having mid term goals allows the team to verify progress as they deliver working software, not a report estimating completion. Additionally these checkpoints allow the team to make corrections if they misunderstood the functionality required for the mid-term goal. They also form the framework for the short term goals.

Short term goals focus the implementation questions: “Who does what, when and where?” Short term goals have a time span of a few hours to a couple of days at most. This keeps the development team making visible progress toward the mid term goal. Problems meeting the short term goals can bring a team together by providing an opportunity to cooperate by swarming to overcome the problem. Completing short term goals provides an indication if the mid term goal will be met.

Some teams lose sight of the goals. One team I worked with had a clear business goal which had substantial profit for the company, but they were making glacial progress towards the goal. The details swamped their planning capacity. We created a burn up chart listing the major portions that needed to be completed then sub-divided those into short term tasks. The team met semi- weekly reviewing what had been completed, and what they were going to work on next. This permitted us to show progress to management and balanced the long/mid/short term focus.

If your team isn’t producing like you feel it should, check to see the members understand the business objective. A simple technique is to ask the question, “Why are we doing this project?” Ask each team member and compare the answers. If the answers don’t agree, there’s confusion about the business objective. Help the team understand how the project provides the value to your company. The same process can be used to clarify the mid-term goals if the team agrees on the business objective.

How Unaligned Goals Impact Your Bottom Line

“Never attribute to malice or stupidity that which can be explained by moderately rational individuals following incentives in a complex system of interactions.” Hubbard’s Corollary to Hanlon’s Razor

I recently visited a team I had worked with to see how they were doing. In an effort to get control of feature creep, the IT department directors instituted an “analysis/design” phase just as I left the project. This phase resulted in a design packet that contained all the information the team would need. If the team had questions, they could ask the systems analysts for clarification. This decision did remove change requests from the client (another business unit in the company) … until the client representatives began their user acceptance tests. At that point the client organization refused to accept the software until changes were made. The team started working on the changes and delivered the software six weeks late.

While six weeks doesn’t seem terrible, let’s take a look at the costs associated with the schedule slip.

Failure Demand

Software teams’ productivity falls in two basic categories, value demand and failure demand. When the team started the project they spent their time on value demand – creating value for the client. As the project got close to completion, the team started delivering to the external QAT testers. When the testers sent defects to the team they shifted to a combination of value demand (creating new features) and failure demand (correcting defects). The final six weeks (beyond the 12 week original schedule) the team spent 100% of their time doing failure demand work. I don’t know what the loaded cost for the 7 team members was, but it was a cost that could have been avoided if the IT directors had the same goal as the client .

Lost Opportunity

For the six additional weeks the team worked this project, it could not start the next project queued. This means the potential revenue and benefits for the next project could not be realized as anticipated. Making matters slightly worse, the six week shuffle rippled into delivering the next project since major deployments to production occurred quarterly and delivery for the new project didn’t happen until the next drop window.

Confidence

We can assign a reasonably accurate number to the 6 weeks of failure demand. Using the calculations that justified the next project, we can anticipate how much the lost opportunity cost. What we can’t assign a value to is the loss in confidence the client organization now has in the ability of the IT department to deliver on its commitments. But as I wander through and around clients, I hear cynicism and distrust abound when they discuss IT.

From the Top Down

So what steps can we take to make sure we have common goals, and what can we do if the goals don’t align?

Charter

Check your project charter. In what way does the charter support a major strategic goal for your company? If you can’t find a charter for your project, create one and share with your boss, and your boss’s boss. Tying your project to a strategic corporate goal provides the long term goal teams need for framing their activities.

Vision

With a project charter that supports a strategic goal, next look at the product’s vision statement. Teams with a compelling goal do better work. [1] The product vision also provides a touchstone for the team to use as they work. If you don’t have a product vision, you might consider using the information here http://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html to create one. Be sure to include those who will use the product if you find yourself creating a product vision.

The problem I experience most often with charters and visions isn’t that they don’t exist; it’s that they rarely make it to the team level.

Backlog

Now that you have a project charter and know the product vision, you can create a product back- log to fulfill the vision.

All’s Well that Ends Well

We finally located the second patient a mile down a side road. When the ambulances arrived we loaded the patients and helped the paramedics start the necessary intervention based protocols. Our goals allowed us to focus on achieving a positive outcome for the patients.

By keeping your organization, department and project goals aligned you can achieve success.

]]>http://www.donaldegray.com/goal-goal-whos-got-the-goal/feed/0Why Agile Workshttp://www.donaldegray.com/why-agile-works/
http://www.donaldegray.com/why-agile-works/#commentsMon, 08 Sep 2014 20:57:45 +0000http://www.donaldegray.com/?p=438Someone once asked me, “Don, what does even the wisest person overlook?” The answer was “his nose.” You can see your nose if you focus, but you generally don’t bother. You assume it’s there. Likewise, as I have gained experience in software development, I have learned that explicitly stating my assumptions keeps me from overlooking important aspects of what I’m working on.

The Sliding Scale of Software Development Complexity

Software systems run the gamut, from closed systems with low dimensions and linear behavior to open systems with high dimensions and non-linear behavior (see ﬁgure 1). Closed systems are unchanging, while open systems change based on interactions with their environments. A system with low dimensions has few interactions between its parts, while a system with high dimensions has many interactions. In a system with linear behavior, the output is the sum of the parts, while in a system with non-linear behavior, the output is a product of the system’s interactions. Our assumptions about where software development as a system lies on this continuum determine the processes we choose to use for a project.

Early in my career, I worked on automating the production area in a new plant, “Project S.” We had about 10,000 input/output points and twenty-five operator terminals scattered through five production areas. This project exhibited detailed complexity with a lot of parts to keep track of, but the project’s physical nature limited the dimensions, established a linear process, and kept the scope from expanding.

I assume that some non-physical software projects, such as accounting software, have occurred often enough that they, too, fall in the “Close To” corner. But, how valuable can another accounting package be? That market seems to have enough. If we want to create value, we must leave the “Close To” corner and start sliding toward the “Far From” corner. We might start using unfamiliar technology (have you noticed the recent explosion in languages and frameworks?) and not be completely sure of what needs to be done.

Notice, in figure 2, as we move toward “Far From,” that a project’s nature shifts from simple through complicated, complex, and finally becomes chaotic. In each area, the methods and processes for delivering the project change. Fortunately, methods and processes used for complex projects can also be used for complicated and simple projects. Unfortunately, the single greatest problem I see when working with software development organizations is that they apply methods and processes for simple projects to complex projects.

The primary characteristic of a simple project is the ability to analyze the project. Analysis means breaking a larger project into smaller parts to understand it. If we can understand the smaller parts and successfully aggregate them into the larger project, then we have a simple project. This reductionist thinking started with the Greeks’ trying to understand their world. They hypothesized atoms, which weren’t verified until millennia later.

This thinking leads project managers to ask for a project description. Then, they (or a systems or business analyst) subdivide the project into smaller parts until they can generate a Gantt chart showing modules or tasks, dependencies, and an eventual delivery date.

Many project tools exist (perhaps most famously Microsoft Project) that deal with this detailed complexity. Properly created and constantly updated, these tools can project a delivery date. But, what assumptions do project managers make while creating these schedules? In my experience, common assumptions include:

What the customer asks for won’t change (i.e., fixed scope).

The people I expect to work on the project will work on the project.

The task breakdown is accurate.

The time estimates for tasks are close enough.

Experienced project managers will include tolerances to allow for some variation because these assumptions will exhibit some variation. Nonetheless, the major underlying assumption remains: The project’s nature fits the definition of a simple project (closed, low dimension, and linear behavior).

Not All Projects Are Created Equal

Several years after working on Project S, in a hot August in Chattanooga, Tennessee, I stood quietly in a pool of sweat as the project manager berated us for being behind schedule on “Project C.” The chemical plant we were automating had a fast-track schedule. Pipe fitters made piping runs before the elevation drawings were complete and reviewed. Piping and instrumentation diagrams updated daily. We constantly rewrote the control software and operator displays based on the information du jour.

After three months, the plant owners stopped the project and sent everyone home. A week later, they invited us back to finish the project. We developed the software in the operator control room, not the engineering office. This gave us instant feedback from the users on the displays. The plant engineering VP’s office was two doors away. Every morning, he updated us on necessary control system changes.

I don’t know what happened to the yelling project manager. We never saw him again.

In some ways, this project was simpler than Project S. The plant was much smaller, with fewer input/output points and operator terminals. So, what created the problems?

Project details changed almost daily.

Everyone—engineers, developers, electricians, and pipe-fitters—constantly interacted to deal with the newest information.

Due to these dynamics, this project exhibited the characteristics of a complex project. The original engineering and project management company had demonstrated experience with simple projects, but their simple project methods and tools couldn’t deal with this project’s dynamic complexity. The product of the constant change, the project’s interactions, and time constraint overwhelmed the plan.

Working with Complex Projects

Complex projects exist in the region where we need different tools and methods to solve the problems. Decision making shifts from technically rational thinking to brain-storming, dialectical inquiry, agenda building, intuition, searching for error, and occasionally muddling through. Rather than a process of “sense, categorize, and respond,” the domain requires “probe, sense, and respond.” We try something, evaluate the situation, respond appropriately, and the solution emerges.

Solving complex systems using reduction shifts the goal from providing customer value to building pieces of the overall solution. This leads developers to focus on technical tasks, not delivering small pieces of user value. The hope is that when all the parts get assembled into the system, it will exhibit the characteristics we’re looking for. This works for simple projects. But, more often than not, it doesn’t work, indicating that the project has a complex nature and we have used the wrong method to work it.

Agile Manifesto Principle: “Business people and developers must work together daily throughout the project.” [1]

In my article, “Goal, Goal, Who’s Got the Goal?” [2] I shared the three goals every project needs: the project goal, sprint goal, and daily goal.

The project goal needs to align with your company’s strategic goals. It should focus on customer value. People don’t purchase software because they want another program but because they will benefit from using the software. This provides them the value that convinces them to spend the money.

The sprint goal defines what the development team will deliver in the next sprint or iteration. While the team works to deliver customer value, it does so by completing technical work. The sprint goal keeps the team focused on the immediate work.

The daily goal keeps the team synchronized. It highlights completed work (I’ve worked with a team that applauds every task completed) and allows team members to share information and ask for help removing impediments.

Having clear and aligned goals creates a point attractor. This attractor allows the complex solution to develop over time. It creates a focus that pulls the work toward the final solution, one piece of user value at a time.

During Project C, sitting in the control room allowed us to ask the plant operators for ideas on what they needed to see and be able to do with the control software. Having the VP of engineering down the hall enabled us to deliver value with minimal delay.

REDUCE DELAY

Agile Manifesto Principle: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. ”

Delays in software development come in many forms. In large, siloed companies, finding the person with the needed information and skills isn’t always easy.

I worked with one client moving from silos to Scrum who routinely took more than a day to identify the silo needed to solve a problem and the correct person to do the work. Most people in that company were also assigned to multiple teams. One person was assigned to six different teams. Another was so specialized that it took more than three weeks before that person could even look at the problem.

While this might appear efficient from a “resource utilization” viewpoint, it wreaks havoc with delivering user value. In one class I taught, 75 percent of attendees had been on a project that lasted more than a year, and one person had been on a project that went more than two years. Adding offshore development teams compounds this delay. Almost every sprint in this company had at least one task that slipped by each day as we worked with the offshore team members to clarify and answer questions.

Many people think of project work as the actual effort to write the code. Using project management tools to subdivide the work, assign dependencies, and calculate the critical path, we plot when the project will complete. This hides the reality that waiting for everything delays realizing income (that “ROI” thing managers love so much) until the end of the project. Lengthening the time until the end date also puts the project in jeopardy, due to organization priorities, changing requirements, shifting markets, and, in some cases, new legal requirements.

By focusing on incrementally delivering value, managers shift their thinking from “How can I make sure everyone is always working?” to “What causes delay in our process, and how can we restructure to remove those delays?” One client I’m working with has started “on-shoring”—hiring locally so team members can be collocated. When teams learn to think in small units of value, the ability to continuously deliver value increases. Not every project can ship at the end of every sprint, but it’s cool to watch the results when it does happen.

By reducing delays, we can get better and faster feedback.

FEEDBACK

Agile Manifesto Principle: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. ”

Project S and Project C employed different development structures. For Project S, someone took all they tasks he knew about and created a Gantt chart. Adding the task times on the critical path allowed the managers to compute an expected completion date. We followed the (at the time) standard process of analysis, design, coding, testing, and implementation. Managers monitored progress by comparing a task’s scheduled time and actual time. As the schedule slipped, another developer would be added to the team to help make up the difference. Somehow, this never really helped, and the project’s end date didn’t change. This meant that the final phase, testing, was shortened, enabling us to meet the startup date. That didn’t work well either.

Project C, on the other hand, used a development process more like figure 3. Two feedback loops tracked the project’s progress. The inner loop—daily standup, team, and completed stories—allowed us to monitor our daily progress and answered the question “How are we doing right now?” The outer loop (which included everything) answered the question “How are we progressing compared to all the project work?”

Figure 3: Aligned goals using two feedback loops

The feedback loops inherent in this development method demonstrated to the business (stakeholders and product owners) how the software looked and operated. If needed, corrections in the software could be made while the software was still fresh in the developer’s mind and prior to adding additional functionality.

Combining this method to measure progress and reducing delay by collocating with the users demonstrated actual progress. We didn’t have project phases like in Project S.

During Project S, our status meetings included “percent complete” updates for the various tasks. Eventually, I came to understand Tom Cargill’s Ninety-ninety Law:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. [3]

Dividing software development into phases and functional layers inhibits information ﬂow, hides delays, and defers complex and difficult tasks until it’s too late to deliver on schedule. Having clear goals, focusing on business value, reducing delays, and providing feedback on working software allow team members to align their efforts to complete the project.

ALIGNING EFFORT

Agile Manifesto Principle: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. ”

As I worked my way through college, my employer purchased a Data General business computer. It came with a program that allowed us to define what we wanted. The program then churned for hours, creating a business system. It never worked quite right—probably because we didn’t know exactly what we wanted or how to use the program’s output.

What have I learned since then?

People—users, developers, and testers—work together to create software from needs and ideas. People vary, tend to inconsistency, exhibit good citizenship, and are good at looking around. [4] In other words, people also fall into the complex space. To align effort, teams need a compelling work goal, five to nine members, stable membership, shared history, and interdependent work. [5]

The compelling work goal changes our jobs into careers. In Drive, Daniel Pink calls this “purpose.” Having clear goals for the project helps the team connect their effort to results, and this helps create the compelling work goal.

CONTINUOUS IMPROVEMENT

Agile Manifesto Principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. ”

If people are complex systems, then interdependent teams must be complex or even chaotic systems. When teams exhibit the characteristics of chaotic systems (open, non-linear, high dimensions), they have a difficult time accomplishing work. They spend time and energy making and remaking decisions, working on tasks that don’t contribute to product, and dealing with interpersonal issues.

Periodically reflecting on becoming more effective focuses the team on how best to meet their goals. They may change how they develop software (“Let’s try pair programming and notice the impact on code quality and number of defects”), technical practices (TDD, CI, etc.), and how they interact with each other (“Here’s how we can improve our daily check in”).

These decisions provide a framework in which the team may interact and do work. Their agreements move them from chaos to complexity. By norming, they can start performing.

One for All

We tend to assume that our current software project has similar characteristics to our other software projects. But, often, the project characteristics vary significantly. Trying to deliver a complex project (open, high dimension, non-linear) using methods designed to solve simple projects (closed, low dimension, linear) doesn’t work well.

Fortunately, we can use methods designed to deliver complex projects to deliver simple projects. If you’re going to assume anything, assume that you have a complex project and use agile principles. That way, your methods will solve the problem.

This article was originally published in the November/December 2012 Better Software Magazine.

]]>http://www.donaldegray.com/why-agile-works/feed/0Agile Change – The Valueshttp://www.donaldegray.com/agile-change-the-values/
http://www.donaldegray.com/agile-change-the-values/#commentsTue, 29 May 2012 19:20:42 +0000http://www.donaldegray.com/?p=362What does Agile involve? And what do I mean “Agile”? Does “Agile” mean “Agile, the Manifesto” and the “agile, the principles“? How about “agile, the software development methods“? Actually, “Agile” in this case means “all of the above”. When I look ate these, I find change. Changing what we value. Changing how we develop and deliver software. Changing the engineering practices and methods to create software to support change.

Our environment, abilities, beliefs and values influence our behavior. Any action we take results from how these affect our thinking.

It seems to me changes resulting from/attributed to Agile should have values that parallel those in the Agile Manifesto. Without too much effort this results in:

In Agile Change we value:

Individuals and interactions over processes and tools

Learning and changes in behavior over new org charts and process documents

Participation and refinement over top down directives

Recognizing new opportunities over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Using the Stacy Matrix as a guide, it’s my observation that change falls into the “complex space”. This means mechanistic, Tayloristic, plan driven change will usually fail, and create multiple messes while doing so. These models do not map to a reality involving multiple concurrent paths and the ensuing change in decision making.

I get concerned about a change processes involving people and making statements like: “Diagnose gaps and manage resistance.” and “Never letting up.”

]]>http://www.donaldegray.com/agile-change-the-values/feed/1Organizational Changes Make Messeshttp://www.donaldegray.com/organizational-changes-make-messes/
http://www.donaldegray.com/organizational-changes-make-messes/#commentsTue, 22 May 2012 21:41:32 +0000http://www.donaldegray.com/?p=357Last week Mike Cottmeyer posted that People Are Messy. He gave an excellent example how two people approach and respond differently to change. I might choose different words to describe people. I definitely agree that change gets messy. Change starts getting messy when our change model doesn’t map to the reality we deal with.

I’ve summarized the differences in the types of change in this table. The descriptions come from HSD. I added the equations (for us math/engineer types) and the graphs of what the change might look like.

Name

Description

Equation(s)

Looks Like

Static

Static change is the simplest,being two-dimensional, it depends on direction and force. It is also predictable. Static change is about moving from Point A to Point B by applying force.

axn+axn-1+…
+ c

Dynamic

Dynamic change is more complicated, being multi-dimensional. It can best be described as moving along a smooth trajectory toward a predictable end point. Like water shooting out of a hose, if pressure and angle are known, you canpredict height and distance of the arc of water.

axnbym + ax(n-1)by(m-1)
+ … + c

Dynamical

Dynamical change is complex and results from multiple forces acting in unpredictable ways, generating surprising outcomes. Think about water dripping from a faucet. The rate of drops depend on too many factors to to predict, precisely, when each drop will fall. The amount of deposit in the pipes; the temperature, wind, and humidity in the room; and the amount of water in the pipe interact in unpredictable ways to determine when drops will fall—non-predictable and maddening in the middle of the night.

dx/dt = σ (y – x)

dy/dt = x (ρ – z) – y

dz/dt = x y – β z

Let The Mess Begin!

So what happens? Some executive, somewhere, decides things need to change! People get assigned to new departments or teams. A new reporting structure gets defined. The charts are drawn, powerpoint slides created, and “all hands” sessions scheduled. (Using the Organizations Change… post, what model is management using?) The mess starts shortly after the meetings.

In my experience managers usually expect static change behavior. Start here. Go there. Done. You’re in a new team. We moved your equipment and materials to the new space. What’s the problem? Other than everyone having to work through the Change Model?

Some people will work through the Change Model quickly. But

As Mike points out: “On many levels we are dealing with very personal deep seeded stuff… the stuff that anchors us as people and defines who we are in relation to the world.”

This means other people will respond in a Dynamical fashion.

And hence the mess. The mismatch between the change response expected and the change response in the domain.

If you’re not sure what’s happening, you can engage a change artist to help.

The equations for the Lorenz attractor (the picture for dynamical change) came from https://en.wikipedia.org/wiki/Lorenz_attractor. The picture of the Lorenz Attractor is from Wikimedia commons – Lorenz_Ro28-200px.png

Team Powerhouse had problems. The developers didn’t know how much work they could get done in a sprint. The testers received the code about a day before the sprint demo. About half the stories got pushed to the next sprint. All in all, it seemed normal to me. They had just formed, and some chaos seemed reasonable.

Say What?

When organizations change, the old way of working doesn’t work any more. Work flows change. People get put in new groups. Agreement hasn’t formed on what we’re going to do, much less on how we’re going to do it.

Chaos reigns. In a picture it looks like:

How Does This Apply to Software Development?

You can put almost any two inter-related labels on the axes. Common ones I use in software development include “Requirements/Technology” and “What/How“. The closer to agreement you can get, the less chaos exists.

While Chaos may seem bad, it can provide energy and freedom to innovate if the organization has created safety around the change.

It is important for people to understand and not be surprised by this neutral zone, for several reasons. First, if you don’t understand and expect it, you’re more likely to try to rush through or even bypass the neutral zone-and to be discouraged when you find that doesn’t work.

Second, you may be frightened in this no-man’s-land and try to escape. … To abandon the situation, however, is to abort a transition, both personally and organizationally-and to jeopardize the change.

Third, if you escape prematurely from the neutral zone, you’ll not only compromise the change but also lose a great opportunity. … so here let me simply say that the gap between the old and the new is the time when innovation is most possible and when the organization can most easily be revitalized

The neutral zone is thus both a dangerous and an opportune place, and it is the very core of the transition process.1

So What to Do?

Understand your employees will experience some chaos during the neutral zone.

]]>http://www.donaldegray.com/constructive-chaos/feed/0Organizations Change – People Transitionhttp://www.donaldegray.com/organizations-change-people-transition/
http://www.donaldegray.com/organizations-change-people-transition/#commentsFri, 04 May 2012 13:14:32 +0000http://www.donaldegray.com/?p=346Googling “organizational change” returns almost 6 million hits. The LinkedIn Organizational Change Practitioners contains 26,125 members. With this much information and so many people practicing organizational change, you’d think we’d be good at it.

But that’s not what I usually experience in my work. Why does this gap exist?

A Handful of Change Models1

My recent posts have centered around the Satir Change Model. This describes how people respond to change. But how do we change organizations?

The Diffusion Model, which says change more or less happens. A common example of this would be communities of practice in an organization. People choose to meet and share ideas and how they accomplish their tasks. Attendees can choose or adopt new ideas and practices, or not.

The Hole-in-the-Floor Model, which says change is dropped on changes by planners upstairs. Process improvement committees and “You will now be Agile” mandates fall into this category.

The Newtonian Model, which introduces the concept of external motivation to change. Often this takes the form of upper managers creating a sense of urgency, walking around with gantt charts checking to make sure every thing’s reported on schedule, blaming resistors and beating up the laggards.

The Learning Curve Model, which considers the time to adapt to something new. On the job training and mentoring fall into this category.

Other models exist, but often they fall into one of the above categories.

A Little More About Organizations

According to the Merriam-Webster dictionary “an administrative and functional structure (as a business or a political party)” describes what I mean when I say “organization”.

This means we change an organization by re-arranging its structure. We add a new department (Quality Control), insert a new role (Director of Quality), reassign people, update the HR manuals, and re-draw the development process. Implement the new structure and we’re done! Sort of. If the change doesn’t seem to work fast enough, we can increase the pressure or put motivational posters on the wall.

But What About the People?

While organizations can change at the drop of a new org chart, people can’t. We miss the old familiar way, aren’t really sure what’s going on, and where this might all finish. In Managing Transitions, Making the Most of Change William Bridges identifies these three zones as the Ending, the Neutral Zone, and the New Beginning.

Ending – Letting go of the old ways and the old identity people had. This first phase of transition is an ending, and the time when you need to help people to deal with their losses.

Neutral Zone – Going to an in-between time when the old is gone, but the new isn’t fully operational. We call this time the “neutral zone”: it’s when critical psychological realignments and repatternings take place.

New Beginning – Coming out of transition and making a new beginning. This is when people develop the new identity, experience the new energy, and discover the new sense of purpose that make the change begin to work.

It looks like this:

Using our previous example of moving a cross functional development team into a team room:

Moving to the team room represents the change. Make the announcement and move. I’ve seen teams pick up their computers, manuals and move. I’ve worked where “facilities” moved the equipment and books over the weekend. Either move has a discrete start and end. The change announcement starts the transition process.

When team members hear they’re moving to a team room, they wonder: “What will it be like?”, “How will this affect my ability to concentrate?”, “If I play along, how long will it take before we move back into cubes?”

After the equipment arrives and they’re sitting in the team room, they start to adapt to their new surroundings. They may establish times when the team tries to stay quiet. Two or three may go to the whiteboard and have a conversation about a piece of code. They develop simple rules for handling interruptions.

Eventually the team room becomes the norm. Team members become comfortable with the change to the team room. I’ve seen those most opposed to moving become ardent supporters for the change.

Handy Reminders

Companies change.

People transition.

Not everyone in the organization completes the transition started by the change.

Those who do make the transition from ending to new beginning do so at different rates.

“You need all three phases, and in that order for a transition to work. The phases don’t happen separately; they often go on at the same time. … Perhaps it would be more accurate to think of them as three processes and to say that the transition cannot be completed until all three of taken place.”2

You can help people understand and transition quicker. Bring in a change artist like me who has domain experience and has helped other organizations and their employees through the change/transition process.

]]>http://www.donaldegray.com/organizations-change-people-transition/feed/0Responding to Changeshttp://www.donaldegray.com/responding-to-changes/
http://www.donaldegray.com/responding-to-changes/#commentsMon, 23 Apr 2012 17:21:55 +0000http://www.donaldegray.com/?p=339The team I worked with was scattered in a cube farm with 5 foot walls. Well, except for the two who chose to work in a large storage closet.

After the first sprint, we finally moved to a common area. Still in cubes, but with short walls so everyone could see everyone else. Well, except for the two guys in the closet.

It took some influencing, but eventually they moved too. Some people just don’t seem to be in a hurry to change.

The team sat around the room. They struggled to find a way to refactor an object that had become a catch-all for the application’s bits and pieces. Every time they got close to a solution, Peter would chime in with another possibility. Finally Joy snapped, “This is how we’re going to do it!” stopping all conversation.

Youíve probably noticed people behave differently. Differences become pronounced during change. People start to act out in ways that don’t make sense to us. But if we look at peoples’ temperaments, we might have an idea what’s happening for them. Based on the Jungian psychological types, David Keirsey’s four temperaments allow us to understand weaknesses and strengths during change.

CHANGE AND TEMPERAMENT1

The Visionary (NT) likes working with ideas. NT Visionaries are most interested in designing, rather than implementing, change. They like to provoke with ideas, even during Chaos when such provocation is inappropriate and may cause much pain and confusion.

The Catalyst (NF) likes working with people to help them grow, but is concerned that people should not suffer from change. They have a tendency not to let people experience their own pain, so they may short-circuit Integration by trying to be helpful. They are such team players that they may want everyone to do the same thing, even if their personalities are different. Also, they may want everyone to do something at the same time, even if people are at different stages of the change process.

The Organizer (SJ) likes order and system. The important thing to [them] is not just doing it, but doing it right. .. They are best at carrying the transformation into actual practice, long after the NT Visionaries have gotten bored. Although SJ Organizers tend to fear quick change, they may push for quick closure, like getting firm commitments during Chaos when it is inappropriate. They may also stifle all change by requiring that success be provable in advance.

The Troubleshooter (SP) likes getting the job done. [They] want quick fixes, not elaborate plans. They are the least likely to deny the foreign element, because they see it as an opportunity to swing into action. For SP Troubleshooters, change should be fast, so they don’t get stuck with something that’s boring. As a result, they are impatient with planning, and may provoke change for its own sake, piling one change on another, even during Chaos. Impatient with Integration and Practice, they may drop out if change seems too slow.

It’s important to notice that each temperament has both strengths and weaknesses during change. We can utilize different strengths to help achieve the desired New Status Quo. Knowing where the change currently resides on the Satir Change Model allows us to understand why team members act like they do.

These descriptions aren’t “one size fits all.” People have many facets so don’t expect all NTs to act the same way during change. At minimum these descriptions could be thought of as “tendencies”. Sometimes they’ll be dead on. While not truth, they can be useful.

Change can seem simple and straight forward when drawn and diagrammed with nice squares, straight lines, and check lists. But when we look at what actually happens, change is anything but straight forward. If youíre currently in a mess, contact me and letís clean up the mess together.

]]>http://www.donaldegray.com/responding-to-changes/feed/1Failure Paths During Changehttp://www.donaldegray.com/failure-paths-during-change/
http://www.donaldegray.com/failure-paths-during-change/#commentsThu, 19 Apr 2012 21:27:25 +0000http://www.donaldegray.com/?p=336In Understanding Change I described the Satir Change Model. Near the bottom I acknowledged that I described a “happy path” change. Many designed changes never change anything. Other change initiatives look promising for a while, but as time passes people revert to working “the way we’ve always worked around here.” In the “move to team room” scenario these would be the team never moving into the team room, and the team moving to the team room, but slowly reverting to staying in their cubes.

What happens in these situations? Actually, many paths exist between starting a change, and ending back in the old status quo. How many paths can you find in this figure that lead back to the old status quo?

Now you see what traps change initiatives and takes them off track, usually back to the old status quo. If your change initiative has started its path back to the old status quo, contact me and let’s work together on helping the change succeed.

]]>http://www.donaldegray.com/failure-paths-during-change/feed/0Understanding Changehttp://www.donaldegray.com/understanding-change/
http://www.donaldegray.com/understanding-change/#commentsTue, 17 Apr 2012 15:10:38 +0000http://www.donaldegray.com/?p=330At the end of Andrew Fuqua’s presentation on “How to Energize Your Team” at agile-atlanta the conversation turned to how change affects teams. I drew and explained the Satir Change Curve.

Late Status Quo – things humming along nicely. Everyone know what’s expected from them and how to do it. In a word – comfortable. Eventually along comes a

Foreign Element – this event shocks the system. It could be a manager forcing a team to move to a team room. It could be changing from gated to incremental and iterative development.

Chaos – means the systems now operates in ways we cannot predict. People no longer know exactly what’s expected, and if they have an idea, they don’t know how to do it. Team members may try many ideas to get a semblance of order.

Transforming Idea – the team discovers how the change benefits them. They discover osmotic communication. When they need quiet to focus, earbuds covered by noise canceling headsets! (I’ve seen it done)

Integration and Practice – the team experiments with their environment. Add mood lighting. Agree to periods of quiet time for focusing. Implementing whole team development.

New Status Quo – where the team has accepted the change to the team room and have become comfortable in it. They know what to do, and how to do it. Which eventually becomes the next Late Status Quo.

This represents the change “happy path”. The journey from Late to New Status Quo contains many hazards and opportunities to revert to the Late Status Quo.

Sometimes, it seems like people asking other people to change believe change happens like flipping a switch. When they see people holding on to what used to work, flailing, or trying out many new ideas they think somehting is wrong–either with the change or the people. But this process is normal, natural, inevitable.

If your organization is going through a change and you need help, give me a call or send an email.

]]>http://www.donaldegray.com/understanding-change/feed/0No Group Is a Team on Day Onehttp://www.donaldegray.com/no-group-is-a-team-on-day-one/
http://www.donaldegray.com/no-group-is-a-team-on-day-one/#commentsWed, 30 Nov 2011 14:35:47 +0000http://www.donaldegray.com/?p=310The agile training class for a newly formed team was almost complete. We’d covered values, practices, roles, the product backlog, done simulations teaching the Scrum process and I could see the end of training. A little team building activity, and we could start tomorrow with building the backlog, story sizing, then start the first sprint. Forging ahead, the team selected a name, came up with a list of team norms, and they became a team with me as their ScrumMaster.

Over the next few weeks, I noticed cracks appearing. One member tried to find ways to avoid the daily standup. Another member only checked in code toward the end of the sprint. Yet another happily worked on what he was assigned, but never volunteered to take tasks from the task board. At times, the entire team struggled to understand how its activities blended with and supported the activities of the other teams on the project.

There didn’t seem to be a unifying focus, something with which all the team members could identify. What could I have done differently?

Forming a Team

Over the years, I’ve seen teams formed many different ways. There’s the Five You process where the manager goes “You, you, you, you, and you. You’re now a team!” Often, these team members were selected because they were between projects, they possessed approximately the right skills, and it was time to get a new project started.

Matrixed teams form somewhat differently. Team members get assigned by skill level to projects. The greater (or rarer) your skill, the more teams you get assigned to on a part-time basis. This way, everyone has 100 percent of his time assigned to project work. I once met a QA “resource” (which in itself says a lot about the company) assigned to three Scrum teams. For some reason, he didn’t seem to get much done but go to meetings. Matrixed team assignments guarantees all projects get delivered in the maximum amount of time possible, if at all.

In the case of the team I worked with, the developers became a team because they all worked in the same office. I believe in collocation, but being together, in itself, doesn’t provide impetus to become a team. So what might?

What Makes a Team?

In The Wisdom of Teams1 we find the conditions needed to exist for teams to form:

A compelling work goal

Interdependent work

Stable membership

Shared history

Five to nine members

Interestingly, a compelling work goal often gets overlooked. The team had work to do, but I don’t believe “We’re part of an project that will save the company a bunch of money” constitutes a compelling work goal. Don’t get me wrong, helping the company save money is a good thing, but does it call forth the urge to slay dragons or at remove impediments from the development process?

We did have interdependent work, both within the team and between the teams. Other than some members not checking code in regularly, a lot of thought and effort went into making sure the teams’ code didn’t break other parts of the application. The code management system and continuous integration worked quite well when developers did check in their code.

This team had sort of worked together prior to my arrival. The team members knew each other but divided the work so they had the minimum amount of interaction. So, while they had stable team membership, how they handled work created knowledge silos and prevented them from learning from each other.

Shared history initially seems to indicate the team has to work together for some time. I’ve learned since my work with this team to use experiential activities to actively start creating shared history instead of letting the shared history happen and hope for the best.

Teams generally need five members. This allows for sufficient skill, experience, and knowledge to generate good decisions and actions. When teams get more than nine members, the communications paths tend to become centralized and the larger group informally splits into two smaller groups, losing a coherent whole.

Creating a Team

Creating a team involves more than picking five to nine people then having them pick a name (although choosing a name for the team can be both fun and enlightening). Managers usually set the initial team membership and pick the project on which the team will work. This means managers need to align the team members’ skills so they can fulfill the project’s vision. If the project doesn’t have a vision statement how can the team coalesce around a compelling work goal? It doesn’t exist.

Team formation activities can range from creating a formal team charter to the Five You process. It may make sense for some teams to go through the formal process of documenting the purpose; summarizing their structure, customers, and stakeholders; listing the members; identifying roles; and defining the team’s authority—but I don’t usually see this in agile software development teams.

With the team members selected we can do specific activities to help create team identity, highlight the team’s purpose and establish ground rules.

Team Identity Activity—Design a Box

This activity lets the team define itself and create an identity to share with the rest of the organization.

Team members need to design a shrink-wrap box that represents their team. They design the box front and back. This involves:

Coming up with a team name

A picture

Three to four key bullet points on the front to “sell” the team

A detailed feature description on the back

Operating parameters

It also tends to be a lot of fun.

Team Purpose Activity—Team Elevator Statement

This activity focuses on the “compelling work.”It aligns the team’s actions with the product vision and corporate mission statement. It’s the team’s reason d’être.

Using the “elevator speech” format helps the team succinctly pull these ideas into a sentence they can share with others.

Working agreements specify the team’s operating parameters. They list expectations between the team members. They serve as guide rails as the team builds its shared history. They might include meeting information, team norms, a definition of done, and other pertinent items.

When working with the team to create its working agreements, I use the expand-then-collapse facilitation process. After explaining the goal for the working agreements, I solicit suggestions from the team members about what they feel will be important to them. I use stickies for this. Then we post the stickies, having a conversation about what the words mean. After we have everyone’s input, we look for duplicates, suggestions that form part of another suggestion. We aim for seven to nine agreements. Anything more results in a list no one can remember.

I’d be lying if I told you these activities automatically create great teams. Nothing can automatically create great teams. But, by focusing on your team’s purpose, identity, and working agreements you can help team members answer the question “Why am I here?” and set the team up for success.