The Agile Tribe

The Zen of Agile

Author: Colin McCririck

We don’t really do TDD, we are a long way from achieving continuous delivery and our low levels of test coverage make releases a nervous time, but we think we’re pretty good at Agile.

I was reflecting on what I had learnt in the past year and how agile my team had become.  Despite immaturity at some of the key agile practices, in 12 months we deployed 79 releases to production for an application that is now processing 2 million transactions a day and serving 5 lines of business, 45 products and 3,000 concurrent users.   We ran four major projects concurrently while supporting production on a single codebase.  2011 involved lots of hard work, a dose of good luck and some progress on our journey to be more agile.

So here are some things I learnt last year:

  1. Speed.  Velocity is great, especially if you deploy to production often, because business benefits start rolling early.  Rapid delivery also builds confidence and trust in your delivery capability (with management and the business).  There is, however, a dark side.  Velocity for us has brought with it technical debt.  The business and project teams care less about this while projects are delivering but speak to any production support or maintenance team and quality and technical debt usually feature highly.  Getting the balance right is difficult.  Do you pay your credit card off every month or let the interest grow till you hit the card limit (there’s a reason banks set limits on credit cards – there’s a point of no return).  Lesson –Deliver things fast to build business trust and confidence – success breeds success.  Make sure someone champions quality and technical debt reduction.  Velocity rarely needs a champion because it’s simpler to understand gets its own momentum.
  2. Quality.  If speed is not matched with repeatable testing capability then you’ve built technical debt because every change requires regression testing to give confidence that the production system won’t break.  Remember this is the same functionality we wanted to deliver fast to get early benefits – if changes break the system your benefits stop rolling a lot faster than your project took to get them rolling.  Building quality in is the best way of working.  Traditional projects have late testing cycles.  The culture of ‘develop functionality fast and get someone else to test it later’ (lets call it test separation) amplifies two problems.  The first is slow defect feedback cycles which raise costs and lowers quality.  Secondly, projects cut testing effort when schedules slip and deadlines are committed.  Test separation culture is strong and difficult to shift to a team owned test culture (BDD, ATDD, TDD, test automation ie team shared accountability for building quality in).  Don’t underestimate this.  This is particularly important as you scale.  A team of 8-10 TDD guns can do amazing things, but when you scale that to 150, you have different problems to solve (hiring 10 TDD guns won’t change the other 140 people).  Lesson – Invest in building quality in.  It’s cheaper and more effective long term.  For larger teams you need to build capability and apply change management to make it stick.
  3. Scale.  Size matters.  Agile is easier with small teams of smart engaged people but so is waterfall.  Big organisations have momentum and it’s difficult to turn a big ship.  Beware lipstick on a pig (politics drives some people to put lipstick on their pigs and call them agile) – thankfully agile is pretty transparent and pigs with lipstick stand out if you’re willing to walk the floors and read a few story walls.  Scaling from 10 people to 100+ usually means you have a normal distribution curve of capability.  To counteract this you need a change program at multiple levels.  Examples include the shift from manual to automated testing and the changing role of BA’s, developers, testers but also decision making and business involvement.  Lesson – Walk the floors, use the transparency to reinforce the changes.  Be brave enough to declare pigs with lipstick as pigs.
  4. Culture.  From a leadership perspective this is one of the most important.  Many people see Agile as a methodology or see technical views of practices like TDD.  From a leadership perspective I see a shift from hierarchical command and control to self empowered teams – the teams choose what stories get done next.  This is confronting to leaders who thrive on the power of control and followers who want to be told what to do.  But a culture where people collaborate to understand business priorities and work together to deliver them faster is very powerful.  Cultural change needs strong leadership but also needs the right attitude and adaptability of the people in the engine room.  Lesson – Be willing to try new things and make it safe to fail.  Educate business, technical leaders and project managers as well as the engine room.  Set expectations – not everyone will drink the kool-aid.
  5. People.  Standups and retrospectives are easy to learn, TDD is hard (as is BDD).  Many TDD advocates probably disagree, but I’ve found this practice to be much more difficult to adopt at a large scale.  I think this is because it’s a mindset shift.  Arrogance plays a part but change resistance is a bigger component.  Why do I need to test a one line change to a 10 line class?  In an application with 500,000 lines of code no one knows how the whole thing behaves.  TDD combined with automated acceptance tests provides fast feedback (read higher quality and lower cost defect reduction) and confidence that changes can be deployed to production.  People who have relied on testers and testing stages of projects for years struggle to change to the mindset that testing happens at the beginning, should be automated and repeatable and is the whole teams accountability.  Lesson – people naturally resist change.  A learning culture still needs goals and measures to help guide and drive capability improvement.

