Using agile for things that aren't software
•
5 j'aime•619 vues
From UK Government Fast Stream Conference in February 2017, a presentation about how agile project management can be used for things that aren't software, including a case study on the successes and failures of a skills project.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (16)
Similaire à Using agile for things that aren't software
Similaire à Using agile for things that aren't software (20)
Dernier
Dernier (20)
Using agile for things that aren't software
- 1. Using Agile for things that aren’t software Tracey Williams @tewilliam February 2017
- 2. Agile 101 Agile is a project management method
- 4. Agile 101 Pioneering Breaking new ground Uncertain environment Unpredictable Standard Known Certain environment Stable Diagram simplified from Simon Wardley’s blog http://blog.gardeviance.org/2013/11/oh-not-again-should-we-be-agile-or-six.html Agile performs best Prince II etc. performs best Greater certainty
- 6. Case Study - MOJ Digital Capability Project Aim: Improve digital capability Generalist Civil Servants Digital Specialists Discovery Focus Non-Digital Specialist Civil Servants
- 7. Discovery, what did our users say? 1 3 2 24 People want to learn, but not online. “Face to face, interactive learning is a big investment, but compared to online learning, or just listening, it is worth it” People want to work digitally, but need leaders. “Oh, that would work! But I don’t think we would be allowed to do it.” People like digital tools, but exaggerate risks. “It’s obviously useful, is it IL3?” People know they have users, but not how to learn from them. “We held a consultation with users, it was hideous, people came back very upset”
- 8. User needs as user stories As a... policy advisor I need to... do learning courses at lunch times So that... training fits around the demands of my work For example:
- 9. Some characteristics to define a digitally capable person 1 Put user needs ahead of process 2 Start small, and improve from there 3 Make the most of digital tools 24 Manage risk, don’t be blocked by it 25 Feel empowered to innovate https://mojdigital.blog.gov.uk/2014/12/19/digital-capability-bringing-innovative- styles-of-working-to-moj/
- 10. In Agile, we take a small slice and deliver a product quickly 1 Put user needs ahead of process 2 Start small, and improve from there 3 Make the most of digital tools 24 Manage risk, don’t be blocked by it 25 Feel empowered to innovate Initial focus
- 11. What happened next? Alpha testing options with staff in Alpha e.g. training, workshops, lunch & learn Discovering what works best through user testing Make our offering scalable in Beta (via Civil Service Learning)
- 12. Our Alphas
- 13. How did it go? The good stuff People were excited to be involved in something that felt different :)
- 14. How did it go? The good stuff People found the sessions useful and learnt from how we were developing them :)
- 15. How did it go? The good stuff We discarded things early that we might otherwise have put into a formal framework :)
- 16. BUT... We took too long to deliver and the world moved on before we could scale up in Beta :/
- 17. Agile - Practical Application Some practical tips on putting Agile into practice
- 18. Agile - Practical Application 1 Read GDS Service Manual www.gov.uk/service-manual The principles remain the same for any project
- 19. Agile - Practical Application 2 Get out there and speak to USERS (Though there can be heavy overlap) Users ≠ Stakeholders
- 20. Agile - Practical Application 3 Test something small WITH USERS within WEEKS (Pilots usually take months, too late to make big changes) Alphas ≠ Pilots
- 21. Agile - Practical Application 4 Review user reactions at least fortnightly, iterate model based on that based on ≠ “take into account”
- 22. Agile - Practical Application A couple to start with: gds.blog.gov.uk/2015/10/09/how-to-be-agile-in-a-non-agile-environment/ www.gov.uk/service-manual/agile-delivery/agile-methodologies There are lots of useful blogs and other resources out there. Search for them!
- 23. Tactics to overcome resistance
- 24. Tactics to overcome resistance 1 Persuasion Civil Service style…. Exploit the hierarchy! Have any leaders made statements about change/transformation? What does your DG/Perm Sec want? Can you make your manager look good with this?
- 25. Can you just get on with it? Tactics to overcome resistance 2 Rear Adm. Dr. Grace Hopper “It is easier to ask forgiveness than it is to get permission” Imagesource:https://obamawhitehouse.archives.gov/blog/2014/12/22/honoring-grace-hopper
- 26. Tactics to overcome resistance 3 Be Bold... Read: medium.com/@JanetHughes “[Being bold] involves taking a risk based on a credible belief that you’re right, even if nobody else agrees with you at the time.”
- 27. Bonus slide: some wise words to end on “The most difficult thing is the decision to act, the rest is merely tenacity.” Amelia Earhart “Done is better than perfect.” Sheryl Sandberg “The difference between successful people and others is how long they spend time feeling sorry for themselves.” Barbara Corcoran “You can’t be that kid standing at the top of the waterslide, overthinking it. You have to go down the chute.” Tina Fey
- 28. Using Agile for things that aren’t software Tracey Williams @tewilliam February 2017
Notes de l'éditeur
- It’s that simple!
- Founded by a group of American software developers in 2001 on a ski holiday They found that they were being asked to produce excellent documentation, contracts and plans at the expense of actually good and working software. They wrote a manifesto for changing that.
- Agile isn’t right for every project. It works well where there is less certainty about the environment and the outcomes. [Credit Simon Wardley]
- From that first manifesto, this is the terminology of how projects have come to be run. I’ll explain more about each phase as we go through the case study next. In brief: Discovery - you find out what your users actually need before planning anything Alpha - make rough drafts / prototypes and test them with your users until you get something you’re confident meets the needs you’ve discovered Beta - for scaling up. You firm up your Alpha, put the right infrastructure in place and make it public BEFORE IT IS FINISHED Live - you’re confident it meets your user needs BUT you don’t stop developing and testing
- To meet the goals of the wider government strategy, our aim was to improve digital capability We interviewed users from these two groups and ran group sessions to discover their needs around Learning Working digitally Along the way we also realised we needed to *define* digital capability too, which I’ll come to.
- Discovered some interesting and unexpected things. I’d assumed it might be just a training issue, but actually the role of risk aversion and leadership came through really strongly
- You can turn those findings into user stories [Flag up extract from gds service manual] And you can display them on the wall to remind you of your main focus
- This was a discovery output from our interviews and group sessions - to help us develop a scale to measure our success It also set us a useful scope for the work we could do
- In Agile, you go for a “Minimum Viable Product” What is the smallest thing you could deliver in its entirety to meet the need? The learning you’ll gain from doing a small slice quickly can then usefully inform you as you take the next slice This works really well if you’re doing something that’s breaking new ground It means you don’t try to plan too much in a situation where you’re uncertain how people will react to your product
- This was the plan for what we did next
- We ran various types of sessions with staff (workshops, lunch and learn) Content was updated and improved after each session, iterating on what had worked and what hadn’t. All staff involved knew we were developing the sessions - no pretence this was a finished product Example of useful finding - too much content is counterproductive, only so much you can get across Received 100% positive feedback on sessions
- A review of our Alphas
- A review of our Alphas
- As I said, too much content is a bad thing - we knew what worked by the end of Alpha phase
- > The discovery had lasted months not weeks > Leadership changed and priorities changed, this was no longer as important as other things > Still a really valuable learning experience, and materials still being used a year later
- It’s for software development but the principles remain the same for any project
- Users = the people who use your product or service Stakeholders = the people who have an INTEREST in your product or service (some of whom are users)
- I would argue that Pilots are more similar to Beta phase, it’s a near finished article that you go public with and test
- It is vital that your users lead you to where you are going, not just act as an influence This is hard when Ministers and leaders have a fixed idea of what they want
- GDS blog is a goldmine
- It’s a common theme People who have risen to positions of authority doing things in a particular way don’t always want to do things any other way They are comfortable with what they know, so have some empathy with their situation rather than getting angry!
- The CS works on hierarchies. Can you find someone in the hierarchy to approach about this? Say you’re hoping to learn from them, you have ideas etc. Failing a direct meeting, how about private office?
- Grace Hopper was a pioneering computer coder in the US Navy, and she coined this phrase. Does anyone need to know *how* you do things now, as long as they get done? Can you get a quick win, make your seniors look good then present how you did it once it’s working? If you answer no to either of these, be aware of the risk you’d be taking - I’m not advocating lying to your boss...
- You are the leaders of the future. We need you to be bold.