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 »

The path to Agile

Author: Susan Akers

 Two of the most common questions I get asked as the Agile Academy Advisor are:

“How can I start my Agile journey? 

What type of training can I get?” 

 So I thought perhaps it was about time that I put something together in one spot to make it easy for people to see a clear path ahead of them and feel confident in moving to an Agile way of working.  One way to see what training might be useful is to have a look at our role based Training Roadmap and then read the course overview to make sure that you have the necessary pre-requisites.  The roadmap shows the recommended courses and pathway.

The Agile Academy has also produced a number of artefacts to complement our training courses and give budding Agilists an opportunity to have open access to easy to understand material.  These include our Agile in Practice Help Sheets which cover a number of Agile practices and techniques.  Most of these also have a complementary video which explains more about how each of these techniques can be used. 

All the very best on your Agile journey.  Don’t be discouraged if your path becomes a little windy, there are many resources to guide you and if you have any questions at all around Agile or training please feel free to contact us directly.

Leave a comment »

Agile Australia through the looking glass

Authors: Robert McDonald, Belinda Lawrence and Wayne Allan

Some views and take aways from the recent 2011 Agile Australia conference.  This is what three people saw and heard.

Robert McDonald, Operational Reporting Analyst

“If there is word to describe what happened in the Agile Australia conference of 2011, it was ‘vibe’.
Being part of such a collection of ‘Can Do’, challenging, active and clever people, all intent on making the world a better place was fun. Some had the longer scaled up version which looked towards a bright future, while others shared their ‘tactical’ excellence.
Read the rest of this entry »


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 »

12 Agile Adoption Failure Modes with Jean Tabaka

Author: Renee Troughton (@AgileRenee)

I had the pleasure on the 9th June to see Jean Tabaka in action at the Brisbane YOW night. Topic in reflection: 12 Agile Adoption Failure Modes.

My interest was immediately peaked when the opening question was:

“Ask the four or five people around you what are some of the key causes for an Agile Implementation to fail”.

What we were met with was two elements of failure – 1) at a team layer and 2) at an organisation or enterprise layer. An element of distinction between these two was not really made so I am left to assume most of the twelve failure modes are directed at an enterprise layer.
Read the rest of this entry »

Leave a comment »

Agile – in name only?

Authors: The Agile Coaching Community

“We place the highest value in actual implementation and taking action. There are many things one doesn’t understand and therefore, we ask them why don’t you just go ahead and take action; try to do something? You realize how little you know and you face your own failures and you simply can correct those failures and redo it again and at the second trial you realize another mistake or another thing you don’t like so you can redo it once again. So by constant improvement, or, should I say, the improvement based upon action, one can rise to the higher level of practice and knowledge”. – Fujio Cho
Read the rest of this entry »

1 Comment »

Becoming Agile

Author: Craig Smith

After a recent talk I gave about Being a Business Analyst in an Agile world, I was asked for some resources that might also help a Project Manager move into the world of Agile. The difficult thing I find that project managers deal with on Agile teams is the need to let go of work at the task level, and the need to move to more of a leader role and what I call a “traffic cop” that protects the team.

The PM is outside the core team, dealing with stakeholders, budgets, resourcing and all of the big issues whilst protecting the team so they can get on and deliver software. Hence the reason I recommend that a PM is not the iteration now.

For Leadership and Project Management:

And then there are many new leadership techniques which fit hand in hand with Agile (moving from management to leadership) as well as many good books, but a couple to get you started:

Some great books:

Here is a list that was put together earlier in the year of the Top 100 Agile books, and I would agree with most of the titles on this list, so it might be worth a browse as well.

Agile Training:

Finally, it would be remiss of me not to mention the Agile Academy, they have a two day Project Management course that was developed originally based on work carried out in Suncorp.

Craig is an Agile coach and has spoken at various conferences about Agile and related topics including Agile 2010, Agile Australia 2010 and the Atlassian Summit. He openly shares his knowledge and experiences through slideshare and his blog.

Leave a comment »

Final thoughts on running a 70 person retrospective

Author: Jonathan Coleman

After the celebration morning tea, I did some follow up work to keep the momentum going and so that everyone was reminded of the great experience we had on the day of the retrospective. I emailed out photos/descriptions of the major issues, the top things we could do about them, and the names of the action owners to everyone. We then followed this up through the next iteration. Several workshops were born and we chased up on issues through these.

Would I do it again with 70 people? My answer would be YES!

This was a very successful retrospective in that it did the following things:

  • Gave people a chance to speak out in the group (through smaller groups on the day)
  • Allowed people to “own” the issues rather than being told what to focus on
  • Fostered intense collaboration between the groups because of the necessary timeboxing
  • Allowed people who don’t usually have an opportunity to present, to be front and centre to the team what the actions were.
  • Built the team culture of facing obstacles honestly, and having the ability with the team itself to overcome them.
  • Nothing is impossible!

So, again thanks go to the ideas/tips gleaned from the Agile Academy’s Facilitation Course. The retrospective itself was a really useful session for me and thanks to everyone who attended and took part. I look forward to facilitating future retrospectives, no matter how big. My final thanks go to James King and Craig Smith, two great Agile coaches and trainers for their ideas and input.

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 »

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?