When you re Agile you get Lean

Size: px
Start display at page:

Download "When you re Agile you get Lean"

Transcription

1 When you re Agile you get Lean

2 Introduction When you re Agile you get Lean Lean manufacturing (or simply Lean ) refers to the manufacturing philosophy laid out in the Toyota Production System 1. By applying this philosophy systematically to the manufacture of cars, Toyota became the global leader with a brand (except for a recent hiccup or two) nearly synonymous with quality. Lean integrates each step of the supply chain into a holistic value stream. Waste reduction, a core tenet of the Lean philosophy, is the act of stripping away (production) waste that occurs in the value stream while preserving or augmenting the value of the final product as perceived by the endcustomer. In this white paper, we will explore how the concept of Lean waste reduction has migrated from its origin in manufacturing to the software development industry through the use of Agile. First we will explore how different kinds of manufacturing waste have analogs in software development. Then, after we introduce guiding principles that the Lean and Agile philosophies share, we will discuss Agile practices that embody these principles in terms that demonstrate how they reduce software development waste. The seven Lean wastes The seven kinds of waste as first outlined by Taiicho Ohno 2, provide a framework to identify and remove waste from manufacturing. Although software development and manufacturing differ in important ways, once you start looking for the counterparts of manufacturing waste in software development it is surprising sometimes how easy they are to find. 1. Inventory. Inventory includes all parts and materials that have been purchased and are waiting to be used. It also includes work-in-process (WIP). WIP is everything that is being worked on that is not yet ready for shipment or sale. Inventory and WIP lead to waste because by definition they tie up resources that are not yet able to generate a return. In addition, the greater the inventory, the greater the risk of obsolescence, loss and write off. Inventory in software development. In knowledge work such as software development, we can think of inventory as being maintained in documentation and in non-deployed software. Software work-in-process (WIP) is all activity (and therefore expense) subsequent to business case approval but preceding deployment to production. This includes requirements documents, project plans, functional and design specifications, source code, test plans, and tests plus the time to create these artifacts. If a project is a year or more in duration, WIP continues to build up over the entire period prior to production use. WIP is also tantamount to the accumulation 1

3 of write-off risk for software investments because if the project ends prematurely or never is delivered, no business value is generated and the WIP investment is lost. Waterfall software project WIP 2. Motion. Motion is the movement of people or equipment that takes place in excess of what is essential to contribute value. To paraphrase the words of Shigeo Shingo, a co-developer of the Toyota production System (TPS), it's only the last turn of a bolt that tightens it - the rest is just movement. 3 Motion in software development. Motion in team members is manifested through activities like travel time, walking to meetings, task-switching between projects and work interruptions. A 30 second work interruption can result in a five-minute think time reset for a developer. 3. Waiting. Waiting is the delay between steps in production. If an order comes in the mail and sits in a mailbox, that is the waste of waiting. If an item is assembled, the delay before it is packaged is the waste of waiting. Waiting in software development. Examples include waiting for milestone and change request approvals and sign-offs, waiting for clarifications and elaborations from sponsors and analysts, waiting for builds and testing to complete, waiting for your turn in meetings and conference calls, waiting for deployment schedules and architectural and code reviews. Any elapsed time in excess of what is needed to execute the added value step is a form of waiting. Looked at in that manner, even the most efficient operations still have a great deal of waiting in principle, leaving plenty of opportunity for future improvements. 4. Over-production. Over-production is production ahead of demand. For example, saleable units waiting in warehouses for buyers are over-production waste. As is the case with WIP, overproduction increases the risk of obsolescence. 2

4 Over-production in software development. Since the model for software use is that one unit (i.e., one release) is shared by many users (even more so in SAAS environments) and the physical material cost of a software unit is minimal, over-production is not expressed as producing units in excess of demand. Rather, over-production in software development occurs when we build features that are either 1: never or rarely used or that are 2: deployed prematurely. 5. Over-processing. Over processing is processing done in excess of what is needed. Buffing a surface a minute longer than is needed for the next step in processing is a minute of processing waste. Over-processing not only consumes time and resources without adding value; it may damage or make the end-product less valuable and shorten the useful life of processing tools. The waste of waiting often leads to the waste of over-processing. Occupying your time with busy work may reduce the emotional distress of waiting by fostering the illusion that at least something productive is getting done, but if it s not adding any value it s making things worse. Over-processing in software development. Over or redundant processing in software includes low and no value meetings and conference calls, duplicative approvals, redundant reporting, redundant specifications, over-engineering code and gold-plating specifications, design and code reviews that don t result in technical improvements. Overly detailed work breakdown structures and overly precise estimations are also forms of processing waste. 6. Transport. Transportation waste is the movement of materials and goods that is not actually required to perform the processing. It also includes damage to materials and goods that are the result of transportation. Transport in software development. Since software comprises information electronically stored and accessed, the physically transport of materials or finished goods is of little concern. However, there is the analogous waste of translating and handing-off customer requirements through subsequent phases such as functional specifications, UML diagrams, source code and tests. In addition, there is also information loss (or the introduction of noise) that damages the information just as finished goods and materials are sometimes damaged through transportation. Requirements Lost in translation 3

5 Defects. The waste of defects refers to the cost of searching for defects, finding them and the cost of fixing the defects. Defects in software development. Testing and inspections that do not result in finding bugs are considered defect waste in software development. Other examples are features that were implemented but were never requested, inaccurate specifications, production bugs, and substandard user experience. Principles and practices: methodology or philosophy? Methodologies are typically structured as a set of practices defined in terms of rules and procedures. For someone working within the methodology, knowledge of what principles lay behind the practices is less important than following the rules and learning the procedures. One can think of the encapsulation of principles within a procedure as a benefit of a methodology: the practitioner can apply what the experts have previously determined are the best practices without having to think too much. With Agile and Lean it s a different story. Practitioners are expected to understand the principles in addition to learning the practices. When practitioners agree to adopt Agile practices, they also accept the responsibility to achieve the goals of the principles embodied within the practices. This is what is meant by Agile value statements such as individuals over processes, customer collaboration over contract negotiation, and responding to change over following a plan. 4 Process is necessary but not sufficient to assure high-value outcomes. Much like a squad in battlefield conditions, the agile team faces a rapidly changing environment and needs to make prudent decisions on how best to apply guiding principles rather than look up the right answer in a field manual. If outcomes are not ideal, it is the practitioner s responsibility to make the necessary adjustments (most often in their own behavior) to achieve the desired outcomes. When practitioners adopt Agile practices, they are expected to think more not less. We can summarize this distinction by saying that Lean and Agile are principle-driven rather than ruledriven. For this reason, many Agile practitioners are more comfortable referring to their community of practice as a philosophy rather than a methodology. We will now introduce three principles that Agile and Lean hold in common. Although there are plenty of other principles that we could discuss, these principles in particular make evident just how much Agile and Lean share a common philosophy. After each principle we will provide examples of Agile practices that embody that principle and demonstrate how they reduce software development waste. 4

