Downloaded 15 times
Uploaded byNathan Gloyn
You keep using the word agile, i do not think it means what you think it means
The document critiques common misconceptions about agile methodology, emphasizing that it's often misapplied as merely following set rules or completing tasks, rather than focusing on delivering working software and customer collaboration. It outlines principles from the Agile Manifesto, stressing the importance of communication, flexibility, and valuing working software over exhaustive documentation. To effectively reclaim agile, teams should prioritize collaboration, transparency, and continuous delivery of value while adapting practices to suit their specific contexts.
More Related Content
Similar to You keep using the word agile, i do not think it means what you think it means
You keep using the word agile, i do not think it means what you think it means
- 1. You keep usingthe word agile I DO NOT THINK IT MEANS WHAT YOU THINK IT MEANS @NathanGloyn
- 2. Quick poll Who’s “doing” agile? silhouetteshuman group by Gerd Altmann used under CC 0
- 3. What most peoplethink is agile Work in 2 week iterations User Stories Story points/Planning Poker Backlog of items Meetings Board with post it notes or Jira
- 4. You’re telling me thisisn’t agile? If You're Not Confused by Brian Talbot used under CC BY
- 5. Why isn’t thisagile? Cargo Cult
- 6. Why isn’t thisagile? Focus on completing the tasks/stories Software is not deployable KPI’s based on tasks/stories Team not self organising Meetings do not add value
- 7. How did weget here? 1995 - 2000 2001 - 2008 2008 - 2012 2012 - today
- 8. How did weget here? The problem delivering a product is the development process
- 9. How did weget here? It will be cheaper
- 10. How did weget here? Software will be “delivered” more frequently
- 11. How did weget here? Able to change requirements right up to the last minute with no problems
- 12. How did weget here? Want a “named” method with process & practices
- 13. How did weget here? Certification implies knowledge
- 14. Stand back…. I’m certified! Derivativeof Superhero Rob by Rob Cottingham used under CC BY
- 15. Where it goeswrong Mistaking practice for result Just renaming existing processes/roles Misunderstood/missed the point behind of a practice Not interested in agile outside of the development process Agile isn’t the right process
- 16. The result an unwittingvictim...bwahahhahahaa by Bark used under CC BYSelf Portrait As A Stressed-Out Bride To Be by Brittney Bush Bollay used under CC BY What have I done!? by Miguel Angel used under CC BY
- 17. So what is agile? Self-PortraitE by Steve Snodgrass used under CC BY
- 18. Agile Manifesto Individuals andinteractions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
- 19. Principles behind agilemanifesto Highest priority is customer satisfaction through early and continuous delivery of valuable software Welcome changing requirements, even late in development, to harness change for customers competitive advantage Deliver working software frequently with a preference to the shorter timescale Business people & developers to work together daily
- 20. Principles behind agilemanifesto Build projects around motivated individuals, giving them environment & support they need, and trust them to get the job done Most efficient way of conveying information is face-to-face conversation Working software is the primary measure of progress Promote sustainable development. Sponsors, developers & users should be able to maintain constant pace indefinitely
- 21. Principles behind agilemanifesto Continuous attention to technical excellence & good design Simplicity – art of maximising work not done – is essential Best architectures, requirements & designs emerge from self-organising teams Team should meet at regular intervals to reflect on how to improve
- 22. Why would youwant to use agile? Communication Transparency Trust Collaboration Delivering value to the business
- 23. What is value? Today Ibring value to the world by Kimberly King used under CC BY
- 24. What is “value”? Valuelikely to be specific to your team/business/organisation Determine what your value (or values) Work out how to measure it Use your “value” to help with decision making around work to be done
- 25. Agile isn’t… Completing tasks Userstories, Story points & planning poker Meetings Working through Product Owner “to-do” list Following an Agile methodology
- 26. Agile is… Working software Focusedon vision & goals Feedback loops Delivering value People from across the business/organisation all work together
- 27. Its not a setof rules "Rules and Regulations...Threshing Committee of the U.S. Food Administration for Knox Co." by Unknown or not provided used under CC BY
- 28. Technical practices Unit testingRefactoring YAGNI PairProgramming Continuous Integration Version control ATDD BDD TDD Refactoring Collective ownership Continuous Deployment Iterative development Mob programming
- 29. Product practices User Stories Productbacklog Product canvas Value stream mappingCustomer on site Personas Vision & Goals MVP Product Roadmap MoSCoW
- 30. Project practices Story Points flow Storymapping No Estimates Definition of done Impact Mapping options Visual work tracking Restrict WIP Classes of work Kaizen Retrospectives Eliminate waste Pull based Risk Storming Release Train cynefin
- 31. The difference Working softwareis the priority Focused on goals for the project/product Looking to add value Everyone involved collaborates around the work
- 32. How to “reclaim”agile? Nothing wrong with starting with a methodology You do not have to “follow the rules” The wider business becoming involved Become involved with the wider business Evolve
- 33. What does evolutionlook like? Variety of practices from methodologies Pick the practices that work Focus on vision/goal for project Keep delivering working software Keep collaborating
- 34. What to takeaway Always focus on delivering working software Make whatever process you have transparent Communication & Collaboration is key Don’t be bound by “the rules” Evolve to help you deliver value
- 35.
Editor's Notes
- #3 Of the people who are agile check how many are doing Scrum, XP, Kanban, something else
- #16 Mistaken belief that all they need to do is to implement practices from a chosen methodology and they’ll get all the rewards that they hear about on the internet Keep all their existing ways of working, just rename them and add on parts that they weren’t already doing People have read up on the practices and might well start off trying to follow them but often fall by the wayside and implement what they think it should
- #19 Working software is the only concrete thing in the left side, all the other items on the left of the manifesto are about ideas & principles
- #20 Customer satisfaction with software delivered is key Understanding that requirements change should influence how we build the software Focus on delivering working software and the more frequently it can be delivered the better Business people need to be working with the developers/testers so can answer questions, provide additional information, confirm work complete, etc
- #21 Give the team what they need then get out of their way and let them get on with developing the software – no micro-management Studies have shown that there is a spectrum for most efficient way to convey information with face-to-face being the best way to do so Again stressing that working software is the thing that is the measure of progress, not the number of tasks/user stories completed Sustainable development is key, should be able to guarantee software will be delivered all the time
- #22 Focus on technical excellence – reduce bugs & design to enable change No gold plating, only doing what is needed (YAGNI) The team building the software should be the ones who are driving gathering requirements, designing the software, technical standards, etc goes back to trust the team Meet regularly to improve, not necessarily to a timetable but when e
- #26 “As a … I want … so that ….” has become a common way to express requirements, the idea being that it is quick to create and therefore easy to work with Unfortunately a lot of people take the user story at face value and don’t understand what is involved in creating a good user story and all the supporting information required to make them useful, let alone the whole idea of using them as a starting point for a conversation about what is actually needed. A lot of teams believe, sincerely, that they are following an agile methodology but practising a methodology doesn’t make you agile Even though the team follows all the rules of their chosen methodology, ensuring that they are doing what is proscribed in whatever book or course they’ve read/attended, when looked at closely they aren’t actually agile People frequently associate agile with meetings, more specifically people tend to associate SCRUM with meetings The meetings are supposed to be scheduled points in time for the team to get together for specific reasons but often these meetings are hijacked and the reason for them is subverted
- #31 Technical practices – TDD, Pair programming, YAGNI, continuous integration/delivery/deployment Product practices – user stories, product backlog, value stream mapping, Project practices – flow, restrict WIP, no estimates, definition of done, information radiators, options
- #33 The idea of Shu-Ha-Ri is often put forward in relation to agile (most frequently SCRUM) but then people become unhappy if you didn’t “follow the rules” of scrum, you were considered to be doing scrum-but the zealots declared you weren’t doing it “right” if you didn’t follow the rules. As a minimum if the business understands what involved with working in an agile manner then it can become easier to handle things like resource allocation, work prioritization. If a business fully grasps working in an agile way then looking at techniques such as “value stream mapping” can help them understand everything that is involved in creation of the software and can identify problems that are outside of development & test