Moving Too Fast

Sometimes I move too fast. Maybe my attention span has been eroded by all of that tweeting and the never ending Facebook updates. I caught myself skimming through a book the other day just so that I could catch “the good parts” or find something that caught my eye. I realized that the book looked pretty good and I would probably enjoy sitting down and reading it. But I put it aside atop my ever growing pile of books I don’t have enough time to read. I’m just too busy right now. I’m sure I’m not alone. Everybody has too many things demanding their attention these days. Children, house, work, friends…and the list goes on. We are cursed with over-rich and over-stimulating lives.

Obviously this has been on my mind of late as I rush about pell-mell from one meeting to the next. I’m starting to get this nagging
feeling that If I could just find a way to slow down a bit, I might be a much more effective person. Well, that begs the question, “What would slowing down look like?” Are there some constructive things I could do to more effectively manage the pace of change in my admittedly all-too-agile life? You see, sometimes I’d rather be really good at just a few things than mediocre at a lot of things.

So what can we do? Here are a few ideas:

• Meditation: (Reflect) Take the time to reflect on what you are doing and how you are living
• Journaling: (Make it Visible) Start to capture the frantic pace. This is the first step toward bringing it under control
• Share it with others: (Transparency, Feedback) Share your experience with others and compare notes.
• Apply time management practices: (Prioritize) Adopt David Allen’s GTD, Personal Kanban, or perhaps the 7 Habits. Whatever works best for you.
• Measure: (Value) Use apps like Mercury App to rate your performance as you work to simplify and focus.
• Stop blogging…Hey! Where did that come from?

Or maybe we should just go over to zenhabits. I’ll let you know how it goes…

Paired Presentations

Often when people talk about public speaking, they are typically referring to an individual speaker. You don’t see much advice for people who present in pairs. When it works out, it is a beautiful thing where the whole is greater than the sum of the parts. When it fails, usually one speaker or the other takes the brunt of the damage. Here are some things that I recommend doing to insure a paired speaking engagement is successful:

1. Keep it simple and let each speaker own a portion of the presentation on his or her own. This avoids a situation where one person does all the talking and the other just chimes in from time to time. I feel that both speakers need to be perceived by the audience as experts in their own right. It doesn’t even have to be a large section of the presentation that you own – just some section that is all yours. I feel like this works well with people who are new to presenting – I can include them for whatever period they feel most comfortable. The anti-pattern here is where a second speaker in a pair only chimes in from time to time. This leaves them only offering the occasional comment. This can leave a perception of that second person as interrupting the first speaker.
2. Rehearse together – I know it’s hard to do, but you will both find weak areas in each other’s material. When I’m working on speaking material, I tend to get these ideas that I think are totally brilliant. We’re talking about genius stuff here. I can’t tell you how often I have shared this brilliant material with my partner only to discover that it falls completely flat. It must be an echo chamber in my skull (it is empty anyhow). Better to have a lame idea shot down by my partner than some poor unsuspecting audience. Often, the idea just needs refinement.
3. The 3 secrets to a good presentation with a partner? Support. Support. Support. Focus on the other person in your presentation. If they rock, then you both are very likely going to look brilliant. If they suck, you haven’t got a chance. Be there to encourage them when the practice doesn’t go well. Be there to provide ideas and alternatives. Be patient when they are struggling and time is running short. Make them feel welcome and like a key contributor.
4. Have a victory celebration afterward! It’s not often that I get to share a presentation with someone. Two people qualify as a party in my book, so go for it! Celebrate the accomplishment! It’s a big deal when two people can collaborate together successfully to provide a rich experience for an audience. Not many people can do it well.

I’m sure there is a lot of good advice for people who are co-presenting and I’d love to hear it. These are just a few things that I’ve learned by trial and error (a lot of the latter).

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.