6 1. Deploy as soon as possible In essence this means that production should be organized so that tangible value gets in the hands of the end-customer as soon as possible. The sooner you release the end product, the sooner you receive a tangible return. The power of this principle increases as uncertainty in the operating environment increases. Under uncertain conditions, learning as you go is a must. The shorter the release cycle, the quicker you learn from market feedback. The more frequently you release, the more opportunities you have to learn to do better. After all, it s better to fail sooner than later and when you do fail, its best to learn from your failure. Corollary: Never defer a fix Barry Boehm demonstrated many years ago that the later in the process you find a defect, the more costly it is to fix 5. The tonic to this problem, taking steps to eliminate the cause defects and fixing them as soon as possible, is core to both Agile and Lean philosophies. As we will see, although there is some work you may wish to defer and even avoid doing entirely, it would never be at the expense of deferring fixes that you know need to be made, nor would you knowingly take a step that might increase the future incidence of defects. Defects cost more to fix the longer they fester because more has been invested that now needs to be reworked or ripped out. In addition, as time goes by, more stakeholders will be affected. Furthermore, defects that accrue over time snowball in ways that multiplies the damage they cause. Agile practices The cost of deferring a defect 5 Early and frequent delivery Early and frequent delivery is defined as shortening the time to deliver the first release and reducing the time between releases. You obtain the earliest possible delivery by limiting the first release to the minimal marketable set of features (MMF). 5

7 Early and frequent delivery has the highest impact on reducing WIP, the most significant form of inventory waste. By limiting your first release to the MMF, you also reduce the waste of over-production. Since there will be plenty of opportunities to release new features in subsequent releases, the pressure to deploy features of dubious value in one big bang release is diminished. Since shortening the release cycle automatically reduces the size of WIP, the chances that you will incur waiting and over-processing waste is correspondingly diminished. Releasing more frequently means more opportunities to obtain enduser feedback, which reduces defect waste. Defect Short release cycles reduce WIP waste is also reduced by shortening the times between defect origination, defect discovery and defect fix. Iterative development and the Definition of Done If early and frequent delivery is the best way to achieve value, then iterative development is the means by which we achieve it. Iterative development means completing all the phases of development for a slice of the total requirements within a very short time box. The emphasis here is on the word complete. Agile teams care about this so much that they create and enforce the definition of done (DOD). At a minimum, it is a list of everything that needs to be completed in order to deliver deployable code. That encompasses the whole range of development tasks from requirements to user acceptance testing. It also means that the new slice of work is fully integrated with all the work that preceded it, which at a minimum includes comprehensive regression and systems integration testing. As Agile teams mature, they extend the DOD to progressively shorten the last mile journey to production. Some Agile teams (especially those deploying to the Web or cloud environments) have extended their DOD to its logical conclusion by implementing the capability for push button release and deploy code to production after each iteration. In some cases, code may be pushed to production one or more times each day! 6

8 Short iterations reduce WIP By completing everything that needs to be done for a small slice of work, WIP is dramatically decreased. At a minimum, the only work that is not completed during the iteration is code migration through staging and into production. By focusing on doing the work we can get done within the iteration, we avoid waiting for inputs that are not immediately available to the production team. When we use Scrum as our project management framework, waiting is reduced further through the roles of two people: the ScrumMaster and Product Owner. The ScrumMaster is devoted to removing obstacles that cause delays to production. The Product Owner is devoted to providing answers about requirements in a timely manner. Also, the process of the daily Scrum (standup) meeting provides an atmosphere for all team members to update the entire team on their progress which makes blocking problems immediately evident. Since the scope of the iteration is fixed on a small set of requirements, the risk of over-production is constrained. Also, since the DOD enforces a high standard for completeness, including the completion of all testing within the iteration, the risk of defects is dramatically reduced. Since a lot of work needs to be completed in a very short period of time, the team can quickly move to triage mode to throw over board any work that is not critical to getting the job done. Consequently there is little tolerance for over-processing. Automated unit testing and high test coverage The use of third-party automated test frameworks or customized test harnesses enable teams to implement unit tests at the smallest increment of coding (e.g., a single method, or procedure or 7

9 validation). The ability to easily automate tests while code is being written makes it much more feasible to achieve the commitment to comprehensively test all source code within the iteration. Automating the tests reduces the delay of waiting for test results and largely eliminates the need to defer testing to some later point, reducing WIP. Wait time is further reduced by running the automated tests as part of frequent automated regression testing. Automating the tests also reduces the physical motion of the tester by reducing manual testing. Automation also reduces the motion of the developer by reducing the amount and complexity of future debugging that would otherwise be necessary when test coverage is not comprehensive. Automated tests naturally reduce the chance of defects and the more comprehensive and earlier the testing, the smaller the likelihood that bugs make their way into production. A high percentage of unit test coverage reduces over-processing by reducing the need and likelihood of redundant acceptance testing. Automated tests also reduce the errors that are generated from handing code back and forth between developers and testers. Test driven development In a nutshell, test driven development (TDD) is the practice of writing the unit test before writing the code. The test is then run and automatically fails since the code has not yet been written. The task of the developer is to write the code needed for the test to pass. This sequence is then repeated for the next unit test and in this way a software object or service is implemented one step at a time. Test driven development is almost always practiced in conjunction with unit test automation. We have described how short releases and iterative development reduce WIP at the macro level. TDD reduces WIP at the micro level. Used in conjunction with just-in-time requirements realization (discussed later), a task can be fully completed (designed, tested and coded) within sixty minutes of its definition. The task is small but it is implemented without incurring the waste of waiting and while keeping WIP small. Since the code is constrained by the tests that precede it, the developer is limited to writing only the code needed and no more, which reduces the wastes of over-processing and overproduction. And since no code advances without being tested, defects are reduced. Continuous integration and don t break the build Continuous integration (CI) is the practice of integrating each increment of code soon after it is written and successfully unit tested into the code repository 6. This is generally done in an automated fashion by using a CI server. The CI system not only compiles and builds the code, but executes all the unit, regression, integration and acceptance tests for the whole build or project. Just as the Definition of Done can be extended to be more complete, so can the CI system. In addition to unit and system integration tests, user acceptance tests, performance tests, and code analytics can be added to the CI system thereby extending the team s capability and scope for ensuring quality. Extending the scope of the CI system also reduces the amount of work that would otherwise be performed in subsequent 8

10 testing, staging and deployment phases. In addition, source code can be tagged to make it traceable to requirements and development activities. The typical minimum frequency for a member of a properly functioning Agile team to integrate their code is at least once a day. High performing Agile teams expect to integrate their code many times throughout the day, and often as frequently as every few minutes. This means that the CI process cycle time needs to be extremely short: otherwise noticeable wait waste will start to occur. The mature practice of CI includes an expectation that team members don t break the build. This commitment is often specified in the team s Definition of Done. Don t break the build means if an increment of code generates a fail condition as it is being integrated, then the build must be fixed immediately. This likely involves removing the source code that precipitated the failure. However, it could also include fixing or changing source code or tests elsewhere in the project, which likely was written by a different team member. Typically, this means another Agile practice collective code ownership (discussed later) is also employed. CI reduces WIP by automating the completion of testing and integration so a rigorous Definition of Done can be maintained as each task is performed. The automation reduces the motion of manual work and serves up the performance metrics in a form that is directly consumable by the team and key stakeholders. Waiting for processing to complete is similarly reduced through automation. Since problems are resolved as they are identified, they don t compound, which reduces what otherwise would result in additional processing. Defects are reduced by the facilitation of frequent and comprehensive testing and the commitment to identify and fix bugs quickly. This practice also makes it practical for technical quality to be measured in terms beyond bug count to include such items as code quality, test coverage and user acceptance. Iteration (Sprint) Review Iteration (or demo) Review takes place at the end of the iteration and is in effect a mini-user acceptance test. Business representatives see the new code in action and are able to evaluate whether or not the value behind the requirements is provided by the implementation. These tangible demonstrations help business representatives provide useful feedback for the next step in the project. Iteration Review adds an additional level of assurance that the code as implemented will have practical business value. Since this is done after every iteration, business approval of the work is obtained early and frequently, which reduces WIP. The team need not wait for business approval nor need the business to wait on the team to get a tangible idea of progress. Defects are reduced via the practical measure of user validation and acceptance. 9

