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 »

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 Evolution of Test Driven Developers

Author: Peter Sellars (Reprinted with thanks to Peter)

Evolution

Test Driven Development (TDD) since its rediscovery by Kent Beck in the early noughties has led to an evolution in the information technology developers of our species. So where on the test driven developer evolutionary tree do you or your developer kind sit?
Read the rest of this entry »

Leave a comment »