Category Archives: Uncategorized

N = Infinity

What happens when you scale agile concepts and software projects way down or up toward infinity. Here are some variables to consider:

  • Team size
  • KLOC
  • Project duration
  • Number of technologies involved
  • Team locations
  • Complexity (too general?)

Experiments Per Week

It strikes me that a team subscribing to the Agile Manifesto should be changing constantly. Woody Zuill often discusses an important principle arising out of the Agile Manifesto “Responding to Change over following the plan”:

To improve a team must frequently question their most deeply held beliefs.

A corrollary to that is that a team must:

The more often that a team devises, utilizes, and reflects on experimental changes to their processes on a project the better.

This statement leads to a fuzzy metric that I’ll call Experiments Per Week (EPW). EPW can be used to gauge the health of a team as it works on a given project.


First team members need to think of an experiment to run.
Experimental changes to consider:

  • Change size of team
  • Cancel a meeting
  • Restrict email use
  • Change pair structure (Mob Programming, pairing previously unpaired roles, etc.?)
  • Stop Estimating


Enough team members must buy into trying the experiment for it to be successful. For personal experiments the only one to buy on may be an individual. For larger experiments more team members need to “sign-on” to try the experiment.


The end-of-experiment reflection time could be called a debrief, a retrospective, or something else. But after a fixed amount of time to try the experiment the team must decide how it went.

  • What went well
  • What was different
  • What were the surpises
  • Did we add value
  • Could this experiment be broadened or changed to reflect new circumstances?
  • Should we try the experiment again

A Few Paired Experiments

I pair-develop software in a communal, cube-less, collaborative software development office all day at my current consulting engagement. I wouldn’t want it any other way! Certain pair partners and I just seem to click, we get into the flow, and with other pair partners I find myself extra drained at the end of the day and I wonder why.

Here are some thoughts on being and energized and energizing pair partner:

Foster learning opportunities

One of the most energizing things for me is to help others make mental breakthroughs. I take the opportunity to be a mentor and to be mentored by my pair partners and the other pairs working on the project.

Change your tools

When the way forward has become murky, walk away from the computer and go to the whiteboard or a flipchart. Change your tools often throughout the day. If you are a pen person try a colored pencil or sticky notes. Move your computer to another part of the office. Experiments and change are exciting and energizing.

Treat interruptions seriously

If your pair partner is disengaged by using his/her phone treat it seriously. Ask “Is everything going okay? I notice your are checking your phone a lot?” Demonstrate caring. I do not let disengagement slide because it will drain my energy. Would your doubles ping-pong partner check their phone during a point?

Tweak the sharing interval

Try changing how long each person codes before handing over the keyboard. Sometimes an hour or two of switching every 15 minutes will have you energized and the next hour it makes sense to switch only twice because the particular task is amenable to larger chunks of keyboard time. Keyboard use intervals can be tinkered with throughout the day to get a desired outcome.

Agile Singapore 2014

I’ll be attending Agile Singapore 2014 this November. The CEO of one of my consulting Alma Maters, Menlo Innovations, Rich Sheridan, will be there giving the closing keynote to the conference. Michael C. Feathers will be speaking there as well.

Rich’s new book is titled Joy, Inc.: How We Build a Workplace That People Love and it describes the Menlo Innovations “software factory”, a place where I have been very happy to call my work-home these last few years in Ann Arbor, MI.

Michael C. Feathers (Author of the highly praised book Working Effectively with Legacy Code), is slated to give a talk titled Constructive Action in the Face of Technical Debt.

I have both of their books in my hands now and I’ll be reading them through before I get to Singapore… or maybe on the plane!