The Agile Gymnasium

January 12, 2016


I used to be a weightlifter. All through college, and for much of my adult life I have been in gyms exercising in one form or another. I’ve had some modest success. The experience of joining a gym goes along some standard lines. You’ve probably done it yourself. You show up and they take you around the facility and orient you to the equipment. They may even go so far as to give you some very basic training. You get an introduction to circuit training and then they slap you on the butt and tell you to “go be awesome!” You can record your exercise sessions on this little card over here…

That’s pretty much it.

As you might imagine, the success rate with that sort of system is fairly low. A lot of people never come back (although many continue to pay their monthly dues). Those who do come back typically have no idea what modern exercise programming looks like and simply go through the motions: they ride the stair master, do a few sit-ups, and maybe do some curls. That sort of exercise has some marginal utility – you get some small amount of aerobic benefit, but it’s a far cry from exercising a meaningful percentage of most people’s potential.

Most people stop there, but there are a few who have a more ambitious goal in mind. They may be trying to improve their tennis game with better conditioning. They may be looking to build massive pectoral muscles (like most teenage boys). They may be trying to maintain their conditioning in the off season of their sport, perhaps like cycling in the winter. In other words, the purpose of their exercise is to improve their performance in some sort of real world scenario.

I’d like to pause for a moment here. I was listening to a discussion with some folks who owned their own gym and they had an interesting model. It had three tiers to it:

  1. Gym Work: Work in the gym is not like the real world at all. It is where you go to prepare for the real world. The gym is a safe place to work to the point of failure (that’s important) and to learn.
  2. Expeditions: Expeditions are adventures in the real world that are guided by a coach. So it is real world experience, but with someone there to guide you and help if you fail.
  3. The Real World: This is where it all comes together. Ultimately, this is where the training in the Gym and the experience in the expeditions pays off in terms of improved performance.

As a model for the role of training for high performance, I thought this made a lot of sense. There was one more thing that they added to this: They were capturing data on the entire group’s performance and analyzing it in order to provide better training for individuals in the future!

So when you join the gym, you use a training program that is similar to what others in the gym are using. Your performance of that program is measured and metrics across the entire population training in the gym are measured. Then experimental changes are made to the training program and their benefit (or lack thereof) is measured across the group. Gradually their training program improves over time. But the training isn’t just tested in the gym. They also track the performance of their members when they go on expeditions. This measures the effectiveness of their training program in the real world.

OK, enough about this gym. What if we could use the same metaphor for the way we train our development teams? Training would be a weekly thing. Something where you go in for training on a periodic basis to firm up your skills. There might be repetitions (pair programming, mob programming, etc.) and there might be coaching (coaching circles, etc.) and there might be someone who is coordinating the training program and measuring the performance across the entire group of trainees.

There could be expeditions from time to time. Hackathons where people get to try out what they have learned in the gym out in the real world. You know: build a real project, maybe deliver something over a weekend. Test out your mastery of your skills in the real world – with a coach there if you need it.

Then there is game day – the real world. You take what you have learned and join a team. You get to flex your massive coding and collaboration muscles and help build something challenging – something amazing. What a great model for development! But I’m not done yet…

Let’s take this model, we’ll call it the “gymnasium model”, and apply it to something like Certified Scrum Master Training. Right now, there is two days of class time and exercises and then they slap the CSM on you and send the newly minted CSM out into the world. It’s a hauntingly similar scenario to the average person’s experience at the Gym: welcome to scrum, now “go be awesome!” Maybe you do a few sprints, do a few standups and off you go. That’s about as agile as most people get. Seriously. You get some marginal benefit, but that’s about it. It could be so much more.

But what if we did things differently? What if instead of signing up for a 2 day class, you were to join an Agile gym. Maybe twice each week you go into the gym to “work out”. A coach would give you a workout, perhaps something like this:

1. Dysfunctional Standup
2. 3 Reps in the coaching dojo
3. 2 Sets of mob programming
4. 2 reps of code katas
5. 1 cool down with a retrospective

That’s just a sample workout. The Agile Gym is a safe place to try out new skills and to push ourselves. The coach would be responsible for measuring the effectiveness of the workout and modifying it over time. Experimenting with new techniques and combinations of methods and evaluating the outcomes. Of course, this is just training in the gym. From time to time we are going to need to test our our competence in the real world. The coach would provide some guided expeditions (perhaps twice a month). For example:

1. Participating in a Hackathon
2. Participating in a Startup Weekend
3. Participating in a Maker Fair

These are events in the real world that are important places to evaluate the effectiveness of our training in the gym. If our coding skills have improved, then we should do well at these events and build confidence in our ability to use our newfound skills in the real world. Speaking of the real world, hopefully now we would see the agile behaviors that we have practiced being manifested in useful ways in the actual projects that we are running from day to day. Our collaboration skills should be tight, our planning impeccable, our retrospectives revealing. And if we find any weak areas, then it is back to the gym for more training.

In this model, the gym is always open. You actually practice your skills and see improvement. What an amazing way to learn about agile!

It’s not a bad model really. Actually, it’s a really darn good one. Who wants to start a gym?

Announcing The Swarming Development Method

October 6, 2014


By now, you’ve probably figured out that I’m laying out all the guidance for using Swarming as a legitimate, full-fledged, Agile method. It looks like this:


There you have it. A complete method for swarming. Wrap it up and ship it.

“But wait!” you say, “You’re not a real methodologist, your just some guy with a blog!” You are absolutely right. What gives me the right to propose a new agile methodology? What kind of egomaniac thinks he can just pop up with a completely new method of team development? Well, actually, it’s not that new. I pulled a lot of the material from a variety of existing sources. I copied the format for the Values and the principles from the Agile Manifesto. Nothing here is all that original. After all, if I’m right, bugs have been doing this stuff without the benefit of my genius for millions of years. Why would I do this?

First, I’d like to state this as emphatically as I can: ANYBODY CAN DO THIS! We can all be copying methods and tweaking them – and we should. No real experience is required. After all, that’s how the guys who came up with Scrum, and Kanban, and XP did it. They copied ideas from Takeuchi and Nonaka, Ohno, Demming, Goldratt, and a whole bunch of others. We need to keep doing that – copying and stealing and mixing and removing bits until we find methods that work even better. Take this opportunity to make a methodology that is an expression of your beliefs. Heck, maybe it expresses the vision of your entire team…or company.

Secondly, there just aren’t enough methodologies out there. Having scrum taking over 80% of the agile project management ecosystem is really, really…boring. Ken Schwaber, one of the creators of Scrum, has always maintained that something better will come along one day. I’m sure that’s true, but it won’t happen unless we are creating a vibrant ecosystem of competing methods. Just having Scrum and Kanban isn’t enough.

So feel free to take this methodology – it’s yours. Run with it (careful, it’s pointy), copy it, break it, fix it, and for God’s sake, make something wonderful.

Moving Too Fast

August 23, 2011

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

May 15, 2011

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

April 30, 2011

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

April 22, 2011

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

April 20, 2011

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

December 18, 2010

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

December 17, 2010

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

November 7, 2010

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.