Systems Thinking aggregator

Esther Derby: Five Reasons to Hire a Coach for Agile Teams

Esther Derby (noreply@blogger.com) — Tue, 30 Jun 2009 07:32:15 +0000

I run into managers who think that they can coach the team as the team adopts Agile methods. In my experience, this usually doesn't work out very well.

So managers, support the team as they learn Agile methods by hiring a coach! It's a investment in success.

Here are five reasons that coach cannot be you.

1. The team needs someone skilled in XP engineering practices and current on the latest testing tools. If you haven't written code in more than three years, or you've never worked on a team that used all the XP practices you don't have the knowledge to coach the team. Sorry. Doesn't make you a bad person or cancel out your value to the organization. Does mean you are not the right person to coach on XP.

2. You may have a conflict of interest. If you are being measured on delivery dates, its possible that you'll ask the team to cut corners, work extra hours, or drop practices to meet a date. That would be bad. The team needs someone who will hold the process in place and help them hold firm when someone is worried about making a date. That can't be you, if you're the one worried about making the date.

Even if you'd never do that, on some level, the team may not believe that yet, especially if you've ever done so in the past. And if they think you'll cave in the face of a date, they'll cave before you even ask them to. It just works that way.

3. A coach will help the team stick to the process, and guide them away from making adjustments that nibble away at iterative incremental development until they are back in a mini-waterfall.

Agile really does involve a shift in the mental model of software development, and until you have an intuitive grasp of the principles and values, the nibbles will make sense to you, too. You've got to live it for a while before you can coach it.

4. As long as you are there to solve problems and tell people what to do, it will be easy for the team to remain dependent on you. It may feel good to be needed, but in the long run, it doesn't help the team, doesn't help the company, and doesn't help you.

5. You've got a ton of other stuff to do supporting the team, removing obstacles, running organizational interference, and working on the work system. Plus you have to do the budget.

Of course, you don't have to be dependent on outside coaches forever. Once you've established a few Agile teams, you can develop a cadre of coaches made up of your own experienced people.

Esther Derby: Pfeffer's Six Dangerous Myths About Pay

Esther Derby (noreply@blogger.com) — Mon, 29 Jun 2009 17:49:28 +0000

A few days ago, I had a little twitter conversation with Dave Rooney, Ben Simo, and Elisabeth Hendrickson about rate vs. cost.

Which reminded me of Jeffrey Pfeffer's excellent article, Six Dangerous Myths About Pay (originally in HBR May/June 1998).

This article should be required reading for all managers.

The Myths are:

Myth #1: labor rates are the same as labor costs.

Myth #2: cutting labor rates will lower labor costs.

Myth #3: labor costs represent a large portion of a company's total costs.

Myth #4: keeping labor costs low creates a potent and sustainable competitive edge.

Myth #5: individual incentive pay improves performance.

Myth #6: people work primarily for the money.

Ain't none of 'em so.

When managers confuse labor rate with labor cost, they make decisions that usually end up costing lots of money.

Labor is an easy to count cost. It's much harder to count the costs of multi-tasking, poor decision-making, ineffective and demotivating work systems, communication latency and other wastes. But the later factors have a big effect on productivity, and therefore, labor cost.

Nynke Etk Fokma: thunderbird

Nynke Etk Fokma — Fri, 26 Jun 2009 12:35:16 +0000

The launch of a revamped website: http://www.satirworkshops.com, where we can park Spooo key! stuff. Exciting! I love it! Let’s play and fool around! Tagged: heyoka, launch, satir workshops site, thunderbird

Willem van den Ende: Photo Suggest – photos to go with your blog entry or slide

Willem — Thu, 25 Jun 2009 12:59:23 +0000

We proudly announce Photo Suggest, a web application that helps you find photos with liberal licenses to go with your blog entry or slide Check it out.

Dancing Peacock by Hamed Saber

Here’s why:

As a writer, I want photos to go with my blog entry, so that it looks appealing for readers and inspires me to write more.

Brickpit Ring Walk Bicentenial Park by Louise Docker

As a presenter, I want photos to go with my slide, so the slides have metaphors that make people think, and my presentations look well prepared.