11 2. Defer decisions to the last responsible moment When you re Agile you get Lean Avoid making a decision now if you might obtain information in the future that could improve your decision as long as the delay you incur does not create irreversible damage 7. At first blush this appears to be the procrastinator s dream come true; however there is a key difference. Applying this principle requires that a tradeoff judgment is possible, desirable and made without delay. The power of this principle increases as the magnitude of uncertainty in the operating environment increases. Corollary: Do just enough and no more Agile teams apply this practice to all the activities involved in software development, including document creation, planning, designing, coding and testing. This means that an individual does only what is essential to meet the current necessary step and no more. It also means to avoid duplicating efforts and generating redundant information. What is just enough is not always immediately self-evident, especially when multiple stakeholders are involved. Agile inspired shops welcome dialog to reconcile different perspectives and establish agreement about how work is completed and whether or not it should be completed. Agile practices Just-in-time requirements and a dynamic product backlog A just-in-time requirement is the practice of deferring the full elaboration of the requirement until just before you plan to implement it. Requirements are managed through a dynamic product backlog with the highest priority items at the top. These are the most detailed because they are next up for implementation. Lower priority items at the bottom are less detailed. Priorities can be changed, and requirements added or deleted at any time by the business representative (also known as the Product Owner in Scrum). Pulling requirements from the top of the backlog, completing their specification and estimating the effort needed to implement them are the first steps of each development iteration cycle. 10

12 Dynamic backlog management WIP is limited by completing the requirement specification for only the items the team pulls from the backlog which they intend to complete during the iteration (typically two weeks in length). Development can start sooner since there is no need to wait for the completion of a full product specification before development tasks begin. Over-processing and motion waste are reduced because you avoid documenting requirements that may never be needed or are subject to change before development begins. Similarly, the cost of changing priority and scope is dramatically reduced. In addition, since requirements are prioritized, chances are increased that if scope is reduced, the higher value features will make it into the release. Since scope can be changed at will, better decisions can be made (and unmade) about which features should be included, thereby reducing over-production. What does get implemented is less likely to be defective since mindshare is concentrated on a small segment of work and the work is started right after the team receives the latest and best information available about the requirements and their acceptance criteria. Multi-level planning Multi-level planning is doing the right level of planning and creating plans at the right times. The higher the level the more summarized the plan. Also, the longer the time frame covered, the less frequent the planning activity. At one extreme is the product or system vision that may be revisited on a quarterly basis. The roadmap might be reviewed every month or two and the release plan bi-weekly. At the other extreme, task defining and planning is conducted on a continuous basis, since tasks are 11

13 often not fully defined until right before they are implemented and may only be minutes in duration. Multi-level planning emphasizes planning over plans. This means that the detailed planning of work is integrated into the production process and the bias is toward discussion, collaboration and implementation rather than maintaining plan documentation. Multi-level Planning Since task level planning is limited to imminent work, plan inventories and WIP is kept to a minimum. Scheduling task level work breakdown structures (WBS) weeks in advance is both unnecessary and is prone to generating processing waste since scope is frequently adjusted through the use of the dynamic product backlog. Communicating task schedules between project management and the implementation team generates motion and transport waste that is reduced through multi-level planning. Planning at different levels means less waiting on plan approvals and updates between management and implementation teams. Business collaboration Business collaboration is the commitment for the development team and the business representative to work together on a continuous basis. This commitment extends the engagement beyond the traditional project approach where most interaction is concentrated at the beginning on user requirements and then at the end on user acceptance. In many organizations, this can mean that the business representative co-locates with the team. At a minimum it means that a business representative is highly available to answer questions, to provide feedback and direction, and 12

14 participate in iteration planning and iteration reviews. As was discussed previously, rather than plan and specify everything up front, these activities are done incrementally over the course of the project. Business collaboration reduces wait waste by reducing work delays caused by waiting for answers and approvals. It reduces WIP by enabling the incremental definition of specifications that in turn facilitates the incremental delivery of value. Establishing and maintaining ongoing and effective collaboration leads to better mutual understanding, thereby reducing the cause of many defects. Sustaining an ongoing dialog about the initiative that is frequently punctuated by joint planning and review of recently completed work means there is less need to save the current state of the project through interim documentation. This not only reduces motion and processing waste by reducing the need to generate, revise and review documents, but it also reduces transport waste by reducing translations and handoffs. 3. Unleash Team Power Many people say they are pro-team or team players without having a full understanding of how teams can add value beyond what a collection of individuals might be able to accomplish when working separately. Beyond maintaining the appearance of political correctness, it s not always clear what people mean when they make this claim. Do they really intend to make meaningful commitments to support team behavior and do they have the knowledge and ability to do so? Leveraging the power of teams has been a core component of Lean thinking from the start. Agile practices are designed to establish and support the rapid development of high-powered teams in a deliberate and disciplined fashion. Organizations that are serious about applying Agile and Lean principles must make deep commitments to develop and sustain teams. This includes establishing conditions for teams to form and thrive as well as shifting responsibility and accountability from supervisors to teams. Corollary: don t underutilize creative brain power This principle is often referred to as the 8 th lean waste and is fundamental to lean thinking 8. The idea is that if all we expect from people is to perform their tasks without considering how things could be improved, we are throwing the best part of people away, including the key to our future success. Integral to Lean manufacturing is the concept that the production workers are responsible for reducing Lean waste, not some distant manager or process engineer. The people closest to the problem are expected to use their brains to improve the operating environment. This is a far cry from the management attitude that employees are not paid to think. 13

15 It s ironic that Lean emerged from manufacturing, the industry that championed the idea that production is optimized by transforming people into assembly line automatons. What is doubly ironic is when the outmoded notions for managing are applied to knowledge work such as software development where people are paid to think! Yet this is precisely what happens when software developers are expected to submit without reservation to overly prescriptive methodologies and practices. Corollary: the team is the unit of production Software developers spend more time designing than they do building to specifications. (building is done by the compiler). Design work requires experimentation with ideas. The book Where Good Ideas Come From 9 demonstrates how through time, innovation is enabled through collaboration. Through collaboration, ideas born in the minds of individuals take root in the real world and are nurtured until they bear fruit in the form of tangible business value. In addition to providing a platform for the collaboration necessary to foster design-work, teams can remove obstacles by swarming problems in hours that individuals working alone could never resolve. Teams also are robust and self-healing in ways that are not possible for individuals. For these reasons, Agile organizations measure productivity at the team level; not at the individual level. Agile practices Small team size The general guideline for an agile team size is about seven plus or minus 2 or about the size of a large family. The team should be small enough to facilitate the development of strong interpersonal relationships. Small teams reduce wait times and process waste because practitioners that know each other well communicate efficiently and have fewer misunderstandings. Stronger relationships mean that people are more likely and able to help each other remove obstacles, further reducing wait time and processing (communication) waste. Better communication leads to more rapid task completion which reduces WIP. Reduced misunderstanding also reduces the cause of some defects. The transport waste of incomplete handoffs and translation errors are directly reduced through cohesive team relationships. 14

