Archive for the ‘Agile & Lean’ Category

Is easy the same as hard?

Agile & Lean, Musings | Posted by Doc
Oct 11 2010

Many, many years ago, when I was actively engaged in writing, designing, and architecting software applications and systems, I established for myself two guiding principles for the user interface*:

  1. Make it as easy as possible for the user to get it right.
  2. Make it as hard as possible for the user to get it wrong.

Are they the same thing? They seem to be on the surface.

They are not the same thing at all.

guide_nbgFrom the UI standpoint, the first means offering hints, guidance, and making it obvious what the user is supposed to do. The second means constraining the user with dropdown lists and radio buttons and wizardy things so that they have fewer choices and fewer paths to choose.

I was thinking about this in terms of adopting new practices. Is it possible to apply these same principles?

At a large organization, as they started the point of the wedge – their first few projects – they created a set of artifacts. They had recommended procedures, examples of documents, photos of card walls and reports, and the like. They also said “new projects will do this particular thing this way”. My first reaction was “that’s too prescriptive!” After all, we talk about being suggestions or recommendations, not a set of prescriptions. And yet, for an organization or a that is starting something new, where and how do they start?

Certainly, I am comfortable recommending and coaching. What I’ve experienced in both is that we offer our suggestions and recommendations, right? How many times have you learned something new from someone else and decided that doing just what they showed you was the best way to get started? In fact, isn’t that one of the most basic ways to learn new skills? To imitate your teacher/mentor/guide/master? Certainly when I studied the martial arts, that’s what we did.

So let’s take my two principles and examine them in the context of adopting new practices and learning new skills.

Make it as easy as possible for them to get it right

Training is an example of this. It offers guidance, example artifacts, some tools, and so on. This doesn’t constrain them, but rather provides some boundaries and guidelines that help them find and stay on the right path.

Make it as hard as possible for them to get it “wrong”

Okay, first I have to argue with myself about the word wrong. Let’s that to “make it as hard as possible for them to go very far down rat holes.”

How prescriptive is it reasonable to be, when working with adoption? Is it okay to say “do a burn-up chart, and do it this way” at the beginning? How about stand-ups? Pairing, automated testing, continuous integration, card walls,…

If we consider this in the context of learning models, maybe it’ll all make sense:

Shuhari**

confused-flipped“Shuhari is a Japanese martial art concept, and describes the stages of learning to mastery.”

“During the Shu phase the student should loyally follow the instruction of a single teacher; the student is not yet ready to explore and compare different paths.”

Four Stages of Competence**

“The Four Stages of Learning describe how a person learns, progressing from 1. Unconscious Incompetence (you don’t know that you don’t know something), to 2. Conscious Incompetence (you are now aware that you are incompetent at something), to 3. Conscious Competence (you develop a skill in that area but have to think about it), to the final stage 4. Unconscious Competence (you are good at it and it now comes naturally).”

The Dreyfus Model of Skill Acquisition**

“The Dreyfus model of skill acquisition is a model of how students acquire skills through formal instruction and practicing. Brothers Stuart and Hubert Dreyfus proposed the model in 1980 in an influential, 18-page report on their research at the University of California, Berkeley, Operations Research Center for the United States Air Force Office of Scientific Research. The model proposes that a student passes through five distinct stages: novice, advanced beginner, competent, proficient, and expert.”

“In the novice stage, a person follows rules as given, without context, with no sense of responsibility beyond following the rules exactly. Competence develops when the individual develops organizing principles to quickly access the particular rules that are relevant to the specific task at hand; hence, competence is characterized by active decision making in choosing a course of action. Proficiency is shown by individuals who develop intuition to guide their decisions and devise their own rules to formulate plans. The progression is thus from rigid adherence to rules to an intuitive mode of reasoning based on tacit knowledge.”

[Thanks, Pat Kua, for your thoughtful writing on this topic.]

Where does this all lead me?

In all of these models, and many more that are out there, there is a consistent progression: ignorance, rules/teaching, practice with guidance, achieving some level of mastery.

In being a change agent, coach, master, teacher, or mentor, it’s important to remember that in the beginning it is appropriate to offer more rules and constraints. The student – the person, team, or organization – isn’t ready to really think about things yet. Offering these constraints, however, leaves the student free to think. By reducing their degrees of freedom of choice in the early stages, we also reduce the need to think about what they’re doing and give them the freedom to think about why they’re doing it and what it means to and for them.

So make it easy and make it hard.


* This all predates the exciting work that was to come in the area of User Experience, which all started for me with Alan Cooper’s book “The Inmates Are Running the Asylum”.

** Quotes from Wikipedia

Driven by Desire

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

one_angry_man_facing right-flipped. It’s what I spend my time thinking and talking about. Whether it’s coaching or or organizational or individual, change.

And change is hard.

Thinking back to the Plow, there will be varying amounts and degrees of resistance whenever change is occurring. It doesn’t matter whether the change is initiated internally or externally.

The challenge when you’re an agent of change, therefore, is to reduce the amount and degree of resistance. Of course, if you know my IAAM philosophy, then you know that I believe that you can’t cause change or change resistance. Rather you can offer others the information and perspective that you bring to the table, perhaps couched in such a way as to be most influential or persuasive. But when you get right down to it, change must come from within: within the individual and within the organization.

There’s an implication here for those of us who are, in fact, agents of change. The implication is this: our job is not to change people or organizations.

Our job, then, is to help individuals and organizations desire change.

Whoa. That’s a challenge. How do you guide/help/lead one person, much less an organization, to want change, when change is threatening, frightening, intimidating?

Start by understanding the pain points that they live with today. I know this seems simple and obvious, and to a certain extent it is.

Sadly, too often we go in with the attitude “change is coming, so toughen up, and let’s go!”

That doesn’t work.

Think about yourself. When have you been successful in making a change in yourself? For me, I know it’s only when I want to, not when I think I should. Even when I need to, I still have to want to or the change will fail.

Just look at my waistline. ;) I’m working on it. Ignoring traveling, I’m actually achieving change.  Change in my eating habits and exercise habits and attitude toward food.  Not because someone told me I should.  Not because someone else cares (although they might). It’s because *I* want to change.

So the next time you are sitting in the change agent’s seat, stop and ask the first question: “Why should they care?”

The Plow

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

The other day, in a meeting, someone made reference to the 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 . Imagine the image at the right – strong desire, willingness, and . 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/

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 “” and the 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!

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 on 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 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.”

Is culture change necessary?

Agile & Lean | Posted by Doc
Aug 10 2010

I’m spending a lot of time doing these days. on various aspects of 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 , 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 ?”

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 , 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.

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 adoption. Those of us who feel that we really know 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 .

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.

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 ”:

  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

I’ve run into a number of organizations that are following Scrum*. Prior to , 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 ? 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

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.

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 , and simple ways to describe them.

When talking about teams as compared to teams, one of the things that has become apparent is that is also a 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 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 to a culture of collaboration must come from the as well as the team.