Software Waste is Invisible

August 19, 2014

invisibleme_000-782530

You know what one of the biggest problems with knowledge work is? It’s mostly invisible. We can talk about it, but we can’t see it. You can’t see the stuff you want to create (except perhaps in your own head, which really doesn’t count) and perhaps most importantly you can’t see the stuff that is missing.

It gets worse the more people you add to the equation. That’s right, go to a planning meeting and you will find a long list of things that the team thinks they want to do (struggling to make the work visible), but I can almost guarantee you there is no list of what is missing. Why not? Because we can’t see it. It’s hard enough to see the work – that’s tough enough to begin with, but you can just forget about seeing the delay that is associated with that work.

I was reading Reinertson’s book on Product Development Flow the other day and within a couple of pages, it hit me: we can’t see what the hell we are trying to do – and that makes knowledge work really hard. We are like blind men trying to describe the proverbial elephant. If I were assembling a bicycle, I would be able to see all the parts before I put them together. I might even have some sort of inventory list to check against. I can physically see and verify the parts and the work that needs to be done. Compared to knowledge work, this physical assembly is worlds easier to estimate and accomplish – simply because we can see it.

OK, to you this may be a big, “Duh!” moment. Fair enough. But here is where I realize that we may often have a problem. What is the output of a planning meeting? Some user stories, some tasks, maybe a few follow up questions? Perhaps a calendar or timeline of some sort? How often do you see a list of all the risks or potential delays that need to be addressed as an output of a planning meeting? Yeah, never.

You see any process can be broken down into work and delay. This is the foundation for value streams. The thing is, you can’t have one and not the other. There is always delay in any system, no matter how efficient it is. But delay is one of the most neglected things we plan for. Honestly, most of the time we don’t plan for it. We plan the work and choose to ignore the delay. This is like talking about the work, but not acknowledging the impediments to the work. You can’t have one without the other. 

So why in the world would you NOT plan for delay? Planning for it is simply acknowledging that it’s real. Well, I would submit that part of the reason that delay doesn’t get more consideration is because it’s invisible. It’s very hard for us to see and visualize. Let’s face it, human beings perception of time is a total mess. We suck at assessing duration, so why would we be any good at assessing delay?

On agile teams we have evolved mechanisms to make the work visible: Story boards, Kanban boards, & Story maps, are just some of the techniques that have evolved to make work visible to us. We need similar mechanisms to make delay, impediments and other forms of waste visible too. Once we do that, we will have a more realistic vision of the work we are trying to do.


If Everybody’s Happy, You’re Doing It Wrong

August 11, 2014

So there you are, wrapping up another successful release planning session. Sprints are all laid out for the entire release. All the user stories you can think of have been defined. All the daunting challenges laid down. Compromises have been made. Dates committed to. Everyone contributed to the planning effort fully.

So why isn’t everyone happy? Let’s check in with the product owner: The product owner looks like somebody ran over his puppy. The team? They won’t make eye contact and they’re flinching like they’ve just spent hours playing Russian roulette. What’s up? Well, here’s the dynamic that typically plays out:

  • The product owner has some fantasy of what they think they will get delivered as part of the release. This fantasy has absolutely no basis in reality, it just reflects the product owner’s hopes for what he/she thinks they can get out of the team (it’s just human nature). This is inevitably far beyond what the team is actually capable of. My rule of thumb? A team is typically capable of delivering about 1/3 of what a product owner asks for in a release. That’s not based on any metrics, its just an observation. However, more often than not, it seems to play out that way.
  • The team is immediately confronted with a mountain of work they can’t possibly achieve in the time allotted – even under the most optimistic circumstances. It’s their job to shatter the dreams of the product owner. Of course, strangling dreams is hard work. Naturally enough, the product owner doesn’t give up easy. They fight tooth and nail to retain any semblance of their dream.
  • After an hour, perhaps two, maybe even three or four (shudder), the battle is over.

I’m going to go out on a limb here and speculate that this is no one’s idea of a positive dynamic. But it seems to happen pretty often with agile projects. It sure doesn’t look like much fun. I’m pretty sure this isn’t in the Agile Manifesto. So how do we avoid this kind of trauma?

  • The product owner needs to be a central part of the team. They need to live with the team, be passionate about the product, and witness to what a team does daily. Fail to engage in any of this and a product owner loses touch with the work the team does and loses the ability to gauge their capabilities. Doing all of this is hard. There’s a reason that the product owner is the toughest job in Scrum.
  • The team needs to embrace their product owner as an equal member of the team. You have to let them in. Work together. Let go of the roles and focus on the work.
  • Prepare for the release planning in advance. There is no reason for it to be a rude surprise. Spend time together grooming the backlog together. As a team.
  • Don’t cave to pressure from upper management. Behind every product owner is a slavering business with an insatiable desire for product. Ooh, did I just write that?

