What a ScrumMaster Can Learn From a Mountain Guide – Preparing Breakfast

Having experience as a mountain guide helped me understand how teams work in various situations. Some of the behaviours apply to the professional world as well.

P1080194.sized
Photo courtesy of Tomasz Rosiek

Imagine you wake up on a sunny morning in the tent piched on the mountain pass. The first task for the group, after crawling out of their sleeping bags: prepare something to eat.

Process

You may count on some people being very helpful (or hungry ;)) and eager to spread jam on slices of bread, but most of your team is probably yawning or hesitating what to do.

What you need to do is:

  1. Start working – cutting the bread, vegetables, etc.
  2. Encourage others to join (inviting by name works best)
  3. Withdraw after short time, let someone else cut the next cucumber.

The most important (and the hardest) part is 3. It is easy to get involved into something, but there are probably more important things waiting for you (campfire, water supplies, plans for the day, oh, lots of stuff). If you do not start leaving work for others you will quickly end up doing more you can manage.

Tools

I have encountered it over and over again – some people do not pack knives. They are generally willing to help, but they do not have a crucial tool. I ended up bringing spare ones on each trip :evil:.

Your responsibility as a leader is to start, show an example and ensure people have everything they need to acomplish the job. After that do yourself (and your team – in the long term) a favor by taking a step back.

Retrospectives and Experiments

On team retrospectives this point seems to be the hardest one – deciding upon specific action points. Gathering data and discussion are much easier parts 😉

Experiments

Here is an approach to make commitment for the action points a bit easier – make them experiments.

Try an idea for a week and see if it works. Put a clear timeframe after which an experiment is collectively evaluated by the team.

Our case

During company retrospective at SoftwareMill we had a discussion on improving our (remote) communication and we were considering using Mumble. Not everyone (including myself) was sold to this idea, but we decided to install it anyway and asked everyone to give it a try.

What brought me round to do the experiment was Tomek Szymański‘s reply to my concerns:

“How can you say you do not like it if you have not tried it?”

Within two or three weeks of experiments we ended up with a different tool (TeamSpeak gave us better quality). For some of teams it turned out bo be their favorite communication channel, other teams decided not to use it, but at least they made a decision based on their experience instead of speculations.

How does it make a difference?

This approach is especially useful if the proposal for an action point breaks the current habit or is somehow unusual, which makes some of the retrospective participants concerned about it. An experiment is a better idea for such a case than trying to enforce a solution.

For a team making the commitment for just a week or so is much easier. And maybe at the point of evaluation (which may happen on the next retrospective) those who were concerned will change their mind.

Give it a try!

So, next time you are stuck on a retrospective try conducting an experiment 🙂 Let me know how it worked for you.

-Paweł

My Talk @ GeeCON 2012

Tomorrow I am giving a talk “Visibility Shift In Distributed Teams” on GeeCON conference in Poznań.

Presentation abstract

Slides

If you are one of the geeks attending this great Java conference, join me in Room 8 at 11:30 to learn how working remotely looks like and what happens when an agile team gets distributed.

See you there!

JAXLondon – Lessons Learned

Last week I have attended the JAX conference in London. Here is a couple of highlights that attracted my attention enough to write them down.

Product Backlog

Roman Pichler about the Product Backlog:

Low-priority backlog entries should be much less detailed than those on top.

When (and if) their time comes, they will be probably split into smaller stories. This also shows that the backlog is something designed to be often changed (and reviewed!).

Why do you need to allocate time for gathering requirements/design/architecture work every iteration?

Think about the Waterfall approach and all the work done in the initial project phase, before coding. When following Scrum methodology this work still remains. The only difference is that it is now scattered among the iterations.

Guess the number

Jason Gorman came up with a great exercise during his Keynote. 2 teams were trying to guess the 4-digit number, taking turns.

? ? ? ?

One team was made to guess the whole number up front, while another one were free to guess it digit by digit.

Now, Dear Reader, guess who was able to figure out the number faster and which team represents the Waterfall and which one is Scrum 😉

Jason also pointed out that when building a software solution “how fast we learn is actually more important than how fast we deliver”.

Measuring effects of TDD

In the introduction to his talk, Keith Braithwaite showed a correlation of Cyclomatic Complexity values against the probability of faults being found, which I find really useful to convince myself to think twice before adding another “if” into code. And, yeah, at some point the probability reaches 100% 😉

Keith’s analysis of Cyclomatic Complexity distribution in various open-source projects proved that in the tested code one can observe higher preference for less complex methods, though there still remain parts of code of high complexity.

What is more, a nicely TD-Designed project’s code needs somehow express the same behaviour as the codebase with lots of “if” statements. How is this richness achieved? Well, maybe we trade off here more interactions (and greater coupling!) for less “ifs”.

