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 »

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 »


Agile – what does it really mean? Learning from failure.

Author: Michael Stange

Continuing on the theme from the previous blog by the Agile Coaching community, I thought I would look at how a ‘safe to fail’ environment compares to ‘safe to innovate’ one.

John Lasseter also known as ‘The sorcerer-in-chief of Disney and Pixar’ is the envy of most producers. His perfect 10-for-10 winning strike rate is a feat unheard of in Hollywood, where a 1-in-10 hit ratio keeps most companies in business.
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 »

Retrospectives without action are like faulty vending machines – neither give you change!

Authors: The Agile Coaching Community

In this second part of their blog, the Agile coaching community continue to share their experiences of running successful retrospectives.

Teams should focus on the goal of the retrospective, the context of the team and use questions that will help the team to move forward and improve. Look for problems that are similar and identify the root cause. Many issues could be solved by this one simple action.

We also recommend shaking things up occasionally and trying something new to ensure the retrospectives don’t get stale.

There are many techniques and ways to run Agile retrospectives and any or all of them could be used depending on the situation and the context of the team. Some excellent resources on retrospectives include the book –Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. There is also an Agile Retrospective Resource Wiki that contains plans, tips and tricks and other helpful hints ( and you can also find several one page Agile Practice Help sheets on a variety of Retrospectives from the Agile Academy’s website.

No matter what type of retrospective technique you use,make sure to set up a positive and appreciative environment that encourages generative thinking!

Research has shown, that more of the brain functions in the presence of positive focus and praise, than problems focus and criticism. Consider asking, “What can be done better?” rather than, “What didn’t go well?” Help the team capture and recognise their successes and achievements and reward the generation of new ideas.

“No action, no change. Limited action, limited change. Lots of action, Change occurs.” ~ Catherine Pulsifer

No matter what method you choose or questions you ask, the important thing is to come out up with concrete ideas, then put them into action so they lead to change. Remember, the focus is on continuously improving. Change can’t occur without an action and a catalyst.

Many of us find that there’s no time for actions, we spend too much time reading through the cards running out of time to plan our actions!

So here are some tips we feel that might help ensure you get the most value from your retrospective:

  1. Plan enough time to discuss actions and make sure they are assigned to someone
  2. At the beginning of the retro follow up on actions from the last one to ensure they have been done
  3. Consider capturing retro discussion points throughout the iteration on a Big Visible Chart (BVC) and use the retrospective to focus on actions
  4. Prioritise and focus on the things that have a high impact and high frequency
  5. Keep a positive focus
  6. Consider holding the retro offsite. Creating a relaxed and non-interruptive environment is very important
  7. Communicate the output and share the learning. Also publish on the wall to insure transparency and open communication
  8. Keep up the energy levels by holding retrospectives regularly and don’t be afraid to share it up by trying something new in your retro
  9. Remember that good is the enemy of great (from Jim Collins’s book on “Good to Great”)

    So what has been your experience with retrospectives? Are they working for your team? What have you found worked or didn’t work? Do you have any suggestions that others could benefit from?

1 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 »

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 »

“10 + 1 pointers to a more innovative Agile journey!”

Author: Chris Zaharia

Someone suggested that I write a blog on my top tips for using innovation with Agile to make great things happen.

From Flickr - Cayusa.

This got me thinking about Clayton Christensen’s “The Innovator’s Dilemma”. In it he explains how start-ups have taken over previous market leaders across many industries, time and time again because they chose to introduce “disruptive innovations”. What this means is that it may be better to release a product or service that would cannibalise or even replace your core business than to wait for a competitor to beat you to it! Sounds like Agile to me. You collaborate with and learn from your customers what they really want. Most people will accept the less than perfect if they can see that at each step it is fulfilling one of their needs.

A success story that reflects this is Atlassian, one of the most effective adapters of Agile in Australia. I was fortunate enough to meet Mike Cannon-Brookes, the co-founder, back in 2008 when he explained how they identified that their existing customers found enterprise software much too complex to use. So they listened, developed and delivered an innovative suite of products which gave customers a simple, easy to use group of solutions, resulting in taking market share from previous leaders who were ineffective at innovating and turning an initial investment of $10,000 into over $75million in revenue business. We now see some of these products (Jira, Confluence and GreenHopper) being used by the likes of companies such as Macquarie, BMW and Adobe.

I’m not in the same league as those innovators at Atlassian but I am an innovator and offer a few words of advice from my own experience.

  1. Don’t let others knock your ideas down even if they think it could never work. Gather Energisers around you. They will provide support for your ideas and constructive criticism when appropriate as opposed to Energy Sappers who will say NO to all your ideas until you are discouraged to bring any more up.
  2. Go to GenY employees for ideas, and graduates who have recently finished University, as they usually have the latest perspectives on the most current trends and technologies and are more than happy to share their ideas. Consider giving them the time to develop their own side-projects too, possibly even create a graduate innovation initiative for them to conceptualise and deliver projects with formal teams and budgets. Similar initiatives have been a great success at companies such as Suncorp and Deloittes.
  3. Even go as far as to approach the younger iGeneration and children for ideas. Their perspective can bring surprisingly blunt and down-to-earth approaches that might jumpstart innovations. Don’t dismiss the GenXs and Baby Boomers either, as they can give a more realistic perspective which can enhance ideas to become feasible products. In fact, Deloittes has an effective method of hatching more realistic innovative solutions by pairing up a junior and senior employee to come up with ideas.
  4. Don’t leave innovative features that come up in a forgotten backlog due to the difficulty in estimating them. One way to address this is to perform a spike. Another method is to develop a throw-away prototype and demonstrate it.
  5. Allow customers or work colleagues from other parts of the business to take a look at the product. You can gain a variety of ideas which can introduce new approaches you may have forgotten or not even thought of by giving access to the product’s current iteration or via an communications channel like Yammer to get feedback from a much larger internal audience.
  6. Implementing an idea management system where anyone within your department or organisation can share ideas or challenges and vote on the best solutions.
  7. Bringing people in from outside your core team to take part or at least observe parts of your project. This may result in more efficient methods/processes being identified and taken up by the team.
  8. Have team members participate in industry workshops and events and then present what they have learnt to the rest of the team.
  9. Don’t limit yourself to only looking at competitors. Look at industries which are at the forefront of the technologies you are adapting. For example, in the insurance industry, a market leader in online retailing may have features that no other insurance website has and adapting it would bring in efficiencies in navigation that translate to increased business value.
  10. Actively follow the latest trends and technologies in as many industries as you can, and consider using a checklist of these when brainstorming at the concept phase of your Agile project.
  11. Finally, you can look at brainstorming sessions or even creative-thinking techniques for individuals such as SCAMPER. I found “Thinkertoys” by Michael Michalko to be a great book with lots of techniques to help you come up with ideas in the first place.

My final word of advice is this:
I see many people come up with great ideas and say they will do something but never drive themselves enough to act on it. You have to do something about it to really make it happen. Don’t just keep your ideas to yourself, otherwise you may be living with regrets about what might have been. Apple’s Steve Jobs once said “Innovation distinguishes between a leader and a follower” so be a leader and make those ideas come true.

You CAN change the world!


Energy Sappers Vs Energisers – Which one are you???

Author: Fiona Mullen

I was inspired after reading “Liquid Thinking” written by Damian Hughes which talks about ways you can change your thinking so that you can reach your full potential.

From Lukasz Strachanowski (Flickr)

Damian notes that there are 2 types of folks – Energisers (Possibility Thinkers) and Energy Sappers (Probability Thinkers). These 2 groups have a very distinct approach to life which you need to understand so that you can manage your relationships with them effectively.

The Energisers have fire in their belly, full of spirit and life, stamina and strength; whereas the Energy Sappers drain every ounce of energy out of your body and can be quite exhaustive.

To really focus on channelling your energy and achieving your goals you need to understand the comments and clues of both groups. So let’s start with the energy sappers (get the negative folk over with early). They will have statements around:

“ We have done this before” or the classic “Yes but …”

On the other hand, when you pitch an idea to an Energiser , before you have even finished your sentence they have jumped in boots and all with “That sounds good” and in their mind they are already planning how to deliver the idea as it has spurred them on.

I choose to surround myself with Energisers both personally and professionally as I find that when I am with these folk my cup overflows with energy. They have heaps of ideas and passion and this spurs me on to think about new things and keep focussing on the end goal which is making a difference… So which one are you???

Can you see the possibilities or do you think an idea is probably going to fail?