Stopping

The other day I was re-reading Robert Pirsig’s Zen and the Art of Motorcycle Maintenance. I was looking for a metaphor for quality used in the book that I remembered reading long ago. I found myself sucked into the book almost immediately and I stumbled across a quote that caught my attention.

Mountains should be climbed with as little effort as possible and without desire. The reality of your own nature should determine the speed. If you become restless, speed up. If you become winded, slow down. You climb the mountain in an equilibrium between restlessness and exhaustion. Then, when you are no longer thinking ahead, each footstep isn’t a means to an end but a unique event in itself.

This gave me pause. You see in software development, this kind of thinking is completely alien. Maybe that’s too broad a generalization, so let me refine that statement a bit: for me, that notion of equilibrium and balance is foreign. You could say it’s all the same. I’ve grown up in the software business. I know how to work all night to hit a deadline, to “sprint” toward a goal. I’ve been doing it for 20 years.

And boy, sometimes I get tired. Really tired.

I once told someone that I have no right to preach the merits of sustainable pace to anyone – because I can’t seem to do it myself. Recently, in a rather dramatic turn of events, I collapsed just prior to a speaking engagement. The pace, the pressure, and the travel just added up to too much. Fortunately, that’s all it appears to have been – stress. Thank God.

But I was left with a compelling desire to…sit still for a while.

It occurred to me that the mountain wasn’t going to go anywhere, so I might as well take a break.

The really curious thing was that I was still restless. I had just been delivered one of life’s little telegrams with the message, “Slow down or die.” I figured most rational people would pay some heed to a message like this. Apparently I’m not a member of that clique (the rational ones). Now this doesn’t come as a remarkable surprise to me, but I did face this revelation with some curiosity.

The question is, why the hell can’t I slow down? Maybe its the business I’m in. Let’s face it: software development is all about going faster. Call it Scrum, call it XP, shucks I really don’t care what you call it. The bottom line is that it’s all about delivering value faster. Of course value is also what Pirsig’s book is about, the subtitle being, an Inquiry into Values. So what are my values? Is delivering fast one of them?

If I look at the agile manifesto, a document that can be fairly said to have influenced my work life quite substantially, I read the following:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Well, there is no reference to going faster that I can read into that. Now you might argue that the principles might state otherwise, but on the face of it, the values don’t have anything to say about how fast we delivery software.

Of course with all the running about that I tend to do, it may just be that I’m a lot lower down on this metaphorical mountain than I had previously thought. You see, I’m not sure I’ve had much practice at this stopping game.

Maybe it’s like this: when you learn how to ride a bike, the first thing you learn to do is learn how to get going. How to get started. How to initiate the process. Once we do that then we need to learn how to keep it going. How to sustain our progress and navigate through unexpected turns. Finally, we need to learn how to stop. It could be a gentle glide or a power slide, but stopping is just as important as starting.

Frequently I see teams that in some very important ways seem to have mastered the first two steps, but seem to struggle when it’s time to stop. There are all kinds of reasons to stop when working on a team. For instance:

1) at the end of the release

2) at the end of the day

3) at the end of the sprint

4) when something goes wrong or breaks

5) when someone notices something out of the ordinary

6) when the team is done

The funny thing is, like a lot of things that I observe on teams, I see these reasons for stopping in myself too (I have a list of things to stop that is very nearly ten times that long). So I have become very curious about this “stopping” thing. Frankly, I find it all a bit terrifying. It feels risky to think about stopping. So I’m approaching it with due caution. Dipping my toe in the slow pool – starting with some meditation.

So, I take the time to stop and do nothing a few times a day. I just sit there and listen to the hum of the world whizzing by. I’ll be honest, I can’t tolerate it very long before I am sucked back into the frenetic pace of “the game”. It’s an experiment. An attempt to practice that crazy stopping thing. I have to admit it’s kind of nice…sometimes.

