Agile SPRINT WATERFALL MVP LEA TIME WIP TIMEE. in softwa developme

Transcription

1 SCR MAS UM TER Agile SPRINT WATERFALL MVP WIP UM SCR LEA D TIME LEA N UCT D O PR NER OW CYC L TIMEE Defining used the most tood) s r e d n u is (+ m rases h p & s m ter re in softwa nt developme

2 Common Terms The terms defined on this page and the following will be used in the expanded definitions found throughout this book. We encourage you to familiarize yourself with these terms and definitions and/or refer back to them as necessary. Agile Manifesto A document created in 2001 by a small group of software developers which highlights the values and principles which laid the foundation for Agile Software Development Build-Measure-Learn A product development feedback loop used to turn ideas into products. Build-Measure-Learn allows for learning from the customer(s) and helps inform a decision to pivot (change course) or persevere (stay on course). MVP (Minimum Viable Product) The term MVP was historically coined and defined. However, the definition offered by Eric Ries in his book The Lean Startup is, perhaps, preferred. MVP is the version of the product that enables a full turn of the BuildMeasure-Learn loop with a minimum amount of effort and the least amount of development time. Kanban An adaptation of the Toyota Production System designed for use in knowledge work. It focuses on visualizing a process and how work flows through it. It helps limit the amount of work in process, focusing on continuously delivering value to the customers and reducing the amount of time it takes to do so. David Anderson authored a book defining this methodology. Scrum Guide A 13-page document which lays out the principles behind Scrum and the roles, artifacts and events used by the framework. This document is free and can be downloaded online.

3 Sprint Planning Scrum defines a planning session at the beginning of a Sprint. In this session, the highest priority work is selected for completion and a plan to complete the work is devised. Daily Scrum A 15 minute, time-constrained event described in Scrum as a way to measure progress toward completing the Sprint Goal. This goal is usually represented by work selected from the Product Backlog. Releasable Product Increment A version of the product that solves the customers problem, is fully tested, and meets the standard of quality. The decision to release is optional. Sprint Review An event described by Scrum in which stakeholders gather, review the releasable product increment produced at the end of a Sprint & give feedback. Sprint Retrospective An event described by Scrum where the entire Scrum team gathers to evaluate the successes and challenges of the previous Sprint. Topics can include: how the team is working together, how the technology is serving their needs, how the process is going, etc.. Team commitment to improve future Sprints is the goal. The Retrospective is the Kaizen (continuous improvement) event in Scrum. Sprint Goal A high-level business goal which can be extracted from work the Scrum team has selected for completion in a Sprint. Understanding business goals helps the Scrum team solve the business problem and deliver the most value.

4 Waterfall If you have a defined process with phase gates (such as an approval phase) you likely have a waterfall process. Waterfall operates with a defined process flow (like a real waterfall). Commonly, a large project starts with a requirements gathering phase in which all of the customers requirements are determined and documented. A solution phase follows in which technical architects and team leads may gather to provide detailed designs. Those designs are then turned into a functioning solution by the technical team in a build phase. Of course, a quality assurance phase follows the build phase and, perhaps, a final sign-off at the end. It could take years for a large project to complete which puts a lot of pressure to create visibility into the progress of the project. Some of the common problems with regard to waterfall in software development are designs that can't be implemented as described, quality problems that are not caught until late in the project, or requirements that are unclear or misunderstood. In all cases these common problems can cause cost overruns, 'scope creep' and deadlines that are missed. This method of executing a large project comes from manufacturing and construction where it is very expensive to make physical changes to something once it has been built. Software is much more fluid and can be changed more easily. As such, different processes are best applied. Anyone working in software development at any stage of the development life-cycle, including managers.

5 Agile According to Merriam-Webster: able to move quickly and easily. This is, perhaps, the best definition. So often in the software development industry people forget that Agile is not the thing being agile is. The Agile Manifesto and its associated 12 principles, all roll up to the idea of delivering customers maximum value by staying responsive to their needs and spending less time doing things that are not as important. A group of software developers aimed to get away from bloated, plan-driven software development life-cycles and move toward customer focused methods which maximize the value of the work delivered. This Agile Manifesto made it okay to write great software to deliver the best outcomes for customers. The term Agile software development has its roots in this document. The audience that benefits from this concept is broad. Software development is on the leading edge of implementing frameworks and tools that allow for agility. However, companies like Toyota have been doing it for years. As agile ideas become even more mainstream, companies will have to be highly responsive to customer needs and changing preferences or they won t be able to compete.

6 Lean In software development, Lean is related to ideas from Lean manufacturing. The closest thing to a formal structure resembling lean in software development is what David Anderson formalized in Kanban. Toyota did a lot of great work in creating demand-pull systems and just-in-time processes to reduce waste and deliver the right thing at the right time. Kanban cards were used to signal upstream processes to deliver more parts to the downstream consumers. David Anderson borrowed many of these ideas, including others used in Lean manufacturing and applied them to software development in his book on the subject. Kanban is an agile method used in software development, IT operations, and is really great for any type of work that has a defined process which might include other areas of the business not related to technology such as human resources, marketing, finance, etc. It s a great tool for managing hand-offs and reducing the time it takes to deliver value to your customers.

7 Scrum A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. (Per the Scrum Guide) Jeff Sutherland and Ken Schwaber conceived the Scrum process in the early 90 s. They codified Scrum in 1995 in order to present it at the Oopsla conference in Austin, Texas (US) and published the paper SCRUM Software Development Process.Ken and Jeff inherited the name Scrum from the 1986 groundbreaking paper The New New Product Development Game by Takeuchi and Nonaka, two acknowledged management thinkers. With the term Scrum Nonaka and Takeuchi referred to the game of rugby to stress the importance of teams and some analogies between a team sport like rugby and being successful in the game of new product development. The research described in their paper showed that outstanding performance in the development of new, complex products is achieved when teams, as small and self-organizing units of people, are fed with objectives, not with tasks. The best teams are those that are given direction within which they have room to devise their own tactics on how to best head towards their joint objective. Teams require autonomy to achieve excellence. The Scrum framework for software development implements the principles described in this paper for developing and sustaining complex software products. While its original target audience is those writing software in teams, many types of complex work (unrelated to building software) can benefit from using the Scrum framework.

8 Sprint The heart of Scrum is a Sprint one month or less during which a Done, usable, and potentially releasable product increment is created. (Per the Scrum Guide) Sprints best have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints contain and consist of: 1. Sprint Planning 2. Daily Scrums 3. Development Work 4. Sprint Reviews 5. Sprint Retrospectives During the Sprint: 1. No changes are made that would endanger the Sprint Goal. 2. Quality goals do not decrease. 3. Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. Sprints, like projects, are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Additionally, Sprints reduce the risk of wasted build time and financial loss. This concept s history dates back to the original Scrum Guide. Everyone on a Scrum team and anyone who needs to understand why a Scrum Team operates in Sprints.

9 Product Owner The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. (Per the Scrum Guide) This concept s history dates back to the original Scrum Guide. Anyone implementing the Scrum framework. This idea is also often used in Kanban implementations. The goal is to designate a single person to set priority for a team to optimize the value it delivers and have a feedback mechanism to ensure that value is truly being maximized.

10 Scrum Master The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. This concept has been around since the original Scrum Guide. Management, Development teams, Scrum Masters anyone who needs to understand what a Scrum Master is and their purpose on the team.

11 WIP Work in Process. Work that has started but not yet finished. Any work to which resources have been dedicated is considered in progress even if you stop working on it and return it to your backlog of unfinished items. In manufacturing, once raw materials have been converted, it is in progress until a finished product which can be sold is produced. In knowledge work, the same principle applies. This term comes from manufacturing and supply chain management. Any material that is committed and has been transformed can no longer be sent back to the original supplier. In manufacturing or a supply chain, having a large amount of work in progress is undesirable because of the costs involved. When money is tied up in unfinished product that cannot be sold or returned to the suppliers, it cannot be used for other things like payroll, investment opportunities, etc. In software development, we suffer from the same problem. Work in process has no value to our customers until finished. The goal is to reduce WIP to focus on finishing work as quickly as possible. Software development teams, management, and product owners.

12 Lead Time The time it takes for something to go from initiation to completion in a process. This term is commonly used in manufacturing to understand the time it takes to convert raw materials into finished goods. For total end-to-end lead time, one should consider lead time to be how long it takes to go from concept-to-cash. This is not the same as cycle time. Product owners, development teams, management anyone looking to improve the speed at which your customers get value. Cycle Time The average time between successive outputs and is the inverse of throughput rate. If 3 teams build software and, on average, each team delivers one feature per week, lead time is 1 week (the time it takes one feature to go from initiation to done). Cycle time is 1/3 week because your throughput is 3 features per week and its inverse is 1/3. This is not the same as lead time. This term is also commonly used in manufacturing to understand output. Scrum Masters & management.

13 We can help! Got a question on a buzzword we didn t touch on? Do you need help with Agile or Scrum? LAURA AKERLUND laura.akerlund@centare.com