Monday, August 31, 2009

Why does Scrum feel so good?

Everyone likes the feeling of having success. And nothing is more depressing than a consistently growing bad feeling that something is not right or heading in the wrong direction. Typical example of such bad feelings: hearing or reading for the 5th time "it's 90% finished".

So what is the great mood enlarger in agile, iterative methods like Scrum? Simply its transparent progress of small and visible results!

And this is not only for product owners to quickly see what they expected but also for the development team to quickly get positive feedback and as well for scrum masters to quickly see that their mentorship is fruitful.

Quick satisfaction with your own work is a success key of being agile!

Friday, August 28, 2009

Daily Video Scrum

Implementing agile methods like Scrum relies on broad communication. With a distributed team there's a need for much more heavy communication. Unfortunately the distributedness of a team complicates easy communication. In most cases the common ways to send and receive information is
  • one-to-one/many by email: the most anonymous distributed communication from one person to a group of people. Advantage: ability to spread complete and detailed information. Disadvantage: uncertainty of the message being read and understood.
  • one-to-one by phone: the most direct distributed communication between two persons. Advantage: direct feedback is possible. Disadvantage: not useful for team communication.
  • one-to-many by phone (phone conference): mostly uni-directional communication from one person to a group of people. Advantage: team communication is limited but possible. Disadvantage: direct feedback is hidden.
  • many-to-many by meeting: ideal way of team communication. Advantage: face-to-face in one room, ability to use boards, cards, beamers. Disadvantage: unable to participate for distributed team members
Best solution for distributed teams: use a video conferencing system with all team members in front of the cameras. That way you virtually enlarge the meeting room and can use most of the advantages of a usual meeting. By adding a beamer to each side of the system and setting up a remote desktop infrastructure, all other tools can be simulated as well.
I initiated a Daily Video Scrum for my distributed development team. Of course a little more preparation is needed to start the video system and, the beamer. But it's worth the effort - try it and you will see the benefits!

Planning Joker

In one of our last planning poker sessions the team was asked to give estimates for a story. Surprisingly all of the team members chose either a 100, an infinite card, or a combination of cards to express the weirdness of the story. After some explanations it came clear that we were missing an important card in our deck: the Planning Joker!

What's the meaning of the Planning Joker? - "I will not estimate this story as it is completely crazy."
If a story has a vast lack of meaning and does not contain any useful information then the Planning Joker is the right choice. An example for such a story would be "as a user I want to see all information" - whatever this means, it is not estimatable and needs clarification by the product owner.
Besides of a new meaningful expression in your poker sessions, the Planning Joker adds some healthy amount of fun to these sessions. Try to use it and see if it works for you - feedback is highly appreciated.
Thanks to Anton Morozov for the nice drawing of the Planning Joker.

Thursday, August 27, 2009

Iteration planning: hours of tasks or number of tasks?

I recently had a discussion with another Scrum Master. He participated as a chicken in my sprint planning meeting.

When the team had finished the breakdown of user stories into tasks, I wanted to get estimates in working hours for every single tasks of the sprint. The other Scrum Master wondered why I insisted on getting those hours. He would have just worked with the number of tasks in the sprint rather than put more effort in getting those estimates. In his eyes that would be sufficient to track progress and draw an iteration burndown.

In my point of view it is not enough to have the number of tasks solely due to following reasons:
  • task sizes are unknown and not comparable
  • it is difficult for the team to choose open tasks for the next day without knowing an estimated effort in hours
  • it is impossible for the team to honestly commit to a story on the basis of story points (or ideal days) only
  • the iteration burndown will get more realistic and shows "real work done"
Finally an iteration contains a more detailed scope than a release so more detailed estimating and planning has to be applied.
Bibliographic recommendation on this topic: Mike Cohn - Agile Estimating and Planning (

Saturday, August 22, 2009

Information Overload: Focus on the essence

Why am I starting to write the first post of my own blog? What do I expect? What do readers expect from my blog? And who has answers to all that questions?

I just asked myself how many time one has to spend to be updated with all news from Facebook friends, Twitter followings, Xing and linkedin contacts, and all other interesting information sources. Summed up I

  • have 315 direct social networking contacts,
  • am subscribed to 30 interest groups,
  • am member of 4 organizations, associations, or institutes, and
  • have been in email contact with more than 1.000 people in the last 15 years.
Let's assume an activity rate of 5% for my email contacts and 10% for my social networking contacts. This will lead to some 80 active contacts - with one message a day resulting in 80 messages daily.
Let's further assume that the interest groups and other organizations publish 5 messages as daily average. This will lead to some 170 messages daily.
So I should deal with 250 messages every single day - that sounds quite exciting! This is probably even more exciting when returning from a 10 days vacation...
To make a long story short: it's just not possible to handle such vast amounts of information!
What's the solution of all of this? Focus on the essence in three steps:
  1. Read only the subject of an email, the abstract of a paper, the labels of a blog. Dismiss highly uninteresting topics instantly - do not keep them to postpone your time, just get rid of unimportant things.
  2. Cluster all information and try to delete as much redundant or outdated messages inside each cluster - this will reduce the number of messages.
  3. Dare to delete everything which needs no urgent attention - people will get back to you if it's really necessary.
Focus on the essence:take care of the interesting, the new, and the urgent - simply ignore all other information.
Try it and be agile!