So, that’s where I’m at. This post has meandered and digressed and gone nowhere in particular. That feels about right. This is probably a good place to stop.

Developing the Impediments Game – Iteration 2

This is a continuation of my last post where I was endeavoring to create a board game that allows players to simulate the trade-offs with dealing (or not) with impediments.

This time around I wanted to add a new element to the gameplay: risk

So how do risks work? Well, a risk is something that you can decide to address at any time, so you can pull one from the deck at any turn. After all, risk is always there, right? If you pull a risk from the deck, you will find it has a cost to mitigate the risk. That cost is expressed in the number of spaces you give up in order to “buy” or mitigate the risk. What is the benefit of mitigating a risk you ask? Well, if you have a risk that you have paid to mitigate, then you can avoid the next impediment that comes along. In effect, you are taking out insurance against a future impediment. My view is that there is a risk lifecycle where:

An unmitigated risk can become an impediment which can (perhaps) become a lesson learned

It is a progression of sorts that I believe takes place in the project management world. Fail to deal with the risk, and you are more likely to encounter an impediment. Fail to deal with an impediment, and you now have an opportunity to suffer (and hopefully learn).

I also thought that aside from the role of the dice, there ought to be an additional level of uncertainty. Everybody knows that bad things can happen on projects, right? Major setbacks can come out of nowhere. So I borrowed a notion from the game, “Chutes and Ladders” and created “slides” where a team could slide backwards on the project and lose ground if they just happen to land on the wrong space.

The “slides” are the black bars on the board that connect two spaces (OK, I stole some hair ribbons from my daughter).

OK, so how does this actually play out in practice? Well, once again I started with my two players: this time it was Green and Red. Red would take a strategy of addressing risk, and Green would take the strategy of ignoring risk and simply dealing with impediments. Here’s how each turn of play worked:

1. Roll the dice to see how far you advance
2. Roll the dice again to see if you encounter an impediment (you found an impediment if you roll 1-3 otherwise you dodge the bullet) Take an impediment card if the roll dictates
3. Optionally, take a risk card

On the next roll for advancement you get to do one of three things:

1. If you have an impediment card you must subtract the impediment from the roll in order to “pay the impediment tax” and move on. This can take more than one roll (causing you to lose multiple turns).
2. If you have a risk card, you can pay for the risk card before moving on. Again, you subtract the value on the card from your roll. The practical cost is that you lose turns while you address the risk.
3. If you don’t have an impediment to deal with (Lucky you!) or a risk to mitigate (eat your veggies!) then you are free to advance further on the board.
4. If you have a previous risk card that you have purchased, you can use it to skip paying for an impediment you have discovered.

So how did this all play out? Well, the player (Red) that took the strategy of paying for risk up front. Sure enough, they started off slow, but then they raced around the board, and even with a few unfortunate slips on my “slides” they still managed to easily outpaced the Green player and won the game. Lesson? Address your risks early and you will avoid future impediments, but are still subject to the vagaries of project circumstance.

OK, so I’m feeling a lot better about the game now. This second iteration was pretty interesting. It’s not quite so trivial and seems to allow (me) to explore some interesting trade-offs in risk and impediment management. Now, I’ll know I have something great on my hands if one of my kids walks by and offers to play. Who wants to play? I’ve got a few more ideas, but I’ll save those for iteration 3.

Warming Up for Deliberate Practice

I think often that people really appreciate the value of practice, however they find it really hard to actually do. I’m like that, I fully understand the merits of practice and the benefits it brings, but I absolutely hate to do it. I suspect there are a lot of people like that. In fact Anders Ericsson named the four essential qualities of practice and the final one on the list is:

“Practice isn’t much fun.”

No wonder people don’t like to practice! It’s a grind. It’s hard work. It puts you in a place where you fail. Why would anybody practice under those conditions?

