Thanks for a great 2014

December 31, 2014



“Cheers to a new year and another chance for us to get it right.” -Oprah Winfrey

This blog was first started back in 2007. Since then, I’ve published 258 posts on topics that ranged from outright rants, to humor, to reviews and recommendations. Everything on the topic of Agile software development processes.

Originally the idea was to dedicate the blog exclusively to the tools used on agile projects (hence the title). Obviously I didn’t end up confining myself to just discussing tools. After all, we agilists prefer interactions over processes and tools. So I ended up writing on a variety of agile topics. Most of the topics were things that simply came spontaneously. The ideas arising from my work, my reading or simply my feelings.

Looking back, some my posts were insightful, and others were simply boring. Occasionally I have taken what felt like significant risks with the material I’ve posted by saying things that I knew would not be popular or well received. In some ways that has made writing a blog like this very liberating.

Things began slowly in 2014 with just one post in March. After 200 posts, I think it’s fair to say that I was running out of steam. It wasn’t until August, when an old colleague of mine noted that I hadn’t been writing much, that things began to change. The writing engine fired up and I began posting again.

At this point, I started a new blog, onestandardman. The idea was to focus on a long-standing fascination of mine: Self-experimentation. I wanted to run experiments serially and share the results.

So now I was writing two blogs! In fact, this just seemed to grease the writing gears for me. For 35 days, I kept up a blistering pace of writing, posting twice a day. Once to each blog. September was a ferociously productive month for me.

The interesting thing was that in the past, I had a hard time keeping my writing quality high when I wrote with such frequency. This time quality was not a problem. The material just kept on coming and all I had to do was write whatever the voices in my head were telling me. Eventually, the writing pace slowed to a more sustainable level of 2-3 times per week.

It has been a wonderful year. I’ve encountered greater challenges this year than ever before. Thanks for being there.


Slowing Down

February 12, 2013


Last week I led a session at Agile Open Northwest called, “Slowing Down”. The idea for this session was inspired by my own struggles with becoming quite over-committed to a variety of things (my job, my hobbies, etc.) and the resulting stress and crisis it has created for me. You see, the funny thing about it all was that even though I was perfectly aware of what I was doing by over-committing like crazy, I couldn’t seem to stop.

The Introduction

So I came to this session, not as an expert selling a solution, but rather as a novice seeking help. Since I really didn’t know where things were going to go, I simply started with the session title. I wrote “Slowing Down” on the whiteboard and introduced myself to the small group of people who had joined me for the session. I started with a story of my own. It was a bit like what I imagine an Alcholics Anonymous conversation starts like, “Hi, my name is Tom and I can’t slow down…”

Fortunately for me, many in the audience had a similar story. Since we are a bunch of software development types, it didn’t take long for the concept of sustainable pace to be mentioned. Of course we all knew full well what sustainable pace means. It is a term that I originally encountered in Xtreme Programming. I could ramble on for hours about the importance of keeping the pace and duration of your work under control so that you can sustain your creative energy and not burn out. Easy. But I can’t seem to do it worth a damn. That’s the interesting bit. Why? Why is it that, even knowing the importance of maintaining a sustainable pace, I and others like me seem to struggle so hard with it?


A few interesting ideas for why we get sucked into this dynamic were suggested during the session:


Ownership – Feelings of ownership can make it hard for people to let go of tasks and delegate them to others. For example, it is very easy for project leaders to feel a very strong sense of ownership and commitment to the success of projects that they are working on. This can be quite normal – often our organization want this kind of commitment from us. However, like many things, this can go too far. The undesired dynamic plays out as a feeling that you and only you are personally responsible for the success or failure of the project (what happened to the team?). When challenged, people who struggle with ownership issues will often look with incomprehension when asked to give up some part of a project, “If I don’t do it, who will?” I think that in some cases this inability to give up ownership can also manifest as heroism (ownership + adrenaline junkie). Perhaps at its heart, ownership issues are tightly tied to ego. They seem to manifest as a very selfish view of project success or failure.


Bad Habit

Habit – We form all sorts of bad habits that contribute to the stress in our lives. For example, I’ve gotten into the habit of checking my email compulsively throughout the day. Often even when at home. Habits like this that tether us to the office and constant communication serve to raise our overall stress levels. Other examples include habitually taking home the laptop with you every night and carrying the work phone with you wherever you go.

Culture – One major reason for difficulty with slowing down is the work culture you live in. People shared many different stories of how the expectations at work made it hard or almost impossible for them to escape the pressures of the office. Everything from evil bosses that demand attendance over performance to co-workers who make snide comments when a colleague dares to leave the office at 5:00. Some places even provide rewards for those who make decisions that put work above any other activity. Examples of these sorts of influences in the workplace abound.

