You Can’t Do Collaboration Without Being a Collaborator

In various software development circles I hear the phrase “You can’t do Agile, you have to be Agile”.  This makes sense to me so never thought much about it.  However, when asked about Gangplank and describing it we choose say collaborative workspace over coworking, but it’s hard to get people to understand that difference.

It wasn’t until I read Johanna Rotham’s Six Behaviors to Consider for an Agile Teamthat it really hit home.  It made sense.  “You can’t do collaboration, you have to be a collaborator”.  In a nutshell, we didn’t create Gangplank because it’s what we do, we created Gangplank because it’s who we are.  This might sound like a trivial subtlety, but I think it’s really what makes Gangplank work.

Retrospective Test Idea

I have been wanting to share retrospective data lately in the hopes others would share their data back.  This is a quick experiment.  If people find it useful please comment.  I will then execute part two of the exercise.

Retrospective #29232


The team has been struggling with making hard commitments and hitting them.   Additionally, there have been a few projects seeing a higher than normal number of defects.  The team has been short staffed and just moved into a new building.  Team Members 8.


Being in a new building meant no whiteboards and an unconventional conference room setting.  All exercises had to be adjusted accordingly.

I like to give the team a schedule to keep me honest and from preventing overage.

Setting The Stage (5 Mins)

Asked each member of the team member to state whether they hit their commitment with a simple yes or no?  Followed by a single word that summed up their week.

  • Bugs
  • Productive
  • Provisioning
  • Defects
  • Advisor TLC
  • Frustrating
  • WiFi

Gather Data (30 Mins)

Had the team do Triple Nickels.  Created 3 items influenced from what prevented meeting commitments from setting the stage and ask them to talk candidly about them. Note: 3 minutes and then pass (24 minutes plus setup time)

Three items were Defects, Commitment, Pace

Asked the following…

What did we notice?  What surprised us?  What met expectations?  What is missing?  What needs more examination?

Generate Insights (15 Mins)

Took the top three things listed from the what needs more examination.  Then split teams in two groups of 4 to brain storm items for things that they could do to address the issues.

  • Where is time going and what are the consequences
  • Where defects come from and how to deal with them better
  • Simplest Solution Possible

Decide What To Do (30 Mins)

Had teams take their ideas and write them in the form of stories on index cards as part of the planning game.  Had each team prioritize their stories.  Then each team read off stories in alternating fashion to eliminate any duplicates.  Each team then was asked to task out what was necessary to complete the story for the top three stories and provide a “next action” for any remaining stories.

All stories and tasks were entered in Basecamp Todo list to be executed during next iteration.

Close (10 Mins)

Appreciations were made around the room.

Total Time (90 Mins)

Quick and dirty.  Less than optimal, but better than not having a retrospective because there was not a “good place” to execute it.

Sunday Review: Extreme Programming Explained by Kent Beck

I have decided to do a dead simple book review every Sunday. Some of this is to just share what I’m reading. Rather than go with some complex rating system a book will either be a thumbs up or a thumbs down. Thumbs up means I highly recommend reading the book. A thumbs down means read something else unless you have free time on your hands. I will then do a one or two sentence at most comment on the book.
Take Away: This is the current bible of good software development practices. Kent unchains the disciplined programmer by introducing him to the team.

Sunday Review: Practices of an Agile Develoeper by Andy Hunt

I have decided to do a dead simple book review every Sunday. Some of this is to just share what I’m reading. Rather than go with some complex rating system a book will either be a thumbs up or a thumbs down. Thumbs up means I highly recommend reading the book. A thumbs down means read something else unless you have free time on your hands. I will then do a one or two sentence at most comment on the book.
Take Away: This is a great look at the spirit of Agile from a developer’s perspective.  The angel/devil reminders are a great re-enforcers of good/bad habits.

1% Improvement Over Time Is Significant

Who wants to be 1% better?  Not very many people.

Who wants to be 50% better? Significantly more people.

Who wishes they could be perfect? Most people.

I had heard the quotes “Perfection not a destination, it is a journey that never ends” and “The longest journey starts with a single step”.  This is why I love the principles behind agile software development.  There are really only two imperatives.  Inspect and Adapt.  If you are regularly doing these two things you should be seeing some form of continuous improvement in what you are doing.