16 Persistent teams When you re Agile you get Lean Teams take time to form. Over time their productivity and efficiency gets better and better. All of the waste reduction advantages of small teams are strengthened as the team matures. The investment in team development is lost if the team does not persist. Retrospectives The retrospective is one of the team ceremonies in Scrum. The team spends time after each iteration reflecting on what is working and what is not working and then makes a commitment to adjust their behavior accordingly in some tangible way. It is a lightweight, self-directed process that teams use to improve incrementally. Typically the focus of retrospectives is to improve the team s well-being, become more effective and increase the quality of the outcome. Since retrospectives can improve all aspects of team performance, all of the waste reduction advantages of small teams are strengthened through their use. Cross-functional teams Cross-functional teams possess all the functional capabilities needed to get work completed in accordance with the Definition of Done. At a minimum this includes all the development skills that are needed to develop and test the technologies that are integrated to form the product or system. Additional functions that may be required on some teams are architecture, business analysis, usability, user interface design, technical writing, content production and production operations. Cross-functional teams reduce WIP, waiting, over-processing, translation and handoff waste by keeping dependencies on functions outside of the team to a minimum and broadening the positive impact of team collaboration. Defect waste is also reduced through better coordinated technology integration and more tightly coupled development/test cycles. Self-organizing teams Self-organization is the organic process by which individuals interact and form into a team. Organizations support this process by not unnecessarily interfering with this process (e.g., avoiding the micro-management of task planning and assignment) and by providing an environment that facilitates team development and sustainment. Self-organizing teams are encouraged to be as self-directed as feasible, especially in regard to how work is defined, organized and implemented. Self-organizing teams reduce the need for supervisor and project manager task management, which reduces additional processing, waiting, translation and WIP waste. In addition, since self-organized 15

17 teams have more control over how they do things, they are able to make deeper and more meaningful commitments on what they can complete and how they will improve over time. Collective code ownership Collective code ownership is the principle that the team, not the individual, is responsible for all of the work products that are produced. This has a huge impact on reducing wait waste by avoiding single person bottlenecks. It also has a big impact on defect reduction. Less time is wasted deciding who should be responsible (reducing motion and over-processing) for fixing defects and more of the team s collective time is allocated to eliminating defects as a key objective. A commitment to collective code ownership is what makes it possible for a team to commit to high standards for the Definition of Done and make commitments to not break the build possible. Single project assignment Single project assignment (AKA dedicated teams) simply means that most, if not all, of the team members are on one and only one project at a time. Meaningful team commitments are impossible without full-time commitment of the team s members, since a singular focus is required to meet the short timescale commitments of iterative development week after week. This means Agile cannot be practiced unless most team members are dedicated. However, it can make sense for some team members to be involved part-time when their contributions are required only occasionally (e.g. database administration). Single assignment by definition reduces the waste of task-switching (transportation). There also is no need to wait for team members to get back to work. WIP is reduced since the throughput of one project is increased if it obtains the full capacity of the team members. Co-location and facilitated team communication Face-to-face co-location is the ideal for small team communications since it is by far the best way to facilitate effective collaboration. Nevertheless distributed teams are a reality in today s business environment, which precludes this possibility. This barrier to collaboration can be remediated through the use of other means to facilitate high-bandwidth intra-team communication. This includes all the efforts needed to assure that distributed team members are able to effectively communicate and collaborate. This takes into account travel, video, social media, collaboration tools, co-locating when you can, and the like. 16

18 Without a solid investment in and on-going commitment to facilitated communication, you will not be able to develop or sustain an effective Agile team. As team communication improves and grows more continuous, wait times are reduced and overall understanding improves between team members. This reduces the incidence of misunderstandings, which means fewer defects. In addition, the need to translate (transportation) is reduced as well as the motion needed to work together. Pair-programming Pair programming is when two programmers work at one workstation together to produce unit tests and source code. As counter-intuitive as it may seem, pair programming is usually more efficient and results in higher quality outcomes than the alternative. Continuous code reviews One way pair programming reduces wait time is through the practice of continuous code review (one person reviews the code while the other person is writing it). As can be seen in the diagram above, continuous code reviews reduce wait and handoffs states by collapsing a two-step process into one and reduce extra processing by reducing re-work. When all team members over time pair with each other, relationships are strengthened and cross-fertilization of skills and knowledge result which decreases wait waste by eliminating single person dependencies and increases the teams collective ability to produce higher quality outcomes, which reduces defects. Summary The following table summarizes our discussion of how the Agile practices implement Lean concepts of 17

19 waste reduction. Although we have discussed the practices individually, they are designed to work together as part of an Agile system of thinking drawn from Scrum, Extreme Programming and Lean. 18

20 19

21 Conclusion When you re Agile you get Lean So when we add up all the different ways we can reduce waste through the use of Agile practices, how much does it amount to? The answer is a lot. Practices such as early and frequent delivery and iterative development can have an immediate and dramatic impact on reducing waste such as WIP, which can easily be measured in financial terms such as increased return on investment, lower development costs and reduced write-off risk. Shaving waste consistently over time has revolutionized manufacturing across the world; now it s revolutionizing software development. Lean started out as a competitive advantage for Toyota. Today if you expect to be a player in the manufacturing industry it is a competitive reality. We have every reason to believe that what has been a competitive advantage in software development will soon become a capability that is necessary to compete. 20

22 Endnotes 1 Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. China: Productivity Press, Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. China: Productivity Press, Shingo, Shigeo. A Study of the Toyota Production System. China: Productivity Press, Manifesto for Agile Software Development, Boehm, Barry. Software Engineering Economics. New Jersey: Prentice Hall, Martin Fowler, Continuous Integration, May 01, Poppendieck, Mary and Tom. Lean Software Development: An Agile Toolkit. Boston: Addison-Wesley Professional, Pete Abilla, The 8 th Type of Muda, January 23, Johnson, Steven. Where Good Ideas Come From. New York: Riverhead Trade,

The Business Value of Agile Transformation

The Business Value of Agile Transformation SolutionsIQ The Business Value of Agile Transformation By John Rudd Overview The potential benefits of full-scale Agile are enormous, although rarely fully realized. Many of the companies that adopt Agile

More information

Agile Projects 7. Agile Project Management 21

Agile Projects 7. Agile Project Management 21 Contents Contents 1 2 3 4 Agile Projects 7 Introduction 8 About the Book 9 The Problems 10 The Agile Manifesto 12 Agile Approach 14 The Benefits 16 Project Components 18 Summary 20 Agile Project Management

More information

Watson Internet of Things. Agile Development Why requirements matter

Watson Internet of Things. Agile Development Why requirements matter Watson Internet of Things Agile Development Why requirements matter Executive summary The clear benefits of agile development better collaboration, incremental delivery, early error detection and the elimination

More information

Chapter 4 Document Driven Approach for Agile Methodology

Chapter 4 Document Driven Approach for Agile Methodology Chapter 4 Document Driven Approach for Agile Methodology In this chapter, 4.1. Introduction 4.2. Documentation Selection Factors 4.3. Minimum Required Documents 4.4. Summary 4.1. Introduction In all, the

More information

Agile at Mid-Scale. Al Shalloway. Introducing FLow for Enterprise Transformations (FLEX)

Agile at Mid-Scale. Al Shalloway. Introducing FLow for Enterprise Transformations (FLEX) Agile at Mid-Scale Introducing FLow for Enterprise Transformations (FLEX) Al Shalloway CEO, Founder alshall@netobjectives.com @AlShalloway Co-founder of Lean-Systems Society Co-founder Lean-Kanban University

More information

Agile Development Doesn t Have to Mean Fragile Enterprise Processes

Agile Development Doesn t Have to Mean Fragile Enterprise Processes Fragile Enterprise Processes An MKS White Paper By: Colin Doyle ALM Strategic Product Manager MKS Inc. The Move to Agile Agile software development methodologies are garnering a lot of interest these days.

More information

Advanced Release Planning