For these two stories we might not have bothered writing a web application – we could use the regular flickr search. However:

As a writer or presenter, I want to easily credit the photographer so that I can fulfill the obligations that go with the license and give viewers the opportunity to see more of their work.

I used to have Super Human Powers by Esparta Palma

We found that finding photos to go with a presentation was easy enough, but collecting the credits and then adding an attribution to the photo in a blog entry or the end of a presentation) often turned out to be a lot of clicks, which meant that we would not add photos to presentations as often as we like…

How does it work?

Photo Suggest queries Flickr and searches for photos with a liberal license (see the about page for a short list) sorted by interestingness. If you click on the link below an image, it takes you to the details page that shows the full credits, license and description together with the image. The reason we called it ’suggest’ is that when you type a keyword, the results are often not what you’d expect, but can more often than not make an interesting contribution to your text.

How did we get here?

With QWAN we try to apply lean and agile principles to everything we do, so we reflect at our ways of working continuously, identify things that add value, and do more of them, as well as things that are wasteful and eliminate them. We started to give more and more presentations to get the word out – we love experiential sessions over anything else, but they do not get us into more traditional conferences. Styles like Presentation Zen led us to do more with images.

Presentations with attractive imagery inspire me more when I do a presentation and they seem to energize the audience as well, so it becomes easier to add experiential elements (small exercises, questions) to a presentation.

Marc Evers and I have been thinking about how to improve our presentations as well as the way we produce them for a while. This led to a bunch of wild ideas, which we used as stories for the new new new! product development game – participants have to plan a ‘presentation 3.0′ project.

With Lasse Koskela I ran a Scrapheap Challenge at XP2009 – participants have to write a working application in half an hour. For that we needed exercises. Some stories from the game seemed well suited, so I did a small experiment – in half an hour I got quite far. Then I called Marc and asked him if he wanted to help me finish it into a working application. We had noticed we were losing some of our “superhuman powers” , so Marc suggested to “start from production”, which meant I talked him through the app while we brought it into version control and production, before adding more features & polish.

From experiment to production took half a day. After a day it was usable enough (but was missing the finish such as about page and stylesheet) for us for blog entries and presentations. When we demoed it during xp2009 a few participants jotted down the url, which encouraged us to polish and publish it.

What Can We Do With Flickr? by Alan Levine

We hope you enjoy it! Your feedback is welcome.

Pascal Van Cauwenberghe: XP Days Benelux 2009 - Call for Sessions

Pascal — Tue, 23 Jun 2009 15:06:38 +0000

November 23, 2009

November 24, 2009

XP Days Benelux 2009

The next XP Days Benelux will take place on 23 and 24 November, in Mechelen, Belgium. As usual, this is a great opportunity for everybody’s who’s interested in Agile methods to share information and learn from each other.

Submit a proposal

Presenting a session is a great way to learn. Why don’t you submit a session proposal for XP Days Benelux?

Do you work in interesting circumstances? If not, what are you doing there?
Did you learn some new useful tool, technology or method? If not, you should definitely come to XP Days!
Did you experience some failures? If not, are you taking enough risks? Are you still learning?
Did you work together with some new and interesting people? If not, you should definitely come to XP Days because that’s filled with interesting people.

Even if you’ve never created and presented a session before, submit a proposal for XP Days. We practice the agile values, so there’s plenty of collaboration, communication and feedback to help you refine your session. It just requires a bit of courage. Or you could ask for a session on a certain subject. That might give someone the idea to create a session for you.

What are you waiting for?

I just submitted a proposal about solving conflicts without compromise together with Jef Cumps.

Did I mention that up to two presenters per session get a free pass to both days of the conference?

See you at the conference!

Nynke Etk Fokma: spooky

Nynke Etk Fokma — Tue, 23 Jun 2009 11:06:51 +0000

Maturity In 1997, participating in Jerry’s Problem Solving Leadership workshop, I knew I found the “missing element”, perhaps even the “missing link” in the professional environments I had played a role in. I already knew, my body knew, and the workshop gave me the words, and some tools to keep myself safe, and focused enough on [...]

