Downloaded 16 times
Uploaded byPolicy Lab
Workshop 17 adam maddison and roslyn vaughan
This document discusses agile principles and how they can be applied to policy making. It defines agile as favoring individuals, collaboration, and responding to change over processes, documentation, contracts, and sticking to plans. Common misconceptions about agile are that it means projects are delivered sooner, there is no planning, and it is chaotic with little discipline. The document advocates for applying agile principles like iterative delivery, multidisciplinary teams, and open communication used in GDS to the stages of policy making. An example of assisting digital is provided.
More Related Content
Similar to Workshop 17 adam maddison and roslyn vaughan
Workshop 17 adam maddison and roslyn vaughan
- 1. GDSAdam Maddison andRos Vaughan Cabinet Office Adam Maddison and Ros Vaughan Agile and Open Policy Making
- 2. GDSAdam Maddison andRos Vaughan What is “Agile”? Agile principles activity Agile misconceptions Agile within GDS Open Policy and Agile activity Assisted digital case study Questions
- 3. GDSAdam Maddison andRos Vaughan What is this “Agile” (or “agile”) thing?
- 4. GDSAdam Maddison andRos Vaughan The Manifesto for Agile Software Development http://agilemanifesto.org
- 5. GDSAdam Maddison andRos 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 andRos Vaughan The 12 agile principles http://agilemanifesto.org
- 7. GDSAdam Maddison andRos Vaughan Agile is a culture, not a process
- 8. GDSAdam Maddison andRos Vaughan Some common misconceptions of agile
- 9. GDSAdam Maddison andRos Vaughan Misconception: Agile projects deliver sooner
- 10. GDSAdam Maddison andRos Vaughan Misconception: There's no planning with agile
- 11. GDSAdam Maddison andRos Vaughan Misconception: Agile is chaotic with little discipline
- 12. GDSAdam Maddison andRos Vaughan @psd
- 13. GDSAdam Maddison andRos Vaughan What is the “official” GDS agile?
- 14. GDSAdam Maddison andRos Vaughan “What do you want by Friday and how can we do better than we did last week?”* *Mat Wall, Technical Architect at GDS
- 15. GDSAdam Maddison andRos Vaughan The unit of delivery is the team
- 16. GDSAdam Maddison andRos Vaughan The focus is quality
- 17. GDSAdam Maddison andRos Vaughan Get feedback as quickly as possible
- 18. GDSAdam Maddison andRos Vaughan Break down the task
- 19. GDSAdam Maddison andRos Vaughan @psd
- 20. GDSAdam Maddison andRos Vaughan https://www.gov.uk/service-manual/start
- 21. GDSAdam Maddison andRos Vaughan Service Design Phases applied to Open Policy Making?
- 22. GDSAdam Maddison andRos Vaughan
- 23. GDSAdam Maddison andRos Vaughan Case study: Assisted Digital
- 24. GDSAdam Maddison andRos Vaughan Multi-disciplinary team
- 25. GDSAdam Maddison andRos Vaughan Discovery, Alpha, Beta, Live
- 26. GDSAdam Maddison andRos Vaughan
- 27. GDSAdam Maddison andRos Vaughan Open communications
- 28. GDSAdam Maddison andRos Vaughan Discipline
- 29. GDSAdam Maddison andRos Vaughan Questions (or @dog_bytes @ros_vaughan)
- 30. GDSAdam Maddison andRos Vaughan Cabinet Office Adam Maddison and Ros Vaughan @dog_bytes @ros_vaughan
Editor's Notes
- #2 This is the master version of the slide, please use this version and add your names.
- #3 5mins Intros 10mins Agile concepts 20mins Agile principles exercise 15 mins Agile misconceptions
- #4 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.
- #5 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...
- #6 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
- #7 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?
- #8 If you understand the core principles of agile, then practice and promote the culture, you are agile.
- #9 Some of the most common misconceptions of Agile are that...
- #10 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.
- #11 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
- #12 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
- #13 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.
- #14 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
- #15 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
- #16 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.
- #17 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
- #18 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
- #19 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
- #24 Explain what assisted digital is
- #25 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
- #26 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
- #27 Beta: prototype GDS: private/pulic beta OPM: pilot
- #28 User researchers, procurement Worked closely with service delivery to understand practicalities Stakeholder reference group
- #29 User researchers, procurement Worked closely with service delivery to understand practicalities Stakeholder reference group
- #30 User researchers, procurement Worked closely with service delivery to understand practicalities Stakeholder reference group
- #31 This is the master version of the slide, please use this version and add your names.