All of these influences are very common reasons why people find it hard to slow down. It is no wonder that there are many who struggle to maintain a sustainable pace of work at the office. Understanding why you are feeling that pressure is critical to understanding what strategies to use to manage the problem. The strategies where where we ended up going next.


As we moved along in our discussion, people identified strategies that could be used to deal with slowing down and establishing a more sustainable pace. We captured and expanded upon those strategies as we wove the narrative of slowing down.

Setting Boundaries


The first strategy that came up was setting boundaries. Setting boundaries is fundamental to establishing control over your own schedule and pace. Fail to do this and all the rest really doesn’t matter. People told many stories about how they managed to establish meaningful boundaries in their work lives that helped them to keep a meaningful sustainable pace. Some made their 9 to 5 work hours non-negotiable. They never offered the longer hours that many fall into. You get me for 8 hours a day, and the rest of my life is not for sale. It was remarkable to hear the strength of some of these voices. Others refused to take work home or turned off the cell phone after 5.

Basically, what I heard were people establishing a service level agreement for their participation. One benefit that I noticed from this sort of boundary was that it made visible to everyone just what they could and could not expect from you. Visibility is a strongly held value in the agile community and it struck me that making my boundaries more visible would be a uniquely agile way of dealing with the issue (I’m closing the door now…). Another way of making my boundaries and limits visible would be to use a personal task board mechanism like personal kanban in order to not only make my existing commitments visible, but also to review them myself and keep tabs on how the work load is balanced (or not).


Diana Larsen did a great session last year at Agile2012 on personal retrospectives. As team facilitators, we are pretty well versed in running team retrospectives, however I never do them by myself. That is exactly what Diana proposed: do self-retrospectives on a periodic basis in order to reflect on your progress toward your goals, and where you want to go next. I think this would be a useful tool for many, whether it is only at the end of the year or much more frequently. I know that my own responsibilities feel like they have changed quite dramatically in the last year. Stopping to assess those changes might just give you the opportunity to recognize stressful trends and start to do something about it. You can start to do it now, or wait until a crisis imposes that reflection. Your call.

This is just my summary of what I saw and heard during our talk. Looking at the sheer number of topics that we covered it’s quite apparent to me that we covered a broad number of subjects. Many of them are worthy of deep investigation. Perhaps, as the mind map suggests, we have created a map of the terrain of the topic of slowing down. Others may have different take aways. I certainly hope so. I appreciated everything that the group brought to the conversation and I hope that I was able to serve as a reasonable scribe for what was said.

Give the 360 Back to the Team

January 26, 2009


Tired of doing the same old retrospective every sprint? You know how it goes: what went right/what needs improvement/action items. Are you running out of ideas for improvements?

Here’s an idea: at the end of each sprint do a 360 review. Use a survey tool and have every member of the team review each other’s performance in the past sprint. Just a couple of questions would do it. A good tool would summarize the data for each team member. Then, based on that feedback, each individual on the team would have a really good starting point for a discussion about how they can improve their performance in their next sprint.

Imagine doing a 360 every two weeks. Imagine changing the questions every two weeks to meet changing conditions that the team encounters. Imagine having up-to-date feedback on your performance as seen by your peers every sprint.

I offer this notion as a counterpoint to the traditional 360 review that is run by the corporation/HR. You know the one where you have to review a bunch of people you don’t necessarily know, then sit in an uncomfortable meeting with your manager where they review your personality flaws revealed by your peers. Instead, the 360 is for your use only. You decide what to do with it. Nobody else, not the scrum master, no one else is privy to the results.

I’ve done 360 reviews at a couple of different places (it had nothing to do with Agile). In most cases it was a top-down driven process. Questions were determined by my managers (and their managers) and when the results were tabulated they were given to your manager first. Then your manager would review the results with you. Recently however I found myself at a company where they wanted to do things differently. Privacy was a much bigger concern in this culture. People didn’t want anyone to see their results – not even HR.

At first I found this preoccupation with privacy perplexing (I’m very trusting by nature). However, as we went through the process I realized that the privacy actually seemed to improve the 360 review. It keep the feedback limited to the person who needed it most (the person being reviewed), without exposing it to the judgement of others (managers, HR, etc.). Whether or not you wanted to actually *do* anything about the feedback was purely up to you. It took the pressure off the situation – and I usually find that to be a good thing. If my salary isn’t hanging in the balance, I usually make much better decisions.

