Feeds:
Posts
Comments

Archive for September, 2012

What is an effective Stand-up?

Posted in Agile, Agile Back to Basics, Agile Practices, Scrum on September 26, 2012 | 4 Comments »

Can them what you will – Daily Scrum, a Huddle or a Stand-up, but whatever you call it a Stand-up is one of the simplest Agile (and arguably knowledge and service management) practices  out there. Three questions are answered by the “core team”:

  • What I’ve done since we last met…
  • What I plan on doing till we next meet…
  • What is impeding me or may soon…

Simple right? Wrong!

These very simplistic set of steps have led many to believe that the key purpose of a Stand-up is as a progress report. To set the record straight:

The key purpose of a Stand-up is the opportunity to collaborate, share and support each other in the delivery of valuable outcomes.

For those that may not have heard of the above interpretation of a Stand-up’s purpose then let’s take the opportunity to understand it further. As each person answers the three questions what the rest of the team should be doing is listening and wondering to themselves the following questions:

  • How will this impact me?
  • How will this help me?
  • Will my work impact them?
  • Can I help them?
  • Can I potentially learn from something they are doing?
  • Can something I’ve done in the past be useful so that they can learn from it or re-use it?

If the answer is ‘Yes!’ to any of these questions then the team member should pipe up and respond. An effective Stand-up isn’t just the team turning up on time and answering the three questions – it is where teams work together to deliver and reach the delivery goals whilst always upholding the values and principles.

Another common Stand-up myth is that they should be 100% valuable to 100% of the core team 100% of the time. This is simply not the case. As we now understand what an effective Stand-up is you will be lucky to find these opportunities consistently and rarely more than three times in a single Stand-up. In fact, you might go through a few Stand-ups before such an opportunity arises – these uncommon instances of “I’d love to learn more about how to do that, care we pair?”, or “I’ve had a similar problem on my last project let me send through to you what we did”, or “I know that person well, let me talk to them and try to push the impediment out” are what make good Stand-ups.

We’ve all heard of tips like taking difficult conversations offline, ensuring everyone can be heard and timeboxing each person to no more than 2 minutes but here are a few tips that I would additionally recommend to make Stand-ups a little more effective:

  1. Touch your cards. If you don’t do this as you are talking the team is mentally trying to match the first sentence of what you said to the Story Wall. As they are doing that mental matching they are no longer listening to what you saying which consequently invalidates the value of the Stand-up.
  2. Take 2-3 mins before the Stand-up to jot down what you want to remark on. If you don’t do this you dramatically increase the likelihood that you are spending time, whilst others are talking, concentrating on what you are about to say. You need to be in the moment of what the team are saying, not what you are about to do.
  3. Jot down any issues or risks remarked on. Ensure that they are visibly attached to stories with clear owners and status/actions.
  4. Hold each other accountable if a team member is talking about work that isn’t reflected on the Story Wall – get the story written up and prioritised against everything else on the go.

Note: Astute Agilistas will notice the subtle changes in the core three questions. Primarily this is because I have seen effective Stand-ups that whilst they are regular and frequent shift away from the activity being daily. Additionally I like to tack on the “or may soon” to the last question because whilst the question focuses on issues the “may soon” is a focus on possible risks.

Read Full Post »

Dazzling Dones: Using the Done column more effectively

Posted in Agile, Agile Practices, Kanban, Scrum on September 18, 2012 | 2 Comments »

Jvonvoss at Minds.coremedia.com recently did a very interesting blog – A World without Burndowns: The Unified Taskboard. It was an interesting concept – use your done column to replace your burn down chart.

Normally a taskboard will look like this:

 

The done column is just a list of everything that the team has achieved. Colour may be used to denote expedites.

Using Jvonvoss’s advice a standard Iteration Wall would have the Done column split into each day of the Sprint:

 

In this example, whilst on day 9 we know with certainty that we wont get through all the cards within the next two days as we have been consistently achieving 2 cards per day.

 

In the above example knowing whether we would finish all the cards by the end of the Sprint would be harder to work out – but the interesting reason is why. We can very easily see that the daily throughput is spiking up and down a lot. There is a constraint in the system. You would likely be able to see this as well in a Burn Down chart but visually this would pop more for visitors or managers that walk by.

Using Kanban, similar concepts of visualisation within the Done column can be used to track cycle time. In the example above we can see some outliers, but a majority of the cards are being done within three days and expedites are getting done on the same day. Again this won’t necessarily replace other graphs but the transparency is more apparent.

 

 

Lastly, how could you use a wall to track demand over time within the service industry? Cafes commonly print orders on dockets and add them to a backlog of beverages to produce. As the Barista becomes available they take the next priority item in the backlog and begins working on this. Imagine that when done putting the docket up on the wall by the hour that it came through – what would this enable a cafe owner to do? You can see from the above image that the peak time is 8-9 – you would make sure the majority of staff were on at this time, between 12 and 2 you would likely rotate lunch breaks and you might choose to close down earlier than 6 given how few the orders are in that time slot.

What other ways could you think of using the Done column?

Read Full Post »

Radical Management: A Book Review

Posted in Agile, Book Reviews, Management, Stoos on September 14, 2012 | Leave a Comment »

When I mentioned to some community friends that I was going to be reading Steve Denning’s Radical Management book a number of them looked at me as if I had contracted some form of virus. “Why would you read a dumbed down book on Scrum?” they said.

