Extreme Pair-programming
The 'trailer-park boys' at
Energized Work have started extreme pairing. First up .. The Jerry Springer Show. Let me tell you, trying to fix the build with guys fighting in the background ain't easy.
Labels: extreme, pairprogramming
Pomodoro galore
Almost everything for us is now a
pomodoro. Some time ago we replaced the per-iteration planning game with on-demand planning
pomodoros and the end-of-iteration retrospective with a pomodoro retrospective.
Every
Wednesday, the first day of our
weekly iteration, we kick off with a 25-minute planning pomodoro to give us just enough stories to make a start. It uses a modified
fishbowl format to stimulate the right level of technical discussion and keep energy levels surging. When the
board gets short of stories (and the team is in danger of stalling) we run another planning pomodoro to top up the 'waiting' column. We keep doing this until the
showcase on Tuesday but we're careful not to end with loads of stories still in progress.
Our estimation is simply: "Is this story less than 2 days?" and the team shows thumbs up or down. If it's not, the story is split there and then. A pre-planning pomodoro run in advance of Wednesday, looking ahead into the next iteration, helps to size stories appropriately and get the acceptance criteria on the back of the cards. Our velocity is the average-to-date, over all the iterations, of the number of cards that made it to done. This gives us a steadier velocity than summing the estimates of the stories that made it to done in that iteration. We're not really using the velocity for planning purposes though. We use it to calculate a per-story cost, in £, derived from what was delivered in the iteration and the overall capacity cost for the iteration. From this we can then calculate the cost of any inventory and outstanding technical debt. It's sobering to see these things in money terms. I'll blog separately about the simple profit-and-loss sheet we use based on lean accounting and the metrics we watch.
The pomodoro
retrospective is conducted standing up. This keeps things moving and keeps people focused. 25 minutes doesn't provide a lot of scope for variation of activities but we can easily cover our standard format: brainstorming - affinity mapping - dot voting - and agree one action that will improve things. I expect this will eventually get boring so I'm thinking of ways to do pomodoro 'lets improve this, here-and-now' sessions that are triggered by a problem just encountered. I guess these are similar to timeouts. Ultimately, the challenge I've set myself is to focus these continuous improvement pomodoros on making an improvement that is not borne out of (and therefore constrained by) solving a specific problem. They just focus on making an improvement to get better.
We're also experimenting with a new board layout that helps us integrate iterative collaboration with designers. There's some serious thinking to be done here and, to be honest, we could do with a fresh project to try it out on.
Labels: planning game, pomodoro, retrospective
What is it about technical discussions and weeds?
It's tough to prevent technical discussions getting lost in the weeds. Actually, it's the people involved who get lost in the weeds.
What usually starts out as objective and constructive often slides into a protracted subjective and opinionated 'jousting' event. Some people end up focusing on what's personally valuable to them (or motivating for them) rather than on the goal. Some people disengage because they can't get a word in, they've been shouted down, or they've become bored. Everyone walks away frustrated that consensus wasn't reached. Or worse they leave with the illusion of consensus.
Here are some tips for keeping technical discussions out of the weeds:
- First and foremost, ensure people with the right skills and experience are involved.
- Avoid subjectivity by putting personal code and architecture design styles aside.
- Leave egos at home. (Easier said than done!)
- Use simple words and aim for clarity, i.e. avoid jargon, including pattern names. Try to develop a language, and maintain a glossary on a wiki, so that effective conversations can be had without resorting to detailed and time consuming UML and documentation (a simple UML diagram can help in many circumstances).
- Articulate proposals in terms of simplicity, testability, and technical debt.
- Maintain engagement with props to avoid hand waving, e.g. use a whiteboard and draw pictures.
- Be patient, stay focused, and keep listening to get through the groan zone and converge at consensus. To truly understand the points other people are making, work hard to hear what they are saying from their perspective.
- It's one thing to talk passionately with the courage of your convictions, but consensus cannot be reached through force of argument. Remember, you must persuade people through reason not volume.
- Keep assessing the discussion. Dont argue about whether X might do Y - pull-up the code on a projector and show that X does Y. If it has become speculation stop and run a spike to gather some facts. Then reconvene.
- Focus on intent. Keep asking whether the discussion is still valuable.
- If you've got a facilitator handy insist they sit in on the discussion.
Jumbo Wii Night
Photos from Jumbo Wii Night at The Energy Lab:
Labels: fun, wii
Reflecting at the Fun Day
We said there was a
whole lotta fun to be had at our end of project retrospective fun day and that's exactly what we had - fun! And the various retrospective activities interspersed throughout the day produced a lots useful information and ideas. I plan to blog about these separately because we'll be running some experiments based on our ideas to simplify and improve the way we work as a team. In the meantime, here's some photos from the day:
Labels: fun, retrospective
A whole lotta fun to be had
We're going to have a fun day on Friday to celebrate the success of our most recent client work.
We'll start the day at
My Old Dutch Pancake House for brunch and a retrospective. As we do every week, we'll be seeking some small
actions to drive our continuous improvement. In the afternoon we'll hit the
Bloomsbury Bowling to shoot some pool and do some ten pin bowling while engaging in a 'beerstorm', i.e. brainstorming fuelled by beer. I'm keen to stimulate some transformative ideas that could take us to a whole new place. I have no preconceived notions and I'm excited to see what the team comes up with.
It's both productive and revealing to do things like retrospectives and brainstorming in a social setting filled with jokes and laughs,
nom and drinkies. People relax, drop their guard, are less defensive and generally more open to things. And, importantly, our friendship helps avoid anything said being taken as offensive.
Labels: fun, kaikaku, kaizen, retrospective
What makes us tick
We're working on a new Web site with
Tim Nicholls from
Electric Light Box and we did some concept work to develop a brand that captures what we're about here at Energized Work. You'll see the visual brand when the site launches but I wanted to share what we've come up with on how we see ourselves. If you read this blog (or know us) you'll know that we're pretty straight-talking and say what we mean. When we wrote
The Energized Way to describe how we work we used short, sharp, punchy statments. We wanted to use the same approach to capture our ethos. Here's what we came up with:
We show AWARENESS- We see the big picture
- We sense what is important
- We are tuned in
- We see options
We seek CLARITY- We strive for simplicity
- We pursue a vision with purpose
- We are totally focused
- We say what we mean
We build UNITY- We are a team
- We collaborate intensively
- We appreciate diversity
- We invest in friendship
We pursue EXCELLENCE- We are craftsmen
- We have discipline
- We harness innovation
- We deliver
We have the right ATTITUDE- We know our stuff
- We shoulder responsibility
- We operate with integrity
- We are brutally honest
- We are humble
We are FUN- We create energy
- We enjoy what we do
- We are fun to work with
- We are refreshing
Labels: energizedwork, values
'No excuses' done done
Yesterday at
QCon London, Gus and Kris talked about how we at
Energized Work get from
concept to cash every week. It's a simple message really.
Keep it moving:- Sustain throughput and maximize profit by 'shipping' running tested features to production at least every week.
- Automate everything to achieve mobility and continuously invest in it to keep it cheap.
- Don't track bugs, fix 'em.
- Manage debt to keep moving fast.
Keep it working:- Eliminate individual anxiety and keep the team resilient by pair-programming all the time.
- Roll ownership of each story through the team to facilitate collective ownership and knowledge transfer.
- Maintain a rigourous test-driven approach through personal discipline.
- Colocate because the conversations never stop.
- Learn what's really needed by iterating with a full-time onsite customer at the wheel.
Keep it together:- Don't branch and don't stay away from the trunk for longer than 2 hours.
- The build monitors are the focal point.
- If the build breaks fix it immediately, otherwise what's the point of having it.
Keep it real:- Operate all the environments, including production, yourselves. And do your own support.
- Non-functional and sysadmin work is part of development and not an afterthought nor someone elses responsibility.
- Optimize at the right time and always in context of 'the whole'.
Keep it coming:- Write stories to be a little ambiguous to ensure conversation happens.
- Plan just enough when it's needed to prevent stalling.
- Make the showcase count because the client will decide whether to invest more money.
This stuff is as hard or as easy as you want to make it. It's not enough to be doing the technical practices and it's not enough to be living the values and principles. You gotta do it all and more, at the same time, learning all the while. It takes courage, willpower and
zeal. And, dare I say, you gotta know what you're doing. There really are no excuses. Ultimately, for me, it comes down to
having the right people, creating the right environment and working with the right clients.
Here are the
slides (they're better quality than those downloadable from the
QCon site).
When I get the official feedback on the session I'll post it here.
Labels: craftsmanship, qcon
Actions from retrospectives
A retrospective is pretty pointless if you don't come out of it with an action, which you then take in the next iteration.
An action should be small, specific and clearly defined on a card; can be taken immediately; starts something new and good, rather than stops something bad.
Labels: retrospective
