Wednesday, October 30, 2013

Conducting Project Retrospective with a Distributed Team

Like many modern software development teams, some of our team members do not work in the same office as we do.  We have the added and common scenario that some of our colleagues work nearly half way around the world, so our morning is, quite literally, their evening.

And, like many modern software development teams, we like to us an Agile process, using a Scrum model with typically a two week sprint.  On the last day of the sprint, we hold a project retrospective, so that the sprint's events are quite fresh in our mind, then we close the sprint and start the next one.

As in so many aspects of team and sprint management, I like the retrospective to be completely democratic; each team member has an equal opportunity to provide comment.  Here's how we do it:

The purpose of the retrospective is process improvement; what can we learn from this and previous sprints so that we can codify successful behavior and modify less-successful behavior?  To focus on learning lessons, ask two questions:

  1. What did we do well in this sprint?
  2. What could we have done better in this sprint?

To get answers, start with question one and go round-robin, with the questioner going last in the sequence, giving every involved team member (pigs only, please) an opportunity either answer the question at hand.  Each person can either provide a new answer to the question or take a pass.  When they take a pass, they typically are not asked to provide any more answers to the question.  Don't be draconian; if someone remembers something in the course of the process, it is better to be inclusive than rigid to a rule.

It runs something like this:

Scrum Master (SM): Person 1 (P1): Do you have something we did well in this sprint?

P1: Yes, We completed some significant new functionality for our users

SM: Thank you.  Person 2 (P2): Do you have something we did well in this sprint?

P2: Yes, We were very responsive in reviewing Pull Requests

And so forth until everyone has taken a pass on the question.  Then move on to question two.

One way to document the answers in a group is to use a document, word processor or presentation, and put one answer on a page.  Put the document on a large screen so everyone can follow along. Then, print out all pages and put them on the wall.  Each person takes a pen, marker, sticker or something similar and makes three votes on the answers to each question.

The votes are then tallied up and the top three answers are documented in some centralized document of Retrospective Summaries.

How then to do this for teams that are geographically disbursed?  We want everyone to follow along with the documentation of the answers so they every team member can agree to the wording used.  We want every team member to be able to vote and we need to tally up the votes.

When facing these challenges for the current team, I first looked at collaborative work spaces that would let us all see the same documents and perhaps collaboratively edit the documents using some kind of tick mark or initials to indicate votes.  These were less than elegant.

Today we use two technologies to conduct our project retrospectives.  First, we use to have the entire team view the screen of the Scrum Master.  The Scrum Master creates a survey on  The survey has two questions, the ones above.  Each question requires exactly 3 answers be selected.  We then go round-robin and document each answer.  Here's what it looks like as we edit a question:

When we have finished the process of gathering the answers, the SM posts the URL of the survey in to the team chat window and pauses  Every team member votes and when all votes have been collected, the SM unpauses and the team reviews the answers.

The top three answers are documented in a centralized document and an executive summary is sent around.  Every other or third sprint we look back at previous answers to see how we're trending.  We look for answers that we have repeated and talk about how we will retain good practices and what we could use to replace less-successful practices.

By retaining our focus on process improvement, we have the opportunity for every team member to have a voice and everyone has had very helpful inputs, that even if not voted, stay in the collective consciousness.

Wednesday, October 09, 2013

The Joy-Infused Workplace

This is a new thought, so please bear with with while I work it out, but I was so excited by this that I had to put something down on paper, as it were.

I was chatting with some colleagues during a quick coffee break and they were joking about business management practices: ISO, CMMI, MBO, etc.  Joking about how all these were problematic, but they liked ISO because it didn't matter how bad the product was, as long as the process was documented and reproducible.  We steam-rolled into the laughable over-reaching of business processes and how they can block and stifle productivity and creativity.

Then came the seminal moment: One colleague said, "But you have to have some process!  Otherwise everything would just be chaos!"

I couldn't resist.  I was bursting.  I blurted out, "Yes! And it does not matter which process you choose; as long as the team works with it, owns it, uses it, improves it and you, the team and the company are ultimately successful!

"Your processes doesn't even need to come from only one source!  Mix, match and combine!  Pull a little Peer Programming into your Agile Scrum.  Waterfall?  Heck, if it works for you: YES!"

We laughed a bit about that, but I wouldn't let it go.   "If you, your team and your company is successful, then your process is a good one, whatever it is.  I have learned that if you can help everyone enjoy what they do, they will do it well and will want to continue doing well.  The process is incidental; the joie de vivre is what is critical.

"As a matter of fact; that is what the management goal of the company should be: Success by fostering an environment of joy within the company."

My colleague pointed out, "That could backfire: The server went down, but we're happy, so who cares!"

"Great point!"  I practically yelled.  I am excitable.  "But, that would be antithetical to the company's goal of being successful. If the staff is enabled to keep the servers running, maintained and address critical repair issues in a timely manner, then they will feel a tremendous sense of accomplishment and satisfaction; right?"  My colleague agreed.

If everyone in my company felt joy, accomplishment and satisfaction, I doubt there would be a business challenge we could not over come.  So, it's my new business and management philosophy: The Joy-Infused Workplace.

Perhaps I'm just supremely lucky to be able to work standing up and dancing to great music while I write, debug and review Ruby and Rails code and work with some really fine colleagues on my team.  But I suspect, based on the laughter, respect and support we have for one another that we are a high-performing team because of the way we choose to let joy in to our working environment.

Yes, OK, I know: one can't be happy all the time.  I think that does not at all take away from the goal of creating a workplace environment where everyone one can feel acknowledged, accomplishment and satisfaction that leads to regular expressions of joy.