Advanced Release Planning Agile Project Management Jim Highsmith Chapter 8 Advanced Release Planning Failure to keep Release Plans current! Management needs to know how a business problem will be solved, its cost, how long it will

More information

Portfolio Management In An Agile World

Portfolio Management In An Agile World Portfolio Management In An Agile World Rick Austin VP, Enterprise Engagements Principal Consultant 2017 @rickaustin, @leadingagile @GoAgileCamp #AgileCamp2017 2 RICK AUSTIN Information Technology Director

More information

Lecture 1. Topics covered. Rapid p development and delivery is now often the most important requirement for software systems.

Lecture 1. Topics covered. Rapid p development and delivery is now often the most important requirement for software systems. Chapter 3 Agile Software Development Lecture 1 Topics covered Agile g methods Plan-driven and agile development Extreme programming Agile project management Scaling agile methods Rapid software development

More information

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 Friday 30 th September 2016 - Morning Answer any THREE questions

More information

Agile Test Plan How to Construct an Agile Test Plan

Agile Test Plan How to Construct an Agile Test Plan Agile Test Plan How to Construct an Agile Test Plan XBOSoft White Paper How to Construct an Agile Test Plan www.xbosoft.com 2 Agile is changing not only the way we develop software but the way we work

More information

Agile & Lean / Kanban

Agile & Lean / Kanban Agile & Lean / Kanban 0 What is Lean? 1 Agile Development Methods (Dogma) extreme Programming (XP) Scrum Lean Software Development Behavior Driven Development (BDD) Feature Driven Development (FDD) Crystal

More information

Processes and Life- Cycles. Kristian Sandahl

Processes and Life- Cycles. Kristian Sandahl Processes and Life- Cycles Kristian Sandahl 2 Maintenance Requirements Validate Requirements, Verify Specification Acceptance Test (Release testing) System Design (Architecture, High-level Design) Verify

More information

Mike Vincent. mvasoftware.net

Mike Vincent. mvasoftware.net Scrum and ALM Coach Over 30 years as software developer and architect Marketing director, construction project manager and structural engineer previously Microsoft MVP - Visual Studio ALM Professional

More information

Lean Product Development at Scale. Allen Ringel Lean/Agile Transformation Leader Intel

Lean Product Development at Scale. Allen Ringel Lean/Agile Transformation Leader Intel Lean Product Development at Scale Allen Ringel Lean/Agile Transformation Leader Intel A Bit About Intel 2 (Embedded video) https://www.youtube.com/watch?v=jiu16i- D3GM 3 Manufacturing Validation Engineering

More information

Quantifying the Value of Investments in Micro Focus Quality Center Solutions

Quantifying the Value of Investments in Micro Focus Quality Center Solutions Dynamic Value Brief Application Delivery Management Quantifying the Value of Investments in Micro Focus Quality Center Solutions Manage software testing and IT quality management with consistent processes

More information

An Agile Projects Introduction Course #PMCurrent-1

An Agile Projects Introduction Course #PMCurrent-1 An Agile Projects Introduction Course #PMCurrent-1 Aaron MacDaniel, PMP, CSM, MBA Lead Instructor - BetterPM.com An Innate Images, LLC Company 1 Course Agenda About BetterPM.com A typical Waterfall Project

More information

Agile Development Processes. CSCE Lecture 3-08/31/2017

Agile Development Processes. CSCE Lecture 3-08/31/2017 Agile Development Processes CSCE 740 - Lecture 3-08/31/2017 Common Practice: Code & Fix Sit down, write out the code, and fix problems as they occur. No formal structure to development. What is wrong with

More information

DASA DEVOPS. Glossary

DASA DEVOPS. Glossary DASA DEVOPS Glossary Version 1.0.0 May 2016 Agile Agile is a time-boxed and iterative approach of software delivery. It aims to build software incrementally from the start of the project. Agile Benefits

More information

SOLUTION BRIEF CA AGILE REQUIREMENTS DESIGNER FOR CA AGILE CENTRAL. CA Agile Requirements Designer for CA Agile Central

SOLUTION BRIEF CA AGILE REQUIREMENTS DESIGNER FOR CA AGILE CENTRAL. CA Agile Requirements Designer for CA Agile Central SOLUTION BRIEF CA AGILE REQUIREMENTS DESIGNER FOR CA AGILE CENTRAL CA Agile Requirements Designer for CA Agile Central Automatically convert user stories into the smallest set of test cases needed to fully

More information

WHITE PAPER APPLICATION SERVICES. Continuous User Experience Engineering NOVEMBER NTT DATA, Inc. All rights reserved.

WHITE PAPER APPLICATION SERVICES. Continuous User Experience Engineering NOVEMBER NTT DATA, Inc. All rights reserved. WHITE PAPER APPLICATION SERVICES Continuous User Experience Engineering NOVEMBER 2017 2017 NTT DATA, Inc. All rights reserved. Software methodologies Software development methodologies play a vital part

More information

Agile/Lean & Safety: Perfect Match or Impossible Combination?

Agile/Lean & Safety: Perfect Match or Impossible Combination? Agile/Lean & Safety: Perfect Match or Impossible Combination? 1 Mika Katara Matti Vuori Department of Software Systems Tampere University of Technology This presentation reports results of the OHJELMATURVA

More information

Identifying Wastes in Software

Identifying Wastes in Software Page11 Identifying Wastes in Software Mr. Piyush Kumar Pareek* & Dr. A.N.Nandakumar ** *Assistant Professor, Department of CSE, Kammavari Institute of Technology, Bengaluru. **Principal, R.L. Jalappa institute

More information

Achieving Balance: The New Pivotal Points of Software Development

Achieving Balance: The New Pivotal Points of Software Development White Paper Software Delivery & Testing Achieving Balance: The New Pivotal Points of Software Development A rational model of software is to design it quickly; the economic pressure to improvise presents

More information

Agile Program Development. Agile Manifesto 9/3/2013. What is Agile Development? 12 Principles of Agile Development 1 of 4

Agile Program Development. Agile Manifesto 9/3/2013. What is Agile Development? 12 Principles of Agile Development 1 of 4 What is Agile Development? Agile Program Development CSCI 479: Computer Science Design Project Fall 2013 Xiannong Meng Agile software development is a group of software development methods based on iterative

More information

Software Engineering Part 2

Software Engineering Part 2 CS 0901341 Software Engineering Part 2 In this part, we look at 2.1 Software Process 2.2 Software Process Models 2.3 Tools and Techniques for Processing Modelling As we saw in the previous part, the concept

More information

De-Mystifying Kanban:

De-Mystifying Kanban: De-Mystifying Kanban: Understanding Its Many Faces Kanban kanban Al Shalloway Co-founder of, no longer affiliated with, Lean-Kanban University LKU Kanban (Kanban Method) Open Kanban Team Kanban Kanban

More information

Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods.

Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. Agile methods Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods: Focus on the code rather than the design

More information

The Business of Continuous Delivery

The Business of Continuous Delivery The Business of Continuous Delivery Kurt Bittner Principal Analyst @forrester @ksbittner 10 The Business of Continuous Delivery Kurt Bittner Principal Analyst @ksbittner 2014 Forrester Research, Inc. Reproduction

More information

6 Months of Lean-Agile Re-education

6 Months of Lean-Agile Re-education 6 Months of Lean-Agile Re-education Scaling Agile Leads to Lean July 2017 Nerd-a-palooza Some of our execution at FDIC-SQCRM seemed to some of us to be a bit too tactical/rudderless Hard to manage larger

More information

Scaling Software Agility:

