Posted on

Are You a Scrum Master? Be a Gardener.

I have recently been reading Jurgen Appelo’s book Management 3.0: Leading Agile Developers, Developing Agile Leaders. For those wondering what management’s role in an Agile organization should be then this is a good read.

In my current consulting gig I am coaching someone to replace me as a scrum master so we spend a great deal of time talking about Agile, Scrum and what it means to be a scrum master.

One of the things I have always used as a metaphor is the concept of Scrum Master (and managers) as gardeners. Though I may have heard it somewhere and forgot it or it may have reached my subconscious somehow, I came up with the metaphor of gardener because my in-laws live with me and are retired. They spend a great deal of time gardening. It is from their work bringing forth trees, flowers and mountains of vegetables that I took my cue.

Continue reading “Are You a Scrum Master? Be a Gardener.”

Posted on

The Fourth Agile Principle

“Business people and developers must work together daily throughout the project.”

I was in a backlog grooming meeting this morning when I was given reason to reflect on this, the fourth, Agile principle. The reason was that the team I was working with was struggling/arguing about the proper wording of a story. To a few on the team the absolutely precise wording of the story was of paramount importance. While I am a big fan of precision, the vehemence of the need to be precise was a bad smell. It took me some time to realize where the stridency came from.

Continue reading “The Fourth Agile Principle”

Posted on

Not Burning Down? Diagnosing and Fixing the Some of the Problems

Of course you would not expect every sprint to have a perfect burndown. You would not expect to complete every story in every sprint (my goal has always been 90% or greater stories complete), but if you are finding yourself with many “overhanging” stories each sprint there are a number of things that you can do to diagnose and fix the issue. In this particular post, I am going to discuss problems with time and hours.

There are three things that can go wrong with hours:

  1. The number of hours the individual estimates for capacity is too low.
  2. The number of tasks identified is incorrect (not enough tasks identified).
  3. The number of hours associated with each task is too low.

Continue reading “Not Burning Down? Diagnosing and Fixing the Some of the Problems”

Posted on

Trust and Agile

I had the wonderful opportunity to have a panel discussion recently regarding Agile. In my warped world, there is no greater pleasure than getting grilled on how Agile can be implemented in the real world. As such conversations are wont to do, a consistent theme emerged. In this particular conversation it was all about Trust.

If someone asked me to pick one word that could be used to describe a low functional Agile team versus a high functioning team, there are two words that come to mind – Discipline and Trust. Of these trust is probably the most important in that it can be hard to acquire, difficult to keep and easy to lose. As a scrum master, my team has to trust that I have their best interests in mind at all times, that the metrics I compile will never be used to punish them. They need to trust each other to be able to commit to a body of work for any particular sprint, etc.

Continue reading “Trust and Agile”