Neudesic is a Microsoft National Systems Integrator and Gold ISV Partner with a proven track record of providing reliable, effective solutions based on Microsoft’s technology platform. Our technical and industry expertise empower enterprises to enhance their technological capacity and respond to business opportunities with greater efficiency.

I get to work with my good friends Ted Neward and Simon Guest, both of whose judgement I respect.

My title is “National Agile Evangelist”. That means I’ll be focusing on how we can be more effective at developing and delivering our services through the use of Agile, Lean/Kanban, and whatever methodologies suit. I’ll also be focusing on how we assist our clients in adopting these practices and principles to the betterment of their organizations.

The process going from day one (“your position is no longer being funded” at TW) to making the decision to join Neudesic was thoroughly enjoyable for me. I got to spend time with people I knew and liked, people I didn’t yet know and discovered I liked, and also to learn about what’s going on in the Agile Coaching space in the United States.

For each of you that contributed to the journey, please accept my gratitude.

I hope I can do the same for others.

This year, I’m the producer of the Open Jam, with my assistant producer being Rachel Davies. I’ll get back to this in a minute.

There are several reasons to attend a conference like this:

1. Learning
2. Networking (shmoozing)
3. Selling and marketing
4. Teaching and sharing
5. Volunteering or otherwise working at the conference

The first question I ask myself before I go is “What is my purpose here? Do I have multiple purposes? Is there one thing, or some small set of things, that I’d like to accomplish? When I get back home, what will make me feel that the time was well spent or wasted?”

If you know me, you know I spend a bunch of time in #2 (shmoozing) and, if given the opportunity, a bunch of time in #4 (teaching and sharing). It’s not unlikely that I will be doing #5 (volunteering) and #1 (learning). Up until Tuesday of this week, I was expecting to do a bit of #3 (selling/marketing) on behalf of ThoughtWorks. Clearly, I’ll have that time free.

Are you going? If so, what’s your purpose? If your employer/organization is sending you, how will you justify their investment? Will you be better at your job? Be sure that you have some way to identify the benefits you receive, and that your employer/organization therefore receives, based on the events you attend and connections you make.

Now, that said, on to the Open Jam…

In order to make the whole event richer, the organizers of Agile2011 have, for the past few years held an “Open Jam”. It partakes of concepts like birds-of-a-feather (BOF), Open Space Technology/Unconferences, and lounge. Depending on where it has been, who has been responsible, and what’s going on in the conference, it has presented a different face each year. This year, with Rachel and myself producing it, we’ve decided to introduce a couple of extras as part of the Open Jam.

1. PechaKucha (pronounced, if you care, as p’cha-k’cha, not peh-cha-koo-cha): each day, after the programmed sessions have ended, the stage is yours. Come present 20 slides at 20 seconds each for a total of six minutes and forty seconds (6:40). Talk about anything you like: hobbies, technology, passions, sports, design, whatever you like. It should be fun and exciting!
2. Coaches Corner: thanks to the leadership of Mark Levison, there will be an area with experienced Agile coaches who will maintain “office hours” so others can come talk with them. Got challenges? Problems? Curiosity? Just learning? Come and talk to them during their office hours. Various organizations and independents will be represented. You can’t lose!
3. The Fringe: there were many excellent proposals submitted to the conference earlier this year. Having been one of the reviewers, I can tell you that it is never easy to eliminate some. It’s like American Idol or So You Think You Can Dance – it doesn’t matter how good you are, not everyone can win. So we (okay, Rachel) thought it might be nice to have a non-stage on which some of these folks can deliver the goods. We went through the non-accepted proposals (they weren’t rejected, y’know), and have picked an interesting sample (including yours truly, btw) for you.
4. Park Bench: this will be a place where, among other things, the original authors of A Manifesto for Agile Software Development (“the Agile manifesto”) will be dropping by from time to time.

I’ll be there from Sunday afternoon through Friday evening.  Not necessarily in the Open Jam the whole time, but the odds are good that you’ll see me there a time or two if you look for me.

I’m frequently asked “What is the hardest part? Is it the engineering practices? The predictability (or lack thereof)? Staffing?”

None of the above (you probably guessed that).

Boundary friction. Yup, that’s it. Boundary friction.

Imagine two trains. They’re running on tracks that sometimes run parallel, and sometimes diverge and come back together. When they get close enough, they actually touch.

Got it? Got the image of two trains racing or plodding along, coming closer and moving farther away, and sometimes coming into contact? Can you hear the train whistles and the sound of the wind and the wheels?  Feel the vibration?

If they’re both moving at the same speed, what happens when they come together?

Nothing. Smooth, easy, no friction.

What if they’re moving at different speeds? Faster versus slower is not better or worse, just different. So what happens?

Friction. Things heat up, maybe metal gets bent or crunched or marred. It is not smooth and easy, is it?

