Posts Tagged ‘Agile’

The Plow

Agile & Lean, Musings | Posted by Doc
Aug 28 2010

The other day, in a meeting, someone made reference to the change process as a plow. At that moment, I admit that I stopped listening. Not because it wasn’t interesting or valuable, but because the image of the plow took over my attention.

First, the question of pulling, pushing, resistance, and steering. This intrigued me. When we focus on organizational transformation (or whatever term you like), all four things come into play.ox-plow-nepal.jpg

Pull

The pull comes from the organization’s desire to change. The power of the pull, then, is dependent on their desire and willingness and commitment. Imagine the image at the right – strong desire, willingness, and commitment. Now imagine a chihuahua pulling the plow. Would you achieve the same success in the same time? Probably not.

How about the idea of a plow that is pulled, but not pushed or steered. How would it be if the oxen were left to their own devices here? The plow would fall over, and either they’d keep going until they got bored, or they’d get stuck because the plow got stuck on something.

The importance of pull is that it’s nearly impossible to achieve change without some amount of pull, while at the same time, pull is not enough by itself.

Push

train_plow.jpg

Then let’s consider push. Many of us approach our consulting/coaching roles as if our job is to provide a giant push. This just doesn’t work. If there’s no pull, then no matter how hard we try to push, we’re not going to achieve success quickly. Imagine a cruise ship or one of those massive oil tankers. Yes, their default mode of propulsion and steering is from the rear – push. It takes a long time to change the direction of a ship like that, because of the inertia of the ship and the resistance of the water.

Now imagine adding a tugboat at the front of the ship. While neither push nor pull is enough by itself to make a significant change quickly, working together they can effect the change more quickly than otherwise.

So we have the idea of synergy between the organization’s pull, and the change agent’s push. Together, they produce more change more effectively.

Of course, with pull and push working together, you get a linear motion, right?

Resistance

No matter how willing individual people might be, there will be resistance. Sometimes it’s passive resistance: people just keep doing what they’ve always done, not to thwart the change, but because it’s what they know. Sometimes it’s active resistance: people hold fast to their kingdoms or their safety, and change is threatening. Regardless of the reason, there will always be some resistance. In plowing for planting, it’s the earth itself. In the example of our ship, it’s the water. Neither earth nor water is actively resisting, nor is it malicious. Rather, just like organizational processes, water moves in its own way and earth is static in its own way, and you have to work with it rather than against it in order to succeed in effecting change.

Steering

Finally, let’s look at the part that brings them together: steering. Pull without steering is inflexible. The ship will keep moving in one direction. Push without steering is unpredictable. Whether the vagaries of the waves (change) or running into some resistance, pushing can lead to disaster. Consider the Titanic. While they had push and steering, they didn’t apply the steering until it was too late.

And, of course, there are currents in the water that change, and rocks in the ground that resist progress. It takes some attention and thought to recognize and adapt to those currents and obstacles.

We have to consider, therefore, that change is best effected by a combination of pull – the desire to change, push – the drive and incentive and energy, and steering – the intelligence and experience and attention to make decisions on a moment-by-moment basis.

When we find ourselves in coaching/consulting roles, it is a significant challenge to find the balance, and to find the right people/groups to effect that balance.

  • Oxen pulling plow: http://www.hobotraveler.com/2007/02/nepal-plowing-field.html
  • Train plow: http://www.flickr.com/photos/mclaren237/3101440372/

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

I&I over P&T

Agile & Lean, Coping and Communicating | Posted by Doc
Aug 16 2010

One of the value statements from A Manifesto for Agile Software Development is:

Individuals and Interactions over Processes and Tools

For those who are not familiar with the Manifesto, what it says about the value statements is: “…while there is value in the items on the right, we value the items on the left more.”

So this bit says “while there is value in Processes and Tools, we value Individuals and Interactions more.”

I always enjoy this one, when presenting or sharing it. First, because I work for ThoughtWorks, where we are experts on processes and tools. ;) Beyond that, though, is the relevance and power in this value statement.