It took Agile Bob presenting “Being Agile vs Doing Agile” at the Phoenix SCRUM User Group (phxsug) to remind me of this very simple principle.  The hammer to drive the nail home was that if a team is doing 1 week iterations and improves 1% per iteration, they will see over a 50% improvement in the course of a single year.

Stop and think about that for just a minute.  50% improvement in a single year!  Can you imagine bench pressing 50% more 12 months now?  How about cutting 50% off your marathon time this year?  50% more push ups?  Reading 50% more?  Knowing 50% more people.  What about making 50% more money per year?

The problem is we try to make 50% improvement in single week instead of an incremental improvement as little as 1% and when we don’t, we give up and fall back into regular patterns of the status quo.  I challenge you to be 1% better this week.  Then the week after that and the week after that.

Hell.  Be Dangerous.  Consider yourself a 1%-er.  An outlaw to the status quo!

Dysfunctions of (Agile) Teams

Over the holiday break I read Patrick Lencioni‘s “The Five Dysfunctions of a Team: A Leadership Fable“.  The premise is that each dysfunction builds upon the dysfunction before it.  Much like Maslow’s Hierarchy of Needs.   Below is an illustration of the dysfunctions with absence of trust being the building block of dysfunction.

Running multiple organizations and being part of an agile team gives me ample time to see team dynamics and participate in them on a regular basis.  This book really made me think a lot.  The information wasn’t particularly new, but it reminded me that much like agile, leadership of a team can be simple yet insanely difficult at the same time.

Absence of Trust
For some reason most teams think that if they all get along they have some super team work trust going on, but if there is any conflict what so ever that the team is some how not in harmony and that all is wrong with the world.  I remember early variations at Integrum where this certainly was the case.  The truth is that Trust is all about comfort in being vulnerable.  On an agile team this vulnerability is necessary because the only way to continually improve towards excellence is to be honest about your deficiencies.  If someone doesn’t feel they can be open and honest in their weaknesses and mistakes this can never happen.  What is your team doing to build trust and encourage vulnerability?

Fear of Conflict
The biggest smell of a dysfunctional team to me is one that agrees on everything and never has conflict.  Without conflict there are things being left unsaid.  In the end this is just unhealthy.  Willingness to have healthy conflict allows unfiltered and passionate debate about new and innovative ideas.   A good agile team is a “noisy” team.  I think the same goes for pair programming.  If a pair isn’t regularly in heated debate they probably aren’t trying very hard.

Lack of Commitment
I am starting to think that commitment is one of the most powerful words in agile software development.  Healthy teams don’t make excuses.  They don’t blame or shirk responsibility.  The get on the same page and drive towards completing the goal.  Deciding on what to commit to and then measuring to that commitment is key in building a strong team.  I have long thought that accountability was a major problem with no solution, but I am reminded that it’s probably a lack of commitment to blame.

Avoidance of Accountability
This is so so so so difficult.  As calling peers out feels so unnatural.  Who am I to tell you what or how to do something?  What authority do I have over you?  In reality if we have a shared commitment, I am doing both of us a disservice if I don’t speak up and hold you accountable.  It just never feels that way when it’s time to step to the plate and do it.  Recently I was told by someone to RTFM (Read The Fucking Manual) and it kind of stung.  It made me realize that I demand a lot, but at a bare minimum I wasn’t able to perform a basic function of one of the teams goals towards quality.  How embarrassing.  I wasn’t angry.  I was glad.  Their commitment to the goal and trust that I wouldn’t blow up over such a conflict ultimately improved what I was doing.  That’s how agile works right?

Inattention to Results
So often in the past people on our team were driven by ego, career development or recognition.  I childishly called them the “What about me’s?”.    Ultimately the one to blame is not them, but myself.  Failure to give them goals to commit to, left them no choice but to think selfishly.  It’s something that I painfully work on in everything that I am involved in, because frankly it’s hard work.  Guess I need to quit making excuses.

Patrick’s observation in the final summary seemed too fitting for an agile team to not share…
Ironically, teams succeed because they are exceedingly human.  By acknowledging the imperfections of their humanity, members of functional teams overcome the natural tendencies that make trust, conflict, commitment, accountability, and a focus on results so elusive.

For the first time I feel like Integrum has a team that is human.  It might just be that we are starting to achieve that right level of imperfection to function as a committed team.  Makes me feel pretty lucky and excited!