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:
- 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.
- 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.
- 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.
- 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.
- 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.
