The Dance
Getting to flow state with extreme programming practices
As an agile consultant working for, IBM, one of the largest tech companies in the world, I am accustomed to talking to people inside and outside of my company about what it means to build software using extreme programming, why I keep doing it and why I care at all.
“Agile can mean anything these days and there are so many different ways to build software,” I am often told, “what makes extreme programming so great?”
It’s the dancing.
I already know that if I tell people building software this way feels like dancing, I will get a stare and more questions. It really does feel like dancing…like exuberant, joyful dancing and singing with friends. Those friends include the software team and the users.
I have my reasons for drawing this comparison. Before I get to them, I’d like to tell you who I am and what I mean when I say extreme programming.
Atlassian => Pivotal => IBM
AFAIK, I’m the only person in the world with Atlassian, Pivotal and IBM on one resume. These are three companies that care deeply about software process and methodology. While there are marked differences between each, I’ve noticed that each company has recognized the importance of team work, open communication and transparency if you want to build great software.
My definition of extreme programming is rooted in Kent Beck’s “Extreme Programming Explained,” but rather than learning this from a book, I learned from practice, on the ground while working for the Pivotal Tracker team at Pivotal Labs. The Tracker team gave me a great perspective on how XP works on a product team. Tracker has tens (maybe hundreds) of thousands of users. It, along with Cloud Foundry are two great examples of XP working at scale on a product team rather than just on a small consulting project. People ask me all the time if this is something people use to build “real” software. I can safely say EMPHATIC YES.
Now that you know who I am and what I mean when I say XP, here are the reasons why I stay with it and why building software with it feels like joyful dancing.
An end to the blame game
“ARE YOU GOING TO HAVE THIS FINISHED BY FRIDAY.”
This type of sentence always makes me sad because, at the heart of it is someone who doesn’t understand the difference between having developers focus on freaking out about a fake date that was only ever a bad guess versus having developers focus on solving a hard problem. The human brain is going to focus on one or the other. Giving more brain cells to freaking out means those brain cells won’t be used for any problem solving because humans.
On the projects I lead, we have a continuously flowing backlog and a velocity. With those two things, there is no need to saddle a developer or designer’s brain with threats and stress that ultimately are not the real outcome. Instead developers and designers focus on building a user experience that solves a problem. We talk to users. We get feedback for iterating on the next build. That’s a meaningful outcome.
Painless, frequent releases
Once a team has moved beyond freaking out about dates, it becomes much easier to talk about and organize frequent, painless releases. In order to get to frequent, painless releases, care must be taken in how features are broken down into stories by product managers working hand-in-hand with developers and there must be a safety net of tests in place.
You know what’s sad? It’s sad how I often I get looks saying, “you are bonkers” when I put the words painless and release together in a sentence. It IS possible. I know because I’ve seen this happen many, many times. Even if the features are large and complicated, there is always a way to break them down, to get feedback about them early and, yes, to write good tests for them.
In fact, painless releases are the regular way of doing business on consulting AND product teams that focus on using lean and extreme programming practices. It’s not a unicorn. It’s a daily existence that is easier for everyone involved.
Flow state
When releases are painless and the backlog is continuously flowing, I often find that people start working together more closely. You can hear this in how a team talks to each other, how their body language becomes more relaxed and the speed with which the backlog starts emptying out.
People finish each other’s sentences. Designers sit next to develpers while they make small tweaks together. Everyone is in the room and focused on getting the work done. There is no confusion, just a team getting software out the door.
This beautiful event is called flow state.
Living the dream
It sounds fun, doesn’t it? I feel so lucky to have worked on teams where I’ve gotten to experience this plenty of times. In fact, I’ve even experienced this as the normal steady state of a team.
It is possible…yes, really.
It keeps me going and it’s why I stick with XP.
