The Agile Tribe

What's your role in an Agile team?

Author: Susan Akers

 This is an issue that many people face working in an Agile team particularly those in the role of Project Managers or Iteration Managers

Common questions around these two roles can be – 

  • Are they the same role?
  • Should the Iteration Manager just be someone from the team?
  • How much time should be spent on being an IM? Full-time/part-time?

To help answer these questions and more, the Agile Academy has produced yet another handy Agile in Practice Help Sheet on Agile Team Roles and an accompanying video of the same name for those who want a bit more information about the difference between being a Project Manager and Iteration Manager; as well as seeing what other roles should be part of the Core Team and Extended Team.

1 Comment »

The Definition of Done

Author: Susan Akers et al.

The Definition of Done is an interesting one.  When is Done, actually Done?  While we say that the team including your customer should all agree on the same definition – this can be a challenge.

For example, a developer would probably describe the Definition of Done as “the minimum work that needs to be done to make the piece of code related to the story successfully integrate with the build” or something but how do other members of an Agile team see it?

According to a product owner, it may be “when they get what they have asked for”

For UI designers – and yes, they should be part of the Agile team right from the start.  It may be all about DONE DONE DONE”.

  1. Done – with writing the code and unit testing it
  2. Done –  with having it functional and integration tested…by the tester mainly
  3. Done – with UAT and accepted by the user.

All three DONE states have to be passed and only then is a story DONE. A story card can be broken down into multiple tasks if there are specialist skills to be applied ( i.e. Mainframe build, FE build, UI design) but the card is only DONE when all tasks are DONE, DONE DONE.  We would not write a story card for a UI designer separately…hence it is not relevant to them separately. The UI bit would be a task on one or more of the story cards and the card will not be done till ALL task are DONE and DONE and DONE.

A team may feel it is done when:  “A story is done when we truly believe that we will not have to touch it again”.  Simply – when the team thinks it is finished. This allows for undetected defects pushing it back. Typically, it’s after UAT.

The Agile Academy’s Definition of Done video explains in plain English how the different roles see Done and I would certainly recommend having a look!   Also feel free to share your comments and thoughts with the rest of the Agile Tribe here and on Twitter (@theagiletribe).  So what’s your Definition of Done???  Should it be different for different roles?

1 Comment »

Just give me a 'G & T'!

Author: Susan Akers

We talk about having a common language in the world of ‘Agile’ so that all members of the team (both IT and business) have a shared understanding. However, we still can’t seem to get away from the overuse of acronyms. I saw a new one this week and got to thinking about how clever are they really? 
Read the rest of this entry »


Agile Q&A: Wording User Stories

Author: Craig Smith

A former colleague contacted me the other day with a question along the lines of: “I am working with some guys who are looking at creating User Stories and there is a lot of discussion about how they should be worded.”
Read the rest of this entry »

Leave a comment »

Why so little good Agile?

Author: Shane Hastie (reproduced from Shane’s blog)

Today I gave a talk at the NZ Government Testing conference in Wellington. I presented a case study about how the Farm Systems Division of Livestock Improvement Corporation have adopted Agile methods.

I told the story of Team Awesome (they choose the name themselves), how their practices have changed and the measurable benefits that have resulted from their new way of working:

  • Massive reduction in residual defects
  • Increased team satisfaction
  • Shorter time to market
  • Increased customer satisfaction.

Read the rest of this entry »


The Family Agile

Author: Shawn Wallace

I have been using Agile techniques on projects for many years now to a point at which I can barely remember doing things any other way. Even so,  I have never tried using them outside of the office until recently.
Read the rest of this entry »


Be Lean by keeping words to a minimum!

Author: Susan Akers

Imagine if we limited speakers to 20 seconds per Powerpoint slide for a total of 20 slides – yes – a total of 6 minutes and 42 seconds.
Read the rest of this entry »

Leave a comment »

Lessons learned on my Agile journey

Author: Colin McCririck

On a recent walk by the story walls of nearby teams I noticed some small innovations which led me to say “have you seen …..” at our management stand-up. I’ve now found little things on one team’s wall have permeated across teams to their walls including:

  • Slow moving card sticker
  • Repeating card sticker (for tasks or other items that repeat in multiple iterations)
  • An ‘away sick’ and ‘on holidays’ area on the wall to put people’s avatars, so that these things are visible to all visitors and the team – a big advantage of this is – the reduction in email (one of my pet hates is using email for all communication).

Some of the above might seem trivial but small improvements often make big changes over time. They also made me think and reflect on how I have viewed Agile:

  1. Agile maturity comes with many small steps
  2. It’s important to encourage teams to make these steps themselves
  3. Copying between teams is encouraged and is not cheating (as schools might have taught!)
  4. Having a critical mass of Agile teams propels maturity further due to the copying synergy (i.e. shared learning).

