1. GDSAdam Maddison and Ros Vaughan
Cabinet Office
Adam Maddison and Ros Vaughan
Agile and Open Policy Making
2. GDSAdam Maddison and Ros Vaughan
What is “Agile”?
Agile principles activity
Agile misconceptions
Agile within GDS
Open Policy and Agile activity
Assisted digital case study
Questions
4. GDSAdam Maddison and Ros Vaughan
The Manifesto for Agile
Software Development
http://agilemanifesto.org
5. GDSAdam Maddison and Ros Vaughan
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While there is value in the items on the right, we value
the items on the left more
http://agilemanifesto.org
6. GDSAdam Maddison and Ros Vaughan
The 12 agile principles
http://agilemanifesto.org
14. GDSAdam Maddison and Ros Vaughan
“What do you want by Friday
and how can we do better than
we did last week?”*
*Mat Wall, Technical Architect at GDS
This is a brief presentation on what is agile - with a small ‘a’ - what being agile means and how we are being agile at GDS.
Please ask questions, this session will probably leave you with more questions and we won’t answer everything here.
In winter 2001, 17 software developers met at the Snowbird ski resort in Utah - not just to ski - to discuss lightweight software development methods.
They published the Manifesto, which is focused on software but can be applied to non-software products.
It has four main guidelines...
This ending statement is important here... "While there is value in the items on the right, we value the items on the left more."
"The whole purpose of the Agile Manifesto is to deliver better software. We need to focus on value and results that add to a firm's competitive advantage. Of course, this was always the intention of Waterfall projects. It simply did not happen very often. All too often we focused on the process and documentation, which resulted in a false sense of security; and we didn't communicate with the people who, in the end, are most important."
http://www.scrumalliance.org/community/articles/2013/2013-april/what-does-the-agile-manifesto-mean
Breakout exercise - with the people sitting next to you, look at the handout and reword the principles into 5 words or less that fit with policy work. If you don’t think it applies to policy - why?
If you understand the core principles of agile, then practice and promote the culture, you are agile.
Some of the most common misconceptions of Agile are that...
Agile projects deliver sooner:
The main aim of agile is to deliver value as soon as possible. However this is rarely the finished product, but it allows the tight customer feedback loop needed to deliver what the customer actually wants, not what they thought they wanted at the start.
Agile's focus is on building a quality product and not the speed of its delivery.
Agile projects can take just as long as traditional methods, such as waterfall - but Waterfall projects are three times more likely to fail than Agile projects according to the Standish group of management consultants.
In contrast to a Gantt chart, running well into the future, with all key milestones and delivery dates planned from a detailed requirements document, employing agile principles allows you to delay decisions until they really need to be made, avoiding Big Design Up Front;
Central to agile is the ability to change direction based on the (inevitably) changing landscape.
So you are constantly planning and, crucially, adapting those plans based on what you discover.
Eisenhower: planning is everything the plan is nothing
With
customer collaboration,
constant planning,
visible progress,
frequent user testing and
continuous delivery,
agile is far from ill-disciplined.
But the processes and tools used should be the minimum needed for the given situation.
When agile is done badly (or not communicated effectively) it can feel to people that it is chaotic - but that’s probably the same with any project that isn’t disiplined
Hands up, who has heard of the term scrum? - in what context?
Scrum is not agile. It a methodology based on the principles of agile
There are many tools, techniques and recommendations like scrum that you can use to help you. But just using these doesn't mean that you are being agile.
So a question we often get asked.
There is no official GDS agile - we come from a variety of backgrounds, our teams do different things in different ways. We are framework agnostic
Matt Wall, Technical Architect as GDS, describes agile as this.
This sounds like over-simplification, but at its heart that is what being agile is about.
This is its underlying principle; continuous iteration and improvement based on feedback, not speculation. Inspect and adapt.
We are framework agnostic
We have small, cross-functional teams of
designers,
developers,
business analysts
product and delivery managers
working together with customers (departments and agencies) and users.
Communication and collaboration are key.
The teams are self-organising, and autonomous. They are empowered to deliver.
We use practices such as Test driven development that allow us to focus on delivering quality:
Better quality results in:
less re-work
lower maintenance
happier users
We use processes such as continuous integration that allow us to deliver regularly
Adam’s old team deployed roughly twice a week.
Amazon apparently every 11.6 seconds.
Quick delivery allows you to get rapid feedback from users to make sure we’re delivering the right thing -
And if we’re not, the short lead time lowers the cost of change. We can fail. But… We fail early. We fail small.
The key to successful agile projects is this short feedback loop
The
In order to do that, we need to focus in detail on what we want to deliver next. So we break down the task into small features or user stories - components of functionality that deliver real value to end users.
Prioritise and re-prioritise to make sure we’re doing the next most important thing
Explain what assisted digital is
User researchers, procurement
Worked closely with service delivery to understand practicalities
Worth having an experienced delivery manager and product manager (or people who are brought into agile) to lead by example
Discovery: looked at what the need was, who was involved and what was currently available. Published a policy paper ‘Government approach to assisted digital’ - didn’t set out the how, but set out the vision for what providing good assisted digital would provide and who was involved
Alpha: developed the personas further and started to map an ideal user journey through assisted digital. Shared this with services (eg passports, LPA, rural payment etc) and stakeholders like CAB etc to get feedback
Beta: selected a few services to work with to test assisted digital with users. Different services tested different elements (eg triaging people; phone support
Live: should probably update the Govt approach to assisted digital with case study and lessons, along with the model. Published guiance into the Digital by Default Serviec Manual - continuously improving this
Beta: prototype
GDS: private/pulic beta
OPM: pilot
User researchers, procurement
Worked closely with service delivery to understand practicalities
Stakeholder reference group
User researchers, procurement
Worked closely with service delivery to understand practicalities
Stakeholder reference group
User researchers, procurement
Worked closely with service delivery to understand practicalities
Stakeholder reference group
This is the master version of the slide, please use this version and add your names.
