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.

Why do you care?

I just returned from attending Agile2011. I spent five nights and five days immersed in the community of friends, colleagues, luminaries, associates, strangers, and vendors that comprise the event. As always, it was entertaining, illuminating, exhausting, and heart-warming.

I had conversations about techniques and challenges, career and day-to-day work, my recent job situation, family, friendship, travel, technology, games,… I’m sure you get the picture.

I spent much of my time in the Open Jam, as I was the Producer and felt some responsibility there, and because that’s where I would spend a lot of time anyway because I love to shmooze with people, and because I’m looking for a new job and it was a good place to catch up with people to talk about it. And I did – shmooze, talk about jobs, and fulfill my responsibilities.

I also attended a couple of sessions, and poked my head into a few others.  I delivered my Facilitation Fun! session in the Open Jam Fringe to a small but enthusiastic group. I coordinated the PechaKucha area and presented there one evening.

I wrote a few blog posts while I was there, stimulated by recent events in my career and by the book I’m currently reading.

Mostly, I was immersed in the sense of community that exists at this event. I’ve experienced it at lots of other events, as well, but the Agile20xx events bring a sense of community that is remarkable. There’s a sense of intention, collaboration, and connection that I rarely experience elsewhere.
And then it was Friday. I had two meetings on Friday morning, so was only able to spend a short time in the halls, catching up with a few people with whom I had not yet caught up, and waving and saying goodbye to and hugging a number of others. The event was primarily at the Grand America hotel in Salt Lake City, with some sessions and some lodging across the street in the Little America hotel.  On Friday morning after my last meeting, as I started to leave the Grand America to go across to finish packing and leaving, I hesitated on the threshhold of the Grand America.

“Have I seen the people I wanted to see, and said goodbye properly?”

I looked at my watch, and thought about it for a minute, standing there quietly, looking across the driveway towards the Little America across the street.

Summer Camp Syndrome™.

I found myself feeling drawn back into the venue so I could extend the immersion and the feeling of connectedness and belonging. I was exhausted, had just enough time to finish packing and check out, and still – irrationally – felt myself drawn back in. After all, with 1600+ people attending, and knowing many dozens, perhaps hundreds, of them, it’s obvious that I had not been able to even see, much less talk with, all the folks that I would have liked to connect with.

So there I stood, on the threshold both physically and emotionally, considering the irrational. Should I go back in, make at least one more pass through the halls, maybe feeling rushed for time, or continue on my way and do the rational thing.

It was agony. The banquet the night before was “the climax” of the event, but of course I only saw a relatively small number of people there. I was feeling like I wanted something like the closing circle of an Open Space. Not exactly, but something like it. Some sense of closure and completion was lacking for me.

I did the rational thing, mentally and emotionally and physically leaving the event and the community, and walked across the street to the Little America.

Of course, it’s never that clean and simple. I ran into friends from ThoughtWorks in the lobby of the Little America and stopped to chat. After packing and while on my way out, I ran into friends from Leandog and stopped to chat. Waiting outside to go to the airport were Lyssa Adkins and Michael Spayd, creators of the Agile Coaching Institute. We rode to the airport together, and I continued the connection while walking through the airport and having lunch with Lyssa.

Lyssa and I separated after lunch, me going directly to my gate, which was right there, Lyssa heading off to another terminal for a later flight.

Summer Camp Syndrome™.

There’s a feeling almost like addiction and withdrawal, regarding an event like this. The immersion is so powerful, so emotional, that it’s almost a physical pain to end it – to cut it off. That’s “Summer Camp Syndrome” – the sadness, sorrow, and sense of disconnection that comes at the end of an immersive, community event in which strong connections are formed. The need for continuation and closure, all at the same time, that leaves me (and maybe you) standing at the threshold feeling simultaneously drawn in and out.

There’s no question that I’m very happy to be home with my lovely wife of 35 years, Debbie.

And there’s no question that I’m feeling sad about the people I didn’t see and talk with, the people I did see and talk with but didn’t get to say farewell to, and even the people I spent time with at the end, because that time ended too. I am, as I said, exhausted, but in the best possible way. And I’m eager for next year’s conference, so I can do it all again.

In the meantime, I hope I’ll see some of these folks at other events coming up, like Pablo’s Fiesta, Agile Open Southern California, and Øredev.

I don’t even want to stop writing this post, because it helps me to keep feeling connected.

But I will.

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.

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.

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.

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.

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.