All posts by ben

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.

An Experiment in Soliciting Feedback

At one of the software development companies that I consult with we are encouraged to solicit a “Feedback Lunch” every so often. It is traditionally a one-hour lunchtime sit-down. I invite five or six members of the team to participate. Menlo has a flat organization system. I invite my peers to come and discuss what I’m doing well and where I can improve. This is not a meaningless exercise–the feedback that the team gives can lead to an upward renegotiation of my contracting rates and is a good way to gauge how I am valued as a contractor.

I decided that I wanted to shake up the normal model. I was going to follow the oft-repeated Menlo Innovations cultural maxim “Make Mistakes Faster”, and run an experiment. Here’s what I did:

After my 7 colleagues had arrived and sat down around the lunch table I announced that I had an activity. “We have about 50 minutes left and I’d like to spend the first part of that time trying a new activity. I want you to begin by pairing, and interviewing each other about me!” I prepared pre-printed index cards with same four questions on them:

  1. What does Ben do well?
  2. What does Ben do Badly?
  3. How would you like Ben to grow?
  4. What surprised you about Ben?

Interview Questions
I explained that we would take no more than 15 minutes to do the interviews. Each person would interview their pair partner, and then I would call time and they would swap roles. Afterward we would come together and begin the feedback process by reporting to the group about the results of their interviews. I set them to it and moved off a bit to the other end of the lunch space so that they could speak without me shadowing over them. It was quiet at first. But soon people got into their roles as Interviewers and Interviewees. There was a constant buzz of communication happening and I had them switch roles after about 5 minutes. After the second 5 minute session I brought everyone back together.

I explained that I wasn’t sure how the interviews would go, but I was happy with the sense of interest that I perceived them taking in the interview process. “Thank you all for trying that, now that everyone has been interviewed I thought we might report on our interviews.” Then Thomas mentioned “Everyone has been interviewed except for you!” Hmm, he was right. Of course it makes sense that I self-report to the group too, and it turned out to be a great segway into the group discussion. The group assumed the role of Interviewer and I was on the spot to begin answering the questions I had written for them. The group went down the list and asked me my questions. What do you do well? Badly? How do you want to grow? What surprised you about you? As I answered the questions I saw looks of recognition on many peoples’ faces as I mentioned some attribute or behavior that they had also noticed. This lasted for about 5-10 minutes and we still had about 25 minutes left.

The next things was to get the feedback from the group. I drew a quadrant onto a flipchat, one section for each of the interview questions (Good, Bad, Growth, Surprises). As people reported back on their interviews we scrawled out the feedback on sticky notes and stuck them up on in the corresponding quadrant of the flipchart. We used up almost all of our time having a lively discussion as people mentioned the interesting things gleaned from their interviews and we stuck the notes up on the chart. I finished the meeting feeling energized and excited to try out an experiment and to have it go so well. I think that I received some valuable insights into how the team views me as a consultant and also some ideas about how I can grow in my consulting practice.

We finished the session by taping down the sticky notes so that I could take the flipchart home without all the stickies falling off, and we debriefed for a few moments. There was some enthusiasm for the process that I had experimented with. Some people thought that the interviews did not particularly enhance what feedback they would have given. I also laid out a few of my reasons for wanting to try the experiment:

Feedback Flipchart

  • Interviewing each other instead of initially giving me feedback directly would lower inhibitions to saying difficult or contentious feelings.
  • People are busy and it’s difficult to find time to prepare to give much feedback so being interviewed would give them all a chance to reconnect with their opinions and thoughts about my work as a contractor.
  • We pair constantly at Menlo so it seemed fitting to try and conduct feedback in a paired manner.

Ideas for the activities came from Agile Retrospectives: Making Good Teams Great, which I have found to have some great ideas for team reflection. Also, thanks to the Menlo team for allowing me to experiment on them, and for giving me valuable feedback!

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!