While doing my research on practice I came across an interesting book on music practice called “The Art of Practice” When I cracked the cover I was quite surprised to discover that a good portion of the book was given over to the discussion of how to prepare for practice before the practicing even starts. That was a revelation to me. You mean there are ways we can prepare ourselves for practice?

That got me thinking about how I might prepare to practice things that are important to me. Take writing for example: sometimes I’m able to be very prolific, writing with relative ease. Other times it’s a relentless slog. What do I do to prepare myself to write? Short answer? Absolutely nothing! Does drinking count? Hey, either the magic is there or it isn’t, right?

Well what if I were to treat my writing more like practice and less like some fickle magical process that I have no control over? What would preparing for practice look like? Here are a few ideas I’m trying out now:

1. Set the location. Rather than try to write while I’m sitting in front of the TV (a recipe for almost guaranteed failure) I’m only going to write in my office.
2. Set the tone. I’m going to crank up iTunes whenever I write. I’ve discovered that I feel much more productive with certain kinds of music. It really helps. I don’t try and explain it, I just turn the dial to eleven and groove to my SuperTramp. According to my wife, SuperTramp doesn’t work for her. You’ve been warned. Learn from my example and buy some earbuds.
3. Do warm ups. Your going to laugh, but I’ve started using a typing tutor. Here’s my theory: Writing means typing. typing requires some dexterity and that dexterity requires some warming up. If the fingers are ready, then the brain might just be too.
4. Time box it. I will only commit to writing in short bursts. Right now I’m using pomodoro’s. If that doesn’t feel right, I might use (10+2)*5 instead. The idea is to lower the threshold of commitment for myself. I want to take what is often a too daunting task and turn it into something that is easily approachable and achievable.

That’s what I’ve done so far. Here are some additional items that I’m considering adding to my writing warmup repertoire as well (in those outlined above don’t do the trick):

1. Going for a brisk walk before writing.
2. Meditation
3. Hand stretches – don’t want to aggravate the ol’ carpal tunnel now do we?
4. Reading a short story or poem before starting to “prime the pump”

I’m sure this is well explored territory for writers. The idea is that using these strategies I can better prepare myself for the practice that I’m engaged in (in this case, writing). There are a lot of other practice areas that I bet you could apply warm up strategies to. Some examples:

1. Coding
2. Testing
3. Facilitation
4. Public speaking
5. Conflict Management

I’m pretty sure this is just a tiny start. Pick anything that you can practice and I’m sure there is a set of warm up routines that you can use to help make the practice easier to engage in. In a very real sense, knowing that real deliberate practice is hard shouldn’t scare us away from it. We need to prepare ourselves for a good practice session so that we can succeed.

I’ll make one other observation on the results of incorporating this warm up into my writing practice: my writing exercise has become exhausting work. That’s another common attribute of deliberate practice – it’s exhausting. You can’t keep it up for long. I think the warmup helps me get myself into a fairly high state of performance before I begin the practice. I’m already going 100 miles an hour when I cross the starting line rather than 25. I start practicing closer to the peak of my strength, rather than still trying to warm up. Give me 20 or thirty minutes of non-stop hammering away at the keyboard and I’m starting to get tired. Really tired. After an hour I’m totally wasted. I don’t mind. I seem to be extremely productive this way, so I’ll take it. Give it a try. You might find it makes a big difference.

A Quick Question About Practice

When you practice something in a disciplined way on occasion you may experience interruptions in your practice. I’m talking about the usual stuff that happens to everybody: you go on vacation for a week, you get a bad case of the flu and spend a week recovering, you are injured, life happens. So what happens when you return to your practice?

I know that in my case there is a very noticeable degradation in my performance. I lose ground and I have to spend time re-attaining the level of performance I once had prior to the interruption. Does that same phenomenon happen for scrum teams? Do we go away for Christmas break and come back into the office and…suck? Do we need some time to get ourselves back up to our prior competence levels? How does that work for you?

Leadership Practice #3 – Envisioning