Esther Derby: When to stand back, when to step in

Esther Derby (noreply@blogger.com) — Mon, 22 Jun 2009 23:46:12 +0000

Part of my definition of a successful team is that the members of the team increase their knowledge and capacity as a result of their work on the team. That means that giving the team the opportunity to learn is part of the job.

One of challenges I see when managers first start working with agile teams is knowing when to step back, and when to step in. Swinging too far in either direction hampers team learning.

Helicopter Managers step in too soon. They swoop in at the first whiff of a problem to "rescue" the team. They deprive the team of the chance to think, solve problems, and decide together. These managers may believe they are doing the team a favor; what they really do is hamper the team's development.

Absentee Managers throw up their hands and say "you figure it out," no matter what the issue, or whether the team has the skill and authority to solve the problem. These mangers let the team flail and churn, wasting time and building frustration. People do learn from mistakes; but when people feel frustrated, hopeless or abandoned by their manager, increased capability is not the likely learning outcome.

Self-organizing teams still need managers. But those manager need to know when to step in, and when to stand back.

Here are three guidelines to help managers gauge their actions with self-organizing teams.

#1. If the team has the skills to solve the problem--or they are on the verge of having the skills--give them space to solve the problem. If they're stuck or don't see how to use the skills they have, ask questions to help them get unstuck. They will learn much more from wrestling with the problem than having the manager fix it. (Assuming it's not a management problem. Then it's managements job to fix it.)

#2. When time is not of the essence give the team time to work the issue. If it takes a day or two to solve the problem, will it bring the company to it's knees? (If the answer is yes, you've got bigger problems than working with a self-organizing teams.) Keep in mind that many companies live in permanent fire-fighting mode and believe that everything is urgent. Or the manager believe that people won't actually apply sufficient effort unless they believe the issue is urgent. Again, that's a bigger problem. OTOH, if there's information that will help the team solve the problem give the information. Withholding the information is just plain wrong. Likewise, if there's a very simple solution that the team is overlooking, ask questions to help them discover it.

#3. If the solution space is limited in scope and impact, or the decision is reversible, give the team space to solve the problem, even it there's a good chance they'll get it wrong the first time. If the solution space isn't bounded, then there's something amiss with the way the problem or decision authority has been delegated. Bound the issue so that the team is involved and there's appropriate fiscal and management oversight.

There's always a trade off between expediency and a learning opportunity. Self-organizing teams can outperform manager-let teams....but only if the managers are willing to navigate the balance.

Shifting from a manager-led team to a self-organizing team is a little tricky. It calls on a different set of skills, and brings up questions about value and identify for many managers.

But there's still plenty of work for managers to do. It just doesn't involve task management and having all the answers.

Rachel Davies: Getting Agile Teams Talking About Risks

Rachel Davies — Sun, 21 Jun 2009 20:27:37 +0000

Following up on Antony Marcano's post about Risk Management strategies. I've noticed that many teams abandon Risk Management when they adopt Agile. Instead, they rely on agile practices alone to help them reduce the impact of risks. In my view, this is not enough. Many Agile plans are too optimistic and contain no contingency. New requirements are sure to come up and the team is bound to have overlooked some of the technical challenges. Packing a plan tightly at the start without any slack leads to disappointment all round for customers and developers. Finding out about issues as they come...

Johanna Rothman: Learning or Working?

johanna — Sun, 21 Jun 2009 20:04:55 +0000

I’ve been teaching workshops for much of the past few weeks, and I’ve noticed an interesting pattern. I get great comments (and usually good numbers) from people who participate in the workshop. I don’t get many comments, and I get substantially lower numerical grades from people who leave their laptops open during the workshop.

These people are convinced they must pay attention to their work issues while they are in the workshop. And, they are the same people who want the “cheat sheet” or the “10-second overview of user stories” (true!). They are the ones who don’t participate in the debriefs for the experiential activities. They are the people who don’t see the value of instructor-facilitated and experiential training.