In summary, do simpler agile practices first, build on successes, keep learning.  Some agile practices are hard (especially at larger scale) but also have greater benefits.  Build a learning culture.  To misquote a Zen saying, if you think you’ve achieved it, you haven’t.

Leave a comment »

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 »

Agile is a Fad!

Author:  Jonathan ‘Kupe’ Kupersmith

Jonathan 'Kupe' Kupersmith

Jonathan “Kupe” Kupersmith is Vice President of Brand Development, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at
(This blog was originally written on the BA Times blog site. It is kindly reproduced here with Kupe’s permission).
Agile is the hottest word in our profession these days. Go to any BA or PM conference and there is at least 1 session dedicated to agile. Even if the session does not have agile in it, you’ll hear the agile word over and over. On sites like this one, there are many blogs and articles written about agile. Here is the article that inspired me to write this post, Four Agile Tips to Eliminate Rework in Application Development.
 The article lists these four tips which are credited to agile methods.
  1. Collaborate – Involve multiple stakeholders in requirements definition.
  2. Be Lean – Quote from article – “Agile methods teach us that a 400-page document is not required in order for development to begin. In an agile environment, development can start with high-level user stories with perhaps one layer of detail added.”
  3. Iterate – Approach requirements definition in an iterative process.
  4. Visualize – requirements do not have to be written in paragraph form.

I agree 100% with all of these tips not because they are agile tips, but because they are smart practices. Before the Agile Manifesto was developed, I worked on teams that collaborated, were lean, iterated, and visualized. I wrote about this in a blog post last year, My First Agile Project. I would guess you have been doing this for some time too. This is why the word agile is a fad. In the near future we will stop having debates of whether you use agile vs. traditional approaches. We’ll just start doing what is appropriate for projects to drive results.

This spring I saw Scott Ambler speak and he said we don’t need repeatable processes we need repeatable results. What this says to me, is do what is needed to drive results.  Teams need to come together and determine what will work best to give them the best chance to deliver results. This is just smart.

The agile movement shook our community and made us all think about how we were running projects. It made us make sure we are focusing on business value. Don’t push for agile over waterfall, push for what is right for the project. Push for what is right for the business in the short and long term. Even though I think the word agile is a fad, the agile movement is definitely a trend.

All the best,


Don’t forget to leave your comments below.

Leave a 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 »


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 »


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 »

Running a Successful Large Scale Retrospective

Author: Jonathan Coleman

The first thing I can say about running a large scale retrospective is:
I’ve been sweating on this for a while. In our particular project we have about 70 people involved on a day to day basis. Previous retrospectives have involved the whole team at once resulting in retrospectives dragging on, and most people leaving on a low note.

So as part of my role as Iteration Manager, I have to be willing to accept feedback and seek help!

As a result of the realisation that I generally suck at facilitating large crowds! I attended the Agile Academy’s recent Facilitation Course presented by James King in Brisbane.

This was an extremely valuable day for me! I learned some great tips and tricks, and the Q & A session was focussed on the large crowd retro issue. The essential thing I learned was that Preparation would be key to ensuring a successful outcome which we could learn from and avert disaster and a waste of time.

So in the preparation phase, I

  1. Set up 7 Stations around the room with butcher’s paper – stickies and whiteboards;
  2. Mined the last 15 retrospectives for recurring themes and challenges;
  3. Prepared a video for viewing on large screens;
  4. Booked the meeting room and sent the invite out so the right people would be ‘at the table’.
Leave a comment »

The Games Agilists Play

Author: Susan Akers

Games are always a terrific way to get people relaxed and willing to learn. All you need to do to see this is just to step into any room at a lunch break at a conference with a group of Agilists!

Mary Gorman, the author of Playing at Work: Games that deliver value on says “You can learn from games, use them to instigate change, innovate, and make product decisions.” She goes on to suggest a range of games, how to play them and what value agile teams can get out of them.

Really it is all about having fun and letting your inner child run free in its creativity.

Mary also has a link to her excellent blog on Being Agile when Designing and Playing Agile Games where she actually links the Agile Manifesto and the 12 Principles of Agile to designing an Agile game.

So get playing!

Leave a comment »

Unusual questions to ask at a Retrospective

Author: James King

I was in an agile training session recently and we were discussing retrospectives. A participant bravely mentioned that he was going to be running a retrospective for 70 people. This resulted in a great discussion where the class and I (and one of the agile coaches) went through some potential approaches. But I also promised to publish some of the more unusual questions I sometimes ask in my retrospectives and a suggested agenda. So here goes!

A Fantasy Retrospective

I thought the easiest way might be to tell a story. This is a bit different to the agenda that I think our hardy training member followed but let’s see how it might go:

The Possible Agenda