Scaling Software Agility: Scaling Software Agility: Best Practices for Large Enterprises Agile 201 Seven Agile Team Practices that Scale 1 Seven Agile Team Practices That Scale 2 1. Define/Build/Test Team 3 Conway s Law Organizations

More information

Agile Delivery Framework (ADF)

Agile Delivery Framework (ADF) Agile Delivery Framework (ADF) Overview Agile is an iterative methodology with self-directed teams and the ability to embrace change rapidly. This document summarizes the Agile Scrum process as well as

More information

SEPTEMBER 2018 The Agile Team s Playbook to Doing Agile

SEPTEMBER 2018 The Agile Team s Playbook to Doing Agile SEPTEMBER 2018 The Agile Team s Playbook to Doing Agile A how-to guide for agile practitioners Agile is an umbrella term for a variety of work-management approaches that share common principles, among

More information

Lean IT Opex in the Clouds August 16, 2017 Sudhagar Raghavan

Lean IT Opex in the Clouds August 16, 2017 Sudhagar Raghavan 150 Jahre Lean IT Opex in the Clouds August 16, 2017 Sudhagar Raghavan 8/22/2017 1 150 Jahre 8/22/2017 # 150 Jahre 8/22/2017 # 150 Jahre 8/22/2017 # Software Development Life Cycle - The Waterfall Model

More information

Introduction to Agile Life Cycles. CSCI 5828: Foundations of Software Engineering Lecture 07 09/13/2016

Introduction to Agile Life Cycles. CSCI 5828: Foundations of Software Engineering Lecture 07 09/13/2016 Introduction to Agile Life Cycles CSCI 5828: Foundations of Software Engineering Lecture 07 09/13/2016 1 Goals Introduction to Agile Life Cycles The Agile Manifesto and Agile Principles Agile Life Cycles

More information

AGILE SOLUTIONS. Agile Basics

AGILE SOLUTIONS. Agile Basics AGILE SOLUTIONS Agile Basics info@one80services.com one80services.com AGILE SOLUTIONS Agile Basics Table of Contents 2 Who We Are 3 What Is Agile? 4 Agile Values 5 Agile Principles 6 Agile Development

More information

Software Engineering Lecture 5 Agile Software Development

Software Engineering Lecture 5 Agile Software Development Software Engineering Lecture 5 Agile Software Development JJCAO Mostly based on the presentation of Software Engineering, 9ed Exercise Describe the main activities in the software design process and the

More information

The Challenge: Balancing Change and Control of Continuous Delivery at Scale

The Challenge: Balancing Change and Control of Continuous Delivery at Scale WWW.PLUTORA.COM SOLUTION BRIEF The Challenge: Balancing Change and Control of Continuous Delivery at Scale DevOps bridges the gap between development and operations to deliver business value more frequently.

More information

Managing Projects of Chaotic and Unpredictable Behavior

Managing Projects of Chaotic and Unpredictable Behavior Managing Projects of Chaotic and Unpredictable Behavior by Richard Dick Carlson Copyright 2013, Richard Carlson; All Rights Reserved 1 Managing Projects of Chaotic and Unpredictable Behavior Dick Carlson,

More information

Scrum Testing: A Beginner s Guide

Scrum Testing: A Beginner s Guide Scrum Testing: A Beginner s Guide What is Scrum? Building complex software applications is a difficult task. Scrum methodology comes as a solution for executing such complicated task. It helps development

More information

Standard Work and the Lean Enterprise Net Objectives Inc. All Rights Reserved.

Standard Work and the Lean Enterprise Net Objectives Inc. All Rights Reserved. Standard Work and the Lean Enterprise 2010 Net Objectives Inc. All Rights Reserved. Lean Thinking Lean Thinking provides foundational principles which involve the entire lifecycle of realizing business

More information

The Faster Road to Innovation Why Workopolis Went Agile

The Faster Road to Innovation Why Workopolis Went Agile The Faster Road to Innovation Why Workopolis Went Agile What I m Covering Today Why did we transition to Agile? What we wanted to Achieve Highlights of How We Did It What we Achieved What we Learned Technology

More information

Agile. How would you implement agile methodologies and tools for web projects? What do you see as the benefits and challenges to doing this?

Agile. How would you implement agile methodologies and tools for web projects? What do you see as the benefits and challenges to doing this? Agile How would you implement agile methodologies and tools for web projects? What do you see as the benefits and challenges to doing this? What is Agile? The term agile (sometimes written Agile) was popularised

More information

Agile Thinking. Petri Heiramo. Agile Coach, CST

Agile Thinking. Petri Heiramo. Agile Coach, CST Agile Thinking Petri Heiramo Agile Coach, CST What is Important in Agile? Values Principles Practices Rules It is important to know why things work so that we do not sabotage them (by accident). Copyright

More information

Co-founder and Managing Director of RADTAC Specialist in Agile and Iterative approaches since mid 80s Agile Alliance Founder Member in 2002

Co-founder and Managing Director of RADTAC Specialist in Agile and Iterative approaches since mid 80s Agile Alliance Founder Member in 2002 Introduction to Agile BCS Spring School 2 nd March 2009 David Hicks david.hicks@radtac.co.uk Tel: 07778 558296 www.radtac.co.uk Introduction : David Hicks, RADTAC Co-founder and Managing Director of RADTAC

More information

Lean Methods for High-Variety, Low-Volume Industries

Lean Methods for High-Variety, Low-Volume Industries Setpoint Systems, Inc. Authored By: Malorie Rasmussen & Nate Morris Lean Methods for High-Variety, Low-Volume Industries www.setpointusa.com info@setpointusa.com 801-621-4117 Page 1 Setpoint provides lean

More information

Johanna Rothman. Chapter 1 Why Agile and Lean Approaches Work. Copyright 2017

Johanna Rothman. Chapter 1 Why Agile and Lean Approaches Work. Copyright 2017 Johanna Rothman Chapter 1 Why Agile and Lean Approaches Work Copyright 2017 Agile and Lean Approaches Why such approaches exist! Software, we have a problem It was thought you could hand a software team

More information

Software Development Life Cycle

Software Development Life Cycle Software Development Life Cycle Author : harvix-distrogmail-com When people are asked to define the SDLC (Software Development Life Cycle), they often come up with something like the following: 1. Planning

More information

Chapter 3 Agile Software Development. Part 1b

Chapter 3 Agile Software Development. Part 1b Chapter 3 Agile Software Development Part 1b 1 Testing in XP Testing is central to XP and XP has developed an approach where the program is tested after every change has been made. XP testing features:

More information

Data Warehousing provides easy access

Data Warehousing provides easy access Data Warehouse Process Data Warehousing provides easy access to the right data at the right time to the right users so that the right business decisions can be made. The Data Warehouse Process is a prescription

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 7 Agile Methodologies: Scrum 1 Agile Methodologies: Brief History First appeared in 1995. The once-common perception that agile methodologies

More information

Processes and Life- Cycles. Kristian Sandahl

Processes and Life- Cycles. Kristian Sandahl Processes and Life- Cycles Kristian Sandahl 2 Maintenance Requirements Validate Requirements, Verify Specification Acceptance Test (Release testing) System Design (Architecture, High-level Design) Verify

More information

12 Things to Shorten Your Lead Time

12 Things to Shorten Your Lead Time h 12 Things to Shorten Your Lead Time Stephan Schmidt You may distribute this ebook freely, and/or bundle it as a free bonus with other products, as long as it is left completely intact, unaltered and

More information

Scrum. a description. V Scrum Alliance,Inc 1

Scrum. a description. V Scrum Alliance,Inc 1 Scrum a description V 2012.12.13 2012 Scrum Alliance,Inc 1 Scrum Principles Values from the Agile Manifesto Scrum is the best-known of the Agile frameworks. It is the source of much of the thinking behind

