Downloaded 73 times
Uploaded byThanh Nguyen
Introduction to Agile and Lean Software Development
The document provides an introduction to agile and lean software development. It discusses traditional vs agile development, defines agile as iterative and incremental using a plan-do-check-act approach with empowered cross-functional teams relying on automation. It covers the agile manifesto, principles and core practices including short iterations, deming's PDCA model, and the agile software development lifecycle. Lean concepts are introduced such as eliminating waste, amplifying learning, deciding late and delivering fast to empower teams and build integrity.
More Related Content
Similar to Introduction to Agile and Lean Software Development
Introduction to Agile and Lean Software Development
- 1. INTRODUCTION TO AGILE & LEANSOFTWARE DEVELOPMENT Lean Software Development 1
- 2. ① Introduction toAgile Traditional vs. Agile Agile Manifesto & Principles ② Definition of Agile Iterative & Incremental & Plan Do Check Act Empower & Cross Functional Teams Reliance on Automation ③ Agile Core Principles & Practices ④ Agile Software Development Lifecycle A. Agile Lean Software Development 2
- 3. 6/30/2015 Lean SoftwareDevelopment 3 ① Agile Manifesto & Principles Produce Value Early: highest priority is to satisfy the Customer through early & continuous delivery of valuable software. Welcome Change: welcome changing requirements, even late in development. Process harness change for the customer’s competitive advantage. Iterative Delivery: Deliver working software frequently, every couple of weeks/months, with a preference to the shorter timescale. Daily Business Collaboration: Business People and Developers must work together daily throughout the project. Trust Motivated Team: build projects around motivated individuals. Give them the environment & support their need, and trust them to get the job done. Face-to-Face Communication: most efficient & effective method of conveying information to and within development team is face-to-face conversation. Working Software: working software is the primary measure of progress. Sustainable Pace: Agile processes promote sustainable development. The Sponsors, Developers, Users should maintain a constant pace indefinitely. Technical Excellent: continuous attention to technical excellence & good design enhances agility. Keep It Simple: simplicity - the art of maximizing the amount of work not done - is essential. Self-Organize: the best architectures, requirements, and designs emerge from self-organizing teams. Reflect & Adjust: At regular intervals, the team reflects on how to become more effective, then tunes & adjusts its behavior accordingly. The Agile Manifesto: Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over following a Plan
- 4. 6/30/2015 Lean SoftwareDevelopment 4 ② Definition of Agile – Iterative Time Analysis Design Coding Testing 20% done (100% usable!) Time Analysis Design Coding Testing Do we have half a solution yet? Traditional Process Agile Process
- 5. 6/30/2015 Lean SoftwareDevelopment 5 ② Waterfall Requires Perfect Vision 1 2 3 4 5 Waterfall calls for a fully formed idea up front. And, doing it on time requires dead accurate estimation.
- 6. 6/30/2015 Lean SoftwareDevelopment 6 ② Incremental - Agile Expects Vision Shift 1 2 3 A more iterative allows you to move from vague idea to realization making course corrections as you go … stop when diminishing returns are encountered! 4 5 … builds a rough version, validates it, then slowly builds up quality
- 7. 6/30/2015 Lean SoftwareDevelopment 7 ② Short Iterations, Small Releases
- 8. 6/30/2015 Lean SoftwareDevelopment 8 ② Short Iterations, Small Releases
- 9. PDCA PDCA forGAP Analysis 6/30/2015 Lean Software Development 9 ② Deming’s PDCA (Plan Do Check Act/Adjust)
- 10. 6/30/2015 Lean SoftwareDevelopment 10 ② Empower & Cross Functional Teams
- 11. 6/30/2015 Lean SoftwareDevelopment 11 ② Reliance on Automation Build Scripts (Ant, Puppet, Bash, PowerShell) Version Control (SVN, CVS, GIT) Build Integration (Jenkins, Maven) Test 1 (Automated Regression Tests) Test 2 (Manual & Migration Tests) Sandbox On-Demand Pull Nightly Pull Automated Push Manager Developers Tester Compile/Tag Source Run Unit Tests Run Functional Tests Run Test Coverage Static Code Analysis Build Database WatchesCommit Uses Test Informs Stakeholder Inspect
- 12. 6/30/2015 Lean SoftwareDevelopment 12 ③ Agile Core Principles & Practices 1. Early Delivery of Value through Iterations with Demos: the project should be broken into a series of time-boxed, iterations that have a demo to show progress to all Stakeholders. 2. Continuous Involvement of the Customer: tradeoff is an important part of the process. Prioritize business value of work with Business & IT working collaboratively to balance risk. 3. Retrospectives: weekly team retrospective should be held to learn how to improve & enhance the project delivery efforts. 4. Communication: daily ‘Scrum’ should be held amongst team members to understand what has been accomplished, what will be accomplished & what roadblocks exist. 5. User Stories reflect Business Value & Priority: User Stories are managed in a backlog, prioritized by business value & releases are determined by the development velocity & what is deemed acceptable as a production release. 6. Acceptance Tests for all Requirements: Everyone owns ‘quality’. Standards, Test Automation, and key principles, such as Test Early / Test Often, are emphasized. 7. Sustainable Pace or Velocity: Team Members are involved in estimates & commitment dates. 8. High Visibility: Information on project status, progress and issues/risks should be maintained in real-time, web accessible tools.
- 13. 6/30/2015 Lean SoftwareDevelopment 13 ④ Agile Software Development Lifecycle Crystal DSDM XP FDD Agile RUP Scrum Concept Creation Requirements Specification Design Code Unit Test Integration Test System Test Acceptance Test System in Use Adapted from Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478. (pp. 95) KEY: Project management Process Practices / activities / work products
- 14. 6/30/2015 Lean SoftwareDevelopment 14 ① Traditional vs. Agile Project Management Conventional projects take too long and often miss the mark Lean (agile) methods link developers and users to hit the mark quickly: Extrinsic-Value & Intrinsic-Quality
- 15. Communication: Frequent collaboration betweenUsers & Programmers Use simple design, common metaphors, application of patterns Simplicity Focus on the simplest solution Don’t build more functionality than required Refactor complexity Feedback Unit Tests for feedback from the System Acceptance Tests for feedback from Customer The Planning Game for feedback from the Team Courage Refactor code to make future changes easier Throw code away that is obsolete Respect Respect for others; self-respect Adopting the other 4-values Respect gained from others in Team 6/30/2015 Lean Software Development 15 ① 5 Core Principles of XP
- 16. 6/30/2015 Lean SoftwareDevelopment 16 ① XP Practices Fine-Scale Feedback Pair Programming Planning Game Test-Driven Development Whole Team Continuous Process Continuous Integration Refactoring or Design Improving Small Releases Shared Understanding Coding Standard Collective Code Ownership Simple Design System Metaphor Programmer Welfare Sustainable Pace
- 17. 3 Principles Start withwhat you know Agree to pursue incremental, evolutionary change Respect current roles, responsibilities, and job titles 5 Core Practices Visualize Limiting Work-In-Progress Manage Flow Make management policy Improve collaboratively using “safe to fail” experiments 6/30/2015 Lean Software Development 17 ① Lean Kanban
- 18. 1. Lean forSoftware vs. Manufacturing 2. From Lean Manufacturing : Aim for continuous flow (single-piece flow) Watch your queues (pull production) 3. Pay to learn early in the project 4. Develop for Business Value once risks are down 5. Trim the Tail: choose to deliver by Value / Date B. Why Agile / Lean in Software Development Lean Software Development 18
- 19. 6/30/2015 Lean SoftwareDevelopment 19 ① Lean for Software vs. Manufacturing I wish they’d decide what style they want! Users & Sponsors Testers Business Analysts I wish they’d decide what functions they want! A decision I wish they’d decide on the UI design already! I wish they’d think a bit more carefully before coding! Programmers Every line of code is a decision UI Designers Software development looks like manufacturing if the unit of inventory is the invalidated decision!
- 20. 6/30/2015 Lean SoftwareDevelopment 20 ① Software Development has correction loops Detailed decisions about external appearance Decisions about function and style Detailed decisions about function and data Decisions about program structure Decisions about system correctness Users & Sponsors UI Designers Programmers Testers Business Analysts
- 21. 6/30/2015 Lean SoftwareDevelopment 21 ② From Lean Manufacturing: aim for continuous flow time Testers 100 lines of code show up for testing # of design decisions Decisions being validated or broken How long this line of code / screen / use case / decision sits in the testing queue Decisions arriving
- 22. 6/30/2015 Lean SoftwareDevelopment 22 ② Kaizen - Continuous Improvement IEEE
- 23. 6/30/2015 Lean SoftwareDevelopment 23 ② From Lean Manufacturing: watch your queues Users & Sponsors absent UI Designers Business Analysts some Programmers Database Designers Tester Enough Users & Sponsors UI Designer A few Business Analysts Lots of Programmers Single, solitary Database Designer Many Business Analysts Not enough Programmers Some Testers Enough Users & Sponsors
- 24. 6/30/2015 Lean SoftwareDevelopment 24 ③ Waterfall is a late-learning strategy Delivers nearly no knowledge (or risk reduction) Knowledge comes at the “moment of truth”: final integration. time cost Growth of knowledge with big-bang integration
- 25. 6/30/2015 Lean SoftwareDevelopment 25 ③ Agile pay to learn early in the project Development sequence indifferent (with respect to knowledge) Delivers knowledge (risk reduction) time cost Growth of knowledge with early, continuous integration
- 26. 6/30/2015 Lean SoftwareDevelopment 26 ④ Develop for Business Value once risks are down time Knowledge growing (risk reduction) cost Growth of business value Business value growing
- 27. 6/30/2015 Lean SoftwareDevelopment 27 ⑤ Trim the Tail: choose to deliver by Value or Date Trim to deliver on-time (or early) Delay to get more or better
- 28. Lean Software DevelopmentHistory & Thinking Tools C. Lean Software Development Lean Software Development 28
- 29. 6/30/2015 Lean SoftwareDevelopment 29 7 Lean Principles Lean Eliminate Waste Amplify Learning Decide as Late as Possible Deliver as Fast as Possible Empower the Team Build Integrity In See the Whole
- 30. 6/30/2015 Lean SoftwareDevelopment 30 ① Eliminate Waste Waste is anything that doesn’t add VALUE to a product Value as Perceived by Customer Many types of Waste to be avoided Delivering Value Deliver what the Customer wants immediately Value Stream Mapping
- 31. 6/30/2015 Lean SoftwareDevelopment 31 ① Eliminate Waste - Delivering Value Waste Description Example Partially Done Work Work started, but not complete; partially done work can entropy • Untested / Undocumented Code • Specs waiting for development Extra Processes Extra work that does not add value • Forgetting Decisions, re-trying Solution, un-utilize Knowledge • Unnecessary approvals Extra Features Features that are not required, or are thought as nice-to-haves • Gold plating • Technology features Task Switching Multi-tasking between several different projects when they are context-switching penalties • People on multiple projects Waiting Delays waiting for reviews & approvals • Waiting for prototype reviews • Waiting for document approvals Motion The effort required to communicate or move information or deliverables from 1 group to another; if teams are no co-located, this effort may need to be greater • Distributed teams • Handoffs: passing/getting information/work from someone Defects Defective documents or software that need corrective • Requirements defects • Software bugs
- 32. 6/30/2015 Lean SoftwareDevelopment 32 ① Waste – Value Stream Mapping Before Sales people Marketing Requirements’ sources Entering reqs. to the system Analysis Management Acceptance Prioritization Release Planning VAT: 1 hour VAT: 3 hour VAT: 1 hour VAT: 1 hour VAT: 1 hour NVAT: 5 days NVAT: 3 days NVAT: 4 days NVAT: 2 days VALUE ADDING TIME (VAT): 7 hours NON-VALUE ADDING TIME (NVAT): 14 days Development process
- 33. 6/30/2015 Lean SoftwareDevelopment 33 ① Waste – Value Stream Mapping Process Three general steps (Abdulmalek and Rajkopal): Choose a product target for improvement. Draw a Current State Map of the process, then analyzing the system and identifying its Weaknesses. Create a Future State Map, depicts how the system should look like when wastes have been removed. Apply the technique of “Five Why’s” which aims to identify the root-cause behind the Weakness. Value Stream Mapping follow the Continuous Improvement philosophy of Lean (Kaizen).
- 34. 6/30/2015 Lean SoftwareDevelopment 34 ① Waste – Value Stream Mapping - After Sales people Marketing Requirements’ sources Entering reqs. to the system Analysis Management Acceptance Prioritization Release Planning VAT: 1 hour VAT: 3 hour VAT: 1 hour VAT: 1 hour VAT: 1 hour NVAT: 3 days NVAT: 2 days NVAT: 3 days NVAT: 2 days VALUE ADDING TIME (VAT): 7 hours NON-VALUE ADDING TIME (NVAT): 10 days Development process
- 35. 6/30/2015 Lean SoftwareDevelopment 35 ② Amplify Learning Development is an exercise in discovery Adapt based upon empirical data, not assumption Repeat steps until requirements are met Expect & embrace mistakes then learn from them
- 36. 6/30/2015 Lean SoftwareDevelopment 36 ③ Decide as Late as Possible Expect uncertain & make decisions when uncertain is at a minimum Avoid locking in decisions until the future is closer & easier to predict (with options-based approach) Delay decisions are based on fact, not speculation, not on uncertain assumptions / predictions Keeping design options open & adapting to context is more valuable than committing early
- 37. 6/30/2015 Lean SoftwareDevelopment 37 ④ Deliver as Fast as Possible Rapid Software Development has many advantages Customers get what they need now not the biggest that survives, but the fastest Customers can delay determining what they want until they know more Just-In-Time in Iteration Compressing the Value Stream eliminate waste Self-Pulling system during a stand-up meeting
- 38. 6/30/2015 Lean SoftwareDevelopment 38 ⑤ Empower the Team No One understands the details better than the People doing the work. Developers can let each other know when work needs to be done Work-Out technique Use of “Pull” and “Local Signaling” mechanisms Find good people & let them do their own job Self-Organizing Teams are more empowered Ownership of challenges, success or failure
- 39. 6/30/2015 Lean SoftwareDevelopment 39 ⑥ Build Integrity In (Build Quality In) A System has integrity when it gives the Customer exactly what they want. Perceived Integrity is crucial Understand problem domain & resolve same time Conceptual Integrity is mandatory Refactoring: simplicity, clarity, minimum amount Integrity is the result of many processes working together effectively
- 40. 6/30/2015 Lean SoftwareDevelopment 40 ⑦ See the Whole Concentrate on the effort of the Team as a WHOLE rather than as a group of individuals. Focus on Overall system performance Think big, act small, fail fast; learn rapidly Avoid tendency to maximize only specialized parts of overall system Be wary of individual organization needs when using Contracts
- 41. 6/30/2015 Lean SoftwareDevelopment 41 More Info Social Linked-In: vn.linkedin.com/in/nguyennhatthanh Social Slideshare: www.slideshare.net/SmartBizVN Personal Website: http://smartbiz.vn/sales/en Show Cases: http://smartbiz.vn/sales/en/projects/ Email: Sun.SmartBiz@gmail.com Phone: (+84) 938 203080
Editor's Notes
- #2 *
- #4 Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- #9 http://mike2.openmethodology.org/
- #22 The word kaizen means “continuous improvement” in quality, technology, processes, company culture, productivity, safety, and leadership. It comes from the Japanese words (“kai”) which means “change” or “to correct” and (“zen”) which means “good.”
- #23 Japanese words (“kai”) which means “change” or “to correct” and (“zen”) which means “good.” Jidoka (Autonomation) Continuous Improvement in quality, technology, processes, company culture, productivity, safety, and leadership. IEEE: Improving Everyday, Everybody, and Everywhere
- #31 Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include: unnecessary code and functionality delay in the software development process unclear requirements avoidable process repetition (often caused by insufficient testing) bureaucracy slow internal communication In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Extra processes and features not often used by customers are waste. Waiting for other activities, teams, processes is waste. Defects and lower quality are waste. Managerial overhead not producing real value is waste. A value stream mapping technique is used to identify waste. The second step is to point out sources of waste and to eliminate them. Waste-removal should take place iteratively until even seemingly essential processes and procedures are liquidated.
- #36 Software development is a continuous learning process with the additional challenge of development teams and end product sizes. The best approach for improving a software development environment is to amplify learning. The accumulation of defects should be prevented by running tests as soon as the code is written. Instead of adding more documentation or detailed planning, different ideas could be tried by writing code and building. The process of user requirements gathering could be simplified by presenting screens to the end-users and getting their input. The learning process is sped up by usage of short iteration cycles – each one coupled with refactoring and integration testing. Increasing feedback via short feedback sessions with customers helps when determining the current phase of development and adjusting efforts for future improvements. During those short sessions both customer representatives and the development team learn more about the domain problem and figure out possible solutions for further development. Thus the customers better understand their needs, based on the existing result of development efforts, and the developers learn how to better satisfy those needs. Another idea in the communication and learning process with a customer is set-based development – this concentrates on communicating the constraints of the future solution and not the possible solutions, thus promoting the birth of the solution via dialogue with the customer.
- #37 As software development is always associated with some uncertainty, better results should be achieved with an options-based approach, delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. The more complex a system is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments. The iterative approach promotes this principle – the ability to adapt to changes and correct mistakes, which might be very costly if discovered after the release of the system. An agile software development approach can move the building of options earlier for customers, thus delaying certain crucial decisions until customers have realized their needs better. This also allows later adaptation to changes and the prevention of costly earlier technology-bounded decisions. This does not mean that no planning should be involved – on the contrary, planning activities should be concentrated on the different options and adapting to the current situation, as well as clarifying confusing situations by establishing patterns for rapid action. Evaluating different options is effective as soon as it is realized that they are not free, but provide the needed flexibility for late decision making.
- #38 In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end product is delivered without major defects, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the learning and communication within the team. With speed, decisions can be delayed. Speed assures the fulfilling of the customer's present needs and not what they required yesterday. This gives them the opportunity to delay making up their minds about what they really require until they gain better knowledge. Customers value rapid delivery of a quality product. The just-in-time production ideology could be applied to software development, recognizing its specific requirements and environment. This is achieved by presenting the needed result and letting the team organize itself and divide the tasks for accomplishing the needed result for a specific iteration. At the beginning, the customer provides the needed input. This could be simply presented in small cards or stories – the developers estimate the time needed for the implementation of each card. Thus the work organization changes into self-pulling system – each morning during a stand-up meeting, each member of the team reviews what has been done yesterday, what is to be done today and tomorrow, and prompts for any inputs needed from colleagues or the customer. This requires transparency of the process, which is also beneficial for team communication. Another key idea in Toyota's Product Development System is set-based design. If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the surviving designs are compared and one is chosen, perhaps with some modifications based on learning from the others - a great example of deferring commitment until the last possible moment. Software decisions could also benefit from this practice to minimize the risk brought on by big up-front design.
- #39 There has been a traditional belief in most businesses about the decision-making in the organization – the managers tell the workers how to do their own job. In a "Work-Out technique", the roles are turned – the managers are taught how to listen to the developers, so they can explain better what actions might be taken, as well as provide suggestions for improvements. The lean approach favors the aphorism "find good people and let them do their own job," encouraging progress, catching errors, and removing impediments, but not micro-managing. Another mistaken belief has been the consideration of people as resources. People might be resources from the point of view of a statistical data sheet, but in software development, as well as any organizational business, people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. People need motivation and a higher purpose to work for – purpose within the reachable reality, with the assurance that the team might choose its own commitments. The developers should be given access to the customer; the team leader should provide support and help in difficult situations, as well as ensure that skepticism does not ruin the team’s spirit. Agile projects are built around motivated individuals and the team organize themselves without the command and control structure Self-organizing teams in which the interactions are high and processes are low.
- #40 The customer needs to have an overall experience of the System – this is the so-called perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, price and how well it solves problems. Conceptual Integrity means that the system’s separate components work well together as a whole with balance between flexibility, maintainability, efficiency, and responsiveness. This could be achieved by understanding the problem domain and solving it at the same time, not sequentially. The needed information is received in small batch pieces – not in one vast chunk with preferable face-to-face communication and not any written documentation. The information flow should be constant in both directions – from customer to developers and back, thus avoiding the large stressful amount of information after long development in isolation. One of the healthy ways towards integral architecture is refactoring. As more features are added to the original code base, the harder it becomes to add further improvements. Refactoring is about keeping simplicity, clarity, minimum amount of features in the code. Repetitions in the code are signs for bad code designs and should be avoided. The complete and automated building process should be accompanied by a complete and automated suite of developer and customer tests, having the same versioning, synchronization and semantics as the current state of the System. At the end the integrity should be verified with thorough testing, thus ensuring the System does what the customer expects it to. Automated tests are also considered part of the production process, and therefore if they do not add value they should be considered waste. Automated testing should not be a goal, but rather a means to an end, specifically the reduction of defects.
- #41 Software systems nowadays are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to accumulate during the development process – by decomposing the big tasks into smaller tasks, and by standardizing different stages of development, the root causes of defects should be found and eliminated. The larger the system, the more organizations that are involved in its development and the more parts are developed by different teams, the greater the importance of having well defined relationships between different vendors, in order to produce a system with smoothly interacting components. During a longer period of development, a stronger subcontractor network is far more beneficial than short-term profit optimizing, which does not enable win-win relationships. Lean thinking has to be understood well by all members of a project, before implementing in a concrete, real-life situation. "Think big, act small, fail fast; learn rapidly" – these slogans summarize the importance of understanding the field and the suitability of implementing lean principles along the whole software development process. Only when all of the lean principles are implemented together, combined with strong "common sense" with respect to the working environment, is there a basis for success in software development.