When organizations are implementing agile (or any systemic change, really), without considering the whole organization, friction is inevitable. Let’s say that Business Operations is used to doing things one way, and isn’t ready to change (yet). Along comes this project team that’s doing Agile. Again, I’m not arguing that “agile is faster/better”, I’m just saying that it’s like they’re moving at different speeds. Where they come together, there will be more or less friction depending on how close to parallel and how close to the same speed they are.

In this case, it means that if both organizations are not embracing the change in similar ways, there will be more friction.

You can’t impose a change on part of the organization without affecting the rest of the organization. That’s ostrich behavior.

The trick, the secret (it’s actually neither a trick nor a secret, though) is to figure out how to get them to truly come together.

That doesn’t mean telling Business Operations (or Sales or Product Management or…) “For this to work, you have to adopt Agile principles and practices and methodologies. Now. Today.”

No, it means figuring out how to evolve together, taking smaller or larger steps when they’re appropriate. Like embracing the Last Responsible Moment principle. Like the Simple Design principle.

Implement as much change as you can readily absorb, in order to get you a bit further along. Then inspect and adapt. Don’t rush.

Organizations are organisms, and the organs and skeletal structure are all part of the same organism.

Or trains. Yeah, they’re trains.

This is such a good object lesson about testing, it’s almost not funny.

This fellow manages a development team. He’s concerned that they’re not as effective as he thinks they could be, that they have a low “bus factor” (my term), and that testing in particular is not what it could be. They have legacy code, and it sounded like they have quite a bit of specialization, in spite of having only four developers.

I latched onto that last point first. “Have you tried pairing?” I asked.

“No, I hadn’t really thought of it yet.”

Lots of intermediate discussion…

“What do you do when you have an odd number of people?”

I knew he was listening carefully, and yet I was getting a feeling of resistance. I tried to offer ways in which he could get buy in from the team, make some changes that would encourage them to think and examine the way they’ve been working, and make it a team thing, not something imposed from above.

“Well, I’m really concerned about the testers.”

I suggested co-location, or some version of it. He explained that they have separate two-person offices, and he can’t change that.

All of this got me to wondering whether he really wants to facilitate change, or he just wants to talk about it. He said some of the right things, but when it got down to actually doing it, he repeatedly explained to me how hard it would be, and what the obstacles are.

Change is hard. Embrace change only if you really believe that it has the potential to deliver benefit. And then embrace it wholeheartedly.

Here’s how the story goes: you build a project plan, and do your best to manage to the project plan. Things drop out, like testing and documentation and training, as you run short on time and/or money, or your resources are committed elsewhere. Ultimately, with a system with multiple components/subsystems/systems, you get to the point of integration. Your project plan allows for some time to do the integration, including fixing the bugs uncovered during integration.

The problem I’ve seen over and over is that there are more bugs than anticipated, the team has been split up to work on other projects, there’s neither time nor money left for this project, and the developers and testers are multitasking from their new assignments to get these things fixed. Oh, and they’ve forgotten everything they knew about the code and tests that they wrote a year ago.

The time and effort and cost that are not part of the original project plan? That’s what I call “the hidden project plan”.

The short answer? Continuous integration / deployment / delivery, combined with effective TDD and automated functional testing. These things, along with a number of other agile practices, can reduce or eliminate the hidden project plan such that when a team says “it’s done” it’s really done.

I was talking to my friends Maura and Shawn

Here’s the result of my developing and wondering and pondering and talking:

I want to start on open source project to create something – game, system, website, whatever – that incorporates elements of alternate reality games (as described by McGonigal) including the four defining traits of games^*, somehow tracking and recording practice toward 10,000 hours, and that focuses on intrinsic motivation with a tickle of extrinsic motivation.

My first focus would be on facilitating the adoption of Agile principles and practices in organizations, although it’s far from limited to that.

I’m not defining it any further than this for now, because I want to engage folks “out there” to work with me on this project. It feels LARGE. It’s certainly larger than I can envision and implement myself. Does it intrigue you? Would you like to join me in creating something that could make a significant mark on the world?

If you’re reading this, then you know how to reach me. That’s your first quest.

^* “When you strip away the genre differences and the technological complexities, all games share four defining traits: a goal, rules, a feedback system, and voluntary participation.” ~Jane McGonigal, “Reality is Broken”

In many situations, there is certainly a sense of accomplishment. In fact, at our internal training at ThoughtWorks, we’ve² moved away from lecture and classroom intensive training, and toward project-focused, experiential learning. This allows the participants to gain feelings of achievement and accomplishment, to learn about collaboration, and to find a sense of discovery. Much of the instruction has moved to a Socratic Method, which both leads and allows the participants to use their intrinsic motivation.

The question I’m exploring is “can we apply these same methods and techniques in a public, less-controlled setting?” I believe the answer is yes.

What would the changes have to be?

