Agile Advice for Aviva (and many other big companies)

I’m starting this blog entry on the train returning to London after speaking at Sync Conference in Norwich - and I’m finishing sitting in my local coffee shop on Tuesday. (My conference presentation Agile in 90 minutes is online (PDF) or via Slideshare.)

An awful lot of people at SyncConf worked for Aviva and during the day I spoke to many of them. Aviva are trying to be “Agile” but like every other big company are struggling.

Personally I’m pessimistic about their chances. Someone asked me if I could name a big company which had made the Agile change and I struggled. Yes, many big companies are trying Agile, and yes there are many successful teams in these companies. But has an entire company made the entire change? I don’t know of any.

All the banks are trying it, and all are failing in similar ways (see Reverse-Tolstoy and Why Agile will Never work in Investment Banking). Many other big corporations are trying and most of what I here is not positive.

During the day I did build up a picture of much that is happening inside Aviva and I did give some advice in conversations. Now I’ve thought about it there is some more, bullet points below.

(I can say this because Aviva are not my client - OK, I did do a little work with them years about but it was insignificant. If Aviva were my client I wouldn’t be writing this blog, I don’t speak openly like this about clients. I try to avoid talking about active clients at all in this blog. Nor am I in the habit of giving unsolicited free advice to clients.)

Advice for Top

• There are no Silver Bullets: Conway’s Law, Reverse-Conway’s Law, Brooks Law, Goodhart’s Law and dis-economies of scale constrain what can be done.
• Take Software Craftsmanship seriously: Start and apprenticeship programme - speak to Jason Gorman about how the BBC do it
• Let a thousand flowers bloom: dump any attempts at standardised working and let people experiment, let them have fun as they learn and change. In a few years time when you’ve made lots of progress start to mine out your own “Good practices” and sharing them amount teams.
• (That also means be prepared to work with multiple difference consultants, coaches and advisors. Accept they will give you different advice. Yes engage with some big players but also work with the small players.)
• Embrace dis-economies of scale - you don’t have time to be involved with the details so delegate
• Get with Quality: the Quanlity v. Time trade-off is the reverse of what you think; higher quality (i.e. reduced bug count) makes for shorter scheduled, shorter schedules makes for lower costs, together this make for happier customers and more responsive business
• Get clear about what you want: if it is cutting costs say so, you can use some of the Agile toolkit for this but don’t expect to use it all or achieve Agility. There is nothing wrong with not being Agile if you have a better alternative.
• Pay the SyncConf Norwich team to re-run the conference again (with a few tweaks) inside the company. (You’ll have to pay the speakers but this will be a drop in your ocean of your IT budget.)
• Go further and let give employees attending seed money, let them spend it to sign up for courses and bring in some of the consultants they liked into the company. Yes this is radical, no apologies.
• If you want to be Agile then accept that it won’t be the lowest costs, it should result in the greatest value overall so focus on value not costs
• Your business and IT operations need to be more joined up. Maybe you want to dismantle your IT group, at least embed it in the business.
• Your annual planning cycle needs to relax, you need to learn to start small pieces of work without having every T crossed an i dotted.
• In the long run you want to look to Beyond Budgetting.
• Don’t worry about your CMMI or ISO or whatever accreditation, my clients have FDA and ISO-13485 approval, if they can do it so can you.
• In the meantime give up on strategic planning: that idea died in the paddy fields of Vietnam thanks to Robert MacNamara. Go read Henry Mintzberg “Rise and Fall of Strategic Planning”.

Advice for the Middle

• Visualise, visualise, visualise: boards, graphs, everything!
• You have to lead the top, they don’t know how to spell TDD so educate them
• Involve “the business”, their representatives in everything
• Get with the Quality Agenda: ditto the above, embrace and push quality to eliminate bugs. Give your team support, send them on training, hire consultants to come and coach, buy them books.
• Architects must also code
• Celebrate every little success; make sure the whole company knows about a realise
• Spend on travel: Indian outsourcing doesn’t work because you paid TCS, you actually have to go there and see, they have to come here and see, you need to talk, talk, talk. Skype, VOIP, everything
• Don’t spend money on expensive test tools
• Manage teams as a whole: not a Test Team and a Test Manager there, and a Dev Team and a Dev Manager there, and a BA…. the whole team wins or looses together.
• There is no long term future for Test Managers, you options are: a) focus on Test and work to improve the Testing Process, specifically Automation; b) focus on management and manage the whole development team; c) disentangle Test from Quality and become get Quality throughout the process
• Form self-support book study groups: spend an hour, meet for lunch every other week, agree a book, agree a chapter in advance, someone volunteer to summarise it. Open each meeting by going once around the table and having someone say something positive (“Tell me something that made you smile today?” “Tell me something you learned this week?”).
• Good luck: you have the hardest task, and its lonely. Some of you will need to lay down your jobs to make this happen

Advice for the Workers

• You control the means of product, Agile is in your hands, Make it So. Your greatest weapon is Quality, you have the power to improve it today.
• Embrace Test Driven Development, Refactoring (i.e. emergent design.) Dump big-up-front design, get coding on day-1 and work out the design later.
• You have to lead the middle and they will lead the top. Neither of these two groups knows as much about your work as you do. Lead by showing them what works. Which means…
• You have to do it, make those improvements. Developers start learning TDD, spend your own money if you need to. Testers: download the open source test automation tools and enrol developers to help you get them working.
• Testers: Automation, Automation, Automation - get with the Open Source tools - Selenium, FIT/Fitnesse, Cucumber, etc. etc.
• Form your own study groups
• Make sure retrospectives happen and action items are actioned

Most of this advice is applicable to any large company. I really don’t know that much about the inside of your company, I’m assuming. Nor is this list really that different from the one I published on InfoQ last year - 10 things for making your Agile adoption successful.

Finally, Aviva, you don’t have to take any of my advice but a) I guess your paid advisors are saying similar things and b) if you don’t change new competitors will kill you; you are big so it will take time but it is never nice to watch a big animal in pain.