Release planning doesn’t have to be a nightmare. OK, in theory…


Failing Fast

August 6, 2014

IMG_2037

 

 

 

 

 

 

 

 

 

“Forget your perfect offering. There is a crack, a crack in everything. That’s how the light gets in.”
-Leonard Cohen

How’s that for a weird quote? I heard it the other day on the radio and it stuck in my head. It has a resonance for me that I just can’t seem to shake. You see, like most folks, I’m intimately familiar with imperfection. I’m faced with it in many of the projects I’m most passionate about: My writing, my career, my boat…

Yeah, I’m building a boat. Technically, it’s my second boat. I think just admitting that qualifies one as insane. The first boat was a mere 9 foot skiff I made for my daughters. It took me almost 3 years to complete it. I should probably mention that I have absolutely no woodworking skills. So after I finished the first one, I decided to build another. This second boat is just for me. Well, me and my brother actually. We’re building it together in his garage. We’re about a year into it so far and it’s coming along pretty well.

OK, honestly it’s a little early to tell. We make a lot of mistakes.

I don’t know what it is about working with wood, but any mistakes you make tend to jump right out at you. Of course, the bigger the project the more room there seems to be for error. I’m discovering that a 17 foot boat leaves lots of room for error. Cutting parts to shape is hard. Getting screws to bite and not strip. Glue everywhere. One false move with a power tool and there are splinters galore. The whole project really is just a glorious catastrophe waiting to happen.

If ever there were a case study in failure, this boat is it for me. Now that might sound terribly defeatist, but it’s not meant to. You see, I’ll finish this boat too, one way or another. It’s just that I’ve got a whole lot of failing to do in between now and the day I finally launch her.

Of course, given all this failing, it’s still pretty astonishing how slowly I manage to learn. For instance, I’m noticing that I don’t seem to give up my standard ways of learning, even in the face of overwhelming evidence that they are not paying dividends. I’m fairly sure I’m not alone in this behavior.

First there is my innate impatience to see quick results. This whole measure twice, cut once thing just doesn’t seem to come naturally. For some reason I’m always in a rush. I find it extraordinarily difficult to slow down and just take my time. Maybe it’s some american thing where we are just impatient with anything that impedes progress…No, I don’t buy that either. I think slowing down is really hard work. It takes discipline to slow down and treat things in a very thoughtful and conscientious manner.

Savoring the moment and appreciating how things feel in the moment is not something that just happens to you. You have to make time for it. I can show you all of the places on the boat where I rushed the job. The places where I tried to drive the screws in with a power drill (I drove them right through the panels – genius!). The areas where the wood split because I didn’t take the time to test the bend first. The evidence of my own impatience is writ large in the construction of this boat.

Do you want to know the really amazing part? I still keep rushing!

Scary. Did I mention that slowing down is hard?

Another area where I struggle to learn: working as a team. Working as a team is hard too. First you have to keep those you are working with in mind all the time.  That doesn’t come naturally at all for me. I’ve never really been a good team player. I grew up participating in individual sports like running, wrestling and weightlifting. I operate very well solo. Working as a team has been an alien experience. For example, when my brother and I are working on the boat, I often struggle to figure out what he can do to help. I’ve seen this on software development teams too. Ask a developer what needs to be done, and you will get a detailed list of all of the work that remains. No problem. Ask that same developer how someone else can help them get that work done, and often you will get a blank look. When you are not accustomed to working on a team, it’s hard to picture what teamwork looks like.

To make matters worse, my brother and I have different skill levels when it comes to woodworking. This means that sometimes I need to take the time to show my brother how to do things (or vice versa). I find that hard to do when I’m rushing to get things done (see above). But without taking that time to show him how to do things, I lose the benefit of his help. I lose the teamwork. I’m finding that teamwork takes some serious patience. Ultimately I know I will go faster if both my brother and I can work at the same level, but that means initially I will have to slow down to achieve that goal. Slowing down to go faster.

I’m very lucky to have someone to like my brother to put up with all my mistakes. In a peculiar way, building a boat with him is teaching me a lot about software development. That’s probably good, because God knows if we’re ever going to finish that boat.


Culture Club

August 6, 2014