I’ve started a new introduction to my workshops. I say something like this: “I know that you are an adult. I trust you to make the right decision about your laptop open or closed. I will warn you that it is impossible to fully participate in this workshop with your laptop open.” (I smile as I say this.) “You have the choice to leave your laptop open or participate in the workshop. If you choose to leave your laptop open, please don’t prevent the other people at your table from working through the activities.” I stop then and start with the workshop.

I have mixed results. The people who believe me at the beginning learn a lot in my workshops. The people who realize I was serious later on in the workshop and finally put away their laptops learn too, and it depends on when they put away their laptops. I can’t tell about the people who don’t put away their laptops. From the way they debrief the workshop, I don’t think they learn much.

I sort-of understand why conference-workshops are like this. Few people expect experiential activities at a conference workshop. (Ha! Gotcha!) Many of them have never encountered interactive and experiential training before. And, too many of them are expected (so they say) to check in at work while they are at the conference.

I don’t understand why a company brings me in and expects their employees to be on their laptops all the time while they are supposed to be at training. People really cannot do two things at once and do each of them well. They can do one thing well and the other not at all. They can do both things poorly. But they can’t learn and work at the same time.

I do ask people in in-house workshops how often they need to check email and check in back with their teams. I try to have enough breaks and a long-enough lunch to take that into account. But it’s quite difficult if the answer is “I have to be on email all the time.” I can’t teach and accommodate that request.

If you are attending a workshop, please participate. If you are working, go ahead! But, please, don’t try to do both at one time. It just doesn’t work.

Remember, the AYE conference is all experiential and interactive sessions. We would love to have you. And, we give you long-enough breaks between sessions so you can email or phone back to work. You’ll learn to work better. Isn’t that the whole point of workshops?

Tweet This Post

Pascal Van Cauwenberghe: Heijunka - Humane work

Pascal — Sat, 20 Jun 2009 17:32:28 +0000

Operational Excellence AND Customer Intimacy, but not at once

In the previous blog entry, we saw how one company resolved the conflict between operational excellence and customer intimacy. They found a way to have both. But we didn’t implement both at the same time.

We first went for Operational Excellence. First we standardised, made things reliable, made work repeatable, not only in production but also in IT. The existing product definitions were inconsistent and complex. This made our code complex because we had to treat every product as a special case. Over a period of about one year all the product definitions and the code were refactored to new standardised forms. All of this happened while the system was in production and new features were released every two months. We got very good at refactoring and migrating without disrupting because we did it so often, in small steps.

A similar ‘refactoring’ happened on the production floor. Product line by product line was tackled: work cells clearly labeled, clear flow lines from input to output established, work in process limited… When I first went to see the production floor I nearly got lost between the piles of work in process and it was hard to see what was going on. After the changes, the area looked a lot more spacious and it was clear at a glance what was going on.

Once we had the production and development system under control, we started to think about customisation and getting more intimate with our customers.

Effectiveness AND Alignment, but not at once

This reminded of Alan Kelly’s blog entry about the “Alignment Trap“. In summary: we want our IT organisations to be effective (do things right) and aligned with business objectives (do the right things). Unfortunately, most organisations do neither.

If we want an organisation that does the right things and does them right, what strategy should we follow? Based on a study, Alan conjectures that it’s best to focus on effectiveness first, alignment second. First learn to do things right, then do the right things.

Managed and Agile, but not at once

I encounter a similar situation in many coaching and consulting engagements. Organisations want IT teams that are reliable, predictable and can be trusted to deliver as promised. And they also want them to be agile, deliver faster and respond to change. Lean and Agile can get you there.

What’s the first step? Usually, we need to bring things under control, clear away the clutter, reduce chaos, limit task switching, limit work in process and make things visible. This often involves “anti-agile” or “anti-lean” measures such as batching support, analysis and design work to avoid task switching and installing strict change management and issue prioritising to keep focus. I always get lots of complaints and get accused of “not being agile” from people who are used to the chaos and suddenly find that the team no longer asks “How High?” when they yell “JUMP!” Those who stop jumping find that they get a lot more done and that the results are better. They are less stressed.

Once we have the process under control, we can start improving the flow.We know how to do things, we can start to go a bit faster, in smaller steps; we can disrupt the stability to improve a bit. And then we find a new stability and so on.

