Archive

Posts Tagged ‘AgileWall’

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 , , , , , , ,