Menu

Subscribe

Dan Sheldon workshop at Transform 2017 notes

on transform17, dan sheldon, it self harm

These recollections are based on my personal notes, mistakes are my mine. My comments added in [square brackets]

Dan Sheldon
Works in the NHS like GDS
In truth it was Dan's article that inspired me to attend this event.
The Government IT self harm playbook

Too Long Didn't Read (TL;DR) Version

Great organisations trust teams to deliver great products for happy users

He went into more detail in the workshop covering: History of the civil service, sources of friction, and some random thoughts in a toolkit. I liked the toolkit a lot as there were many familiar things in there.

Topics

Tips for shit umbrellas
History of Civil Service (UK)
1980s – New public management
Consequences of new public management
Outputs over user experience
Resulting challenges
Friction
Procurement
Why does the govt. outsource
Procurement – traditional processes not designed for small things and microservices
The big problem
How to fix procurement
Understand your value chain
Figure what to buy and how to buy it
Fix the buying process
It’s never too early to think about retirement
Governance
Measures of success
Example of current business case process in IT
How to do user research and prototyping
Misconceptions about Agile
Governance in an agile team
Expose the trade offs
Technology
Enterprise architecture
Buy vs. build
"We need an 'X' system"
Software as service
Security
Toolkit - just a few interesting ideas

Tips for shit umbrellas

Do you want to be a shit funnel (shovel shit onto your team, this slows things down and things get nasty), or a shit umbrella (navigate bureaucracy and protect your team)

History of the Civil Service (UK)

* Northcote and Trevelyan in the 1850s did a report on the civil service

Before their recommendations were adopted the civil service was basically a patrimonial bureaucracy
They recommended:

  • Separation of the service from Ministers and politics
  • Continuous, predictable role, rule governed
  • Qualified and trained professionals

Head of Intelligence in UK – said one change is ‘generalists can’t do everything anymore’ particularly in the digital domain

The big promise of IT has always been presented as better services less money

back to contents

1980s – New public management