If you are going to be a leader within an organization, then you need to be able to clearly communicate a compelling vision. The communication part is relatively easy to practice, but the vision part is worth practicing too.

There are two primary mechanisms for team communication that we can practice easily: Speech and Writing. We can practice speech by participating in groups like Toastmasters. We can practice our writing by using tools for text analysis and review.

Both mechanisms have the benefit of providing very rapid feedback and the feedback can contain lots of fine-grained detail. These are two critical attributes of practice. The feedback needs to be almost immediate(the sooner the better) and the feedback needs to be very detailed and specific so that we can fine tune our performance in a meaningful fashion.

When it comes to vision, one reliable place to start is with a clear statement of the problem you want to tackle. Coming up the problems is the easy part: ask the customer, ask the team, ask the project stakeholders. If you get that far you should have a list as long as your arm. Here’s a pro tip: keep those customer problems at the top of the list. Coming up with that list of problems is an important skill that can be honed and refined. There are places that you can go to look for problems that may be hiding in plain sight: recent communications from customers, defects, impediments. Keeping an updated list would be great way to practice.

Now unless you are very lucky, most of your problems will be vaguely stated and unclear. One of the best things to help you clarify the problem is to actually see it and experience it for yourself. Go to where the problem is. In the lean world this is often referred to as “Going to the Gemba.” The Gemba is the place where the work gets done.

Seeing for yourself will give you the rapid, high quality feedback you need to assess the nature of the problem. You can use techniques like The 5 Why’s to help get at the underlying causes of a problem. Often times the refined problem statement that you end up with looks nothing like the problem statement that you started with. Now these techniques are great for refining the problem statement, but what we are really after here is a vision – the possible solutions to the problem.

Fortunately there are a wealth of different brainstorming strategies that you can use to help discover a set of possible solutions. Here’s one technique that I use (taken with some minor modifications from the wonderful book Thinkertoys by Michael Michalko):

1. State the challenge
2. List your assumptions
3. Challenge your fundamental assumptions
4. Reverse each assumption
5. Record differing viewpoints that might be useful to you
6. Ask yourself how to accomplish each reversal

What you end up with at the end of this exercise is a list of potential solutions to your problem. Pick one. Now all you need to do is to communicate it!

The thing that I really want to convey is that many of these techniques can and should be practiced. With practice we will improve our communication techniques and our problem solving techniques. Put the two together and you have the recipe for someone who can communicate a compelling vision.

Passion vs. Practices

I’ve been doing a fair amount of reading lately on the topic of deliberate practice. There is a sizable body of literature emerging with a lot of interesting things to say about how we can improve the way we practice. As I’ve mentioned before, in the software development business, we’ve really become quite obsessed with the notion of practices and what they can do for our projects. All good stuff – there is a lot of valuable learning to be had there. However, what is it that drives us to practice?

I’ve seen a lot of teams adopt various and sundry practices. Sometimes it sticks and sometimes it doesn’t. Why is that? You introduce agile practices to one team and they take off like a rocket! And another team just keeps plugging along doing the same old stuff…now with iterations. Ugh! So why is it that one team seems to benefit and the other doesn’t? Often times I think it comes down to passion.

What is it that distinguishes a great pianist from a mediocre one? Passion! It’s that drive that keeps them constantly seeking to improve their skills, to push themselves and their teams. But what do we do when we coach these teams? Well, all too often we teach the practices without the passion.

Practice #2: Break It Down

How do you go about memorizing a poem? When I do it, I usually break it down into individual lines or phrases and memorize each one piece by piece. Then I put it all together as I build up a collection of individual lines that I’ve memorized. I suspect it works that way for a lot of things we learn. First we break it down into manageable chunks and then we master the smaller units one at time.