pablo-picasso-don-quixote

 

 

 

 

 

 

Recently I’ve been challenged by the question, “Can you change culture?” I think this is pretty common for folks who work in large organizations. The question of culture and how it blocks or allows us to get things done is a thorny one. There seem to be two opposing schools of thought in the agile community on the subject of culture:

  1. You can’t change culture, you can only adapt to it (customize your process to fit)
  2. You can change culture (through influence, good looks, and the right practices)

Of course, perhaps the first question is, “What is this culture thing anyway?” Most definitions of culture are terribly vague and in my opinion not especially useful (although, couched in the delightfully hand-wavy  terms of corporate sociology, they usually sound very smart). Just for giggles, here are some definitions:

  • Culture is the accepted norms of behavior for a group
  • Culture is the collection of social contracts that a group depends on
  • Culture is how we treat each other
  • Culture = people

I forget where I saw that last definition (Tobias Mayer?), but it’s probably my favorite of the bunch. You see often culture is used in conversation to hide or excuse problems with people. It’s kind of like referring to employees as “resources” (Ooh! Now I can be that irritating agile guy who corrects people’s terminology! A word to the wise: Don’t be that guy). So where was I? Oh yeah, culture. So here’s the deal, I don’t like the term culture because it’s just too damn vague. Often times I get a lot more clarity if I use more specific terms to describe the problem. For example:

  • Our culture won’t permit us to do that = Manager X won’t permit us to do that
  • Our culture only supports hierarchical decision making = Bob likes to make all the decisions

Once I take the time to replace culture with more specific terms (Who, What, Where, When, Why), I usually find that the problem feels more manageable to me. More human and less onerous. On the one hand, “Our culture” is vague and hard to put strategy around. On the other, influencing Manager X is a simple exercise in winning friends and influencing people. That’s something I know how to do. People I can work with. Culture…not so much.

So if you accept this definition of culture (culture = people), then your ability to change the culture directly depends on your ability to influence people. That’s Dale Carnegie stuff. It’s not easy, but it can be done – one person at a time. When you are in a small company, that’s not too daunting a challenge – win a handful of people over and you are done. However, in a large company, it’s quite a different matter. In a large company you have to win over hundreds or even (heaven forbid) thousands. That’s a very different challenge – and it’s an order of manure…uh…magnitude more difficult. It can be done, but it’s a long term challenge that may take years – and while some strategies you will use with larger groups are the same as for small groups, often they can be very different. If you are accustomed to trying to change the culture in small companies, you almost have to learn a completely new language in order to try and change the culture at large companies.

But seriously, can you REALLY change culture in big companies? One way to answer this question is to look for examples of successful culture change within large corporations. There are one or two that I can think of:

  1. Richard Semler, SEMCO (As described in the book, “Maverick”)
  2. James Collins, “Good to Great” (A series of stories of dramatic corporate change)

If you accept these stories as true, then the answer must be that culture change can indeed happen. But perhaps you are an inveterate cynic (like me) and don’t believe everything you read in books. Maybe culture change is just something that people with extraordinary power can achieve (like CEOs). Then what hope do those of us who exist much lower down in the corporate hierarchy have? Two thoughts:

  1. Sometimes we have to accept that our sphere of influence is limited. Those limitations are things that are very real like geography. You may only be able to influence folks that you work with in your particular office (which makes a lot of sense). Influencing the rest of the organization is going to be much harder. This has nothing to do with culture and everything to do with constraints. Start small, gather your wins, and grow.
  2. You can just wait. Bide your time. Sometimes you have to wait for the right opportunity. How long should you wait? I don’t know. There is an element of patience when dealing with culture change. You need a lot of patience. Focus, prioritize, and be ready. There’s nothing wrong with that approach.

OK Tom, what if I still don’t buy it. My company is HUGE and there is just no way that I can influence these clowns…er…people. No matter what happens, once an organization gets above a certain number (perhaps the Dunbar number) then it becomes extremely difficult to change. So difficult in fact, that it’s just not worth fighting. If that really is the case (and in many cases it just may be), there really are two approaches:

It may be that there are kinds of change that will never be accepted within some organizations. However, usually, that is a relatively small set of invariants. There usually still remains a broad spectrum of change that can be introduced successfully. Just stay away from the hot buttons. Does it really matter that you introduce every single one of the 12 XP practices? Or would it be enough just to introduce a few (there is still some benefit gained). Can you bring change in small amounts rather than a huge batch? There is plenty of room for creativity in this sort of culture change.

