• DTA – aid transformation in government, small agency
• Delivery hubs in Sydney and Canberra – help identify and plug capability gaps in teams
• Prototype of how government services could work  gov.au/alpha
• Digital Service Standard – 13 characteristics on what good looks like in government, useful in organisations as well
• Cloud.gov.au  – government cloud service, usage growing, continuous delivery pipeline (which is a major change for government who are used to 2 changes per year)
• The unit of delivery is the team – not about individuals, but the team – borrowed from GDS
• Government is slow, but government is designed to be stable, they cannot fail, they have characteristics that are resistant to change
• Myth that organisations must choose between speed and reliability, high performing organisations deploy more frequently, have shorter lead times, fewer failures and recover faster, but they also have a greater profit
• Want to deliver like a startup but be stable like a government
• Not a lot of cross pollination between departments currently
• Read the policy! – quite often the process is not mandated
• Document what works and doesn’t so it becomes a repeatable pattern – ie. running a meetup inhouse, don’t tell me I can’t do it, tell me how I can run it without being thrown in jail!
• Stick with technologies the government is comfortable with if you are changing the delivery engine
• Security matters – prevention is a battle you will always lose, detection is your best defence – aggregate and log in one place, identify threat signatures, etc
• Embed security people on big services so it is part of the architecture
• Proactive testing between different governments around the world on similar platforms
• Simplest security breaches make the most mess – infected excel macros, leaving free USB keys in the foyer that are malware infected
• Need to put user needs first – alpha mockup using tools like Jeckyll, then beta then live
• Lots of people strictly interpret the design and delivery guides – they are guides not rules!
• Create a longer runway by pulling tech forward – turn down the volume of design, turn up the volume of tech
• If it hurts, do it more often!
• Fixed cost delivery with agile is a thing, agile is a way to de-risk in the government
• Don’t put manual testing on the critical deployment path – have special skills on hand for accessibility, performance and security

The product with the highest return on investment versus risk

Popularised by Eric Ries it subtly changes to

The smallest thing you can build that lets you quickly make it around the build/measure/learn loop

I must profess I have a few issues the MVP concept.

My first is the term. The term MVP is all well and good for you version 1.0 of your product, but what exactly is your next cycle through the loop called – is it called a Minimal Viable Product as well? Why do we not refer to the refinement or further iterations of the build, measure, learn (BML) loop as Minimal Viable Increments? Or better yet, BML increments? We know from using Lean Startup that we rarely get the product right first go, so we should have some simple term that talks about getting it closer to right shouldn’t we?

My second issue with MVP as a concept is that people forget that there is a life cycle to products if you do manage to be successful post the Startup phase. Let’s go through the scenario – you build your first MVP, you increment on it through build, measure learn, you begin to realise customer value, customer growth and manage to retain customers, you increase business revenue; in essence, your startup starts to succeed. Then your customers continue to grow. Suddenly your little tiny product is not handling the growth. You need to desperately take what was a tactical solution and industrialise it, strengthen it so that it can handle the next stage of growth. Your minimal tactical product just isn’t cutting it, it simply isn’t viable anymore. At this point in time the increments from a BML perspective need to focus on operational sustainability – how can you build a platform to sustain an acceptable performance? I call these minimal strengthening increments.

My third issue with MVP is that if you are doing it in a non startup environment – ie an intrapreneur in an already existing and flourishing business, is how to deal with reputational risk. In these large corporate organisations you need to worry about compliance to major standards, either in the country or internationally, you may also need to worry about how your existing shareholders feel about a non polished product out in the marketplace. It is for this reason that you could venture down the path of white-labeling the product, ie taking your brand off it and registering it under a smaller shell of the company, but often it means that the MVP becomes not so very minimal as the company is unwilling to incur reputational risk.

My fourth and final issue with MVP is the very difficult balance between MVP and minimal viable experience (MVE). Sure you could put a product out there to begin learning from, but if the content or the experience of the product is not compelling enough then you are going to risk turning away customers and that comes back to reputational risk for large corporations. Some call this a minimal lovable product.

Don’t get me wrong, I love Lean Startup, but in conclusion, if you are applying it into a corporate environment it is not going to be enough to ensure success and many different considerations need to me made. In a large and established organisation consider the minimal viable increment, the minimal viable experience, the minimal riskable product, and the minimal strengthening increments.