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.

12 thoughts on “Agile Advice for Aviva (and many other big companies)”

  1. Ok – so what's wrong with strat planning done in using Agile methods? e.g. a 6 month sprint, one which looks at the 3 year horizon and amends the plans accordingly.

    I don't believe having a look at the horizon is shortsighted (see the irony there) – I think it's good to keep an eye on the future and what's happening now, and seeing how we can make the systems we are working on today, be ready and able to accept any new channels/interfaces that will be required when TNBT (The Next Big Thing) comes along.

    We know we'll always have to have call centres, we know we'll always have to support online, we know now we'll have to support mobile and we will also (for the foreseeable future) have to support written correspondence.

    We have regulatory changes that are required too – often they have a date in about 3 years to be implemented – this can be refactored into any plan during the "sprint".

    In essence, I think 10 years is too far, I think 5 years is a stretch, I think 3 years is quite reasonable, I think 6 months is too little. It doesn't mean, however, that it won't change during those three years, as lots can happen.

  2. Hi Alan
    your suggestions mostly read like a list of things that you heard from guys at SyncNorwich (things that are being done today). I'm with Zippy on Stratplaning btw – there is plenty of wisdom about action without strategy.

    Glad you got something out of the conference.

    S.

  3. Thanks Beggars, that is really good to know. Next time I'm in Norwich I'll see if I can take you up on the offer.

    Strategies are so often only apparent in the rear view mirror, emergent strategy is just as common as emergent design.

  4. Agree with much of your points. What you need to know is that away from the lectures and conferencess we are doing BDD at Aviva and getting some quite exceptional results.

    Come and have a look and then blog again.

    You can plan, strategise and convince as much as you like… or you can get on and do it and demonstrate the results. Then it becomes the strategy.

  5. In a nutshell:
    – Vision and Strategic Intend is knowing where you want to go
    – Strategic planning is working out the route there and programming it into the organization

    Vision: "I have a dream", "Land a man on the moon and return him to earth…"
    Strategic Planning: Soviet Command & Control economies, Vietnam War, Ford Edsal

  6. PS – "Strategic Planning has no space for emergent strategy or learning because it is all planned in advance." – Does that not imply that the strategic planning function has no feedback loop, has no agility and is entirely waterfall? That's not my understanding of it.

  7. In IT, I speak to the business that the IT has to support. I have to ask them what they are likely to be wanting to do in the next 3-5-10 years in order that we are able to ensure we have the right platforms and capabilities to be able to meet what they see as being needed in that time frame.

    That's vision from them, vision from us and there is inherent planning.

    Perhaps I'm not understanding the semantic difference between Having a strategic vision, having a strategic intent and strategic planning.

    Can you explain further? (I will be reading the book anyway).

    1. Matt,
      I think you've put your finger on the problem here.

      "I have to ask them what they are likely to be wanting to do in the next 3-5-10 years"

      You can't plan 3 years out let alone 10. Is your business asking for anything to work on an iPad or Android tablet? The iPad didn't exist – outside of Apple – 3 years ago.

      Capers Jones (Applied Software Metric, 2008) says requirements "change and grow on average 2% per month." Apply this to your time horizon, you are looking at requirements change of 72%, 120% and 240% on these time horizons. No wonder you have problems. Your business doesn't know what it wants, or rather, it thinks it knows what it wants but it will change massively.

      And on the technology side too: Moore's Law means in 3 years your machines will be 4 times more powerful than today, 5 years they will be 8 times more powerful and 10 years 16 times more powerful. Do you have any idea what that looks like? I don't.

      You might as well read Iain M. Banks and Alistair Reynolds for your requirements – certainly more fun to read.

      What Agile says is: "Instead of trying forecast the future and produce something that is highly adapted to what might come about focus on the present and building adaptability into your technology and processes." That way you will be better able to cope with what happens.

      In nature the adapted animals become extinct when things change, more adaptable animals may be sub-optimal in some ways but they cope with change when it comes.

      For example, rather than trying to figure out what OS your servers are going to be running in 5 years time and targeting that one, target the one you have today but write the systems in such a way that they can move to whatever system you want.

      In practical terms that tends to mean: good code (low coupling, high cohesion), automated tests at Unit level and above, UI and business logic separated. i.e. all good engineering practices. And it means requirements and development processes that can deliver in a few months not years. Long range planning – strategic planning – is a vicious circle: the more you plan the more you need to plan.

      My advice would be: Stop thinking 5 and 10 years out. Think 6 months out max. Put in place processes, quality and technologies that can turn any request around in months then the amount of long range planning you need is much less.

  8. Matt,
    Were you part of the strategic planning function at Google or Apple? If so I'd like to hear your insights.

    Personally I doubt very much these companies use Strategic Planning if for no other reason than Moore's Law. Every 18 months the landscape changing, strategic planning cannot operate on that timescale.

    I have read that Steve Jobs was originally against the AppStore. He wanted to keep the iPhone an Apple only environment. Nor did Apple originally plan on becoming a music company. The iPod was a way of making music on the Mac portable.

    Google originally started with no means of monetarising search. I also wonder when they decided to get into tablets, before or after the iPad appeared?

    I'm sure each of these companies had Vision, even Strategic Vision or Strategic Intent if you prefer the Hamel and Prahalad version. But Strategic Planning? No. I don't believe for one minute they had.

    From the outside, and in retrospect, the Apple, or Google, strategies make good sense and look logical. "The Mac is dying therefore… tablets" but why do it via music and telephones?"

    Strategy – as you will read in the Mintzberg book – is part planned – yes planning has a role – but equally emergent. It is also the result of what happens – success and failure, the opportunities that arise, the innovations that appear, and most importantly: learning.

    Google, Apple and countless start-ups depend on innovation. You can't schedule innovation.

    Strategic Planning has no space for emergent strategy or learning because it is all planned in advance. If failures occur it is usually blames on implementation but should rightly be blamed on planners for not foreseeing that those tasked with implementing the plans were likely to fail.

    As for the start-ups you mentioned: they can't afford planning departments. They just execute. Again vision yes, strategic vision yes, strategic intent yes, but strategic planning No.

    Most fashionable book in Eric Reis Lean Start-Up. Its hard to think of an approach with is more of an anathema to Strategic Planning as Lean Start-Up.

    Personally, I read Mintzberg's book and I see how big up front design history parallels the strategic planning history. Heck, it doesn't just parallel it, it is the same history.

  9. Disagree, and will continue to do so, on "give up on strategic planning".

    Apple had strategic planning.
    Google of course have strategic planning.
    Startups have strategic planning.

    It hasn't died.

    If any business wants to get anywhere, it needs strategic planning. Strategic planning doesn't stop innovation – in fact it promotes it.

    Ignite some petrol in a large open space…it will make a big noise, and will affect the area around it for a second, but that's all it will do.

    Ignite some petrol in a container with a single outlet (e.g. a piston, a jet engine) and it will create momentum and move a large vehicle in a direction it wants to go.

    Strategic planning does constrain random offshoots, but it does finesse and streamline in the ways a company believes it should go.

Comments are closed.

Verified by MonsterInsights