I thought Agile was much easier in small teams and organisations but am now convinced large organisations have greater opportunity to push boundaries further in the Agile journey. However, it does require patience and commitment to long term gain through small improvements and a culture that allows and encourages it.

Leave a comment »

Agile is not a four letter word, but does go by many names.

Author: Susan Akers

As a non- technical Agilist I am often flummoxed by new terms that seem to be have been created by Agile technical people to talk about Agile and its practices and values. So I thought I would put together a little quick reference guide of terms that might prove helpful.

Please remember, that this is from my perspective and undertanding, so I’d be very happy to hear your comments if you have a better definition. I have completed some basic Agile training but the terms I am talking about here seem to be ones that people use on an operational basis. I also started thinking of providing a full A to Z first up, but it was too intensive for me, so here is what I have come up with, from A to G so far.

A: Agile – is a way of thinking and working. It requires a positive attitude towards collaboration with your immediate team members (or part of a broader team), an openness to embrace change and a willingness to act quickly. The goal being to produce workable solutions your customer actually wants, creating less risk and higher business value. This means quick returns (or iterations) so real results are seen in a matter of weeks rather than months or years.

A: Artifact. (yes, this is correct, not a typo). This is anything you produce during the development of a software or business project lifecycle. These could be – Templates, Diagrams, quick “How to” one pagers, or anything you can reuse for another project.

B: Brown Bag (or Lunch ‘n Learn). Usually refers to a lunch time training or information session (hence ‘brown bag’ to bring your lunch in, so can eat and listen at the same time). Some great examples can be found at:

C: Continuous improvement or Cha cha changing. If you can’t accept change, you might think you would hate working in an Agile environment. But, I’m sure that your team will think and talk about a project when it’s completed, and what went right and wrong and what you would do better next time. Congratulations! You have just conducted an Agile retrospective and are using the Agile practice of Continuous Improvement.

D: Do realise that Agile is not just about software development. Agile, as I mentioned under “A”, is a way of thinking about things which is why our business colleagues have taken to it. They have realised that they could use it on their own projects/tasks and gotten the same positive results about solving issues and continuous improving their process to make it easier and more successful the next time. They have also found that having a standup each morning has stopped the interminable wasted status meetings they once had.

E: Experience reports (also known as Field reports). Often seen listed at conferences. My understanding is that they are presentations where experienced practitioners talk about their hands-on experience and discuss case studies, the blockers they had and the lessons they learned from both their sucesses and failures.

F: Fishbowls. Normally this means getting 3-4 seats in the middle of the room (the fishbowl) with the rest of the team in an outer circle watching. Everyone takes a turn in sitting in the fishbowl sharing their concerns, asking questions, and also discussing proposed solutions. Usually one seat is left empty so that if anyone wants to join the discussion in the fishbowl they can sit in the empty chair.

To ensure there is always a seat vacant, an existing member of the fishbowl must voluntarily leave the fishbowl and free up a seat. The great thing about this is that it gives everyone an opportunity to speak so the discussion doesn’t get dominated by just 1 or 2 speakers. An example can be found at:

G: Go for the low hanging fruit. Make the quick wins. Don’t get caught up in the end solution – cut your project into small reachable goals (wins) along the way and do the easy and quick things to complete, first. Why? Because it makes everyone feel positive, and in spite of what challenges you may be facing you are also achieving!

Stay tuned for the next instalment of H to M. Feel free to send me your suggestions as well.

But for the time being:
That’s how Sue sees it! (Source:GLEE)


Agile is in the house!

Author: Susan Akers

I had the great pleasure to sit in on a talk given recently by Christian Scheiber, a project manager who has transferred his work experience with Agile to renovating his family home. Christian described it as an Agile journey where they have delivered several iterations and also put some stories into a backlog when priorities changed.

My first thought was – What a joy it must have been for his wife when he talked to her about what she wanted in the house and then he proceeded to fill the walls with storycards.

Christian argued that this helped both of them get a clear picture of how their requirements differed as the stakeholders so by setting up this basic Agile structure they were able to “get the right information at the right time” and the extensive upfront planning also gave them greater control.

So getting the right people involved at the right time is essential as well. What this meant was that Christian and his wife collaborated and used the MoSCoW principles to help them work out what was a Must Have, a Should have and a Could Have (or Nice to have). The business value to them was that they were able to describe their requirements clearly to the architect all at the same time and being a creative person himself, he understand the work required and how they, as users wanted to interact with each room.

It has not all run smoothly and what project, Agile or otherwise does? An unexpected blocker came in the form of how builders see things – not design, not the cost of this tap or wall unit, not how the room was to be used, the colours and all the other nice things you look forward to when building or renovating – No matter was the question was, the answer they always give was in Linear Metres!

So the renovation continues….. and so do the iterations and the strategies to remove the blocker. Agile remains in this house!

Leave a comment »