Simon Says – Musings of a Technology CTO

This week Matthew Wall of BBC news posted an interesting article on Innovation. In it he lists some of the major reasons “big businesses are poor at Innovation”, things like

• Overly focussed on short term goals – quarterly earnings reports etc
• Worried about taking risks which damage their brand
• Lack of a forceful, entrepreneurial CEO at the helm..

Many of us will have experienced some of these over our careers – some of us have changed company because of them – as a past mentor of mine one said “It’s not the biggest company, or the one with the best products that wins, it’s the one which can react fastest to changing markets…”

And for me, that’s the key, underlying foundation of Innovation – Agility.

One way to be Agile is to not commit too far in the future. Yes, every customer wants to know all the features of all future versions of product, but is that really practical? Can you really decide the roadmap that far in advance?

I’m a great proponent of Scrum methodology – The basic concept of taking a few user stories  – “protect me from being a zombie”, “restrict my IOT devices from talking to unknown webservers” etc, and breaking them down into small, measurable projects.

My team tends to run at 2 week “sprints” – and in the true sense of SCRUM, we release our code at the end of every sprint. Full, production, supported release. For us it means that every two weeks we get to reset our priorities, decide what’s most important, and work on that. For features which take more than two weeks to write, we break them down and again, release the core components as we go – we might not have that feature fully implemented, or even usable, but every sprint, it comes closer to that goal.

I heard a story a few weeks ago about another team who had indeed broken their project down into sprints, but they were 4 weeks long, and they were going to have “5 mini-spirints, followed by a regular sprint then a release”

Hang on – you mean one new version every 6 months? That sounds like waterfall methodology to me – where exactly is the agility in that?

Another thing my team do, is not support anything except the latest release. Yes, I know that few paying customers would accept that..

Or would they? How many people use Chrome (which updates whenever it pleases)? How many would get upset at Salesforce.com’s regular silent back end updates? How often do Amazon patch their AWS services (the answer is, whenever they please).

With the new “app” and cloud mentalities – people have never been more willing to accept a continuous drip-feed of enhancements.

So, Innovate or Die? I choose Innovate – here’s my top 10 thoughts – what would you add?

Simon.

1. Don’t try to boil the ocean – break your Innovation down into valuable, consumable chunks and get them realized.

2. Release before the world moves on – Customers don’t have to keep up with releases –  Prospective Customers won’t wait for you so don’t miss your window of opportunity.

3. Agile means that – if you can’t release at your choice, you’re not agile at all.

4. Analysts help you substantiate what you already know – They rarely tell you anything you don’t

5. If you follow your competition, you’ll only be as good as they were in their previous release – you’ll never get ahead.

6. Eliminate baggage – Find ways of keeping your customers updated to your current release. The more incremental your enhancements, the easier this is.

7. “Big Bang” new versions only really appeal to prospects – existing customers worry how they will migrate. Unless you have big architectural problems or a massive new feature, do you really need a major version change?

8. If your team is bigger than “two pizzas”, then you’ll be spending a large portion of your effort on detailed communication – can you break the project up more and spend that effort realizing, rather than discussing?

9. Meetings are for making decisions, not for reporting – that’s what pre-meeting content is for.

10. The longer a project takes to realize, the more chance the need for it will have evaporated. Fail fast, and decide quickly – if you need to write off a sprint or two, no big deal. If you spent a year on something which isn’t what the market wants – then that’s a problem.