We are all lazy

Last but not least, I found one explanation on why writing tests leads to shorter methods really interesting. Long methods may not be hard to write, but they make testing difficult. Big tests are hard to write indeed. So, when it comes to writing (long) test cases, your laziness forces you to… refactor for smaller methods, cause this will simplify testing!

The best presentation I have attended on the second day was Thinking Distributed to Improve Agility by Jamie Allsop, but… that is another story.

Daily Scrum: The Fourth Question

Let’s face it – Daily Scrum happens to be boring meeting sometimes. In the long run it may turn out to be tiresome routine, even for a team that understands its importance.

To make our meetings at SoftwareMill more interesting, we have implemented the idea of The Fourth Question, which I want to share here.

What is the question today?

Basically, apart from the usual three questions (Done yesterday. Plan for today. Blockers.) each member of the team answers additional one. What is the Fourth Question? Well, that is a good question 🙂

The question is announced by the ScrumMaster, who is free to come up with any question they like. This may be something connected with the project or personal.

Each day the question is different. Since in our team the person that leads the meetings changes every week, each member of the team has their chance to ask questions.

Examples

Here is a list of various questions that appeared on our Daily Scrums:

  • How are you feeling today?
  • Which day is the most effective day for you?
  • How useful this meeting is for you?
  • What have you learned recently?
  • What is your favorite shortcut in our IDE?
  • What should we do with people coming late for Scrum?
  • What did you have for breakfast?
  • What is your favorite movie?
  • What board game did you play recently?
  • What gadget have you bought or received recently?
  • What sport did you practise recently? (And when it was? ;))
  • Ideas to spend time with a child in winter.

Since we are a remote team, we have also asked each other questions like:

  • What type of the office chair have you got?
  • What have you got on your desk that is not connected with your work?
  • Do you listen to the music when you work?
  • How are you making notes?

(Authors: The Whole Team)

Areas of application

This technique

  • is useful for coaching
  • stimulates knowledge sharing
  • will help team members to get to know each other
  • will definitely introduce some fun and diversity 🙂

Guidelines

Of course having one more question might lead to the longer meetings, but with a little bit of discipline it is still possible to keep 15 minutes limit (If this gets difficult you can always ask “What can we do to keep the limit?” ;)).

It is a good practice to announce the question some time before the Daily Scrum. People will then come with the answers ready.

We favor simple questions that can be answered in one sentence.

Give it a try

If you like this idea, do not hesitate and introduce it on your next Daily Scrum meeting. Let me know how it worked in your team and what were your questions.

Have fun with the Fourth Question!

-Paweł

PS See also Łukasz’s post about this idea.

Agile Central Europe 2011 Impressions

Last week I had a pleasure of attending the Agile Central Europe 2011 conference and presenting my talk about working remotely there.

I felt that this conference would be special from the moment I received an invitation to join the open discussion on the way the event should be organized. What a fantastic idea!

The speakers, presentations and the way that the whole ACE! 2011 was organized were more than awesome. Here are the talks I liked most.

Paweł Brodziński – “Kanban: Improvements when you don’t look for them”

The presentation agenda displayed on a Kanban board served as a sort of an introduction (happening in the background) for those not familiar with the Kanban approach (including me). This way Paweł allowed himself more time to go beyond just the basics.

I especially liked the way Kanban shortens the feature lifecycle. Working in 2-week Scrum iterations I sometimes feel that there are too many various features being developed at the same time. Kanban helps to tackle this problem with it’s “Limit Work In Progress” approach.

Andrea Provaglio – Overcoming Self-organization Blocks

Probably the most psychological presentation at ACE! I really enjoyed the demonstration of rowing against the tide as well as the exercises led by Andrea during the Open Space.

By the way Andrea’s Open Space session showed one of the Open Space Principles in action. The session was so popular that the whole group decided to move to another room in order to have more space.Whatever happens is the only thing that could have.”

Marc Löffler – Kaboom – Blow up your watermelon

Marc‘s presentation was both entertaining and enlightening. The watermelon is indeed a perfect metaphor of what  happens pretty often in our industry when it comes to reporting to the management. What is red inside looks more like green when it reaches the top executives.

Closing Keynote – Jurgen Appelo

Both the insight and the way Jurgen presented the content were awesome. He definitely set a new standard for closing keynotes by quoting every single conference speaker in his talk.

I must admit I was impressed with how great this event was. Congratulations to Paul Klipp and all people involved in organizing the ACE! 2011 conference.

-Paweł

PS I am still thinking about the name for the software development method described by Maria Diaconu and Alexandru Bolboacă in their talk “Yes, You Can Deploy Every Two Days!”.