More information

COPYRIGHTED MATERIAL WHAT S IN THIS CHAPTER?

COPYRIGHTED MATERIAL WHAT S IN THIS CHAPTER? 1 WHAT S IN THIS CHAPTER? Defining application lifecycle management Learning about the Visual Studio 2013 product family Seeing ALM in action using Visual Studio Ultimate 2013 In June of 1999, Microsoft

More information

Lecture 8 Agile Software Development

Lecture 8 Agile Software Development Lecture 8 Agile Software Development Includes slides from the companion website for Sommerville, Software Engineering, 10/e. Pearson Higher Education, 2016. All rights reserved. Used with permission. Topics

More information

Robin Yeman IS&GS Agile Transformation Lead ASPIRE. Lockheed Martin Business Unit Phone:

Robin Yeman IS&GS Agile Transformation Lead ASPIRE. Lockheed Martin Business Unit   Phone: Biography Robin Yeman IS&GS Agile Transformation Lead ASPIRE Lockheed Martin Business Unit Email: robin.yeman@lmco.com Phone: 571-535-5854 Career Highlights : 20 Years at Lockheed Martin, 13 Years of Agile

More information

The Kanban Guide for Scrum Teams

The Kanban Guide for Scrum Teams The Kanban Guide for Scrum Teams April 2018 Developed and sustained by Scrum.org and Daniel Vacanti Table of Contents Purpose... 3 Relation to the Scrum Guide... 3 Definition of Kanban... 3 Kanban with

More information

Case Study: How to Eliminate Flaws of Waterfall and Agile Development Processes Using a Hybrid Model

Case Study: How to Eliminate Flaws of Waterfall and Agile Development Processes Using a Hybrid Model Case Study: How to Eliminate Flaws of Waterfall and Agile Development Processes Using a Hybrid Model Agile Waterfall Hybrid Model The Waterfall Model has been the ideal choice for software development.

More information

2. True or false: In Scrum all the requirements for the project are known prior to the start of development.

2. True or false: In Scrum all the requirements for the project are known prior to the start of development. CTC-ITC 310 Program Management California State University Dominguez Hills Fall 2018 Instructor: Howard Rosenthal Assignment 5 A Deeper Look At Agile Methodologies Answer Sheet Each question is worth 10

More information

Business Alignment Through the DevOps Loop

Business Alignment Through the DevOps Loop Business Alignment Through the DevOps Loop Introduction CIOs are more focused than ever on moving from project-based, Waterfall projects to continuous delivery of working software. Agile, Lean, and DevOps

More information

Scrum Team Roles and Functions

Scrum Team Roles and Functions Scrum Team Roles and Functions What is a Scrum Team? The purpose of a Scrum team is to deliver products iteratively and incrementally, maximizing opportunities for feedback Scrum teams are comprised by

More information

Agile Software Development

Agile Software Development Agile Software Development Lecturer: Raman Ramsin Lecture 3 Scrum Framework 1 Scrum Origins First mentioned as a development method in 1986, referring to a fast and flexible product development process

More information

SOFTWARE ENGINEERING SOFTWARE-LIFE CYCLE AND PROCESS MODELS. Saulius Ragaišis.

SOFTWARE ENGINEERING SOFTWARE-LIFE CYCLE AND PROCESS MODELS. Saulius Ragaišis. SOFTWARE ENGINEERING SOFTWARE-LIFE CYCLE AND PROCESS MODELS Saulius Ragaišis saulius.ragaisis@mif.vu.lt CSC2008 SE Software Processes Learning Objectives: Explain the concept of a software life cycle and

More information

EBM EVIDENCE-BASED MANAGEMENT GUIDE

EBM EVIDENCE-BASED MANAGEMENT GUIDE EBM EVIDENCE-BASED MANAGEMENT GUIDE Scrum.org September 2018 How to continuously improve business results by measuring business value and using empirical management OVERVIEW Organizations adopting agile

More information

EBM EVIDENCE-BASED MANAGEMENT GUIDE

EBM EVIDENCE-BASED MANAGEMENT GUIDE EBM EVIDENCE-BASED MANAGEMENT GUIDE Scrum.org January 2019 How to continuously improve business results by measuring business value and using empirical management OVERVIEW Organizations adopting agile

More information

EBM EVIDENCE-BASED MANAGEMENT GUIDE

EBM EVIDENCE-BASED MANAGEMENT GUIDE EBM EVIDENCE-BASED MANAGEMENT GUIDE Scrum.org August 2018 How to improve business results by measuring business value and using empirical management OVERVIEW Organizations adopting agile product delivery

More information

Copyright Software Engineering Competence Center

Copyright Software Engineering Competence Center Copyright Software Engineering Competence Center 2012 1 Copyright Software Engineering Competence Center 2012 5 These are mapped categories to the waste categories of manufacturing. An excellent overview

More information

Service management solutions White paper. Six steps toward assuring service availability and performance.

Service management solutions White paper. Six steps toward assuring service availability and performance. Service management solutions White paper Six steps toward assuring service availability and performance. March 2008 2 Contents 2 Overview 2 Challenges in assuring high service availability and performance

More information

On various testing topics: Integration, large systems, shifting to left, current test ideas, DevOps

On various testing topics: Integration, large systems, shifting to left, current test ideas, DevOps On various testing topics: Integration, large systems, shifting to left, current test ideas, DevOps Matti Vuori www.mattivuori.net matti.vuori@mattivuori.net @Matti_Vuori TUT lecture series of SW Technologies:

More information

Agile Easy Read Snippets - Book 1. Agile Snippets. David Geoffrey Litten Agile Primer

Agile Easy Read Snippets - Book 1. Agile Snippets. David Geoffrey Litten Agile Primer Agile Easy Read Snippets - Book 1 Agile Snippets David Geoffrey Litten Agile Primer The origins of DSDM Atern and Agile. The DSDM consortium which was formed in 1994, resulted from a need for a different

More information

AHGILE A N D B O O K

AHGILE A N D B O O K AGILE HANDBOOK OVERVIEW 2 OVERVIEW This handbook is meant to be a quick-starter guide to Agile Project Management. It is meant for the following people: Someone who is looking for a quick overview on what

More information

Chapter 7. Project Reporting Keeping Everything Visible

Chapter 7. Project Reporting Keeping Everything Visible Chapter 7 Project Reporting Keeping Everything Visible A Scrum project is controlled by means of frequent inspection of the project followed by necessary adaptations Daily Scrum to get a feel for the tone,

More information

