Lean IT and agile practices towards cost effectiveness

1. Lean IT and agile practices towards cost effectiveness Nageswara Nakka

2. Agile • Agile – adjective: • quick and well coordinated in movement • active, lively • not awkward, not lethargic

3. Agile

6. What is Lean IT? • Lean – adjective: efficient and with no wastage • Lean IT is the expansion of lean manufacturing • and lean service principles to software • development and management of information • technology(IT). • Is the elimination of waste, where waste is the • work that adds no value to a product or service.

7. Agenda • Introduction: What is Lean IT? • History of Lean • Principles of Lean Software Development • LSD Implementation aspects

8. Agenda Lean IT: Implementation Aspects Value Waste Speed People Knowledge Quality Partners

9. History

10. History • Interchangeable parts • Interchangeable people • The Toyota Production System • Just-in-time, • autonomation(jidoka) • “Economies of scale”, “Variety(complexity)” • stop-the-line • Non-stock production • Zero inspection

11. Just-in-Time

12. Key Lesson – Stop trying to maximize local efficiencies (utilization)

13. Lean Family Tree –Lean Supply Chain

14. Principles and Practices

15. Principles and Practices • Principles are underlying truths that don’t change over time or space • Practices are realizations of the principles that can and should differ as we move from one environment to the next. They also change as a situation evolves. • Learn-by-doing approach • Understand-before-doing approach • Combined approach - “tailor” practices to fit to the need

16. Software, Development • Software: Is that part of the product that is expected to change. • Development: is the process of transforming ideas into products. • Deterministic school of thought: starts by creating a complete product definition and then creates a realization of that definition • Empirical school of thought: Starts with a high level product concept and then establishes well defined feedback loops that adjust the activities so as to create an optimal interpretation of the concept.

17. Principle 1: Eliminate Waste • Look at the timeline. Timeline clock (start, stop). • LSD focuses on the timeline by reducing waste. • To eliminate waste first we need to recognize the waste. • Waste is anything that does not add value. • Develop a keen sense what value really is. • Good software development organizations develop a deep sense of customer value and delight their customers. • Next step is develop a capability to really see waste • In manufacturing – inventory is waste. • In software development – partially done work is waste.

18. Principle 1: Eliminate Waste • Myth: Early Specification Reduces Waste We set the rules: Will you, valued customer, please give us a list of everything you want the software to do? We will write it down and ask you to sign off on the result. After that, if you want changes or additions, you will have to go through an arduous process called “change management” to get a change approved. So you had better think of everything want right now, because we have to know about it at the beginning in order to develop good software.

19. Principle 2: Build Quality In • Inspections after the fact • Control conditions not to allow defects • Inspections to prevent defects • Inspect the product after each small step • Catch the defect immediately after they occur • When defect is found, stop-the-line, fix-it immediately • Defect tracking systems are queues of partially done work • In lean paradigm queues are collection points for waste

20. Principle 2: Build Quality In • Myth: The Job of Testing is to find Defects • We need more discipline in here, not less. • Don’t focus on putting defects into a defect tracking system • Avoid creating defects in the first place. • Takes a highly disciplined organization to do that. • A release cycle scenario from 4 months to 6 weeks.

21. Principle 3: Create Knowledge • Software Development is a knowledge creation process • Knowledge in the form of Requirements (puzzling) • Architecture and higher level design before coding • As the code is being written • Architecture is validated • Detailed design occurs even if detailed design document was written prior • Detailed design cannot anticipate the complete complexity, cannot account for the feedback • Good project, Bad project

22. Principle 3: Create Knowledge • Myth: Predictions Create Predictability • We need more discipline in here, not less. • Don’t focus on putting defects into a defect tracking system • Avoid creating defects in the first place. • Takes a highly disciplined organization to do that. • A release cycle scenario from 4 months to 6 weeks.

23. Principle 4: Defer Commitment

24. Principle 5: Deliver Fast

25. Principle 6: Respect People

26. Principle 7: Optimize the Whole • Myth: Optimization by Decomposition • A lean organization optimizes the whole value stream • Organizations have a tendency to optimize something less than a value stream (suboptimize) • Decomposition approach – optimize all individual measurements.

27. Value

28. Value - Customer Focused Organization • Deep Customer Understanding • Mind meld between business and technical • Flow of information between market team and development team • Provide Leadership, Empower a complete team • Existence of a champion • Governance: Assigning a Decision maker • Project model (vs) Product model • Product model fosters more collaboration • Internal: Absence of competitive pressure can weaken the intense customer focus (core competency) • IT – Business collaboration is essential for survivability • Internal IT organizations – problem of accountability

29. Waste in Software Development • Root cause – a good candidate “Complexity” • Prescription is simple – “Write Less Code” • Complexity • Cost of complexity – is exponential • Increasing code base • Complex array of products • Complex Organizational structures • Justify every feature • Minimum useful feature set • Don’t automate (business process) complexity • Candidate for automation should be clarified and simplified • Root Cause: No one has been conditioned to think complexity as bad. • Every line of code costs money to write and to support.