• Far less lecture. Just enough to give them a basic understanding, but not enough to fill their heads.
• Challenges that allow them to discover, rather than be spoon-fed.
• Questions rather than assertions, to allow them to incorporate changes in their thinking.
• Achievements that allow them to feel good about themselves while they are learning.
• Some extrinsic motivation, as long as it’s not the main focus.
• The idea of a constant progression toward mastery (which takes me back to Shu Ha Ri and my post Is easy the same as hard?).

We’ll be working on this in our educational content. Expect to see the first results publicly available in the next few months.

Just because, look at this TED Talk by Sugata Mitra. It’s fantastic. (it should be embedded right here)

1 Just in case it hasn’t become painfully clear yet, I am avoiding the word “training”.

2 While I say “we”, in fact I had nothing to do with it. Take a look at Sumeet Moghe’s blog. Sumeet is the driving force behind all of our internal education at ThoughtWorks.

P.S. We’re hiring at ThoughtWorks again (still).

Of course, it’s got me thinking.

Alternate Reality

Does this mean some kind of weird science fiction stuff? No. It means games that can be played in the real world or in virtual worlds that may apply different sets of rules or contexts. McGonigal mentions the virtual worlds of Halo and World of Warcraft in the book. These are two very different contexts and scenarios. Halo is warfare set in something like the real world we know. Okay, there are aliens. But other than that…

I’ve never been a big, enthusiastic gamer, but I do like shooting things and blowing them up. And yet, somehow Halo has never called to me.

And then there’s World of Warcraft, which is a fantasy world in which you complete quests, fight, and band with others. If you’d asked me last week, I’d have said that I had no particular interest. But thanks to Jane McGonigal, I decided to sign up for a free trial of the game. It was more what she said about Intrinsic Motivation (see Dan Pink’s “Drive”) and how the quests relate, and the overall idea of collaboration but not (necessarily) competition.

The quests are compelling. Nothing really happens. I don’t get any prizes or recognition or anything but leveling up in the game. Somehow, in spite of that, I want to keep doing quest after quest. There’s a feeling of satisfaction about it. Finish one, start another. Level up periodically. Fight monsters, deliver messages, get lost and wander around, go up trees and down into the earth… On one level, it seems entirely pointless. On another, I FREAKIN’ GET IT!

Training?

How does this apply? Is there a way to use this kind of approach in delivering what we oh-so-annoyingly* call “training”?

I’m thinking about the idea of intrinsic motivation, quests, achievements that allow each of us to feel a sense of accomplishment, and extending it beyond the specific educational situation. That last includes some form of “social medium” and also thinking about how to extend it into the workplace.

Agile teams are pretty good at this. Each time a person or pair completes a story, they get to move it on. There’s a sense of achievement in that. Of course, they don’t get a nifty “+1″ floating over their heads. They don’t level up to the next level of developer or tester. Maybe there’s a way?

For now, my immediate focus is on how to apply this in the educational/learning situation. Is there a way to design and create learning environments that take advantage of the work of Jane McGonigal, game designers, and others?

* I say “oh-so-annoyingly” because we should NOT be doing “training”. We train pets to certain specific behaviors. When I’m working with a project team or a bunch of folks from an organization that wants to adopt Agile, I’m not training them. I’m leading them to think differently and adopt different behaviors. So “training” just seems the wrong word to me.

In traditional/waterfall, it’s all too likely that we are being dishonest, either through commission or omission: about being on time; about how much is left to do; about when we’ll be done; about the quality of our work. The whole system seems to encourage, or at least support, this kind of dishonesty.

Let me be clear: I am not condemning waterfall wholesale, nor those who practice waterfall. I am examining the cultural biases generated by this approach, and the effects they have on the people.

A phrase I use frequently in Agile:

Based on what we know today, if nothing changes,…

Think about a burn-up chart or burn-down chart. It is immediate. It is based on what we know today, and the forecast/projection only holds true if nothing changes. All the information is clear, it’s right out there for anyone to see, and it’s honest.

When will the project be done? Based on what we know today, if nothing changes…

Because we allow for changes in scope and capacity (velocity), all we know for sure is based on what we’ve accomplished to date, and the current status.

How much is left to do? Based on what we know today, if nothing changes…

As above, the scope might change. If the scope doesn’t change, then we can look at a burn-up chart and tell, with some accuracy, how much is left to do between now and when the progress line touches the scope line.

It goes on and on. The charts are on the wall (including the card wall itself) or in some readily accessible and visible virtual location (like in Mingle).

When I do training, I always make sure that people learn this: “Based on what we know today, if nothing changes…”

It’s honest, based on history, experience, and evidence, and it’s all there for anyone to see.

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.

From 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 Agile 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 Agile being suggestions or recommendations, not a set of prescriptions. And yet, for an organization or a team that is starting something new, where and how do they start?

Certainly, I am comfortable recommending training 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 change 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**

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

** Quotes from Wikipedia

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

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.

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

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/

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!

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

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.