In the end, even after all this, you may come to the conclusion that you can’t change the culture in big organizations. Maybe it’s just too hard. Perhaps you just don’t like Dale Carnegie. I don’t know. That may just be the way it is. If that ends up being the case for you, then saddle up Rozinante. Grab Sancho, and go find some more giants to tilt at. The world is full of them.


Culture Eats Impediments Too

March 3, 2014

hippo

I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.

Some signs you may have a problem introducing a change:

  • Taking action requires getting permission (this is straight from Pawel)
  • Action can’t be taken because projects are too important to risk
  • Only certain people can take action

I have a great example of this happening recently: The group I was with raised an impediment. I had a nifty new impediment display that I wanted to try out (impediments displayed on a big monitor that everyone in the company could see). I sat down to add the impediment to the list, and then I had to pause…because the impediment called out something that might upset some folks. It might REALLY upset some people. I ended up not displaying that impediment. Why not? Was I just a chump? Was I too scared to make an impediment visible? Maybe…

Or perhaps I understood the culture well enough to know that certain things were acceptable to display as impediments, and others weren’t. That’s just the way it works at some places.

The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.

 


Prerequisites for a X-Functional Team

November 22, 2013

nfl_u_bironas_300

I have a confession to make: I’m a huge football fan.

Every Sunday you can find me glued to the TV watching the high drama we call the NFL play out like gladiators in a Roman coliseum. It’s a gorgeous spectacle. The other day I was watching a game where the team was punting to the Hawks. The kicker, a specialist if there ever was one, dispatched the kick and then all hell broke loose.

The receiver, some professional 800 pound wrecking machine of a human being, caught the ball and proceeded to mow his way down the field. This guy was in Beast Mode. He was flinging 300 pound linemen left and right like rag dolls. In short order it was apparent that there was only one thing left between him and the goal line: our hero, the kicker.

The kicker, wearing only one shoe. The tiny little kicker, with shoulder pads that are probably best described as vestigial. This one scrawny guy was the only thing in between a rip-snorting, fire-breathing, brahma bull and the goal.

Right before he tried to tackle the coming human freight train I remember thinking, “You poor bastard.” As you would expect, he was cast aside by the rampaging helmeted monster like a toy.

After the play, the kicker got up, bleeding and concussed and headed for the sideline. You couldn’t blame the guy for thinking, this ain’t my job. I don’t get paid enough for this crap.

But he did it anyway. Let’s face it, anyone can tackle somebody. All you have to do is spread your arms wide and kiss your ass goodbye. We all have the tools required to do that.

And that’s what makes cross functional teams work. On a cross functional team we all have a minimum set of skills that we can all use. Like our kicker, we aren’t all equally skilled at using them, but we can do it in a pinch. If we have too.

The more I thought about that, the more I realized that this is just as applicable to software teams as for football. In order for a truly cross functional team to work, there must be a common underlying set of skills that is shared by every single member of the team. No exceptions. None.

Any member of a truly cross functional software development team must be able to do the following on demand:

  1. Pull the latest version of the code from the code repository
  2. Build the code from scratch
  3. Deploy and configure the application
  4. Build the tests
  5. Configure the tests
  6. Run the tests and be able to understand the results

Every single member of the team needs to be able to do all of the above. Everyone. That means:

  1. The project manager
  2. The developers
  3. The QA
  4. The Release Engineer
  5. The UI guy
  6. The Documentation specialist
  7. The Business analyst
  8. The Product Manager
  9. Did I mention everyone?

You don’t have to know how the code works. You don’t even have to know how to program (although that helps). Each of the tasks I listed is entirely mechanical. You could train a rat to do any of those tasks (with enough food pellets). They are the bare minimum necessary to contribute to helping a cross functional software development team get their work done.

You may even use tools to help make each of these steps nearly automatic (if you are on an especially bright team). That way you minimize the training required for someone to join the team and help you out. You automate the overhead so that any idiot can build the product and run the tests. This makes it possible for others to help you. It lowers the barriers to entry and creates the opportunity for others in your team to help you out.

If you can’t do these things, then you have barriers to helping each other out. If you don’t even know how to build the code, then there isn’t even an opportunity for you to contribute. These things are basic. No, they’re even more important than that, they are primitive. Learning these fundamentals should be part of joining the team for everyone.

So, is your team cross functional according to this definition?


The Agile Experience and The 5 Rules of Accelerated Learning

October 4, 2013

Five_rings

How do you experience Agile?