Lean Principles. Jerry D. Kilpatrick. This article was originally written for and published by MEP Utah in 2003 (

Lean Principles. Jerry D. Kilpatrick. This article was originally written for and published by MEP Utah in 2003 ( Lean Principles By Jerry D. Kilpatrick This article was originally written for and published by MEP Utah in 2003 (www.mep.org) Page 1 of 6 Introduction Lean operating principles began in manufacturing

More information

Agile for Hardware Development

Agile for Hardware Development Agile for Hardware Development. Agile for Hardware Development PLAYBOOK PLAYBOOKHQ.co Contents Background Agile Manifesto Agile Values Cost of Delay Agile Principles Agile Methods Conclusion 3 4 6 7 9

More information

Agile Manifesto Principles

Agile Manifesto Principles Agile Manifesto Principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes

More information

TSP*-Agile Blend: The Gun Smoke Clears

TSP*-Agile Blend: The Gun Smoke Clears TSP*-Agile Blend: The Gun Smoke Clears Alan Padula TSP Symposium September 21-24, 2009 New Orleans, Louisiana 2009 Intuit Inc. All rights reserved. * SM TSP Team Software Process and TSP are service marks

More information

Improving Agile Execution in the Federal Government

Improving Agile Execution in the Federal Government Improving Agile Execution in the Federal Government 1 Committed Partner. Creating Results. In December of 2010 the government introduced the 25 Point Implementation Plan to Reform Federal Information Technology

More information

Architecting for Agility. William A. Estrem, Ph.D President

Architecting for Agility. William A. Estrem, Ph.D President Architecting for Agility William A. Estrem, Ph.D President Bill Estrem President, Metaplexity Associates Bill is the founder and President of Metaplexity Associates, Inc. a training and consulting firm

More information

An Overview of Software Process

An Overview of Software Process An Overview of Software Process Objectives To introduce the general phases of the software development life cycle (SDLC) To describe various generic software process models and discuss their pros and cons

More information

Vendor: GAQM. Exam Code: CSM-001. Exam Name: Certified Scrum Master (CSM) Version: Demo

Vendor: GAQM. Exam Code: CSM-001. Exam Name: Certified Scrum Master (CSM) Version: Demo Vendor: GAQM Exam Code: CSM-001 Exam Name: Certified Scrum Master (CSM) Version: Demo QUESTION 1 What is the maximum amount of time that the team should spend in the daily scrum? A. As long as it takes

More information

Agile Essentials Track: Business Services

Agile Essentials Track: Business Services Agile Essentials Track: Business Services Presenter: Mark Thomas Synopsis Are you a victim of building the wrong solutions slowly? If so, you re not alone, and considering an Agile approach may be the

More information

Russell Pannone February 10, 2009

Russell Pannone February 10, 2009 Russell Pannone February 10, 2009 webeagile@aol.com About Me 27 years of System/Software Product Development Experience Developer Data Modeler Team Lead Project Manager Certified Scrum Master/Certified

More information

THE COMPREHENSIVE FACTORS

THE COMPREHENSIVE FACTORS Solutions for higher performance! USER STORIES ACCEPT LEVEL1 TEST AGILE VS LEAN CODE USER STORIES ACCEPT TEST LEVEL2 CODE TEST USER STORIES ACCEPT LEVEL3 CODE LAUNCH THE COMPREHENSIVE FACTORS Introduction

More information

How to Prepare for and Implement a Project Using Scrum

How to Prepare for and Implement a Project Using Scrum How to Prepare for and Implement a Project Using Scrum 2013 IEEE Software Technology Conference Salt Lake City, UT Dick Carlson Richard.Carlson2@Boeing.com Philip J. Matuzic Philip.J.Matuzic@Boeing.com

More information

Thrivent s Agile Transformation Journey

Thrivent s Agile Transformation Journey Thrivent s Agile Transformation Journey Fox Cities Operational Excellence Association October 5, 2017 0 1 What Makes Thrivent Unique? About Thrivent Financial We are: We have: We ve earned: A not-for-profit,

More information

Agile Planning. Petri Heiramo. Agile Coach, CST

Agile Planning. Petri Heiramo. Agile Coach, CST Agile Planning Petri Heiramo Agile Coach, CST An Agile Plan Is Not a Rough Guide Some teams think that, if they did not finish all stories, that was OK, we are agile Postponing stories was seen as an acceptable

More information

Leveraging Agile with audits. SF IIA Fall Seminar November 30, 2018

Leveraging Agile with audits. SF IIA Fall Seminar November 30, 2018 1 Leveraging Agile with audits SF IIA Fall Seminar November 30, 2018 2 I have never started a poem yet whose end I knew. Writing a poem is discovering. Robert Frost 3 Agile Manifesto While there is value

More information

D25-4. How Intertech Uses Agile

D25-4. How Intertech Uses Agile D25-4 How Intertech Uses Agile How to Use this Download This document shares an overview of how we use Agile/Scrum to deliver successful projects, the major differences between a waterfall/fixed bid project

More information

Agile for Hardware Development

Agile for Hardware Development Agile for Hardware Development. Agile for Hardware Development Playbook Playbookhq.co Contents Background Agile Manifesto Agile Values Cost of Delay Agile Principles Agile Methods Conclusion 3 4 6 7 9

More information

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING Software Engineering Third Year CSE( Sem:I) 2 marks Questions and Answers

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING Software Engineering Third Year CSE( Sem:I) 2 marks Questions and Answers DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING Software Engineering Third Year CSE( Sem:I) 2 marks Questions and Answers UNIT 1 1. What are software myths Answer: Management myths: We already have a book

More information

Enterprise Data Strategy and Governance

Enterprise Data Strategy and Governance Project Charter DATE: 9/20/2017 VERSION 1.0 Prepared By: Melany Leavitt and Paul Given Page 1 Document Revision History Version Number Date Description.01 5/25/2017 Draft Charter.02 9/1/2017 Draft for

More information

CTC/ITC 310 Program Management California State University Dominguez Hills First Exam Answer Key November 20, 2018 Instructor: Howard Rosenthal

CTC/ITC 310 Program Management California State University Dominguez Hills First Exam Answer Key November 20, 2018 Instructor: Howard Rosenthal CTC/ITC 310 Program Management California State University Dominguez Hills First Exam Answer Key November 20, 2018 Instructor: Howard Rosenthal There are 30 questions on this exam. Each question is worth

More information

Knowledge Understanding. Knowledge Understanding: An Agile Journey 11/30/2017

Knowledge Understanding. Knowledge Understanding: An Agile Journey 11/30/2017 Knowledge Understanding: An Agile Journey FRANK RIOS AGILE COACH / TRAINER WORK: FRANK1RIOS@HERECOM PERSONAL: FRANKTRIOS@GMAILCOM Knowledge Understanding 2 1 What does Agile mean to you? 3 An Agile Journey

More information

Agile Portfolio Management for a Fast- Paced World. Are you ready? Are you ready?

Agile Portfolio Management for a Fast- Paced World. Are you ready? Are you ready? Agile Portfolio for a Fast- Paced World Are you ready? Are you ready? 1 Ask a company today what its top priorities are, and you ll hear about growth and customer obsession. For enterprise architects working

More information

Agile Mindset (1/17/2019 for the Ocean State PMI)

Agile Mindset (1/17/2019 for the Ocean State PMI) Get connected with Leapfrog LeapFrog Systems Agile Mindset (1/17/2019 for the Ocean State PMI) Agenda 1. What is Agile? 2. Compare Agile and Traditional SDLC s 3. Agile Delivery Frameworks Scrum, Kanban,

More information

MIS Systems & Infrastructure Lifecycle Management 1. Week 10 March 24, 2016

MIS Systems & Infrastructure Lifecycle Management 1. Week 10 March 24, 2016 MIS 5203 Lifecycle Management 1 Week 10 March 24, 2016 Study Objectives Software Development Processes contd. Alternate Software Development Methodologies 2 Alternate Software Development Methodologies

More information

THE ESSENCE OF AGILE. Embracing Agility Means Agility by the Business, for the Business

THE ESSENCE OF AGILE. Embracing Agility Means Agility by the Business, for the Business THE ESSENCE OF AGILE Embracing Agility Means Agility by the Business, for the Business Author By Nidhi Srivastava Global Head, Consulting Practices, Tata Consultancy Services The push for agility in software

More information

Agile Software Delivery

Agile Software Delivery Agile Software Delivery An Introduction to Delivering Agile Software Projects the waterfall way the waterfall way analysis design build test go live so what s wrong with that? long cycle time users see

More information