Archive for the ‘Agile & Lean’ Category

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

Driving for Self, Driving for Other

Agile & Lean, Coping and Communicating, Musings | Posted by Doc
Jul 18 2010

I spent the past weekend with my brother. We drove from Melbourne down to Aireys Inlet along the Great Ocean Road. The scenery is spectacular.

While driving, I began to notice some of my brother’s patterns, and it got me thinking about my own patterns.

I think there are two main categories of drivers: those who become one with the vehicle, and those for whom the vehicle is a mechanical conveyance that they manipulate. In either case, we generally drive for ourselves. That is, we react in advance, based on what we see and what we expect to do.

Unfortunately, as I experienced with my brother, this means that while the driver’s body is already moving into what’s happening, the passengers are caught by surprise and may feel bumped, bounced, and thrown around.

I think of myself as one of the people in the first category – the vehicle is an extension of my body, and so I move the vehicle almost unconsciously, and my core body is rarely taken by surprise. My wife and children and friends, on the other hand, may find themselves tossed about from time to time.

This got me thinking about Agile adoption. Those of us who feel that we really know Agile are the first kind of driver – we move unconsciously based on what we know or expect to happen next. This is just fine when we’re working on/with teams that already understand and practice Agile.

But what about when we’re working with teams that are new to Agile? Are we moving so unconsciously that they’re being emotionally tossed about? Are they finding themselves caught by surprise, confused, or frustrated because we’re jinking left when they expected us to go right?

The challenge for me is to figure out how to get the “passengers” in sync with the changes so that we reduce the frequency and amplitude of the surprises to the point where they’re no longer surprised.

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

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

Training is amazing

Agile & Lean | Posted by Doc
Feb 09 2010

I’m at the end of day one of training, doing a custom two-day workshop for a client. The requests were long, so we negotiated it down to what we thought would reasonably fit within two days.

At 11am, I was on slide 4 in the PowerPoint deck. The reason it was moving so slowly is that these people are STARVING for information and guidance. They know they’re doing “quagile” (quasi-agile), they want to move closer to “real” Agile, and they are interested and eager and articulate.

It fascinated me all day, as they took what I was presenting and ran with it. Some heated discussions, some passionate, some involving the whole group of 15, some a subset. It went on all day.

It’s frustrating to me that they’re so eager, and facing such challenges in achieving Agile adoption. And yet it’s the same pattern…

The development team wants it, the QAs want it, the BAs and PMs want it – the “business” and the “customer” want the same old thing.

Sigh.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Subtleties (again)

Agile & Lean, Coping and Communicating, Musings | Posted by Doc
Jan 07 2010

While working out this morning, I got to watching other folks at the gym. It’s a fascinating exercise (watching, that is), as there are all sorts of variations on form and the exercises people do.

Here’s the thing…

Let’s consider biceps curls. It’s a simple enough exercise that lots of people do. Whether with a barbell or dumbbells, the form should be pretty much the same. And yet…

Watching one woman, she pulls her elbows back just before she lifts the barbell to her chest. Watching another fellow, he hunches up his shoulders just before lifting. Another person leans back a bit.

The thing about these subtle movements is that they change the exercise. Changing the exercise changes the value that you get from the exercise.

Obviously, most of these people are either unaware of what they’re doing – those subtle movements – or are unaware of how those movements change the exercise.

So let’s consider someone who, as they are saying something to me, tilts their head to the side. I don’t know about you, but that body language usually means “questioning” to me.

How about someone who doesn’t look me in the eye? Or someone who says things like “really” or “I mean it” or “honestly” a lot. Like Simon Cowell on American Idol who frequently says “If I’m being honest…” What? You’re not being honest the rest of the time?

There is so much communicated in those subtleties.

As I said this summer, each of us is responsible for considering what we say and what we do and how it affects or is interpreted by others. Each of us must be conscious of how we change the value of what we say or do by the little things, like pulling back our elbows before the lift.

I was having a conversation with my friend Sunni Brown the other day, and the topic of subtleties came up. I made the contention that mastery of any skill is made through the subtleties.

As I reflect on that, I’m reminded of something my former karate instructor, Jim Mather, used to say… “I can teach a chimpanzee to do kata [forms], but I can’t teach one to do them well!” Having taught many karate students myself, I became aware fairly early on that mastery of the large movements was easy, but mastery of the subtleties was not.

When I was taking a Chinese calligraphy class, I realized that I needed to watch the teacher’s fingers, where they held the brush, at least as much as I needed to watch the brush itself and the strokes she was making. At one point, I realized that she was unaware of many subtle movements she made as she wrote, and that those subtle movements made all the difference between average and masterful. And she did them largely unconsciously. As a result, she wasn’t actively teaching us those things – it was up to us, as her students, to be perceptive enough to learn those things.

The thing is, you can’t expect people in conversation, meetings, training, or life in general to be adept or perceptive enough to discover what you want them to discover – it’s up to you to make it clear to them. You can’t think or say “they should have known what I meant!” because that abrogates your responsibility to communicate effectively, and pushes that responsibility to the other person.

Be subtle by intent. Be clear and obvious the rest of the time.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

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