Heijunka

Heijunka is one of the often forgotten Toyota Way principles. It means “levelling the load”, working at a steady, regular, sustained and sustainable pace. It means planning the work so that there’s a good balance between flow and the load on people and machines.

Large companies who impose just-in-time deliveries to their suppliers without levelling their orders abuse their suppliers. Teams who randomly request clarifications for stories burn out their Product Owner. Teams who push out releases faster than their customers and users can accept them throw away value.

Heijunka means making and keeping work humane.

Which small step can you take to make your work more humane?

Nynke Etk Fokma: near-death-experience

Nynke Etk Fokma — Sat, 20 Jun 2009 10:54:02 +0000

That is not the real problem! It is in how we cope! Our fear of death of the old system may be our greatest fear at the moment. It slows our rhythms, decreases our energy, and actually makes us do what we fear the most – cause a premature death of the economical system. Yet any late [...]

Pascal Van Cauwenberghe: Nemawashi - Decisions by consensus without compromise

Pascal — Fri, 19 Jun 2009 17:20:53 +0000

Decisions by consensus

One of the Toyota Way principles is « Nemawashi », take decisions by consensus.

Building consensus is a slow process, but it’s necessary to get everybody on board before taking a decision. Otherwise, the implementation will be delayed and (unconsciously) sabotaged by those who didn’t agree or weren’t involved.

It’s not just about building support for your ideas. The consensus-building process solicits ideas and review from everyone involved so that the final idea is usually a lot stronger than the original.

But there’s one big misunderstanding about consensus.

Consensus doesn’t require Compromise

It’s tempting to dilute our idea to reach consensus, ensure that everyone gets a bit of what they want, so that they’ll agree to go along.

It doesn’t have to be this way. In “Extreme Toyota” the authors show how Toyota embraces conflicts and doesn’t settle for compromises. They identify six contradictions that are central to Toyota’s way of working:

Moving gradually and taking big leaps
Cultivating frugality while spending huge sums
Operating efficiently as well as redundantly
Cultivating stability and a paranoid mindset
Respecting bureaucratic hierarchy and allowing freedom to dissent
Maintaining simplified and complex communication

“This AND that” sounds better than “This OVER that”… I want to have my cake and eat it too

Enter the business consultants

A few years ago I worked on a project that automated the whole value stream of a business unit. The main challenge was that the different departments had conflicting needs. No surprise there.

One of the conflicts was between the production department that did the work on customer demand and the sales department that sold contracts for doing the work to the customer . The production department needed standardised products with little variation so that they could work efficiently, predictably and hit their Service Level Agreements; the sales team needed customised products so that they could tailor their offering precisely to what the customer needed.

This is a classical conflict. The business consultants on the project called this “Operational Excellence” versus “Customer Intimacy“. And the consultants said we had to choose. It’s one or the other, you can’t have both. It’s like Henry Ford’s saying: “You can have any color car, as long as that color is black.”

Examining the conflict

It’s clear, you can’t have both standardised and customised at the same time. There’s a clear conflict. But we have a tool to deal with conflicts: the Conflict Resolution Diagram. Let’s apply the tool:

The diagram says:

To have a growing, profitable business unit (A) we need to sell what the customer needs (C) and deliver it reliably and cheaply (B).
To produce reliably, predictably at low cost and to hit the Service Level Agreements (B) we need products with little variety (D).
To create an offer that responds to the customer’s need and to grow our market (C) we need to vary our products per customer (D’).
Conflict: we can’t have little variation (D) and a lot of variation (D’) at the same time, but we need both.

Questioning assumptions

We deal with the conflict by questioning the underlying assumptions. Can we find fault with our logic? Bill Dettmer recommends to restate the relationships in “extreme wording”. For example:

There’s absolutely no way to have both low and high variability at the same time! Well, duh!
The only way to be profitable and reliable is to have low variability! Well, it was hard to fault this reasoning as this company operated on large volumes with low margins and tight competition.
Customers always need special cases! Not always, but customers were no longer satisfied with one-size-fits-all offers. If this company couldn’t offer customised products, the competitors would be more than willing to get a new customer.
We could have low variability and yet vary per customer if only we didn’t have so many customers! Going niche wasn’t an option for economical and legal reasons.

