Tag Archives: change

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.

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.

I recently did an interview with the nice folks at Softhouse.se for their Lean Magazine. The interview was a lot of fun, and made me think (which is fun).

The full interview will be in their special anniversary edition, schedule to be out by Christmas. (Information on obtaining the magazine here.) In the meanwhile, some thoughts on the role of managers….

LM: We notice a lot of confusion when we meet managers.

They see a new behavior in their development teams that have started to work according to lean/agile principles and usually the development teams are happy with the change.

But as a manager the questions comes up ñ what should I do now? how can I support this? how do I avoid to destroy the good things?

What is your message to these confused managers? What can they do?

E: Don’t tamper if things are working. Ask what is getting in the way, and go fix it. Ask what the team needs, and obtain it for them. Ask what you can do to help. If the team says “nothing,” don’t inflict help.

The truth is, when teams are working well, managers don’t need intervene. The hard work is in establishing a real team and ensuring enabling conditions are in place. When managers of self-sufficient teams feel like they aren’t doing much, it’s a sign they’ve succeeded. But managers shouldn’t abandon the team. Teams need support and a connection to the organization.

Managers still have an important job to do, working at the system level. Collect metrics that will give a window into the system. Start by tracking the ratio of fixing work to feature work. Then, find out what is driving the fixing work, and start working to improve those issues.

LM: Are there individual managers that will not fit into this /new/ management?

E: People who cannot manage themselves should not manage others. People who can only work through telling, selling, and yelling won’t be successful in companies that embrace lean and agile philosophies.

Some companies find they don’t need as many managers. Some people who are in management roles find they are happy to go back to technical work. But, to me the new roles for managers are exciting and full of promise–developing people, seeing and steering the system, creating environments where people can build products and services that delight customers, satisfy stakeholders, and empower employees.

LM: Can everybody change their behavior or do we need to move some people? To where?

E: Not everyone is capable, and not every one will want to. Some of those people will leave of their own accord. If there is a place in the organization where people who can’t or don’t want to change can still be of service within the organization, support them to find it, and then let them be.

We can never be 100% successful when we expect everyone to change. Don’t spend your precious energy trying to change people who don’t want to. Work with the people who want to change, and most often, when a critical mass has moved to a new way of working, most will come along.

If there are some people who are acting in a way that is destructive to people or the organization, help them find the door. (This advice applies whether you are using lean, agile or any other method known to man.)

Metrics like these won’t tell you what you need to know. More likely, they will lead you astray. How? Let me tell you a story.

Years ago, I worked for a company that was “installing” a Big Methodology from a Big Company. (The fact that they thought they were “installing” a methodology was probably the first warning sign.)

Every one in the department attended Big Methodology training. (This practice is sometimes called “Sheep Dip” training).

The VP mandated that all projects would use the Big Methodology.

The Installation Team audited to ensure that project managers and teams were complying and producing the required “work products” in accordance with the Required Work Products grid in the back of the very large Big Methodology binder.

Of course, there was some grumbling (from the people the Installation Team referred to as “Change Resisters.”) Eventually, people did comply. Every one went to training. Projects managers filled out the required templates, and checked the appropriate boxes. The metrics looked grand!

The VP declared, “Big Methodology is now business as usual!”

At the time, I scoffed at that statement. It was clear to me that people were not using Big Methodology, and that the promised benefits were nowhere in sight. The only things that had really changed were some check boxes and some names (documents became “work products” or “job aids,”).

But, now, I realize that the VP’s statement was TRUE!

We had Big Methodology, and things went on as they had–business as usual! Well, maybe a little worse because people were spending time producing the many documents specified on the Required Work Products grid.

The metrics the VP tracked were easy to count. But they only revealed surface compliance. They didn’t say anything about whether the organization was achieving the improvements promised by Big Methodology and hoped for by the VP.

So when you think about assessing how far along you are in your agile transformation, consider what you are trying to achieve.

I often suggest that managers track three metrics to understand how well their organization is functioning, and whether they are trending in the right direction.

The ratio of fixing work to feature work. How much time are people spending developing valuable new features vs. fixing stuff that wasn’t done right the first time? If you can figure out the sources of fixing work and make some progress there, you have a boost to productivity. Agile methods can address some of the sources of fixing work…but not all of them.

Cycle time. How long does it take to go from an idea to a valuable product in the hands of a customer? Again agile methods can help with delivery. But if it’s the upstream process–planning for products and releases–is broken, you may not see improvement until you address those issues, as well as the development process.

Number of defects escaping to production. This is a category of fixing-work that is a direct indicator that the quality of the development process is improving.