Why do we have processes and tools? I’d argue it’s in service of having to think about those things – the mechanisms and details – less, so that we are free to be creative, productive, and do things other than thinking about the processes and tools.

It’s like my “shower principle”: I wash myself the same way every day. The process is the same every day. As a result, I don’t have to think about the process, and am free to think about other things.

So from this perspective, processes and tools are enablers. They should free us to do the things only we can do, and save us from spending a lot of time thinking about the processes or tools. Developers will frequently tell you that they have strong attachments to their tools-of-choice. Why? Because they know how to use them and don’t have to think about the tools. As a result, they spend most of the time thinking about their code – how to make it better, how to make it satisfy its goals, how to be more creative,…

One of the many things I like about “Agile” and the Agile Manifesto is that they apply to far more than software development. That’s part of what I liked about my exchange with my brother the other day (see “Family Self-organization“). As a brief follow-up, when my brother said to his daughters “I’m offering my iPhone to one of you and $XXX to the other. You decide which is which.”, the girls decided within minutes.

I like this statement from Simon Baker: “Put the right people in the right environment and trust them to get things done.”

Yes, Simon, yes!

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Pushing, Pulling, and Lean-ing

Agile & Lean | Posted by Doc
Aug 16 2010

My colleague and friend David Joyce did a short version of his presentation on Kanban for a group of us at our client site the other day. I must say that I feel, for the first time, that Kanban makes sense. David did a brilliant job of making it simple and clear, and the attraction of it is powerful.

You can view the full thing here on his blog.

Now I have an internal struggle. I’m busily training on Agile stuff based on XP and Scrum. I believe that it works and provides real value. I have worked on XP/Scrum teams, but not on a team doing Kanban. I’m feeling pulled toward Kanban, after listening to David.

It feels as though Kanban is my natural way of working: give me work, don’t give it to me all at once, let me work on one thing until I’m done, and occasionally interrupt me with higher priorities if you must. What’s my status? “I’m working on X.”

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Is culture change necessary?

Agile & Lean | Posted by Doc
Aug 10 2010

I’m spending a lot of time doing training these days. Training on various aspects of Agile Software Development, with a focus on Extreme Programming (XP) and Scrum, although it’s not specific to those approaches/schools of thought.

Most of what people hear is foreign to what they’re accustomed to. Among other things, there’s a different way of managing their work, organising their work and their team, and communicating with the rest of the organisation.

Inevitably, someone will ask “Is it possible to be successful in adopting these practices without an organisational culture change?”

That’s a hard one, because achieving culture change in a large organisation is like turning an ocean liner. It takes a lot of energy, and doesn’t happen quickly.

And yet, I would say that it is not possible to adopt different practices and methodologies – in this case, specifically, Agile Software Development – without a culture change.

The interfaces between the levels of an organisation change. People who expect status and progress reports are now going to be told “come look at our story wall and our burn-up chart.”

The interfaces between the different peer organisations change. If one organisation is still working in the “old” way, then there are serious challenges in working together with an agile organisation that is doing iterative work.

The interfaces between the agile organisation and its external vendors/partners change. Sometimes, it forces a change of vendors. In the Toyota world of the Toyota Production System, their vendors/partners/suppliers not only had to adopt TPS, but were also treated as though they were part of Toyota. As with so much else in agile, there’s far less us vs. them and far more us.

Recognition changes. Instead of a culture of heroism and a culture of blame, we have a culture of shared commitment, shared responsibility, and shared ownership. As a result, recognition and accomplishment go to the team instead of the individual.

Can it be done? Can you adopt “agile” without an organisational culture change?

I’d say no.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Push-Me, Pull-You

Coping and Communicating, Facilitation | Posted by Doc
Aug 10 2010

Do you remember the special animal in the movie “Doctor Dolittle“? The pushmi-pullyu?

The challenge these animals faced was this:

“They had no tail, but a head at each end, and sharp horns on each head.” and “…no matter which way you came towards him, he was always facing you.”

I always thought that an animal like this would die out, because if the heads were equal, it would never be able to go anywhere.

We all know about “too many chiefs and not enough Indians”, which has a similar problem.

