Modern agile overview
•Download as PPTX, PDF•
3 likes•1,054 views
An overview of Joshua Kerievsky’s "Modern Agile", used to generate some interesting discussion at Agile Ottawa in Feb 2016. Based on Joshua's work: * blog: https://www.industriallogic.com/blog/modern-agile/ * webcast: http://leankit.com/blog/2015/12/modern-agile/
Report
Share
Modern agile overview
- 1. Modern Agile Overview Agile Ottawa Feb 2016 by Steve Purkis & Dag Rowe based on Joshua Kerievsky’s work: https://www.industriallogic.com/blog/modern-agile/ http://leankit.com/blog/2015/12/modern-agile/
- 2. Joshua had seen too much of this... Sprints Storypoints Standups Agile?!? http://leankit.com/blog/2015/12/modern-agile/
- 8. Why does your business exist? We have great new tech! We’re the best at what we do! We have brilliant marketing! We have the greatest product(s)! …
- 9. Your business exists… To help your customers achieve something! they don’t have the skills/resources they’re too busy it’s too painful they’d just rather not do it …
- 10. Modern Agile: Go beyond just helping your users… Make them awesome!
- 11. eg: SimpleTax.ca What switching meant to me… No more excel + paper tax returns! Less work figuring out what I needed to do. More money back than I would’ve otherwise! It was really nice to use! Great, friendly support They offered it to me for free… and they actually meant it! They took away the pain, and even made it a little bit pleasant to file taxes.
- 12. What does your user need? May not be the same as what they say they want! Up to you to figure it out. Customer journey mapping https://www.b2binternational.com/publications/customer-journey-mapping/
- 13. Chartering your work How are you going to make your users awesome? What does it mean? What’s your vision? mission? How will you know when you’ve succeeded? Measurable & testable outcomes Ongoing, revisit during a project.
- 14. Big shift in thinking! eg: Definition of Done Internal acceptance criteria
- 15. Big shift in thinking! eg: Definition of Done Internal acceptance criteria vs Validated by real users
- 16. Make Safety a Prerequisite discipline #2
- 17. - Frank Herbert, Dune image: http://hplusmagazine.com/2014/11/04/fear-mind- killer/
- 18. Fear poisons productivity Being fired Being penalised for making a mistake Being rejected Being excluded or marginalised Looking stupid These are basic, primal fears. In our tribal past, rejection by a group could involve banishment, which could result in death.
- 19. Anzeneering “Protecting people is the most important thing we can do, because it frees people to take risks and unlocks their potential. I call this Anzeneering, a new word derived from anzen (meaning safety in Japanese) and engineering.” - Joshua Kerievsky
- 20. everyone, not just devs! Software users Software makers Software managers Software purchasers Software stakeholders Make it safe to fail Read this! https://www.industriallogic.com/blog/anzeneering/
- 21. How do I make it safe to fail at my company? Break down any culture of fear you come across. Empower employees to: voice dissenting opinions safely take risks discuss & address safety issues bring new ideas to the table Avoid mixed messages (we care about your safety, but please
- 22. Remember, it’s people! Respect & appreciation Be authentic Cultivate an open mind Transparency (2 way street!) Shared responsibility Boost communication
- 23. Safety-first is a Cultural Shift Do it safely: evolve gradually. Try to understand where your organisation is at first. Have a plan on how to change. Share it!
- 24. Improve software safety Test! TDD, Automated testing, Manual testing Refactor, continuous improvements Continuous Integration Pay down tech debt de-SPOF coders pair as needed
- 25. Evolution: Smaller releases Less risk for developers, customers, users & managers. Better feedback loops.
- 26. Remember: we’re dealing with complex systems! Assume goodwill Use 5 why’s / root cause Use neutral language Seek to understand, not criticize Encourage everyone to share Blameless Retros http://www.businessinsider.com/etsy-chad-dickerson-blameless-post-mortem-2012-5
- 27. User safety & appreciation Own up to issues and provide solutions eg: Sorry, we overcharged you last month! That’s embarrassing to say the least. We’ve refunded your account, and given you an extra [month free] to make up for it! Step up to show your appreciation Notice things & engage users. eg: You didn’t use all your credit with <SaaS co> this month. 1. do/say nothing 2. message: You didn’t use all your credit this month. Please call us at your earliest convenience to get a refund. 3. message/act: You didn’t use all your credit this month, so we’ve refunded the difference.
- 28. Experiment and Learn Rapidly discipline #3
- 29. Lean Startup = Lean Thinking + Customer Development + Agile Development Lean startup is a process involving rapid and iterative experimentation to test assumptions and build a product or service that customers actually want
- 31. Lean UX = Lean Thinking + Design Thinking + Agile Development Lean UX is a process to build a product that customers actually want with a focus on shared understanding of the experience being designed
- 32. Design Thinking
- 34. Science! 1. Assumptions 2.Hypothesis 3.Experiment 4.Measure 5.Learn Pivot (do something else based on what you’ve learned) Continue
- 35. Fail Fast Make it safe to fail because failure enables learning You can learn by conducting an After Action Review when you project is late and over budget Or you can choose to learn quickly and cheaply before committing to building a product Some people don’t like the word fail - call Learn Fast instead
- 39. Continuous Delivery Maturity Model
- 42. CD Resources Books The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation CD videos http://shop.oreilly.com/product/110000679.do
- 43. Joshua Kerievsky’s Modern Agile Blog post https://www.industriallogic.com/blog/modern-agile/ Webinar @ Lean Kit http://leankit.com/blog/2015/12/modern-agile/
- 44. Things that may come up
- 45. Agile Manifesto & Modern Agile http://leankit.com/blog/2015/12/modern-agile/
Editor's Notes
- “Burger, chips & cola” agile ritualistic. not really agile.
- explain briefly what each section is about. 4 discilpines overlapping principles, practices & recommendations. subject to change Not a framework like Scaled Agile Framework (SAFE), or Large Scale Scrum (LeSS) A lot has happened since the Agile Manifesto was written.
- Arguably there are more methods
- while these might *help you*, they’re not directly helping your customer.
- I didn’t know what I was missing before I switched, and now I’ll never stop singing these guy’s praises. We should all strive to make our users awesome. Big shift in thinking.
- Experimenting on them
- Don’t go overboard. 1-2 paragraphs is usually enough. This idea should extend to your product backlogs / stories.
- Ask audience what their definition of done is.
- Dag’s got a great little video showing this in action later.
- When we work with these fears ever-present, our productivity drops.
- you’re not making it safe for them, if... you loose your users’ data, you burn through all your customer’s money without delivering anything
- Some ideas to get you started...
- Trying to operate in green when your organisation is currently red will likely result in problems. Seek to understand.
- You want to make decisions based on data, not the quality of the powerpoint presentation Note this is not a new idea, in classic lean this is called PDCA - plan do check act
- Outside in development - another way to solve problems Image credit: http://www.neomobile-blog.com/design-thinking/
- Image credit: http://xkcd.com/
- Like science both lean flavours require you to be specific, measurable, and be associated with metrics - e.g. what is the threshold for success? Disproving an assumption is more valuable than validating it
- validated learning Dan North - deliberate discovery Safe to fail
- Need speakers
- Model credit: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Hardcover – Jul 27 2010 by Jez Humble (Author), David Farley (Author) A spreadsheet with the model so we can fill it out.
- Model credit: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Hardcover – Jul 27 2010 by Jez Humble (Author), David Farley (Author) I found having a conversation to model our ‘as is’ state very useful for gaining management buy in.
- Safe to fail - you want to fail early with as few changes as possible Isolate cause of failure more narrowly - e.g. is it a code problem related to one commit, or a problem that emerges when the full stack is set up? Fail sooner so you don’t spend time on builds that have problems Note that manual processes are allowed in the pipeline - e.g QA, security, or process approvals Requirements Solid version control of all aspects of your system Note that this includes you code, code dependencies, OS, and OS dependencies (patch levels) CI - CD is the logical conclusion of CI Automate everything (you can) Smoke tests Solid rollback plans - you expect to fail Push 1 binary through the pipeline - don’t rebuild from environment to environment
- validated learning Dan North - deliberate discovery Safe to fail