For each of these metrics, it is the trend that is important, not an absolute number. The trend will tell you if your attempts at improvement are having an effect. Remember, most changes take time to take hold. If the trend doesn’t move in a month, it may not mean you have taken the wrong action and need to change direction. If the trend isn’t moving over time, then, examine what is happening in the development area. But also look at other aspects of the system. There are few one-to-one cause and effect relationships in complex systems and the trend you see may or may not be directly related to your change. One company I worked with was alarmed to see that defects released to production went up after they started using agile methods. It turned out that prior to the effort to measure defects released to production, no one paid much attention unless the defect brought down a customer site. The increase in the defects trend was related to reporting, not a failure to improve quality.

I find that the three metrics above are generally useful for understanding how a software development organization is functioning as a system. But your reasons for adopting agile methods may be different. Consider the goals you are trying to achieve. What signals would tell you that you are moving in the right direction? How might you measure those? When you think about measures, be wary of target numbers. Measuring against targets almost always causes distortion. That means that people will behave so as to reach the target, perhaps in ways that are counter to the actual goal behind the target. Distortion will keep you from seeing the real picture, and may also cause real harm to your organization.

Useful metrics give you a window into how the system is functioning, and whether your change is having an effect. The numbers themselves are neither good nor bad. They are information that signals you to go and find out, investigate and reason about the system.

Not so very long ago, I made my living writing code. My colleagues and I did our best to understand what our customers needed, and to write code that was easy for other programmers to understand, solid, defect free. When our managers asked us how long it would take to create a new feature or modify and existing program, we studied the problem, considered how much code we’d need to write or change, how we’d integrate the new functions with existing functions, and what sort of testing would allow us to feel confident our work was complete and correct.

Our managers were often not satisfied with our estimates. They wished we could deliver working software more quickly. They suggested we were exaggerating how complicated the work was. They hinted we were padding our estimates, and spoke sternly of work expanding to fill the available time. Then they revised the estimates to fit their desires and handed down a due date.

Strangely enough, the work usually took longer than the managers wished it would. Our managers contemplated the gap between wished-for and actual delivery and pronounced us not sufficiently productive.

And so the quest to improve our productivity began. First it was CASE tools. They were supposed to improve productivity by an order of magnitude (they did not). Then came Rapid Application Development (apparently the managers stopped reading after “Rapid”). The next improvement, Object Oriented programming, was supposed to save the day (it did change the way we think about programming). When I left that company, the productivity pill was a development methodology that took up an entire 4-foot bookshelf.

And the quest to improve productivity in software organizations marches on. More and more often, the quest includes some flavor of Agile Methods, and a promise of hyper-productivity, quick delivery, and change for free.

Agile methods can help achieve business results, get software out the door faster, adjust to new priorities, and dramatically reduce the number of errors that reach the customer.

Agile encourages close collaboration with a product owner or customer (whether that’s an internal customer proxy, product owner or an end-user of the software). This helps teams understand the customer and his context, so they can make better decisions about feature design. Short iterations and frequent demonstrations of working features keeps development close to customer needs and wants.

Agile methods encourage planning based on demonstrated capacity, using agile methods can help prevent cost overruns and help managers make decisions to continue funding feature development–or not. Iteration planning and tracking story points helps teams and management understand capacity. Without this information, plans are merely wishes. Armed with such information, managers have the opportunity to review progress and viability at the end of every iteration.

Working in short iterations to produce working software can allow a company to realize revenue early; when teams finish small chunks of features each iteration, it’s no longer necessary to wait until all the features are completed to test and deploy. Every feature slice is tested and ready for customer acceptance at the end of the iteration. When the slices add up to a marketable set, managers can choose to release.

Agile engineering practices such as automated unit and customer tests, pair programming, and frequent integration find errors early which reduces the number of defects released to the customer. That results in lower support costs, find and fix costs and bad press generated by buggy products. Practices such as simple design, Test Driven Development and refactoring keep the design flexible and clean, avoiding design degradation and escalating costs for future changes.

Many teams who use agile methods are building strong cross-functional teams and report that their satisfaction with work-life and work/life balance is higher. Working at a sustainable pace and re-establishing pride in work bring intrinsic motivation. That makes it easier to attract and retain employees.

But when agile methods—extreme programming, scrum, kanban or some combination there of—are imposed as a way to “fix” perceived programmer productivity problems, the effort almost always fails. Sheep-dip training programs, “going agile” by decree and cherry-picking the agile practices that don’t seem difficult won’t achieve great results.

No method, or set of methods can improve results unless managers also change the way they do their work.

Managers need to get organizational systems working. Managers must do the hard work of understanding the market, their customers, and make difficult choices about what work to do and what work not to do. Managers need to study how teams and organizations really function and then create systems and environments that don’t hinder people from doing work.