31. Mapping the Value Stream • Value Stream Map is a timeline of the major events that occur from the time the clock starts until it stops. • Objective is to reduce the development timeline by removing non-value adding wastes. • Wastes are exposed as delays in the flow. • Long delays and loop backs (churn) in the process. • Value stream maps are diagnostic tools to help find waste

32. Value StreamHigh Priority feature Change Request (Organization A)

33. Value StreamHigh Priority feature Change Request (Organization B)

34. Value Stream – lessons to take away • Even though both organizations are equally busy, Organization A is better organized. • Organization is focusing on making some developers available to drop low priority work to tackle high-priority requests (JIT) • Organization B was focusing so hard on resource utilization which actually is driving the utilization down. • Organization A was doing periodic short releases • Organization B – accumulating code changes for 2 weeks before integration

35. Future Value Stream • Every organization usually has more work than it can possibly do. • However far more work can be done, faster and with higher quality • By eliminating the waste seen in most value streams. • Draw a future value stream map to create a plan for removing the biggest wastes. • Future map should not be an ideal map, should be a path for immediate improvement. • Pick the biggest delays or the longest queues first that can be implemented in near future with one to three key changes. • Repeat the process once benefits are realized, this is a continuous process.

36. Speed – Deliver Fast Speed is the absence of waste Queuing Theory – Little’s Law (stable systems)

37. Variation and Utilization Stable systems (checkout lanes) High utilization (traffic jam)

38. Reducing Cycle Time • 1. Even out the arrival of work • 2. Minimize the number of things in process • 3. Minimize the size of things in process • 4. Establish a regular cadence • 5. Limit work to capacity • 6. Use pull scheduling • Does your organization measure “resource utilization”? • Focus on release schedule? Or Project size?

39. Pull Scheduling Checkpoints • Does your organization measure “resource utilization”? • Focus on release schedule? Or Project size?

40. PeopleEdward Deming’s 4 main points • Appreciation for System • Knowledge about variation • Theory of knowledge (PDCA) • Psychology • Skill • Pride • Expertise • Confidence • cooperation

41. PeopleDeming’s 14 points • 1. Provide for the long-range needs of the company; don’t focus on short-term profitability. The goal is to stay in business and provide jobs. • 2. The world has changed, and managers need to adopt a new way of thinking. Delays, mistakes, defective workmanship, and poor service are no longer acceptable. • 3. Quit depending on inspection to find defects, and start building quality into products while they are being built. Use statistical process control. • 4. Don’t choose suppliers on the basis of low bids alone. Minimize total cost by establishing long-term relationships with suppliers that are based on loyalty and trust. • 5. Work continually to improve the system of production and service. Improvement is not a one-time effort; every activity in the system must be continually improved to reduce waste and improve quality. • 6. Institute training. Managers should know how to do the job they supervise and be able to train workers. Managers also need training to understand the system of production. • 7. Institute leadership. The job of managers is to help people do a better job and remove barriers in the system that keep them from doing their job with pride. The greatest waste in America is failure to use the abilities of people. • 8. Drive out fear. People need to feel secure in order to do their job well. There should never be a conflict between doing what is best for the company and meeting the expectations of a person’s immediate job. • 9. Break down barriers between departments. Create cross-functional teams so everyone can understand each-other’s perspective. Do not undermine team cooperation by rewarding individual performance. • 10. Stop using slogans, exhortations, and targets. It is the system, not the workers, that creates defects and lowers productivity. Exhortations don’t change the system; that is management’s responsibility. • 11. Eliminate numerical quotas for workers and numerical goals for people in management. Eliminate arbitrary deadlines for development teams. This is management by fear. Try leadership. • 12. Eliminate barriers that rob the people of their right to pride of workmanship. Stop treating hourly workers like a commodity. Eliminate annual performance ratings for salaried workers. • 13. Encourage education and self-improvement for everyone. An educated workforce and management is the key to the future. • 14. Take action to accomplish the transformation. A top management team must lead the effort with action, not just support.

42. 21-step program Optimize the Whole • Implement lean across an entire value stream and the complete product • Restructure the measurements • Reduce the cost of crossing boundaries Respect People • Train team leaders/supervisors • Move responsibility and decision making to the lowest possible level • Foster pride in workmanship Deliver Fast • Work in small batches • Limit work to capacity • Focus on cycle time, not utilization

43. 21-step program Defer Commitment • Abolish the notion that it is a good practice to start development with a complete specification • Break dependencies • Maintain options Create Knowledge • Create design-build teams • Maintain a culture of constant improvement • Teach problem-solving methods Build Quality In • Synchronize • Automate • Refactor

44. 21-step program Eliminate Waste • Provide market and technical leadership • Create nothing but value • Write less code

45. References • Implementing Lean Software development: From Concept to Cash – Mary and Tom Popendieck Publisher: Addison-Wesley Professional • The Agile Culture: Leading through Trust and Ownership By: Pollyanna Pixton; Paul Gibson; NielNickolaisen Publisher: Addison-Wesley Professional

46. Q &A