Archive

Posts Tagged ‘AgileWall’

Is your stand-up meeting boring? Try the “Walk the Wall” Stand-Up

February 28th, 2011

Stand-up Meetings are a simple, yet effective, way of getting teams to communicate, commit to short term goals and solve problems. There is a proposed format for stand-up meetings which suggests that each team member should provide answers to the following three questions:

  • What did you do yesterday?
  • What will you do today?
  • Are there any impediments in your way?

Have you ever done that and eventually it turned out to get pretty booooooring? I have… Countless times…

Yesterday/Today Stand-Up Meeting (Traditional Proposed Format)

The Yesterday/Today format is a good way to start with, do not get me wrong. I think it’s very important for teams that are not used to communicating daily to start with that format. I just think that we should always look for improvements as opposed to just following a pre-determined format… Recently we have been trying something a little bit different and it turned out to be much more effective, I’ll explain why. Jason Marcotte coined the term as the Walk the Wall Stand-Up Meeting, I quite liked it.

Basically the sequence of the stand-up meeting is determined by our Story Wall. Each item on the wall gets discussed taking into account the 3 questions mentioned before. Martin Fowler reminds us on his post to “Focus on the Backlog” and this is what this new format is all about:

Walk the Wall Stand-Up Meeting

Here are some of the issues that we are addressing by doing the Walk the Wall Stand-Up.

Monologue/Soliloquy

During the Yesterday/Today Stand-Up we noticed that each team member ended up talking alone and in sequence, usually there were no discussions or quick Q&A. That defeats one of the main purposes of the stand-up, which is communicating. I found a word that describes what we were experiencing: Soliloquy.

Walking the wall allows more than one team member to talk about something, e.g.: explain what they were working on yesterday. It could be that they were actually pairing on that particular item and have similar things to say about it. It also allows people to talk to each other about a particular item (Story, Task or anything on the wall) that is relevant to the entire team. After implementing this we had developers/ba’s/testers talking more about a particular item.
But…
Keep an eye on the quiet members of your team… One of the good things about the Yesterday/Today stand-up is that everyone gets to say something, which empowers and therefore motivates them. The facilitator should perhaps ask direct questions sometimes.

Means to an End - Tasks/Achievements

The three questions above suggest that each member has to explain “what they did” as opposed to “what they achieved”. This leads people into explaining the “tasks” that they executed, as opposed to “goals” that they achieved. E.g.: “Yesterday I went to meeting A and I wrote document B and I paired with John on story D”. There’s a lot missing there:

  • What was achieved?
  • Do you need anything from anyone here in order to proceed?
  • Is this harder/easier than what you thought? Can someone else help?

We see those discussions happening when it’s focused on the stories. It is easier and more likely that someone will mention that “In order for me to finish Story A I need help from a BA” for example.

Facilitator

We also learnt that it helps to have a facilitator during the the stand-up just like we do with retrospectives.

Walk the Wall Stand-Up Meeting with Facilitator

But…

  • It is not a micro-management status update when the manager asks everyone what they are doing and how long it’s going to take so that he can update his Gantt Chart.
  • Rotate the facilitator
And always try to think outside of the box… Do not just follow recipes, be creative and invent your own ways of improving, mix and match and see what happens… :)

Technical , , ,

Funny Story Wall Avatar

May 10th, 2010

No, I will not talk about James Cameron’s blue Jack and Rose new Titanic, aka Avatar.

“An avatar is a computer user’s representation of himself/herself or alter ego, as a two-dimensional icon (picture).

http://en.wikipedia.org/wiki/Avatar_(computing)

Usually on our agile projects, we like to put up walls with big visible charts and walls where we, and other stakeholders, can see what’s happening. One of the most commonly used types of wall is a Story Wall, where one of the messages that we try to convey is who is working on what

One of the ways of doing this is to stick the name or a photo of the person (or pair) who is working on a particular story. One of my life and work philosophies is that a hint of fun in almost everything very seldom hurts, on the other hand it brings a new and better atmosphere to the environment. So why not put a little bit of fun on the story wall?

My current team:

Nigel Fernandes had a goatee very similar to Ali G’s.