The answer for me was simple -

  1. Agile, I feel, isn’t an easy concept for Managers to get. I wanted to check the three prominent books on the market that are there to help Managers become Agile in order to see which one I would recommend if I ever had a manager (which admittedly to date I haven’t) one of them asked me for a recommendation.
  2. Because I do feel that it is hard for Managers to get Agile I wanted to see if there were any hints to what I could do differently or on what practices are relevant for Managers.
  3. I really like Steve Denning’s HBR articles. He has a beautiful writing style which I can appreciate for its simplicity and purpose.

Within this book review I won’t be comparing this book to the other two (although I might do then when I review those), instead I want to focus on my thoughts as I read the book.

Firstly, focusing on my third point above I was not disappointed. For the most part I did continue to enjoy Steve’s writing style in this book. Most pages I felt engaged in and whilst the pages didn’t all fly by, certainly up to the end of Chapter 9 they did (from there it does drag on a little).

Secondly, for a manager that has absolutely zero understanding of Agile and has focused for most of their management tenure on traditional command and control methods, either intentionally or not, I feel that this is an excellent book… to start them on the mental journey.

Which brings me into my third point. It tries to give a practical angle of applying it but I couldn’t in all honesty give this book to a Manager and expect them to be able to do the practices effectively. In fact, in a number of instances there is no detail on how to do a practice. So what this book does really well is get Managers to begin to question what they do and how they do it, less so actually enact change. This could be perceived as quite a concern for many but I don’t think it is that big of a deal – the difficulty is in the mindset change and this book does address well why you would want to shift from being a traditional manager to a radical manager. Additionally the book is riddled with references so if you did read this book and wanted to find more than there are a huge number of useful references at the back.

Now for the negative bits (which I don’t feel outweigh the positive):

  1. Some of the examples are poor – they don’t get the message across or they are weak links to the lesson. Steve is a good storyteller, just a few of the stories are duds. The first one in Chapter 10 is an example of a dud, as is the communicating example further in the same chapter. The roles in Chapter 1 also felt disconnected.
  2. The focus is strongly on Scrum. There is little content on Lean and only a sentence or two on Kanban. It would have been nice to have a broader view of being radical aside from Jeff Sutherland’s perspective. I was aware of this prior to reading the book so maybe I was a little more conscious of it than most readers would be. That said, I actually find that non Iterative Agile is an easier concept for Managers to understand.
  3. Iterations. I’m left with a feeling that Steve doesn’t understand what an Iteration is. It seemed to hint more towards an increment rather than an iteration. The examples that he gives on iterations are poor and for a fundamental principle I think it could have been articulated further.
  4. There are some occasional inaccuracies in advice (in my humble opinion) – like the concept that Value Stream Maps would find the phantom traffic jam problem and what defines “divergence” when using Planning Poker.

So it might be early days to know what book to give to a Manager to learn Agile (even if this was not the intent of this book and it’s intent was to be wider in focus), but overall I would give it a 7/10.

Read Full Post »

If a story is a promise for a conversation then…

Posted in Agile, Agile Practices on September 5, 2012 | Leave a Comment »

  1. If a story is a promise for a conversation then… an estimate is a promise to potentially get it wrong
  2. If a story is a promise for a conversation then… a retrospective is a promise to follow through on agreed to actions
  3. If a story is a promise for a conversation then… a vision is a promise to make some SMART goals and then re-evaluate if it is achievable
  4. If a story is a promise for a conversation then… an epic is a promise to break it down
  5. If a story is a promise for a conversation then… a minimal viable product is a promise to deliver the smallest amount possible to learn
  6. If a story is a promise for a conversation then… an Iteration is a promise to not introduce change within it
  7. If a story is a promise for a conversation then… a minimal marketable feature is a promise to deliver value as early as possible
  8. If a story is a promise for a conversation then…  you really shouldn’t be writing that 20+ page specification – get up, walk over to the team and start having a conversation!

Read Full Post »

The purpose of a Scrum Master

Posted in Agile, Agile Back to Basics, Agile Practices, Culture, Leadership, Scrum on September 3, 2012 | 26 Comments »

I have been pondering lately what the purpose of a Scrum Master or Iteration Manager is.

Many believe that it is a 100% full time role. Some are even concerned that there are formal positions springing up for this role.

Here is my stance (and work in progress model) on the role:

The purpose of the Scrum Master role is to create a self autonomous team through the usage of Agile.

  1. It should never be considered a 100% full time role.
  2. It is a transitory role – there to enable a change in the team.
  3. The change is a change from an environment of Command and Control to an environment of autonomy and empowerment.
  4. The goal is to deliver value to customers frequently and regularly through creation of this environment. The goal is not to have a Scrum Master job for life.
  5. They do this through a series of steps.
  6. These steps are based on Situation Leadership with some tweaking:
    • Directive – The Scrum Master is telling the team what to do and how to do it. This is sometimes common when the team is new to Scrum/Agile and are still learning the rulebook.
    • Facilitative and Advisory – The Scrum Master facilitates cadence activities and advises the team on possible options but is not the final say.
    • Cross Facilitative – The Scrum Master engenders an environment where other team members are starting to facilitate the cadence activities. At this stage the Scrum Master is no longer rounding up everyone for the Daily Standups, instead the team self form and remind each other.
    • Coaching and support – The Scrum Master is only there to course correct and even then only does it through team reflection. They don’t advise on options, instead they engender an atmosphere where the team can come up with their own solutions.
    • Double loop learning – The Scrum Master is ready to hand over the team to itself. The team reflect not only on how they are working together but why they are doing practices in a particular way. It is creating an atmosphere of learning transcendence.

So what, you may ask, does a Scrum Master do as their time with the team whittles down? They do what any good team member in a Scrum team should do – they deliver User Stories!

Read Full Post »

Follow

Get every new post delivered to your Inbox.

Join 604 other followers