## Paired Mathematics

October 21, 2014

This evening my daughter was sitting at the kitchen table, pencil in hand, confronting a full page of math homework. It was one of those dreadfull rote exercises where one has to solve variations on the same problem over and over again until either the exercises are complete or the child expires from boredom. I remember those math exercises, usually associated with the dictum to “Show your work” – meaning that every exercise would take what seemed like hours to complete. I’m breaking out in a cold sweat just thinking about it.

Nobody I know really likes these sorts of homework assignments. I guess they are a rite of passage in grade school. Seeing the dread in her eyes, I sat down and proceeded to just start talking her through it. It was all the usual stuff. I’d ask questions, and talk about different ways of solving the problem. I’d check her results and ask more questions. And I’d challenge her to do silly things (Write your numbers as tiny as you can. Smaller. smaller!). I’d stop and ask her how she did it, because Dad doesn’t know the new math (I really don’t – today they use all sorts of fun strategies that I never learned as a kid). And of course there was a high five at the end.

And then it occurred to me that we were pair programming!

Well, pair problem solving anyway. She was driving – doing the work. I was navigating, validating her work and thinking about how to tackle the next challenge. We had a dialog going on where we questioned each other. It turns out we both tend to make the same kinds of silly mistakes: like father, like daughter. I just see those mistakes better because I’m navigating, and I’m more experienced.

It seems a very similar pattern to what we do when we are pair programming. Someone is working on the problem, the other is verifying, asking questions, looking ahead. And both are very focused. It’s very intense – requiring full concentration. But, depending on who it is, it can be playful too.

That sounds like a nice way to work. Better than individually grinding away. Of course programming and math problems from grade school are very different things. But it made me wonder, is a place where we all pair a more pleasant place?

## Failing Fast

August 6, 2014

“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.

## Stopping

January 28, 2013

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

January 17, 2012

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

October 14, 2011

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

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.