I’m not talking about the process, the rituals, or the artifacts. I’m certainly not asking you to regurgitate any of the usual Agile jargon. I’m talking about how it makes you feel. It usually starts with a question like, “Are you using Agile?” and I catch myself saying things like, “Yes, we do scrum.” Answers like that probably miss the point on a very fundamental level. What I think some people are really asking is, “What does it feel like to work at your company.” What is the experience like?

All too often, that’s as far as the conversation goes. I find myself frustrated by that. You see, I want people who come to work with me to have an experience that is different from the traditional corporate environment. I want them to feel differently. I want them to interact differently. You see, I think a different experience was behind much of the promise of agile methods. Agile provides this groovy toolbox of collaborative methods in order to help change the way working together feels. It promises to change the experience of work.

Just using Agile methods won’t necessarily generate a different experience. You can just go through the motions and not change the feeling of the experience at all. A planning meeting where everyone is seated at a conference table falling asleep in front of some task board on a projector feels a whole lot different from a planning meeting with everyone standing up talking and trading sticky notes back and forth. Its a visceral difference in the experience. You can call them both agile planning meetings, but one feels very different from the other. I see this all the time in daily stand up meetings. Poorly handled stand up meetings usually have all the life and energy of a funeral.

How do we change that experience?

That’s where Willem and Diana Larsen have some interesting ideas. They are working on a book enigmatically entitled, Name This Book that among other things introduces the Five Rules of Accelerated Learning. These rules offer a foundation for techniques that we can use with our teams to enrich the kind learning they have to do every day. These are ideas for improving the learning experience along 5 different dimensions: Alive, Fluency, Signal, Focus, Setting. Each of these dimensions interacts to contribute to the power and effectiveness of the learning experience.

Willem puts it best “I always recommend thinking of the Five Rules as two Values (Alive and Fluency) and three Principles /Tools (Signal, Focus, Setting), and listing them in a consistent order for that purpose (Alive, Fluency, Signal, Focus, Setting). This also makes them easier to recall for new folks”

They also have a smaller 99 cent book that just gives a summary of the Five Rules that you can find here: https://leanpub.com/fiverules. If you are just looking for a quick intro, this is where you could start.

In brief, here are the rules:

Alive

This is about the feeling of energy in an experience. As Willem and Diana put it, this is that feeling of having a peak experience. That moment of total engagement or achieving flow. There is an element of playfulness to it. We want to maximize this feeling in order to enhance  learning.

Fluency

This is the assessment of our skill at actually doing something. In order to provide the right learning experience, we need to assess the fluency of the learners, and perhaps more importantly, create simulations that challenge and allow them to exercise or experience that skill.

Signal

Changing the signal is about amplifying the message so that the learner is most likely to receive it. This can involve reducing distractions, increasing repetition, upping the emotion – using every tool at your disposal to get their attention.

Focus

Keeping learning going requires steadily adjusting the focus so that you accomodate the varying attention levels of your audience. This involves changing the pace, breaking things up and adjusting based on the overall energy level (see aliveness).

Setting

Altering the setting is creating the environment that promotes learning. It’s all about an environment that enhances or amplifies the learning that takes place.

Putting the 5 Rules to Use

First, if you are interested in this sort of stuff,  you should check out their book. They do a fabulous job of laying out all of the rules and putting them in context. Second, if you have a chance, you should definitely catch a presentation on the topic by either Willem or Diana. They are two very engaging speakers and I’ve heard them speak on this subject – it’s worth it. Finally, even if you don’t do any of the above, it’s interesting to note that Willem has put all of this theory into action with Language Hunters – a learning group dedicated to using these techniques to help with teaching and learning rare languages. Check them out.

So obviously, I’m a big fan of their work. The question is: how can you and I apply it? Here are a few places I’ve tried:

Teaching (training, workshops, presentations)

So, I had an experience not very long ago where I saw these ideas in action. It just happened that I was delivering a very interactive workshop at XP2013. I asked everyone in the room to help me generate what I like to think of as an idea cloud at the beginning of the workshop. The experience was like this: as soon as you entered the room, I was there saying hello and inviting you to help me add ideas on note cards to a wall. My goal was to convey a feeling of “Come play with me!” Soon we had a large crowd of people all standing in front of a wall adding ideas. I was jumping in and out of the group, collecting ideas, offering new ones, handing out note cards and generally dancing like a madman (it all felt a bit maniacal). I had music playing, people were talking and the room got pretty noisy pretty quickly. They were competing for space at the wall, helping me facilitate, and generally helping to contribute to a wonderful atmosphere of barely controlled chaos. Folks seemed to be pretty deeply engaged. They were showing me ideas I had never seen before, and I even managed to toss a few originals into the mix. We were teaching each other.

