Advertisement
Check these out next
You keep using the word agile, i do not think it means what you think it means
Sep. 26, 2015•0 likes•3,033 views
4 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Software
Slides for the talk about what people think agile is, what agile is about and how you can get back to the idea of agile. A recording of the talk from NDC London 2016 should be available here https://vimeo.com/158164783
Nathan GloynFollow
Senior Software Developer at Gibraltar SoftwareAdvertisement
Advertisement
Advertisement
Recommended
Crafting digital experiences with agile and design by James HayesScrum Australia Pty Ltd
6.3 Refining, Prioritizing, Backlog Value Management v3.0Technology Expresso Expresso-Consulting
Pragmatic Architecture for Agile TeamsJanne Sinivirta
ARTEM BYKOVETS "Agile manifesto: Principles" Kyiv Project Management DayLviv Startup Club
Heart of agile by Pierre HervouetAgile ME
BA World - BA in AGILE ProjectsMethodgroup
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 @NathanGloyn
- Quick poll Who’s “doing” agile? silhouettes human group by Gerd Altmann used under CC 0
- What most people think is agile Work in 2 week iterations User Stories Story points/Planning Poker Backlog of items Meetings Board with post it notes or Jira
- You’re telling me this isn’t agile? If You're Not Confused by Brian Talbot used under CC BY
- Why isn’t this agile? Cargo Cult
- Why isn’t this agile? 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
- How did we get here? 1995 - 2000 2001 - 2008 2008 - 2012 2012 - today
- How did we get here? The problem delivering a product is the development process
- How did we get here? It will be cheaper
- How did we get here? Software will be “delivered” more frequently
- How did we get here? Able to change requirements right up to the last minute with no problems
- How did we get here? Want a “named” method with process & practices
- How did we get here? Certification implies knowledge
- Stand back…. I’m certified! Derivative of Superhero Rob by Rob Cottingham used under CC BY
- Where it goes wrong 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
- The result an unwitting victim...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
- So what is agile? Self-Portrait E by Steve Snodgrass used under CC BY
- Agile Manifesto Individuals and interactions 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.
- Principles behind agile manifesto 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
- Principles behind agile manifesto 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
- Principles behind agile manifesto 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
- Why would you want to use agile? Communication Transparency Trust Collaboration Delivering value to the business
- What is value? Today I bring value to the world by Kimberly King used under CC BY
- What is “value”? Value likely 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
- Agile isn’t… Completing tasks User stories, Story points & planning poker Meetings Working through Product Owner “to-do” list Following an Agile methodology
- Agile is… Working software Focused on vision & goals Feedback loops Delivering value People from across the business/organisation all work together
- Its not a set of rules "Rules and Regulations...Threshing Committee of the U.S. Food Administration for Knox Co." by Unknown or not provided used under CC BY
- Technical practices Unit testingRefactoring YAGNI Pair Programming Continuous Integration Version control ATDD BDD TDD Refactoring Collective ownership Continuous Deployment Iterative development Mob programming
- Product practices User Stories Product backlog Product canvas Value stream mappingCustomer on site Personas Vision & Goals MVP Product Roadmap MoSCoW
- Project practices Story Points flow Story mapping 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
- The difference Working software is the priority Focused on goals for the project/product Looking to add value Everyone involved collaborates around the work
- 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
- What does evolution look like? Variety of practices from methodologies Pick the practices that work Focus on vision/goal for project Keep delivering working software Keep collaborating
- What to take away 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
- Questions? @NathanGloyn www.designcoderelease.blogspot.com
Editor's Notes
- Of the people who are agile check how many are doing Scrum, XP, Kanban, something else
- 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
- 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
- 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
- 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
- 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
- “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
- 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
- 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
Advertisement