Agile overview
- 1. Agile Overview Benny Zangiri Jan 2018
- 2. How it all began History and Background
- 3. The Supermarket In the 1940s, Toyota started studying American supermarkets In a supermarket, customers generally retrieve what they need at the required time—no more, no less. Furthermore, the supermarket stocks only what it expects to sell in a given time, and customers take only what they need, because future supply is assured They noticed that store clerks restocked a grocery item by their store’s inventory, not their vendor’s supply. Only when an item was near sellout did the clerks order more This observation led Toyota to develop the methodology system that aligns inventory levels with actual consumption
- 4. Toyota Production System (TPS) The main objectives are to design out overburden (Muri) and inconsistency (Mura), and to eliminate waste (Muda) The goal is designing a process capable of delivering the required results smoothly It is crucial to ensure that the process is as flexible as necessary without stress or overburden since this generates waste
- 5. Toyota Production System (TPS) – cont. TPS is grounded on two main conceptual pillars: Just-in-time – meaning "Making only what is needed, only when it is needed, and only in the amount that is needed“ Jidoka (Autonomation) – meaning "Automation with a human touch"
- 6. The Toyota Way principals Continuous improvement Form a long-term vision, meeting challenges with courage and creativity Improve our business operations continuously, always driving for innovation and evolution Go to the source to find the facts to make correct decisions Respect for people Respect others, make every effort to understand each other, take responsibility and do our best to build mutual trust Stimulate personal and professional growth, maximize individual and team performance The right process will produce the right results
- 7. Lean Evolved from TPS at the 1950s Lean comes from Lean Manufacturing, as a way to optimize the production line to minimize waste and maximize value to the customer Everything and every step are examined
- 8. Kanban Kanban (“visual signal” or “card” in Japanese) system that aligns inventory levels with actual consumption A signal tells a supplier to produce and deliver a new shipment when material is consumed. Achieved by better communication through visual management
- 10. Methodologies & Methods Agile Lean Kanban Scrum Crystal Methods Scrumban DSDM FDD
- 11. Methodologies & Methods – cont. Methodologies: Lean, Agile Methods: Kanban, Scrum Lean and Agile practices complement each other and have a lot in common Continuous Improvement and Respect for People are rooted in both Respect for people means, respect the customer by value delivery and respect the employee & Team by providing autonomy, mastery and purpose While Lean and Agile considered Methodologies/Philosophies, Kanban & Scrum are implementations (methods) of Lean and Agile
- 12. Lean Software Development Lean development can be summarized by seven principles: Eliminate waste Amplify learning & knowledge Decide as late as possible – planning activities should be concentrated on the different options Deliver as fast as possible – to get customer feedback Empower the team – "find good people and let them do their own job" Build Quality in – quality is everyone’s job! Optimize the whole – organize teams to be complete, multi- disciplined, co-located product teams, which enables them to have everything they need to deliver E2E, without reference to other teams (Spotify model)
- 13. Lean Software Development – cont. What is software development waste? Building wrong/unnecessary feature Mismanaging the backlog Defects and lower quality Unnecessarily complex solutions Waiting/multitasking Knowledge loss Ineffective communication Unclear or constantly changing requirements (Rework, quality, lack of focus) Bureaucracy
- 14. Agile & Lean Both agile and lean are aimed at achieving business goals and delighting clients with a competitive product of the best quality Lean is about Smart development, improving by eliminate waste and making development process sustainable Agile is about executing faster, adopting to changes and making the development process flexible From here we’ll talk about Agile…
- 15. Agile & Lean – cont. Achieving business goals Best Quality Eliminate waste Sustainable process LeanAgile Execute fast Adopting to changes Flexible process
- 16. Agile Concepts Agile is not a religion!
- 17. Waterfall Poorly adoptive to changing requirements Discover flaws at late stage Very hard to estimate resources and time Value not achieved until the end
- 18. What is Agile Agile is a time-focused, iterative philosophy that allows to build a product step-by-step (incrementally), delivering it by smaller pieces. One of its main benefits is the ability to adapt and change at any step (depending on feedback, market conditions, corporate obstacles, etc.) and to supply only relevant products to the market.
- 19. Benefits of Agile Allow changes easily Increase customer satisfaction Increase visibility Lower development risk, increase quality Regular process improvement
- 20. Agile Concepts (based on the 12 principles) Regular delivery of software Progress should be measured by delivery of valuable software to customers Strive for continuous delivery, in short cycles as possible The Team Open and free communication through daily stand-up and other channels. Face-to- face is the best Maintain high availability between peers People perform best when they are doing something they are passionate about Trust is a key factor. Built over time and easy to lose Continuous improvement via retrospectives Design excellence Know the balance between “Building the right thing” to “Building the thing right” Continuous attention to technical excellency Build what you know you need now and not what you think you may need someday Keep it simple Welcome changes, even late in development
- 21. Common misconceptions about Agile No more planning No more design No more QA No documentation Requirements changes all the time Allow you to go faster
- 22. Agile Methodologies Kanban & Scrum
- 23. 60 seconds on science… A picture is worth a thousand words for scientific reasons: The brain processes visual information 60,000 times faster than text 40 percent of all nerve fibers connected to the brain are linked to the retina Visual information comprises 90 percent of the data that comes to our brain, suggesting that our neurological pathways might even prefer pictorial displays over text
- 24. Kanban Kanban approach aims to manage work by balancing the demands with available capacity Work is pulled as capacity permits, rather than work being pushed into the process when requested
- 25. Scrum Short term detailed planning with constant feedback Simple inspect and adopt cycle Clear tracking and transparency Progress in sprints Sprint Backlog Sprint 2–4 Weeks 24 Hours Deliverables
- 26. General Practices Both Scrum and Kanban share the following general practices: Visualize the work flow Work items are visualized to give participants a view of progress and process, from start to finish usually via board. This increase communication and collaboration Limit Work in Process By limiting content, you can avoid problems caused by task switching and reduce the need to constantly reprioritize items Optimize Flow & Continuous Improvement Teams collect metrics, measure their effectiveness by tracking flow, quality, throughput and more. Continuous improvement is a culture!
- 27. Scrum & Kanban - Key differences Scrum limit WIP by unit of time (sprint iteration). Kanban by workflow state (e.g. max 5 in ‘In Progress’) Scrum board is reset between iterations. Not the case in Kanban In Scrum, changes in product backlog take effect next sprint. In Kanban, changes in product backlog take effect as soon as capacity become available In Scrum, estimations and commitments are mandatory (per sprint iteration). Optional in Kanban
- 28. Focus on Scrum
- 30. Product Backlog Product Backlog is dynamic and lists all features, enhancements and fixes required to be made to the product in the next releases List should be prioritized by business value Clear requirements and Definition of Done (DoD) must be included Definition of Done is the acceptance criteria defined by the Product for ‘Product Entity’ completion
- 31. Product Entities Product content is breaking to pieces, using the following entities: Item Defined by the Product Manager Describe a major feature, usually cross functional Epic Defined by the Product Manager Describe specific functionality. Usually mean ‘big User Story’ Usually will take more than one Sprint to complete User Story Defined by the Product Manager/Owner or the Scrum Team Small, testable, deliverable unit, that fits into one Sprint Task Defined by the Scrum Team only
- 32. Roles & Responsibilities Product Owner Scrum Team Scrum Master
- 33. Product Owner Follow the Product Manager vision Represent the voice of the customers Responsible for managing the product backlog Order and prioritize of items Ensuring that the Backlog is visible and clear to all, and shows what the Scrum Team will work on next Ensuring the Team understands the items to the level needed
- 34. Scrum Team Self organized, cross-functional team Assuming E2E responsibility for product development and delivery With great power comes great responsibility
- 35. Scrum Master Make sure the scrum team is progressing as planned by removing impediments Monitor the work, for example: Track sprint burndown Track plan vs actual Keep the team focused on the tasks and completing the Sprint goals Responsible for the process and ceremonies Plan team capacity Supporting the Product Owner activities
- 36. Ceremonies
- 37. Sprint & Ceremonies The Sprint is the heart of Scrum Sprint is a short duration iteration, consist of the following ceremonies: Pre-planning, Planning, Daily, Review/Demo and Retrospective During the sprint: No changes should be made that would risk the sprint goal Quality do not decrease
- 39. Pre Planning – cont. When: 3-4 working days before the beginning of the Sprint Participating: Product Manager, Team Product Manager presenting the USs to the team, reviewing the requirements All USs must be ready before this meeting, containing clear requirements and DoD
- 41. Planning – cont. When: First day of the sprint Participating: Team, Product Manager (optional) Plan is created by the collaborative work of the entire team The planning answers the following: What can be delivered in the upcoming Sprint How this can be achieved The input to this meeting is the Product Backlog, Team capacity for the sprint and past performance of the Team
- 42. Planning – cont. The number of items selected from the Product Backlog for the Sprint is up to the Team and only the Team can assess what it can accomplish over the upcoming sprint DoD must be understood by all members All User Stories should be break into Tasks, considering all work aspects Tasks are given estimations by one of the following Story Points Time Estimation At the end of the planning, the Team commit to the sprint content
- 44. Daily Scrum – cont. Who: Team, Product Owner (optional) No more than 15 min The meeting optimizes team collaboration and performance by inspecting the work since the last Daily and forecasting upcoming Sprint work Every day, the Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal by the end of the Sprint
- 45. Daily Scrum – cont. Every team member answer 3 questions: What I did yesterday? What I will do today? Any restrictions holding/delaying my work? Scrum Master to facilitate resolution of impediments outside the daily meeting Daily Scrums improve communications, eliminate other meetings, identify impediments for removal, highlight and promote quick decision-making, and improve the Team’s level of knowledge. This is a key inspect and adapt meeting
- 47. Review – cont. When: last day of sprint Who: Team, Product Manager, key stakeholders The team present and demonstrate the work accomplished in the Sprint Work considered completed according to DoD Can replace Hand Over meeting to Support in some cases Product Manager must not be “surprised” at this point…
- 49. Retrospective – cont. When: after the Review and prior to the next Planning Who: Team Most important tool for continuous improvement The team inspect the last sprint regarding the process, relationships, tools and more Every member must share: What was good (to preserve) What went wrong (to improve) An improvement plan should be created and placed for next Sprint
- 50. Retrospective – cont. This encourages the Team to improve, within the Scrum process framework and practices to make it more effective and enjoyable for the next Sprint During each Retrospective, the Team plans ways to increase product quality by improving work processes Scrum Master responsibility to track the improvements
- 51. Sprint Metrics
- 52. Burndown Chart Burndown chart is a graphical representation of work left to do versus time The backlog is on the vertical axis, with time along the horizontal. It is useful for tracking and predicting when all of the work will be completed
- 53. Velocity Chart Velocity Chart shows the amount of value delivered in each sprint, enabling to predict the amount of work the team can get done in future sprints It is useful during sprint planning meetings, to help decide how much work the team can feasibly commit
- 55. User Story User Story is small & testable unit, to fit into single sprint US should be derived from related Epic which is part of an Item US should be ready before pre-planning, holding: Clear Requirements (if needed, link to Requirements/MRD/SRS doc) DoD Every US should hold the following tasks Design, Unit Test, writing TP (QA), Code Review, Monitoring, Create handover doc Adding US after Planning should be avoided. If must: Via Product Manager/Owner Requires a quick planning forum Removing a US with ‘equivalent’ EE + buffer on low maturity
- 56. Story Points Usually sizing by Fibonacci sequence: 1,2,3,5,8,13,21 Benefits: Gives us an overview of the scope of work Uses multiple perspectives to determine the size of work Clears out that we can’t be exact Sizing considering: The amount of work to do The complexity of the work Risk or uncertainty in doing the work Time / Duration
- 57. Scrum Board Team add categories that fit their work flow Board must be updated all time and reviewed by the team in the Daily meetings
- 58. Defects Bug found at early stage is much more cheaper in money, effort and time, to fix than the same bug found later in the process Bugs related to a feature that was detected during the sprint must be fixed immediately as part of the feature. Feature can not be marked as completed otherwise Bugs detected after sprint completed should be managed in Bugs backlog
- 59. Capacity Planning - Example Number of working days in sprint, reducing: 5% un-planned absence 1 day for ceremonies (for 2 weeks Sprint) X% code review (to others) Y% support (when support is small. Otherwise, add “Support Bucket” US) ~15% Scrum Master
- 60. From Dev to Production Version release should be planned for the first day of next sprint Features that require stabilization period will be released in the next planned release Release Notes should be published upon every release, indicating all features and known bugs. Main customers for that are Support and Success Product Manager is responsible to publish external Release Notes Need to establish short & fast Patch release process for unexpected issues
- 61. Thanks