I remember turning around at a key moment to talk to the group. I had my back to the wall and I was surrounded by about 40 people all standing about two feet away and looking right at me. Staring into this sea of expectant faces, I had a moment of panic (it was a little intimidating). I put up my hands and almost reflexively said, “OK everybody, let’s sit down.”

Immediately I realized I’d just made a huge mistake.

matador

All at once I could feel the energy drain out of the crowd. There was almost a palpable sense of disappointment as people searched for a chair. I could almost feel the energy in the room go “Poof!” and disappear. It took me another 10 minutes to get everyone back up on their feet and fully engaged again. The rest of the workshop went great, but that moment where everyone sat down made a huge impression on me. I realized that I had created a critical element of aliveness and engagement that felt almost magical (people told me afterward that they thought it was one of the most energizing workshops they had attended). I think I had managed, for a brief time, to create that alive learning experience in a group of people. Referring back to the 5 Rules, perhaps I had a combination of focus, aliveness, and setting (3 of the 5 rules!) working for the group.

Interviewing

I wrote about an experience with interviewing recently in Bob the Naked Agilist. In that interview I introduced a drawing and asked the participants in the interview to help me clothe a hypothetical Agilist with the things that they would need to survive out in the corporate jungle. It swiftly turned into a very engaging and dynamic dialog where we were generating ideas together and asking each other spontaneous questions about the things we thought were important for our work. For me, it felt like the conversation opened up.

Compared to the traditional interview where we all sit around the table in combative postures and quiz each other, this felt like we were collaborating on building something together. The energy was completely different (and honestly, quite refreshing compared to the usual drudgery of an interview). All I did was walk up to a white board and start drawing pictures. Next time, I’m going to get everyone up at that white board drawing too. I want people to experience interviews differently.

Dear God I must be nuts.

Fire Writing

So I managed to use the aliveness, focus and signal rules to improve the interview. Now that I think of it, an interview is a very intense learning experience for everyone. It makes a lot of sense to try to improve them.

Meetings

One of the things that I think we have done particularly well in the Agile community is rethinking the way meetings are run. For instance, I believe that when I’m doing a meeting well, there are rarely any projectors or PPTs. The walls are usually completely covered with sticky notes, diagrams and all in a bewildering array of handwriting. That’s because everyone in the room has been contributing. Chairs are kicked out of the way against the wall. Tables are piled high with collaboration tools: sticky notes, sharpies, and stickers. None of this is particularly new or extraordinary – these are all the attributes of what I have come to expect from any experienced facilitator when they are dealing with an Agile team. It could be a retrospective, or a planning meeting – it really doesn’t matter. Why is this important? Because we have a body of techniques that makes our meetings feel distinctly different from the usual meeting. The experience is manifestly different.

Coaching

Recently I was working with a team and just happened to be observing one of their stand up meetings. As a coach I was watching and waiting to see how the team dynamic would play out. As I stood there quietly, it occurred to me that I could use the 5 rules to help me asses the outward experience of the team as an outsider. I quickly jotted the 5 rules down in my notebook, and then asked myself some questions: Does this meeting feel Alive? Joe over there is bouncing up and down on the balls of his feet over there. There’s a lot of energy pent up there. Either he has to go to the bathroom or he has something he really wants to say. Nobody else is moving. What’s up with that? Are these people alive or in zombie mode?

Then I switched to the next rule: signal. What message is this person trying to send. Is it clear enough that I can understand it as an outsider or is it encoded in jargon. How are others receiving his message? Is he mumbling? Why?

For each rule I discovered a lot of interesting questions that were open for me to ask. After the team finished I pulled them together for a quick huddle and shared the 5 rules model with them. As I did so, I offered a few questions that I felt would offer seed opportunities for further exploration or introspection. With the judicious use of a few funny examples from my own past, I set the hook. What would you change to increase the liveliness of the meeting? How would you change the environment to improve the learning that takes place? What could you do to improve focus?

So the 5 rules served both as a source for assessment as well as a roadmap for improvement.

Where next?

These days I ask myself, does this feel different? Is this the experience I was hoping to create? Sometimes the answer is no. When that happens, I feel like what Willem and Diana have given us in the Five Rules of Accelerated Learning is a set of strategies I can use to create that new experience.


Follow

Get every new post delivered to your Inbox.

Join 535 other followers