Prabin Deka has been using a scarf indoor, which reminded us a little bit of the posh Jude Law.

Ken Friesen is, obviously, Barbie’s husband.

And why is this Fabio supermodel so famous? I get that all the time… Damn it. :)

Funny Story Wall Avatar

Try to be creative and come up with your own Avatar Selection Criteria… Phillip told once that he likes to Google for images with the person’s name and pick one from the first page… That’s a good one as well.

Anyway, the rule is to have a bit of fun.

Oh, I almost forgot the best Avatar on our project… Luke Stubbles got his name misspelled as Stubbies… And here is his photo.

Technical

Technical Debt Wall Retrospective

September 1st, 2009

Although we should avoid as much as possible Technical Debt, most of the projects end up incurring some of it. However it is important to know “how much” we owe and how much interest we are paying.

Know your debt

Recently on our project we did a Technical Debt Retrospective. Basically we brainstormed on the wall all the Tech Debts we thought we had incurred since the beginning of the project. Then we decided to categorise them by Effort and Pain:

TechDebtRetroEffortVSPain

“The relative effort that the team would have to spend in order to pay this debt.“

Pain is the direct impact on productivity that this debt causes. (interest)”

Keep paying down the principal, not only the interest

If we do not pay down the principal of our debt by refactoring our code we will always be paying just the interest, which means reducing the productivity. The question we asked ourselves was “Which ones should we pay first?”

Looking at the four quadrants of this wall we can identify which ones we can pay so that we can have the highest return.

TechDebtRetroEffortVSPainHighReturnNotWorthOne interesting thing that came out of our retro was that the High Return section was almost empty. We came to the conclusion that this was a good sign, it means that we had already fixed most of the LowEffort/HighPain debt during the normal development. Which is exactly how this type of debt should be paid.

After the retro we kept the Technical Debt Wall next to our Story Wall. From that day on it should become an ongoing wall that we will keep an eye on… Paying whenever possible…

Technical , ,

Goal Driven Retrospective

November 23rd, 2008

Retrospectives are usually conducted in order to keep the continuous improvement engine wheels working properly on a project. It is present on most of the agile processes I have worked with, such as Extreme Programming (XP) and Scrum.

The image below describes retrospective that most of us are used to:

DC93A7F3-2D9D-4525-8301-D40AD993E66F.jpg

On my last project at ThoughtWorks I had the opportunity to introduce to our client, together with Jason, a new type of retrospective, the Goal Driven Retrospective.

Goals and Actions

The Goal Driven Retrospective brings the idea that we should be much more focused on creating actions to achieve common goals shared and agreed within the team and also that will definitely add business value to the client.

7D1B763B-BDAB-40DD-B4C1-5DAE8E3D55EA.jpg

Examples of goals:

  • Zero bugs in UAT
  • Productivity x 2: If a similar feature is required, the team should be able to implement it in at least half the time that they took at the first time
  • Improve work environment

Examples of actions:

  • Showcase and run selenium tests on IE to decrease number of browser dependency bugs in UAT
  • Refactor JSP’s and create a DSL to specify exactly what varies from one story to the other
  • Team lunch to improve work environment

It is essential that the person who is facilitating the retrospective, usually the Scrum Master, XP Coach, or Iteration Manager is aligned with the goals of the organization.

Values

In order to prevent conflict of interest, all the goals are defined based on values:

  • Productivity
  • Cost
  • Quality
  • Morale

By following these values the actions will make the team:

  • Faster
  • Cheaper
  • Better
  • Happier

All the actions must be aligned with all the values.

Some examples of actions that would not be acceptable because they go against values:

Where is morale?
What if someone suggests that in order for the team to be twice as productive they need to work 16 hours a day? If you just had that face and thought: “Come on, we know that this doesn’t work…” you are smart aligned with the values, but remember: this is not common sense.

Slow slow slow… what about productivity?
Or what if to achieve zero bugs in UAT we try to test and automate every single possible scenario in the whole application?

The picture below shows the output from the retrospective we had on the client:

01FAA51A-D2CA-40CC-8F29-8606B3666D5C.jpg

I strongly encourage everyone to give it a go and try this new way of improving.

Technical , , , , , , ,