Writing software is hard. Agile methods can help. But they are not a silver bullet. And no method can improve productivity unless management also changes.

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.

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.

A good idea is a valuable asset, and a lot of good ideas are a treasure trove. But what do you do with those ideas? Here’s a little story about an idea maker who isn’t very good at getting his ideas accepted…and 4 tips to keep your own ideas from withering on the vine.

***

Ron was full of ideas. Good ones, too—or at least he thought so. He had ideas about how team members should organize their work, how to report status, how to speed up the build, and a way to save money on white board markers, to name a few.

But, Ron’s teammates hadn’t picked up on his wonderful ideas. In fact, to Ron’s eyes, they had rejected them out of hand. So, he persisted, arguing why his ideas were a better way.

Eventually, another developer agreed to try Ron’s idea for speeding up the build and asked Ron to work on it with him. Ron refused. “I don’t want to get saddled with the extra work,” he huffed. “That’s like punishing me for having good ideas.” The other developer quickly lost interest.

Many ideas wither, not because they are bad ideas, but because of clumsy presentation. Few people are as inept as Ron; but most nascent ideas stand a better chance if you remember these four things:

1. It’s not about you.

Most of the time, people pursue a new idea because they can see how it will help them. Don’t just tell them why you think your idea is a good one. See the world from their point of view, and frame the idea in terms of what matters to them. If your manager cares only about cost, then talking about quality, speed, reuse, or elegance won’t convince him to try your idea. Connect your idea with what’s important to the people you are hoping to influence.

2. It is about who you know.

Bringing your ideas to fruition is a social process. You will need the aid and interest of others to make your idea reality.

Take stock of your network. Who can help you move the idea forward? Who has influence with people who might champion the idea? What do the people who hold formal and informal power care about? Can your idea help them advance their goals?

3. Action creates attraction.

Rather than pushing your ideas on people, try pulling them in—work by attraction. If you think a team task board would help everyone do better, show them; don’t just tell them. Demonstrate the benefits by creating your own task board and making your progress visible. The time to tell is when someone shows curiosity, not before.

There’s another benefit of showing: You might learn something useful about the how the organization will respond to your idea. Suppose you make your own kanban board and start limiting your own work in process. If your manager increases his scrutiny of your work or berates you for not working hard enough, you’ve obtained valuable information—information that will help you move your idea forward (or choose not to move it forward and look for a new manager, instead).

4. Timing is everything.

Your idea might be good but not viable in this organization at this particular time. An experiment—such as the personal kanban board—can reveal what else needs to change for your idea to succeed.

Sometimes people and groups aren’t ready for an idea. They may not have the prerequisite knowledge to appreciate it, or they may be working from a different mental model in which there’s no place for your idea to fit. In this case, you need to prepare the ground with conversations (sometimes many) before planting the seed of your idea.

When you are brand new to a group, you may see many opportunities for improvement. But, ideas from an outsider can feel like implied criticism. After all, how could an outsider understand the tribulations the team is facing? Show you understand by offering an idea to solve something the group views as a problem, not something you see as a problem. Once the team sees that you can solve their problems, they’ll be more likely to listen to your other ideas.

Sometimes a great idea comes a few seconds too late. When a team has too many ideas, they may feel overwhelmed. Or, as team members chase each shiny, new idea, those ideas may not stick. When the team is close to a decision and a new idea enters the mix, the team goes back into analysis, examining the new idea.

You may have an even better idea, but sometimes it’s best to hold that for the next round and get on with implementing “good enough.”

Ron continued to generate ideas—ideas that usually involved more work for other people, and no ownership on his part. His teammates continued to ignore his ideas until one day someone told him to just shut up. So, if you want to stay out of the Ron trap, remember these four points—it’s not about you, it is about who you know, action creates attraction, timing is everything. I can’t guarantee that all your excellent ideas will come to fruition, but many will. And you’ll been seen as someone who knows how to make things happen.

This article first appeared on stickyminds.com.

When companies decide they want the benefit of the team effect, or adopt agile methods, they (sometimes) realize that they need to update their management style as well. And too often, they enter an 4-step dance of oscillation.

Managers feel overburdened and overwhelmed. Teams are disengaged. They want teams to take more responsibility, and show more engagement. The managers stop telling teams what to do, and wait for teams to step up, take responsibility, and morale to flip into the positive zone. So the managers step back, and the 4-step starts, and usually ends up back where it started–overburdened managers, disengaged teams, and an uptick in cynicism.

If you are in this pattern, you are not alone. It comes from trying to solve a problem, when what you have is a polarity. There are upsides and downsides and you have to attend to both.

