Mark Pearl

The Team

To understand the context of this post, you need some background on the team and the people in the team.

The team consists of 10 multi-skilled people who are able to handle all aspects of software development - from requirements gathering, development, testing to delivery and support. They do this in a collaborative development environment; it is common for team members to sit in small groups working on the same thing.

The team currently does not practice Scrum or Kanban, although they have in the past, and have learnt several principles from those experiences which they are still applying.

At the time that this experience started the team had the following meetings…

  • Daily 15 minute stand up meetings (11:00 am).
  • Weekly 1 hour technology learning sessions (tech brown bags) in the afternoon.
  • Weekly 1 hour business learning sessions (business brown bags) in the afternoon.
  • Every two weeks a 1 hour team code review.
  • Every two weeks a 1 and a half hour team retrospective.

The team has a high level of autonomy with a very flat management structure. While people vary in experience, there is no concept of a ‘senior’ or ‘junior’ role - everybody’s opinion counts and anyone can put forward a process improvement idea. Big team process decisions are typically done in the team retrospective.

The best way to describe the team is as a continuously adapting development and operations team.

I have changed the names of the individuals in this post, but the events are real…;-)

The Experiment

This month we did something I would never have thought of doing on my own - we killed all planned meetings including daily stand ups, code reviews, brown bags, etc.

The idea came from the team retrospective - as a team we were struggling to identify which aspects of our meetings we were finding valuable and which we weren’t. Instead of going down the road of long theoretical discussions on why each part of each meeting was necessary and should remain, we decided to instead cancel all planned meetings for two weeks and see what we missed.

The Rules

The rules were simple…

  1. We would run the experiment for a minimum of two weeks, after which we would get together and re-evaluate.
  2. Team members could still organize informal meetings, but nobody had to attend anything.

The Experience

Day 1 - Fun Times

The day after the retrospective it felt weird. At the time our usual stand up was meant to occur I remember feeling like we should be doing something. Everbody laughed when this was brought up in the team room. I wondered how our product manager would react when he got back from leave and found out about the experiment.

Day 3 - Reaching Out

Three days into the experiment Dave, who is a developer on the team, sent the following email.

While it’s on my mind, I want to share the things I miss from not having had stand ups for the past 3 days:

- Feeling disconnected from what other people are busy with.  
- Knowing where people might need help.  
- Knowing our - deployment state - are we deploying?   
- With regards to what’s broken and who’s looking at it

I know I can go around the team and ask all of these questions, but that seems like high transaction cost vs. doing it once for everyone’s benefit.

Maybe you’d like to share your own observations in this email thread, seeing as we don’t have a stand-up to share it at?

I could relate to Dave’s email. The progress on other peoples work was beginning to blur.

Day 8 - Frustration

Five days after Dave’s email the first reply came in from Sue, who was a tester in the team…

I feel like I just joined a new team.  
Don’t know what’s happening, what people are working on. 
Being in a testing role I feel the disconnection the most.  
Bring back the Stand Ups!!!  
I cannot cope!!!  

George - a member of another dev team who had a dependency on our team and usually attended our stand-ups…

If Sue is feeling disconnected in the same room, imagine how we feel.  
I know we’re moving apart as 2 separate projects, but the interaction is still missed.

Gary, our very brave product owner who had been on leave when we came up with the idea but had supported the team added…

I second the notion for stand ups to return. Things feel disconnected in many ways.  

Any nay-sayers?  

Collin: Any suggestions on the format of stand-up as a first iteration? (I hear you having some ideas, couldn’t follow all the details)  

Dave responded to Gary’s email with…

I propose we start from first principles. Discuss what things are important to everyone which we need to sync on, and start there. We can treat this the same way we do everything - do something small, get feedback, iterate on it. We built the board up this way from a blank space, why not the-thing-we-do-to-make-sure-we’re-on-the-same-page, which may not be a stand-up.  

There was general chatter on Dave’s email - I’m not going to record the specifics - but in essence the whole team agreed they liked the first principles approach.

Day 12 - Disconnection

Two days before the end of the two week experiment Dave sent out the following…

I feel like I have stopped caring about how the team as a whole is delivering. My focus shifted from how we can get stuff out as a team (help remove obstructions etc.) to: I just care about what I’m busy with unless asked for help by someone else. This is obviously a problem as we are as a team responsible for delivering value, and not as individuals.

By this time I had lost total connection with the rest of the team. I had been working with another dev on the team on a specific user story for the week. I had too stopped caring about what others were doing. It didn’t feel great.

The Feedback

At the end of the two weeks an email was sent out with the following questions…

Can you answer the following?
- What you liked about it.  
- What you didn’t like about it.  
- Do you feel it was a worthwhile experience?  
- Any other insights you gained from the experience.  

The following is the collated feedback from team members…

What you liked about it
  • Less interruption while working in the morning.
  • Having the timeslot open. I’ve realised that for the current stand-ups timeslot is terrible. It’s often a very good time to meet with business, so always having it blocked out in your calendar is not great.
  • No time wasted before and after stand-up. With the timing of our old stand-up, I often found myself not being focussed before and after.
  • I didn’t have to listen to stuff that doesn’t interest me.
What you didn’t like about it
  • Feeling very disconnected.
  • Not getting the big picture of where we are and where we are going on a daily basis.
  • Not being aware of what other people are busy with and more importantly what they need help with. Often people can be stuck for a few hours and a few comments at stand-up get the process moving again.
  • Disconnection with team.
  • Not sure where else I can help before starting new work.
  • CFD numbers seemingly lost (I felt these were important although it seems other don’t).
Did you feel it was a worthwhile experience
  • Everybody responded yes.
Any other insights gained from the experience
  • I have noticed that slowly people are starting to ask around questions about what work is happening and where they can get involved. With Stand-up not happening, it took about two weeks for us to start developing alternative ways of trying to connect with the rest of the team. Even the emails re missing stand-ups was a way of people saying – “Hey I feel disconnected – let’s reconnect”. The trick would be to keep that general interaction happening while re-introducing stand-up
  • There is stuff that happens in stand-up which should happen offline.
  • Separation between board and stand-up: I don’t think the board was updated at all.
  • Gaining insight into our process as a whole is troublesome.

We then had a team retrospective where we discussed what we missed and what we didn’t miss from experience…

What we missed
  • Team
  • Shared Ownership
  • Interaction
  • Sense of progress / celebration
  • Sense of identity / coolness
  • Forced the board to be updated
  • Facilitated quicker problem solving
  • Big view of the flow
  • Jokes
  • Smart Goals
  • Checklist
What we didn’t miss
  • The phrase ‘Lets take that offline’
  • To much detail given in daily stand-ups.
  • You can green dot that.
  • False sense of us doing something useful.
  • The time of stand-up.

Where to from here?

We decided to reinstate a vaery basic daily stand-up meeting and that we would rebuild that meeting and our other meetins up from first principles. Each day we would add one additional thing to the stand-up meeting format and then see if we wanted to adopt it or drop a previous addition.

To start with we said we would ask for each story being work on whether it should move.

We also had a bit of a debate about the time we should hold stand-ups. Different people wanted it at different times. We eventually decided to hold stand-ups as the last activity before the day ended. We believe this may not be the ideal time but since we have never had stand up that late in the day we decided to give it a go for a few days and then re-evaluate. Embrace the fail fast principle.

Original Notes

What we liked

Killing Standups what we liked

What we didn’t like

Killing Standups what we didn't like

blog comments powered by Disqus

Want to get my personal insights on what I learn as I learn it? Subscribe now!