So how do you handle a situation where there’s either too much push or too much pull?

In t’ai chi ch’uan (commonly referred to as just tai chi), one of the techniques has to do with pushing. Pushing takes on many different aspects, from forceful lifting/pushing, to a gentler slower movement. As I think about how we work with teams and organisations, it occurs to me that all too often we’re either pushing too hard and too directly, or not enough.

Consider, first, what happens when you try to push someone. What do they do? They brace themselves, at a minimum. Sometimes, they prepare to push back, and then they do push back.

How about if you come up on them gradually? Let’s say you’re standing next to someone, and you slowly shift your weight so that you’re leaning on them – pushing – more and more, little by little? How do they react? Most typically, they will notice when you cross some threshold that is very specific to them. Many times, it will be when some “significant” amount of pressure reaches their awareness. If you were walking down the street, then they’d realize at some point that you had steered them by either physically leaning on them or by entering their “personal space”.

If we are working with a group, team, or organisation, in helping them to adopt new principles, practices, and/or methodologies, some of us – myself most definitely included – have a tendency to push. To be emphatic, zealous, excited, energetic, passionate, insistent,…

We must be aware and wary of creating resistance through our pushing. We must consider whether it’s more effective to lean on them rather than to push them.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Family self-organization

Uncategorized | Posted by Doc
Aug 10 2010

I was talking with my brother the other day. He has gotten his iPhone 4 (after standing in line for 5 hours in the middle of the night in Melbourne). Now he has a dilemma – one iPhone 3G and two daughters.

We banged the challenge around for a while. We approached it in typical parental fashion, exploring the tradeoffs and options. Give the phone to one, money to the other. But one has six months to go on her contract and the other has a year. All the details, all the challenges, the concern that one or the other or both would be unhappy with him because no matter what he does…

I’m sure you get it.

Finally, my brother said that he was willing to put up the phone and some money. The question is, which to which. Phone, money, two girls.

As we walked down the street together talking, it occurred to me that I was ignoring all the things I’ve been learning, teaching, and doing. When I teach Agile fundamentals, I include a session of the Agile Lego Game, which along with it’s other lessons clearly demonstrates the concept of self-organization.

With this in mind, and knowing that my nieces are smart and that they like each other, I said “Put the phone and the money on the table and let them work it out.”

After all, I’ve seen it demonstrated over and over – give people the chance to work together and figure things out, and the odds are that they will.

I’ll let you know how things go with my nieces. ;)

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Whole Agile

Agile & Lean | Posted by Doc
May 23 2010

It has become more and more apparent that there are at least two different views of “doing agile”:

  1. Following one specific school of thought/set of practices, such as Scrum or Kanban or XP
  2. Utilizing a mix of practices, principles, methodologies, and values to create the package that works best for the organization or team

I’ve run into a number of organizations that are following Scrum*. Prior to training, I hear things like:

Don’t talk to us about engineering practices.

Don’t talk about pairing.

Don’t talk about testing.

Independent of my role within ThoughtWorks, I don’t get this. When I factor in my experience at ThoughtWorks, and the experience of my colleagues, I’m left feeling stumped.

How can you talk about “Agile” without considering practices that are effective for developers or testers? How can you ignore the lessons from Lean? What does it mean to “do Agile”?

As of now, I’m referring to “Whole Agile”: the set of things that comprise practices and principles and methodologies that address all aspects of the development and delivery of products, from ideation to architecture to design to writing code and testing and delivery and…

I just don’t know how to talk about Agile without considering all the things that can work. The argument that “pairing is too expensive” doesn’t fly with me. The argument that “only developers need to do Agile” doesn’t fly with me.

Agile must be holistic to be truly effective.

Hence, “Whole Agile”.


* just as an example – I believe that there are many good practices and principles in Scrum

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Video of a webinar I did – Group Wisdom, Group Genius, and Leading Agile Teams

Agile & Lean | Posted by Doc
May 06 2010

Group Wisdom, Group Genius, and Leading Agile Teams from Steven ‘Doc’ List on Vimeo.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Identify, Isolate, and Remove