I turn up with heaps of butchers paper, textas, whiteboards and helpful assistants to make the day work. People come flooding in almost on time and I break them into 10 tables of 7 people. I try to make sure that each table has a spread of different roles but it’s a bit chaotic. I explain the workshop and, after I get my sponsor to put away his iphone, I have HIM to ask the group who they think we are doing the retrospective for.

“The team”, says one agilista.

“But”, says my sponsor,”The team is disbanding. How can we apply our lessons if we have finished”.

“Future projects”, says a project manager.

“But how will they know what we say if they aren’t here?” asks someone, who has been in a lot of retrospectives and seen the information filed away never to be seen again.

After some discussion we agreed that there are two audiences:

  • Future projects; and
  • Ourselves – wherever we end up next.

So I tell people that the workshop will be in three parts:

  1. We will ask a bunch of unusual questions;
  2. Then we will spend some time thinking about how we can use this information ourselves on our next project; and
  3. We will write a letter for “the new project team” to summarise what we learned (you could make a video if you are a modern agilista I guess). We will give this letter to Mary from the project office (who I now introduce) and she will put it on her “project wiki” for others to read when starting their project.

The Plot Thickens!

Now I tell people that each table has been assigned a different set of questions to answer. The questions are printed out on butchers paper and teams have 10 minutes to discuss (and write down) their answers.

After 10 minutes I move most of the team to another table (I move them all clockwise to avoid confusion). However, two people at each table stay behind to explain the answers to the new people arriving. They will not have to justify the answers. At the end of the 10 minutes I move everyone again, but this time a different two people stay behind. This means that I am shuffling up groups a bit and also means that no two people are stuck doing the explaining.

After this we have a ton of information but it is uncollated. So I give each table 2 minutes to summarise the information in front of them (nowhere near enough time, but hping that a pticture will pain a 1000 words)) and then I have them present briefly to the rest of the room.

This takes a little too long, but we get through it and I call for a coffee break. People are relieved to think that it is all over but in fact we are only half way through!! People chat informally over coffee and lamingtons and then I drag them back. Once back I give them 15 minutes to talk about what they learned that might help them personally on their next adventure. After exactly 15 minutes I shut down all conversation, tell people to spend the next 10 minutes writing down a goal for what they will do differently on the next project, as well as what support they might need from others. I trust them to take these lessons with them and don’t ask them to report back to the group.

Next I ask the people at each table to write down a paragraph for a letter to “a new team”. This paragraph takes a while to write and includes anything the team at the table think is relevant to summarise the learning from the information in front of them. Finally I get people to pin the paragraphs up on the wall and everyone walks backwards and forwards reading the paragraphs. This section of the day ends with people asking questions or making final comments about the paragraphs and having Mary (from project office) collect the paragraphs to put into a letter for the “new team”.

Mary will now simply load this onto her wiki as a source of information that the next project team can read if they choose to. So there are no action items left and the team happily disband to head off for a well earned lunch. Hopefully they will read the letter they wrote to themselves (and others) when they are on the next project, but that is up to them.

As they leave I suddenly realise that I should have included a short session at the end of the day to review whether the retrospective itself was useful and whether (or rather how) it could be improved on next time. Ah well – next time I will do better I promise myself.

So, I hear you ask in exaspiration – what were the unusual questions?

Table 1:

  • Let’s assume that communication was one of our biggest challenges.
  • How could we have communicated better within the team during the project?
  • How did we communicate on the project?
  • Would you do it the same way again?
  • What informal channels of communication existed?
  • How did people find out “what was really going on”?
  • How can we do something similar (or better) in a new project?

Table 2:

  • One thing I will miss about the project is ____________
  • Something I hadn’t seen before is ________________
  • Why did these things happen? Do you think you will see them happen on the next project? Should they?
  • How could a new team make it more likely that something similar will happen?

Table 3:

  • What only became apparent well after we started?
  • What should we have seen coming that we wish we avoided?
  • What would have helped us to identify these things earlier?

Table 4:

  • What is the one lesson we should learn from this project that we probably won’t learn?

Table 5:

  • What happened by accident on this project that would be really good to do again?
  • What seemed bad (or frustrating) at the time, but was well worth doing in hindsight?

Table 6:

  • What mistakes did I/we make on this project that were the same as the lessons I/we learned last time?
  • What did I/we do on previous projects that would have been good to do on this project?

Table 7:

  • What changed because of this project?
  • If it was my business, would I do things the same way?

Table 8:

  • What was the most common theme for the retrospectives during the project?
  • What was the best thing we changed after a retrospective?
  • How could we improve on, or repeat the value of, our retrospectives next time?

Table 9:

  • If I had to pick a movie that captured the essence of this project, what would it be?
  • What about a book? Why? What can we learn from that?

Table 10:

  • What new tools, skills or knowledge did I learn on this project?
  • How did I learn it?
  • What tools, skills or knowledge would have really helped me on this project?