One of the things that coaches do in sports is analyze a skill that a player demonstrates. As they do so, they break it down into smaller components. It could be a batters swing that is broken down into the component arm movements, shoulder movements, head movements, hip rotation and foot placement. Overall, the player coordinates all of these pieces into a single unit that we see as the resulting swing, but to the experienced coach, they see much more. The coach may notice that part of the motion isn’t being executed properly. Then they call the players attention to the issue and perhaps they ask them to practice just that part of the motion in isolation. When they have mastered the motion in isolation, they bring it all back together again – hopefully with the end result of a home run hit on game day.

The same thing applies in weightlifting. You may find that you are stalled out in trying to make progress on one of your lifts. A coach will look at the way you perform the lift, and break it down into its component parts. Usually there are sticking points or weak areas in most people’s lifts. Typically a coach helps you identify these problem areas and recommends some exercises that isolate and address that weak area. So you practice just the top part of the lift, or perhaps just the lift off the chest – and you do it over and over again until you have mastered just that small portion of the overall exercise. Then you put it all together again to perform what is hopefully a successful lift.

Obviously it’s not hard to find examples of how we break things down into smaller pieces in order to refine or improve them. So how can we do this as a practice for our projects? First we have to understand what all the components are of the exercise we are planning to perform. Let’s take a scrum planning meeting for example. In a typical sprint planing meeting you might break it down into the following parts:

1. Pre-planning: This includes backlog preparation (Are the stories understandable? are they sized? Have they been prioritized?) Is the product owner ready to discuss and elaborate on the features? Has the planning meeting been scheduled? Is the agenda well defined?
2. Kicking off the meeting: Are the right people there? Is the agenda understood and mutually agreed upon? Are all the materials (sticky notes, whiteboards, etc.) necessary for facilitating the meeting present?
3. Reviewing the stories: Is the team asking questions? Is the product owner prepared to answer them? Are open issues and risks being captured from these conversations? Are new stories being created/deleted?
4. Designing: Is the team prepared with resources to support detailed planning? Are designs/code/tests being proposed? Are requests for additional information being satisfied? Are tasks being captured? Are the tasks getting sized?
5. Commitment: Is the team able to negotiate stories with the product owner? Are there caveats or exceptions that need to be noted? Areas for further exploration?
6. Wrap up: are the notes from the meeting posted someplace for reference later in the sprint? Are there any remaining issues or reservations that need to be addressed?

In broad terms, these are all the things that make up a planning meeting. Doing any one of these things poorly may have an adverse impact on the performance of the team later in the sprint. So there is some pressure to get this meeting right. Inevitably, if you are anything like me, you look at this list and wince a bit – you’re probably seeing things that you could improve. Bingo! That’s what we want to practice! Each of these things can be practiced in isolation.

So, unless we can convince ourselves that we run the perfect planning meeting, the perfect stand-up, the perfect retrospective, then we need to be practicing. All of these activities can be broken down into smaller parts – and it’s very likely that we all do some parts better than others. So let’s start practicing!

Practice #1 – Speed Drills

In Daniel Coyle’s book The Talent Code, he talks about the different ways that people practice that ultimately enable them to achieve extraordinary results. One the things that he mentions is that a key component of deliberate practice is to speed up or slow down the exercise at hand. He gives some great examples of musicians who are asked to play their music so slowly that the tune would not be recognizable by someone listening to them. Alternatively they are asked to play the music as fast as possible, sort of like a 33 RPM record being played at 78 RPM. What does manipulating the speed do for us? Well, for one thing, it highlights mistakes. Mistakes that you might miss playing at regular tempo may be more readily detected when the pace is dramatically slowed down or sped up.

This strategy is also used by athletes. Dramatically slowing down an exercise is used to detect and fix weaknesses in form. Speeding up the exercise is also used to force mistakes that might normally not occur. The idea is to use varying speed to highlight flaws in performance, which in turn enhances learning. It’s pretty apparent how these strategies apply in music and sports, but how could we apply variations in speed to coaching software teams? A few ideas:

1. Vary the length of the time boxes that you do development in. Yeah, you heard me right. Try dramatically shrinking the sprint length down to one week, one day, one hour. On the flip side, you could extend it – double it, triple it, quadruple the sprint duration. I know there are those who will try to convince you that this is a “bad thing”, but take it from me, you won’t go to hell for trying this. Shucks, try eliminating the sprints entirely (an infinite time box?).
2. Vary the length of some of the meetings. If your planning meetings are usually an hour, try all day. If they are 4 hours long, try 10 minutes. Is your stand-up meeting always 15 minutes? How about making it thirty seconds!
3. Speed up your retrospectives. What would happen if it was like a stream of consciousness game – each person has to blurt out the first thing that comes to mind to describe the sprint. If you don’t answer in 2 seconds then you move on to the next person.
4. How slowly can you write code? As an exercise you might find that changing your development pace will have interesting effects. Try out the Pomodoro technique.

Will you make mistakes if you do these things? Hell yes! That’s the point! If you want to learn you need to make mistakes. That means you and your team have to be able to change the variables (in this case: time) in order to push your boundaries and learn new things. What I’m talking about is experimenting with the constraints that you apply to yourself and your team. You can’t experiment like that without breaking a few rules. Let’s face it, if you don’t find anything useful by experimenting with the speed of different activities, you can always return to the status quo and blame me.

A Call to Practice

Recently I’ve been thinking a lot about the way that we practice our profession. It’s probably because my daughter recently started Taekwondo and I watch her practicing her Pumsae or Kata during each class. For her, this practice is very real and disciplined. There is very little ambiguity. I realize that in software development we use the term “practice” pretty loosely compared to a lot of other disciplines. It’s not that we don’t use the term often, in fact we seem to use it every chance we get. It’s as if by repeating the word “practice” we might somehow actually arrive at that professionalism that so many desire. Call it a form of magical thinking. My favorite term of practice is “Best practices”, which are often neither best nor practiced. Best practices belong to some sort of terminological hall of fame alongside “military intelligence” and “near miss”. So what exactly is this beast called practice?

Wikipedia defines practice as:

Practice is the act of rehearsing a behavior over and over, or engaging in an activity again and again, for the purpose of improving or mastering it.

That seems like a pretty good starting point. So, if I’ve got this right, practice is a preparatory event that we do over and over again in order to improve. What do we do that might qualify? Well, we have an entire pile of Agile practices that we might choose from:

• The planning game
• The daily stand-up
• The retrospective
• Test driven development
• Pair programming
• etc.

Those are all practices right? But how often do we really practice them? Once every two weeks you say? Every day? Perhaps. But that’s not what I’m asking. You see, I think there is a meaningful difference between just doing something and practicing something. To me, practice implies a kind of deliberate inquiry. There is an expectation that we will experiment when we engage in practice. We might slow things down in order to identify weak spots. Or we might stop at various points to review our state, whether it be our posture, our attitude, or even our mindset. Often when we practice there is a mentor or coach – someone whom we trust to critique our performance and help us to identify areas for improvement.

So given this new criteria, let me ask again. How often do you practice your agile techniques? Well, to be honest, if you are anything like me the answer is: not all that often. In fact, almost never. So what does that mean? Well, for me it means that although I do many of these practices over and over again, I rarely do them differently. Certainly not with a whole lot of introspection and review. So do you think those practices improve much as a result? Of course not.

Something tells me that I should get started. At least if I want to be really good at what I do. It turns out that for some of these practices I’m in luck. People have come up with activities like coding dojos where you can practice TDD and Pair programming. That’s fabulous, but what about the others: planning, stand-ups, and retrospectives? I have a few ideas, and I’m looking for more.

You see, in the end, I think we call a lot of things practices and what we really mean is “things we do”. We don’t really practice them, not in the disciplined sense. So this is my call to action: find the practice in what you do. Engage in real practice with thoughtful deliberation. Find the techniques that we can all practice, the metaphorical scales that we can use to improve our technique – to become the very best at what we do.