The more I thought about it, the more I thought we should be able to do a 360 review as frequently as we want to (assuming we can keep them low cost/low effort). Better yet, if the team controls the questions that are asked, then perhaps the team can change the questions frequently to match the changing nature of the problems they face. That seems to offer a unique opportunity to provide honest, anonymous feedback for team mates. 

An agile purist might maintain that a team should be able to give each other that sort of feedback without the 360. We should be able to critique each other face to face. Perhaps. There are some teams that are very good at that (very few that I’ve worked with). For the rest, the 360 might be worth experimenting with.

What sorts of questions might you ask in this kind of 360? Here are a few ideas for categories of questions based on the Scrum Values as described by Ken Schwaber:

  1. Commitment
  2. Focus
  3. Openness
  4. Respect
  5. Courage
  6. Technical Skills
  7. Domain knowledge

If you are thinking of trying this out, here are a couple of tools that might be useful for implementing a cheap 360 for your team:

Feedback is good. I’m thinking of using this sort of survey for my presentations.

Type 3 Scrum – OK, now I get it (finally!)

December 11, 2007

It took me a while, but I think I’ve finally grokked the difference between type 1, type 2, and type 3 scrum. These different types or gradations of Scrum were suggested by Jeff Sutherland, one of the originators of Scrum. Briefly, the three types can be rather simply described as follows:

Type 1 – Fixed gates: Standard, out of the book Scrum. Plan your sprint, run your sprint, review your sprint – rinse and repeat.

Type 2 – Overlapping gates: Plan your sprint, run your sprint with ongoing planning sessions (for upcoming sprints), start next sprint as first sprint winds down, review last sprint – rinse and repeat

Type 3 – Mini gates: Plan a feature as needed & start sprint (features can start anytime), when sprint is complete – review it.

The way I see it, with type 1 Scrum, you are starting off with the training wheels on the bike. Things are pretty strictly regimented. We want to get the team used to a time box (they need to learn how to scope their work effectively). We want to get the team used to frequent planning and frequent reviews (put the rudiments of a quality driven, inspect and adapt system in place). And finally, get them used to working with smaller batch sizes.

As a team graduates to type 2 Scrum, they have mastered the fundamentals of type 1 Scrum. Now they can begin to improve on the process. Planning becomes much more of an ongoing activity that never stops. We remove the hard start/stop constraint between sprints. We want to establish a comfortable rhythm where the team begins to blur the lines between the current sprint and the next. We keep the sprint planning and review though – we want that culture of continuous improvement to remain. We probably have a trend of the batch sizes for each sprint starting to get smaller.

Finally, As a team gets comfortable with type 2, they have reached a point of really significant maturity. Now is the time when we can look at the team and say, “What if we reduce the batch size to one?” One sprint has one story. We overlap as many sprints as necessary. Basically we are creating a state of continuous flow where there are always multiple sprints in progress. In addition we have driven the batch size down small enough that the inspect and adapt cycle is now almost continuous. Sweet!

Based on my own experience I know that a team would have a very hard time skipping from type 1 to type 3. It’s an evolution. I also think that it is remarkably similar to other systems like Kanban – after a while I guess they all start to look the same in some respects.

Hanging My Test Driven Christmas Lights – A Retrospective

December 7, 2007

OK, so by now, many have read my first missive regarding my annual sado-masochistic ritual of decorating the house for Christmas. I’ve just finished the whole embarrassing production once again. Time for a little retrospective:

So let’s start by reviewing our objective…

Goal: To win the Elf Award for the best Christmas lights in my subdivision so that I can revel in the glory and adulation of my neighbors and idle passers-by.

What Went Well:

  • More lights than last year
  • Key display items repaired (“Frosty is back!”)
  • Ten Fingers, Ten Toes, Skull still intact, No broken bones
  • No visits to the ER
  • Fewer unexpected blowouts – improved quality
  • Still married

What Could Change:

  • Casualties: 3 fingernails & one stapled thumb
  • Work more closely with the product owner
  • Get approval for changes to the lighting scheme BEFORE implementing

All in all, this year’s lighting experience has been much better than last year’s. There are a few things that might explain this success beyond what I talked about last year. This time I did the work in much smaller chunks instead of trying to do everything in one day. This made the physical exertion seem much less.

I should have gotten approval from the product owner for smaller increments of the work. I had a few scares where my wife came outside, looked at the fruit of my labors, and said, “You’re NOT going to hang icicle lights on the tree are you?”

Of course not, Honey…

Of course the real approval for this release will come from the judging committee when they hand out the Elf Award. Maybe I should bake some cookies for the committee? Should I greet them at the door wearing a tie? Should I write an acceptance speech? Stay tuned.