* The key concept was the adoption of a private sector mentality * Focused on business, rather than be focused on the Minister, or being a civil servant (professional) Some trends included: * **Agencification** – creating agents at arms length from govt. * **Outsourcing** – [in theory]more efficient, because motivated by profit and competition * **Targets** – run govt. by metrics * **Performance Management** focused on individuals not team * **‘Customer service’**= big call centres – let’s look corporate * **Rise of consultants** and **faux business professionalism** – like the [Paleo banana bread video](http://www.smh.com.au/federal-politics/political-news/department-of-finance-video-boss-wrongly-blamed-claire-for-paleo-pear-and-banana-bread-line-20170314-guxmf6.html)

Fun fact: Prince2 and ITIL – were both invented by the British Govt. – Professionalism of project management

back to contents

Consequences of new public management

* Management rather than self managing teams * Agencification – deepened siloes * Outsourcing – reliance on outsourcing became self harm (enabled through mutual self-interest)

Outputs over user experience

* Targets – incentivised deliverables over outcomes * Performance management – for individuals not teams * Generalists valued over (digital) specialists in Govt. * ‘Customer’ service transforming the public (or citizens) into consumers

Resulting challenges

* The challenge of importing the ways of the internet and network age into industrially structured orgs. * Increasing gap between consumer grade usability and govt services

Fun fact: In 2008 the UK Govt. spent 2235 million pounds on HP alone

back to contents

Friction

From four main areas:
  • Procurement
  • Governance
  • Technology
  • Security

Procurement

* In the UK under the GDS iniative spending controls were put in place. This mean saying no to contract renewals. * The challenge was the exit strategy for these, which meant there was a need to build in-house capability * The govt was addicted to contracted outsourcing – had to cut off the supply * Change the mindset from renewals to exits

Why does the govt. outsource

1. **‘Core competency’** – We don’t know IT, especially digital stuff – the writing is on the wall to remain relevant need to have internet/web capabilities 2. **Efficiency** – This is a straw man – do we measure use of the existing service. There is an assumption that outsourcing will ‘magically’ be efficient. Outsourcing comes with baggage. [Efficiency only comes if you are an informed customer - You need to understand what you are outsourcing and whether the service you want is a commodity or an innovative thing unique to your organisation] 3. **Risk transfer** – The blame game of contracts

back to contents

Procurement – traditional processes not designed for small things and microservices

Traditional procurement tends to be:

  • Expensive

  • Slow

  • Unfair

  • Broken

  • A lot of procurement process is tied up in avoiding legal and commercial risk... i.e. arse covering

  • The problem is - contracts requirements were too big, meaning small and medium size businesses were shut out of the procurement processes.

  • This lead to a loss of innovation that SMEs could bring in

  • Reduced competition, increased prices became the norm in a constrained market. This was compounded by preferred supplier lists

  • Leads to vendor lock-in

Two popular ways of scoring bids

  • Least Expensive Technical Fit (LETF)
  • Most Economical Advantageous Tender (MEAT)
  • It shouldn't just be these methods. You need to consider cultural fit and the quality of the product.
  • You can't score working culture
  • Government as a special snow flake

back to contents

The big problem

> Traditional procurement drives you to make the biggest decisions at the point at which you know the least

Contrast with:

  • AWS (most popular server as service model, see this hilarious April Fools AWS for kids site)
  • billing and set up on on demand
  • you can resell your unused capacity

How to fix procurement

* limit contracts to two years * smaller, simpler, projects * open standard * multiple suppliers

This should hopefully cut out the middle man. [Still requires an informed customer or buyer though]. The introduction of a digital marketplace has led to more government money being spent with small and medium enterprises.

1. Understand your value chain

[See Wardley value chain maps](http://www.wardleymaps.com/) > To understand the value chain you need to break down the monolith

[need someone who understands this – an informed customer]

2. Figure what to buy and how to buy it

[Incremental spending is a good approach to develop understanding of what and how to buy] > “Let’s ask the market” – no please don’t [You need situational awareness and an understanding of the value chain to be able to assess the quality of recommendations provided by ‘the market’ ]

Disaggregating spend, being an informed decision maker, and making use of in-house capability with incremental spends is a great way to build program capability

3. Fix the buying process

* Let everyone in and get out of the way * Have a procurement person on your team

4. It’s never too early to think about retirement

back to contents

Governance

> Definition: Making sure we’re doing the right things, in the right way.

From: Building what’s useful: governance and agile delivery | Co-op Digital Blog, Feb 2017

  • Governance (often perceived as)

  • Amorphous

  • It slows us down

  • Based on suspicion not trust, and adversarial

  • Without trust hard to have a good environment

[Teams needs trust, health, team based measurements, and shared motivations.]

  • Bad governance divorces decision making from learning
  • If decision makers are uninformed about execution
  • Leads to prioritising deliverables over outcomes
  • It’s based on guesswork not evidence

[Clear guides of what good looks like – for team]

back to contents

Measures of success

* They are complex and confusing * It’s happening at the wrong time… (we tend to do them up front) * With the wrong people (Highest Paid Persons Opinion HIPPOS) * Business cases – are a good thing (in theory) * They are good because they forces people to clarify benefits and consider options, which naturally leads to solutions… * But before we skip to the solution, let’s define the problem * Again we make the biggest decisions at the point at which we know the least.

back to contents

Example of current business case process in IT

  1. Write policy
  2. Guess requirements
  3. Procure IT system
  4. Inflict on users
  5. Operate (aka stasis)

The business case isn’t the product

  • User research and prototyping produces better business cases

How to do user research and prototyping

* Have a seed or incremental funding model. Supports an agile business case development model. Review proposals and give up to 50k to fund them. * Spend less, do right * Each project at the very least will give you a clearer idea of what your users want * Project needs should be judged by what your end users need.

back to contents

Misconceptions about Agile

Agile is:
  • chaotic
  • means ‘quick’
  • means no planning
  • has no governance
  • means no cost control

Governance in an agile team

1. Outcomes are better than deliverables 2. Measure the right things at the right times 3. Teams are the unit of delivery 4. Network of teams beats hierarchy 5. Everyone is responsible for quality 6. Assure as you go 7. Behaviours matter more than documents 8. See delivery for yourself

Source: Building what’s useful: governance and agile delivery | Co-op Digital Blog, Feb 2017

  • Only do it if it adds value
  • Optimise for smaller more regular decisions
  • Move away from all/nothing big bang decisions

back to contents

Expose the trade offs

* No real prioritisation or limiting of work flow

Pandora prioritisation technique

“What would be stupid for us not to do in the next 90 days?”

Source [Caution this article has annoying pop-ups]:This product prioritisation system nabbed Pandora more than 70 million active monthly users with just 40 engineers | First Round

  • Everyone writes a one pager
  • Everyone gets to vote (not just HIPPOS), use monopoly money

Trust (relationship management) and collaborate important
Bring diverse stakeholders onto your team

back to contents

Technology

  • It's not about the technology... apart from when it is

Enterprise architecture

* Beware of enterprise architects. Like economists they live in abstract models of reality. Up front setting up of standards is not good * One size does not fit all * Dependencies slow teams down * Enterprise above users (including staff) * Kills space for innovation * A better way to go is to develop micro service architecture that allows abstraction and development and choice of architecture as it proves useful over time

Buy vs. build

* This is a false binary choice

"We need an 'X' system"

* Show me the components that make up your system * Tell me about your value chain * Often business lines will be keen on system X and claim it is best of breed for their purpose. Have they tested it? * Try stuff out * Often end up with a square peg round hole type scenario. More needs usually equal less quality

back to contents

Software as service

* Beware software salespeople * Rules engines are also a trap * Software as an 'asset'... sorry it's not * What about your software do you have a plan for continuous improvement [you will get buried in technical debt, and platform lock in if not] * Moving from servers as pets (kept on premises and looked after) to servers as cattle (amazon AWS and servers as commodity) * Dev Ops - Use it to get people who build (project) and people who manage (program) to work together * A service manager can also help to think about thing in the long term operation of a service * Have tech people in your team from day 1 * Learn then automate * Get your devs doing non dev stuff (user research for example) * Let platforms emerge - user products first * Manage diversity, don't ban it

back to contents

Security

* IT security in govt suffers from 'Special snowflake syndrome' * Lots of arse covering * GCHQ (UK Spy Agency) - has an open source github account * GCHQ are also on record saying password expiry is dumb * Shadow IT is a digital desire path * Security is a team sport * Principles are more effective than labels (or accreditation schemes) * Minimum viable security (kind of) * Every security control should be mapped to threat and actor * Risk based approach, consider convenience vs. security

back to contents

Toolkit - just a few interesting ideas

[I liked hearing these a lot. I had heard of quite a few of them so it was good to see other smart digital service thinkers were also finding them]
  • The Cathedral and the Bazaar - On Linux but essentially about top down hiearchical build models, vs. loose networks web models. Ways of organising your organisation.
  • Should we stop building empires and start building networks of communities? [I was across this one and hope we can harness network theory to progress digital services]
  • Productivity paradox - [Many have discussed this, productivity is flattening in most modern economies. High tech projects don't seem to be as productive as promised hello Joint Strike Fighter and Obamacare site :-)]
**Adaptive change vs. Technical change**
Adaptive change Technical change
Learn new ways Apply current knowledge
People on the front line Manager and experts
[This one was new to me, I will definitely learning more about this [model](http://changetheorists.pbworks.com/w/page/15475038/Ron%20Heifetz)]

FIST tells procurement officers: keep a fixed schedule and delivery date – but keep requirements open, so that technological change can be built into the product. To handle the uncertainty, have a small, tight team able to respond rapidly to change during development, deployment, and post-deployment.

Source: FIST: Beating the Innovators’ Dilemma; Faster, Better Weapons Buying | Breaking Defense, Rachel Kleinfeld, July 2013

back to contents

Bruce Klopsteins

UX maven, content strategist, communicator, information obssessive, exploratory completionist, and fan of witty banter. When not quoting other people's brilliance, thoughts are my own.