We looked at it every way possible and couldn’t find a fault with the reasoning until…

Finally, some clarity

The Logical Thinking Processes have a set of “Legitimate Reservations”, a set of critical questions we should ask. The first one is simply called “Clarity“: is the meaning of every word and sentence clear to everybody?

Now, we had already noticed that the different departments seemed to have different definitions for the same word. There were even differences in the way they described the different products to us. Were we talking about the same thing?

The breakthrough came when we asked “What do you mean by ‘Product’?” A product for the Production department wasn’t the same thing as a product for the Sales department. And the accounting & finance department had another definition of product. But… That’s not a bug; it’s a feature: if a Production-Product is different from a Sales-Product, can we have Production-Products with low variation and Sales-Products with high variation?

After a lot more work we came up with a way to standardise Production-Products on a small set of “building blocks” and let Sales create Sales-Products by mixing and matching the building blocks according to customer need. Then we mapped Production-Products onto Accounting-Products. And everybody got what they wanted: Operational Excellence AND Customer Intimacy.

Embrace conflict

We didn’t settle for a compromise, but spent the time to really think through our conflicts and come up with a solution that satisfied all needs. A conflict can be an opportunity to come up with an innovative solution.

You don’t have to settle for compromises if you think about it.

Picture of Bonsai by A. Marques. Thank you.

Pascal Van Cauwenberghe: More about Business Value

Pascal — Wed, 17 Jun 2009 21:59:33 +0000

Liz Keogh comments on the Business Value estimation blog entry.

Thanks for the model; I’ll remember it for when a team needs to actually come up with some numbers (so far we’ve managed to avoid this!).

A business value model is useful without numbers, when prioritising by relative business value.

The most important thing we can do is to make the “value drivers”, the reasons we do this project, clear. Then we can evaluate any decision against these drivers.

“Increasing domain knowledge is one of the top value drivers for this project. Thus, I’d prefer to see feature A in this release, because it will give us more information than feature B, even though A is more expensive than B.”

“Feature C is going to give us a lot more visibility in the market than the other features and visibility is what this project is about.”

The reason I prefer “want” to “need” is for the same reason that we use “should” instead of “will” in BDD - it allows the goals to be questioned.

Yes, we need to question the goals — and everything else. How many questions are raised by “TO achieve this goal AS a stakeholder I NEED a capability”? A seemingly infinite number if I’m the analyst

Is that a valid stakeholder of our system? If we’ve built a context model, we already know which stakeholders we should consider. Or maybe we’ve discovered a new stakeholder we should include in our context model?
Is this a real stakeholder or are they representing a real stakeholder? For example, which is the most powerful user story: “TO sell more AS A salesperson I NEED <some differentiating capability>” or “TO improve my life or work in some meaningful way AS A user I NEED <some differentiating capability>”?
Is that a valid goal of our project?
How does this stakeholder goal get us closer to the project goal?
Is this goal there to support some other goal? If we derive stories from project goals, we will only create stories that achieve a goal or enable another story that brings us closer to the goal.
Do we really need that capability to reach that goal? Is there no other way?
Is that capability sufficient to reach that goal? Do we need something more?

The “Logical Thinking Processes” book taught me an interesting technique: use “strong” language to encourage questioning. For example:

“The only way we can ever reach that goal is to have that capability!” Well no, we could also…
“The only thing we need to satisfy that goal is this capability!” Well no, we also need…
“If that stakeholder’s goal is satisfied they’ll never want anything else again!”. Well no, they’ll also need…
“If we don’t satisfy that stakeholder, this project is doomed!” Well no, they could temporarily….

I like “need”. It’s strong and helps me to derive the minimum number of capabilities to achieve goals. I would ask “Do we need this differentiator? Why? What would happen if we didn’t have it? How will it change the lives of our stakeholders?”

“Want” or “Need”? It doesn’t make much difference. The process and the questions make a difference. People who ask questions make a difference.