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

3 Comments »

Can you MAKE a team Agile or more Agile?

Author: Susan Akers

Having just completed my ScrumMaster training I became aware that while Scrum is focussed on the Deliver Phase of Agile it is in fact, first and foremost about People! As Martin Kearns, our trainer, pointed out and this certainly resonated with me:
 This is evidenced by a recent story told to me by an Agile coach about a team they were working had just completed a challenging project in a very tight timeframe. The phenomenon about this team was that they had never worked together before, came from a wide variety of backgrounds and were working on a new platform, yet they were extremely productive from day 1! and delivered far beyond expectations; and their customers are delighted.
As we all know it can take months for some teams to become productive.

“You have to get the right people talking and doing! ..
The glue that holds people together is their emotional states and what commits people to the sprint is the emotions they feel.”

 

From your experiences, what are the factors that differentiate a ‘great’ team from the less-than great? Are there any common themes? What are the necessary ingredients?

2 Comments »

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 (www.retrospectivewiki.org) 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 »

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 »

Agile's Secret Sauce – Part 3

Authors: Tracey Kay and Julian Coldrey

As project leads, we bring a certain perspective to how we have achieved the team culture described in Part 2 of this series.

So here are some things we did as a project leadership team that seemed to get a good result:

  • We picked the right people. It’s not about assembling the best, most high achieving collection of people. It’s about team fit and picking a group of people who work well together and, as a team, EXCEL.
  • We let the team self-select almost everything. Nothing says empowerment like the ability to choose how you work, what you work on, and who you work with. By enabling our teams to self-select and organise around our goals, they took on the choices as their own and were much more inclined to make them work (or even better, change them when it was obvious they weren’t working!)
  • We eliminated Leads to create accountability. It may seem counterintuitive to drive accountability by eliminating leads in an Agile team, but past experience showed us time and time again that creating leads for each skill set (“Dev leads,” “Test leads,” “BA leads”) caused an immediate diminishing of accountability with the rest of the team. We felt that if someone was given the “lead” role that it flew in the face of the culture of shared accountability we wanted to generate, so no leads became the order of the day.
  • We chose a specific leadership style. Leadership is always important, but in an Agile environment where empowerment and self-direction are critical to success, choosing the right leadership style is paramount. We decided to provide leadership that focused on the vision and purpose of the team, but which was not directive in terms of how to achieve these goals. In other words, our mantra was always “this is what we need to do, now let’s figure out how to do it as a team.” This really empowered the team, got everyone thinking, and ultimately helped create the sort of culture we were looking for.

We hope some of musings in this three part series about what makes up Agile’s secret sauce has resonated with your experiences of building high performing Agile teams. If we could take one thing away from this project experience, it’s that we’ve never regretted any investment we made into building a healthy team culture, as it has consistently been repaid in the form of a fantastic, high performing team who have fun!

Feel free to send us your Agile recipes for success too or direct us to other good blogs/articles.

Leave a comment »