Facilitation | Posted by Doc
May 01 2010

This week is a two-event week for me. First was the Agile Boston Open 2010 in Waltham, Massachusetts. The second is Alt.Net Houston 2010 in Houston, Texas.

While in Boston, I got to spend a good chunk of time with Dan Mezick (InfoQ writer, founder of Agile Boston, founder of New Technology Solutions). Dan was the organizer and driving force behind Agile Boston Open 2010, which had about 250 participants. The event was a hybrid: programmed sessions in the morning, which included Ken Schwaber, Amr Elssamadisy, and Michael de la Maza; true Open Space in the afternoon, including an opening, agenda creation, and closing.

In the evening after the Open Space, Agile Boston held their regular monthly meeting, and I was privileged to follow Jean Tabaka on the program. Jean presented Twelve Agile Adoption Failure Modes. I presented Facilitation Patterns & Antipatterns. The synergy between our presentations, and between us, was exceptional. It was GREAT fun!

The following day, Dan and I did some walking and sightseeing in Waltham and Boston. During that time, we talked a lot about topics that interest both of us, much of it around group relations, group dynamics, facilitation, and working with Agile teams.

At one point, our conversation focused on how to deal with disruptive individuals in groups. My focus was on meetings and events, while Dan’s was on working teams, during this conversation. As we were discussing this, Dan casually said “Identify, isolate, and remove.” That really caught my attention, because it’s such a clear, simple formula.

The challenges with that formula are twofold, for me:

  1. It may apply to a working team. In fact, I’d say that there are circumstances where it clearly does. I feel that it does not apply to meetings and events. Isolating someone and removing someone from a meeting is countereffective, as it will engender the wrong feelings in the target, and negatively affect the group.
  2. It’s so simple that I fear it could become a mantra, and misapplied because it’s so easy to remember and apply.

I’m not disagreeing with Dan, or arguing that I don’t like the formula. I find it compelling, if only for its simplicity. I’m just being cautious that it doesn’t get misused in the wrong circumstances.

That said, I give Dan full credit for spontaneously articulating something that is so effective as a model.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

A Culture of Heroism

Agile & Lean, Coping and Communicating, Musings | Posted by Doc
Feb 11 2010

A while back, I wrote about A Culture of Blame. As I’ve traveled around the US and to other countries, I’ve seen more and more evidence of this, which keeps me thinking. I’m always looking for patterns of behavior, and simple ways to describe them.

When talking about Agile teams as compared to Waterfall teams, one of the things that has become apparent is that Waterfall is also a Culture of Heroism. In fact, in many ways, much of Western culture is about heroism. We laud the star athlete, the exceptional business person, the standout author, and so on. In many cases, it seems to be recognition and acclaim for the individual over the group, or at least the individual separate from the group.

Agile teams foster a culture of collaboration and cooperation. That’s not to say that there’s not room for individual excellence, effort, and achievement. I would say that high performant teams tend to focus on the success of the team over the individual. Is Agile more socialist, while Waterfall is more capitalist? I’m not sure, but it seems that way.

Regardless, there are a number of side effects of a Culture of Heroism:

  • Ego-driven achievement
  • Unhealthy competition (although sometimes it’s quite healthy)
  • Rewards that – in recognizing the individual – discourage the others on the team
  • A focus on the individual rather than the group goals

This is an interesting thing for me, because I’m highly competitive, and am happy to have individual recognition. On the other hand, I believe strongly in subordinating my ego to the purposes and goals of the team, and that the success of the team is what’s important*. Since my ego still wins out at times, I recognize that this is not just a struggle for me, but for others as well.

We’re raised in a culture of individualism and heroism, then we are invited into the Agile fold, and asked to shift our focus and our energy from ourselves to our teams.

I’ll continue to explore this as I get the opportunity to work with more teams. I will say that I’ve seen the culture of heroism everywhere I’ve gone, in one form or another, and believe firmly that the change to a culture of collaboration must come from the leadership as well as the team.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Twitter links powered by Tweet This v1.7, a WordPress plugin for Twitter.