Agile practices and benefits
Download as PPTX, PDF1 like1,095 views
The document covers agile practices, benefits, and methodologies relevant to software development, emphasizing the significance of collaboration, customer feedback, and iterative processes. It outlines various practices such as continuous integration, test-driven development, and daily stand-ups, highlighting their roles in improving value delivery, quality, and productivity. Additionally, it discusses emergent requirements and planning, advocating for flexibility and quick responses to changes throughout the development cycle.
Agile practices and benefits
- 1. Agile Practices and Benefits For Northern Developer Network By Rich Stone and Peter Schuh 1
- 2. Agile • ag·ile (aj-uhl, -ahyl)adj. – 1. Characterized by quickness, lightness, and ease of movement; nimble. – 2. Mentally quick or alert: an agile mind. 2
- 3. 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 3
- 4. Agile Software Development • An iterative and incremental (evolutionary) approach to software development • which is performed in a highly collaborative manner • by self-organizing teams within an effective governance framework • with "just enough" ceremony • that produces high quality solutions • in a cost effective and timely manner • which meets the changing needs of its stakeholders. 4
- 5. Agile Methodology? 5 XP, SCRUM, FDD, DSDM, Crystal Clear – are all agile “process frameworks” – that recommend a group of related practices. All come from a consulting mind-set, and all have fairly prescriptive approaches – rather than value selected approaches – so they look like a consultant with a methodology. Not that they don’t add value, but is it the value you need? Only you can decide that.
- 6. Why Agile? More Value, Higher Quality, Less Risk, More Predictable, and yes, More Productive 6
- 7. Simply Agile • Recognize that value is a more important driver for software asset creation than schedule or cost. • Admit that we don’t/can’t know everything needed to get done before you start so details can emerge. • Decentralize decision making to empower the product team as much as possible, flattening team structures, replacing command and control with intense collaboration. • Exercise all your skill areas concurrently to increase information flow (for the software development system) by shortening all feedback loops. • Build, Borrow, Buy automation tooling to make things easier, faster, more reliable. 7
- 8. Agile Buzzword Bingo? First one to get four in a row wins a cheeseburger! 8
- 9. Agile Practices • We have a list of practices and a bingo card. • We are going to walk through a list of practices that are common and valuable. • If you are on a team that is doing the practice now, put a chip on your card. • If you are not sure if you are doing it, ask. • Questions are valuable – ask away. 9
- 10. Iteration Zero Spend a time box to put delivery infrastructure and product backlog in place (dev environment, test environment, test and build automation, user stories, mockups, etc) Think of it as build a road before we drive the car. Improves Predictability 10
- 11. Continuous Integration Integrating small bits of completed functionality into the team codebase many times a day, and using manual or automated process to ensure that the codebase is clean after each check-in. Continuous integration aims to improve the quality, and to reduce time to deliver, by replacing the practice of applying quality control to larger deliverables. Increases Quality, Reduces Risk 11
- 12. Walking Skeleton A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel. Improves Productivity, Reduces Risk 12
- 13. Test Driven Development Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards. Improves Quality, Reduces Risk 13
- 14. Automated Unit Testing A systemic suite of tests, coded by individual developers to test at the method level, based on restorable data, run after each successful build, to provide immediate feedback on any new code added to the system. Improves Productivity, Quality Reduces Risk 14
- 15. Simple Design This is an extension of YAGNI and satisficing (good enough) design concepts. Don't design for the ultimate scenario, or anticipate future needs, design only what is needed for the current story/requirement. Works best when used with other practices including continuous integration, automated build, refactoring, etc. Improves Productivity, Value Delivery 15
- 16. Acceptance Testing Write tests for each story (requirement) before development (for that story) is complete. Acceptance tests are defined by the customer as the acceptance criteria for the story. Performed as each story is completed, rather than at the end of a time box or immediately prior to release. Improves Quality, Reduces Risk 16
- 17. Co-located Team Seating the entire team in an open-space environment where conversation can be overheard, design and analysis sessions organically emerge, questions can be answered without anyone leaving their chair. Improves Productivity, Quality 17
- 18. Incremental Releases Release product to production as soon as you have something of value, rather than waiting for the entire scope of value to be complete. Moves the flow of information about value back to product team and product owner as early as possible. Improve Value Delivery, Reduce Risk 18
- 19. Product Backlog Sequenced list of features or stories that have value and effort estimates associated with them. Used in all planning exercises Increases Value Delivery 19
- 20. Emergent Requirements Any requirements method that acknowledges that we don't know everything “up front”. Starting with what we know, and expecting to learn more through design, development and feedback from customers. Yield requirements that are independent and can be sequenced. Improves Value, Productivity 20
- 21. Emergent Planning A form of planning, where one works top down, identifying large chunks of work and estimates in gross to form a baseline schedule, then takes a shorter window of time to “elaborate” the plan in more detail (focusing on the near- term deliverables), and continues over time. Improves Predictability, Reduces Risk 21
- 22. Time Boxing The time box (iteration, sprint) is the feedback or measurement cycle of your project. By choosing short time boxes, you increase the information flowing into your development process, so that genuine process improvement can result. Requires planning through sequencing and team commitment of deliverables. Improve Productivity, Predictability, Reduces Risk 22
- 23. Planning Game Making sequencing (a form of prioritization) of stories or features into a game. Designed to reduce emotions in planning. Goal: put the greatest possible value into production over the life of the game. Improves Value Delivery 23
- 24. Retrospective In agile development retrospectives play a very important role in iterative and incremental development. At the end of every time box a retrospective is held to look for ways to improve the process for the next time box. Improve Productivity, Reduce Risk 24
- 25. Burn-up/down Chart A bar chart, or line graph, showing the passage of time on the X axis, and the remaining work estimate on the vertical axis. Useful for determining if the team is burning work, according to a pre-determined schedule or commitment (like within a time box) Improves Predictability 25
- 26. Other Practices • The following practices were weeded out, solely on the basis of our need to restrict the size of the BINGO card. • Just sayin’ 26
- 27. Blitz Planning A single planning activity, attended by members across the project, that can produce a draft product backlog, release plan, and sequencing. Improves Predictability 27
- 28. Refactoring Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. When developers encounter unnecessary complexity in the area of code they are working on, they can simplify and clean the code, thereby paying down technical debt. Improves Quality, Reduces Risk 28
- 29. Automated Deployment Automated deployment of a build to a user- configured environment (for example: DEV, QA, STAGE, PROD) enables early testing of the system in production-like environments and drastically reduces the possibility for migration-based errors. Reduces Risk 29
- 30. Solution Sheets A simplified analysis document that articulates the essential requirements, business logic and/or design of a user story prior to its development. Improves Predictability 30
- 31. Kanban Board A visual, work queue-based approach to planning and tracking that: (1) puts the team's value stream at the center of the development process and (2) easily communicates prioritization and ongoing activity across the team and its stakeholders. Improves Productivity, Value Delivery 31
- 32. Effort Estimates Estimating effort instead of duration: - not when will I have this done, but how much of my time will I spend on this specific work. - allows work to be split across team members, and estimates to calculate mathematically. - allows the development of a cost estimate and a schedule Improves Predictability, Reduces Risk 32
- 33. On Site Customer A practice that engenders a highly-collaborative environment with speedy turn-around times, constant adjustment to user-driven feedback and low documentation. It costs the dedication of a "super user" and the co- location of that individual with the delivery team. Improves Productivity, Value Delivery 33
- 34. User Stories A lightweight, INVEST-based approach to project features/requirements, making them Independent, Negotiable, Valuable, Estimatable, Small, Testable. Improves Value, Productivity 34
- 35. Daily Stand A brief daily whole team meeting (15 min or less) focused on a simplified status of work in progress or recently completed. Helps to identify issues and obstacles, before any commitments are impacted. Improves Productivity, Reduces Risk 35
- 36. Thank You Thanks for playing along. We hope that you were able to glean some valuable nuggets of information. We hope that you will consider adopting/adapting some of the practices presented here for your team’s benefit. The spreadsheet attached to the invite also has links to external (to Northern) information resources regarding Agile Practices 36
Editor's Notes
- #3: Agile has been around since 2001. Most of us have read some of the literature, or at least laughed at the caricatures.
- #4: In 2001 a bunch of consultants got together at some resort and created this manifesto.Many of them had already formed the bases of methodologies that we have heard of that accomplished basically the same thing, but differently.I think these values are interesting, but they don’t tell me what or how, - they don’t even tell me what problem we are solving.
- #5: I stole this from Scott Ambler (who now works for IBM Rational) as their “evangelist”…I think it is a concise definition of the “What” of agile – but it is devoid of the why.
- #6: If you have ever been a part of a new agile adoption on a team, you will probably recollect that there is something of a backlashOne aspect of all agile processes is that they expose information that sometimes is not pleasant to see.Productivity issues, personal agendas, competence issues are all brought to light. The question is how do we respond to this information?
- #7: The major why’s behind agile practices are improvements in value, quality predictability and productivity – The how is because the increased information flow allows us to improve our process and focus on what is important.
- #8: Sometimes I feel like our whole project management and SDLC approach to software development completely forgets that we are creating capital assets, and that the value that is instantiated in the software capabilities that we deliver is made less important by our focus onProcess and Documentation.Managing against constraints (scope, schedule, cost).Fiscal Cycles and Budgets.IT delivery can get hung up wanting to use methodology to indemnify itself against blame for not delivering sufficient or needed business value. By the time developers get requirements, the understanding of how the required capabilities actually add value to the business practitioners is often reduced to almost nothing.
- #9: We are going to play a game – Just to see if you are paying attention.Cheeseburger (or other form of lunch) will go to the winner.
- #11: This really applies to a new product or new team. Here we may start a new project but against existing products. However, sometimes products transition from one team to another (reorg?) – and we need to get established again. Iteration Zero is a way of time boxing start-up cost.
- #12: Now that our standard Java and .Net architectures support this, we should take advantage.Usually the way this works, is that within a short time of each check-in, say 15 minutes – the CI server starts a build. Team is notified of build failure. This means that check-in of code that breaks the build can be backed out, or remediated quickly so that it doesn’t impede the rest of the team, or so that some time later, we can’t figure out where things got broke.Last team I was on the rule was fix the build before you go home or bring in donuts….-- many teams attach Unit Test execution to CI build execution, so that if the build passes, it also runs all the unit tests too.
- #13: Of course this applies to new systems, but can also be used anytime we are leveraging components that are new, or connecting through new integration points. This is a way to reduce risk of unfamiliarity.This can also be done in lieu of a POC, so that you get a working “something” quickly, that is not completely throw away.
- #14: TDD or Test First have been around since the late nineties – If you write the tests before you write the code, and your tests are sufficient to determine working, then when the tests pass you are done – right – well depending on how elegant you want your code to be. If you have the tests, you can refactor to make the code design better without worrying as much about breaking the logic.
- #15: If you are doing TDD, this is really essential – a framework like jUnit or nUnit is necessary to automate the testing necessary to make you really productive.
- #16: YAGNI – You ain’tgonna need it. - don’t design for cases that are not in scope for the current (release, timebox, story) depending on your delivery vector.Satisficing – (yes this is a word) meaning just good enough and no more. Combines satisfy with suffice - Term was coined by Herbert Simon. He pointed out that human beings lack the cognitive resources to maximize: Key here is that we should not be anticipating future state in our design, other than our capacity to extend towards anticipated requirements. This assumes a low cost and risk associated with extending towards future requirements (as supported by other practices like CI, refactoring, Automated unit testing, etc).
- #17: The key take away here is that in agile, we test during each time box, as soon as a story (testable software capability) is complete. Thus we are exercising the testing skill and the development skill concurrently. The information that comes back from testing regarding the quality and usability of our software capability allows us to improve both without extending time.
- #18: Having the developers, testers and analysts (and optimally the customer) sitting in the same space, where free collaboration can occur spontaneously is a huge benefit.
- #19: We all instinctively know that the feedback that we get from actual users is way more valuable than the feedback we get from product management or testing. Business practitioners are our “real” customer. So the faster we get software capabilities in their hands, the more information we have about the value we have delivered. If they touch nothing until we get all the capabilities built, then no information comes back, and we are stuck defending whatever we did, ‘cuz there are no options left.
- #20: If I have a list of all the software capabilities that I have been asked to deliver, in a basic delivery sequence, then as we incrementally deliver these to production, the information that flows back can influence the delivery sequence for future time boxes, and releases.Requests for enhancements that are more valuable than new software capabilities (because we have new information about the business process that we have enabled) can be sequenced ahead of less valuable capabilities.This prevents the delivery of seldom or never used capabilities, while simultaneously our customer clamoring for other things.
- #21: Requirements start with a business value to be deliveredOnce we propose a software capability that delivers that business value, we need to understand how that fits in or impacts various processes, and what its usage pattern will be.The faster we deliver design and working code, the more feedback validates and elaborates our requirements.
- #22: Depending on the length of our time boxes, and the size of our team we need to plan just enough work to keep the team moving forward.If my feedback loop is short, and we can re-sequence work, then why would I plan activities that I might never complete, in great detail. This does not mean that we do not care about risk associated with some software capabilities, our concern for risk should drive the sequencing – that is we compromise between maximizing value and retiring risk in the early increments of delivery.
- #23: If my time boxes are consistent, then the metrics (how much work got completed) helps me tune my commitment along the way. If my time boxes are short (2 weeks) I have lots of time to react even on short projects (3 months or less).
- #24: The purpose of the planning game is to have business (customer) and developers interact about what is important. Planning games contemplates not only the deliver of software capabilities, but also release commitments.Cost, Risk, and Value are drivers for planning moves.
- #25: Retrospectives are valuable, but sometimes hard to manage. It is usually necessary to select one or two things to focus on, that add the most value or solve the most urgent problems identified. - like every other practice – the more frequently you do it, the faster you get good at it.Process improvement for a working team is somewhat like fixing a motorcycle while your customer is driving down blind alleys at high speed. Have any of you ever worked for Rich Houle??? Uh Huh….
- #26: Useful for measuring velocity (rate of estimated work per unit of duration) (e.g. effort days per two week sprint)Also useful because you can see velocity trending up or down over time.-- burn-ups, have the benefit (over burn-down) of being able to expose where sequencing or planning decisions have impacted scope, or where estimate revisions have materially affected the plan.