You don’t have to get stuck in the 4-step oscillation. If your organization wants to move from command and control management to something more like servant leadership, here’s some help for the journey.

Here are things a managers can do to move, and manage the upside and downside of becoming servant leader to a team.

Most of the time, when I hear about “agile change,” someone in management has decided that Scrum (and maybe XP engineering practices) will improve quality and time to market for the company’s software products.

I’ve heard some success stories. And I’ve heard about many failures.

Why do these efforts fail?

Some people blame the failures on mis-understanding Scrum, or not applying it with sufficient rigor. Both of these may be true. But I see a different thread running through these failures. Often the failed change initiatives nibble at the edges, without changing the way work flows through the organization. And that’s a management problem.

What if the change–not just the directive to change–started at (or near) the top?

Here’s are six management practices that will improve the way work flows through the organization.

1. Get Middle Managers Working Together

Many organizations make it difficult for middle managers to work together by structuring goals that foster local optimization and competition. For example, a development manager might be rewarded for meeting a date, while test managers are rewarded for releasing a product with few bugs. It’s easy for the development manager to meet his goal if he doesn’t care about the test manager’s goal.

Other companies are organized so that managers for different products must vie for scarce development resources to meet their goals. The winner isn’t always the organization or its customers.

If you current organizational goals foster conflict or competition, fix them. They take the focus off the real goal, delivering valuable products to your customers. Optimize for the organization’s success, rather than focusing managers on goals that detract from the end result.

2. Decide What to Do and What Not to Do (At Least Not Now)

Ray Cummings said, “Time is what keeps everything from happening at once.” The laws of physics say it can’t happen all at once. So why do we keep trying to do everything at once in our companies? I’ve spoken with several development managers who have a personal policy of never saying no to a request from the business. That keeps the conversation happy for a while—until it becomes clear that it’s not possible for the development team to do everything.

One of the biggest problems in companies is trying to do too much at once. That drives multi-tasking, context switching, and wasted mental cycles. It slows down delivering value to customers and realizing revenue.

But if you want to focus, you need to …

3. Manage Your Product Portfolio

You probably know which products are valuable to your customers and the company. But do you know why? Go and find out. (For some ideas on learning how your customers view your products, see Know Thy Customer.)

Make a retirement plan for products that are waning in value to the customer or the company. Those products will suck up both intellectual and monetary resources.

For the products you will produce, determine which features need to be delivered and in what order. A Kano analysis can shed light on which features have to be there to make the sale, which enhance attractiveness, and which are clear differentiators.

4. Realize the Benefit of the Team Effect

Establish stable cross-functional teams to work on software products. Groups of people who are assigned to one project but report to different functional managers are less likely to jell as a team. When those same people are assigned to more than one project they are extremely unlikely to become a high performing team. Groups of people who have a clear membership and a clear charter jell into teams.

It takes time to build the communication, trust, and commitment that foster high performance. Many organizations rearrange teams every few months to meet the needs of current projects. That obviates the benefit of the team effect. Rather than bring the team to the project, bring the project to the team. A given team may need to add a new member for a particular skill–which is more effective than breaking down, re-staffing, and restarting whole teams.

5. Embrace Adaptive Planning

Don’t use deterministic planning for projects that aren’t deterministic. For most software projects, detailed plans only give the illusion of predictability. Further, they encourage managers to shift the blame for missed dates to the team.

Instead, use adaptive planning. Chart a course, knowing that the competitive landscape and internal factors (e.g., the capability of the team, viability of technologies) may drive the need to adapt and re-plan.

Find a way to measure progress that’s meaningful and reliable enough to let you extrapolate into the future. You won’t find perfect measures of progress or capacity–and if you could they’d probably be too expensive to implement. You need something good enough to make decisions about planning and promises. Gaging team capacity using story points, along with establishing a common definition of done are reasonable starting points.

Adaptive planning works better in the real world of software projects. But it does put responsibility for tough decisions squarely with management.

6. Continue to Improve

Once you have stable teams focused and working on the most valuable products, congratulate yourselves—you are ahead of many companies. But don’t stop. Create a culture of problem-solving leadership though out the company.

Examine policies, procedures, and structures that may have worked at one time, but don’t support the emerging pattern. Some of the first places to look are training policies, hiring practices, differential pay and rating practices, formal approvals, budgeting, and audit policies. Make sure your policies and procedures are working for you and not against you.

***

Some people say Agile could never work–it’s just the latest silver bullet. Agile may be reduced to silver bullet status, if managers expect to solve significant organizational problems by working only at the engineering team level.

But if mangers address the way work flows through the organization, it will make a real difference when development teams start to use Agile Methods. No software development method can solve problems of throughput, quality, or product fit unless management also changes.