• Save
Scrum - What Is Next?
Upcoming SlideShare
Loading in...5
×
 

Scrum - What Is Next?

on

  • 1,815 views

Presentation I did at a client to introduce Lean thinking to Scrum rollout across organization.

Presentation I did at a client to introduce Lean thinking to Scrum rollout across organization.

Statistics

Views

Total Views
1,815
Views on SlideShare
1,803
Embed Views
12

Actions

Likes
4
Downloads
0
Comments
0

3 Embeds 12

http://www.linkedin.com 5
http://www.slideshare.net 4
http://www.lmodules.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Scrum - What Is Next? Scrum - What Is Next? Presentation Transcript

  • So You Have Been Doing Scrum What’s Next??
  • Agenda • Introduction to Lean (40 Minutes) – Brief History – Goals, Values and Practices – Load, Flow and Waste – Toyota Way: Lean Framework • Quick Break (5 Minutes) • Team Organization (30 Minutes) – Component Teams – Feature Teams • Next Steps (15 Minutes) • Q&A (30 Minutes) • Close Copyright © 2009 SolutionsIQ. All rights reserved.
  • Introduction to Lean Steps to becoming a lean, mean producing machine Copyright © 2009 SolutionsIQ. All rights reserved.
  • Brief History of Lean Copyright © 2009 SolutionsIQ. All rights reserved.
  • “It is only through enforced standardization of methods, enforced adoption of the best implements and working conditions, and enforced cooperation that this faster work can be assured. And the duty of enforcing the adoption of standards and enforcing this cooperation rests with management alone.” --Frederick W. Taylor Copyright © 2009 SolutionsIQ. All rights reserved.
  • Taylor’s Principles • Replace rule-of-thumb work methods with methods based on a scientific study of the tasks. • Scientifically select, train, and develop each employee rather than passively leaving them to train themselves. • Provide quot;Detailed instruction and supervision of each worker in the performance of that worker's discrete taskquot; (Montgomery 1997: 250). • Divide work nearly equally between managers and workers, so that the managers apply scientific management principles to planning the work and the workers actually perform the tasks. Copyright © 2009 SolutionsIQ. All rights reserved.
  • PDCA Model W. Edwards Deming Copyright © 2009 SolutionsIQ. All rights reserved.
  • Deming’s 14 Points for Management 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 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. Copyright © 2009 SolutionsIQ. All rights reserved.
  • Deming’s 14 Points for Management (con’t) 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. 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. Copyright © 2009 SolutionsIQ. All rights reserved.
  • History of Production • Craft Production (1700’s – 1920) – Textiles and Other Early Industries, Arts, Etc. – Automobiles Before Ford • Mass Production (1920 – 1970) – Commodity Durable Goods of All Kinds – Ford, Chevrolet Automobiles • Lean Production (1970 – Present) – Commodity AND Specialty Products – Toyota Automobiles Copyright © 2009 SolutionsIQ. All rights reserved.
  • Toyota Production System • Approach to Production – Build only what is needed – Stop if something goes wrong – Eliminate anything which does not add value • Philosophy of Work – Respect for Workers Taiichi Ohno – Full utilization of workers’ capabilities – Entrust workers with responsibility & authority Copyright © 2009 SolutionsIQ. All rights reserved.
  • Womack and Jones • Contrasted Lean to Mass Production • 5 Principles: – Value – Value Stream – Flow – Pull – Perfection • Coined the term “Lean” to describe Toyota Production System Copyright © 2009 SolutionsIQ. All rights reserved.
  • 7 Principles of Lean Software Development Eliminate Build Quality Defer Respect Focus on Optimize the Deliver Fast Waste In Commitment People Learning Whole Copyright © 2009 SolutionsIQ. All rights reserved.
  • Lean Goals, Values and Practices Copyright © 2009 SolutionsIQ. All rights reserved.
  • Lean Goals • Sustainably Deliver Value Fast • Sustainable Shortest Lead Time • Best Quality and Value (to People and Society) • Most Customer Delight • Lowest Cost • High Morale • Safety Copyright © 2009 SolutionsIQ. All rights reserved.
  • Respect for People • Don’t Trouble Your ‘Customer’ • Develop People and Then Build Products • Teams & Individuals Evolve Their Own Practices & Improvements • Managers “Walk the Talk” • Develop Teams • Build Partners Copyright © 2009 SolutionsIQ. All rights reserved.
  • Continuous Improvement • Go See • Kaizen • Shu Ha Ri • Perfection Challenge • Work Towards Flow Copyright © 2009 SolutionsIQ. All rights reserved.
  • Kaisen Team Team Experiments Chooses looking for New Better Way Techniques Techniques Team become Practices Well Techniques Understood Copyright © 2009 SolutionsIQ. All rights reserved.
  • Shu Ha Ri Ri Ha Shu Rules are forgotten as Person reflects on the person has developed Person follows rules rules, looks for mastery, and grasped until they sink in exceptions, and the essence and ‘breaks” the rules underlying forces Copyright © 2009 SolutionsIQ. All rights reserved.
  • Load, Flow and Waste Copyright © 2009 SolutionsIQ. All rights reserved.
  • Muri, Mura, Muda •Manage Muri overload •Streamline Mura flow •Manage Muda process Copyright © 2009 SolutionsIQ. All rights reserved.
  • Complexity Map ELEMENT OF COMPLEXITY CHARACTERISTIC Inconsistency (Mura – streamline flow) Irregularity Inconsistency destroys reliability and predictability. Interruption Imbalance Overload (Muri – manage load) Stress, strain, push Overload limits productivity, functionality, and Undercapacity effectiveness. Overburden Waste (Muda – manage process) Overcapacity Waste is elegance enemy number one. Excess beyond Overdesign what’s needed to solve the problem is considered waste. Excess Motion Too much or too many of anything consumes resources Defects without adding any value. Customers won’t pay for it. Bureaucracy Translate each of these deadly sins to your business. Overprocess For example, overcapacity might mean excess floor space Delay in retail operations. Inventory Overproduction Transport Redundancy Copyright © 2009 SolutionsIQ. All rights reserved.
  • The Basics of Flow and Pull • Flow Characteristics • Pull Characteristics – Time-boxed rhythm – Value traced stories – Compact Team – Shaped by Feedback – Inspect & Adapt – Collaborative design for simplicity • Results • Results – Less Friction – Less Waiting/WIP – Less Defects & Defect Mgmt – Less Requirements Mgmt. – Visibility & Steering – More Value Faster • Roadblocks • Roadblocks – Resource Constraints – Local Focus – Locked Triangle – Product Mgmt. Pushing – Low Test Automation – Weak/Delayed Feedback Loops – Large inventory of defects Copyright © 2009 SolutionsIQ. All rights reserved.
  • Step 1 – Team Flow State 1. Is prepared enough, has enough resource flexibility, testing tools and planning discipline to reliably make and meet its iteration commitments – 100 % Story Acceptance Iteration over Iteration – Done, Done – Acceptance Tested and Accepted without Defects 2. Is working at a sustainable pace to achieve the above goal – Buffers enough slack in the iteration to handle bumps without major overtime – Iteration Retrospectives reveal a passionate team Result: Cost savings from efficient and smooth flow (reduced time slicing and task switching costs). Quality savings gained in reduction in defect handling and down-stream abatement costs. Copyright © 2009 SolutionsIQ. All rights reserved.
  • Step 2 – Team Pull State 1. Pulls from backlog of “Ready” stories that trace to prioritized release themes – Ready – requires defined acceptance tests and a design the team accepts 2. Is synchronized with upstream and downstream process to produce rapid releases to customers – Multiple internal “releases” allow for feedback and smooth flow in the large scale 3. Is working as part of the larger whole – Done, Done, Done – Integrated and system tested into a functioning part of the whole (product or customer) Result: Cost savings from large scale efficient and smooth flow (reduced waiting, paperwork and process). Value gained from rapidly shipping only the most valuable features with customer validation (reducing overproduction and WIP). Copyright © 2009 SolutionsIQ. All rights reserved.
  • Examples of Waste Waste Example Overproduction of features, Features customer doesn’t really want or of elements ahead of the Large requirements document next step; duplication Duplication of data or code Waiting, delay …for clarification, approval, components, other groups to finish something Handoff, conveyance, Spec from analyst to developer moving Code from developer to a tester Extra processing, relearning, Forced conformance to centralized process checklists of reinvention ‘quality’ tasks Recreating a component another developer has made Partially done work (WIP) Requirements written but not coded Software coded but not tested Task switching, motion Multitasking on 3 projects between tasks, interrupt- Partial allocation of person to many teams, projects based multitasking Copyright © 2009 SolutionsIQ. All rights reserved.
  • More Examples of Waste Waste Example Defects, testing and correction Fix and build process at end to find and remove after creation of the product defects Under-realizing people’s Are people only working to their single-speciality job potential and varied skill, insight, title, or …? ideas, suggestions Do people have the chance to change what they see is wasteful? Knowledge and information Information in many separate documents rather than scatter or loss a central wiki with hypertext Communication barriers such as walls between people, or people in multiple locations Wishful thinking (for example, “The estimate cannot increase; the effort estimate is that plans, estimates, and what we want it to be, not what it is now proposed.” specifications are ‘correct’) “We’re behind schedule, but we’ll make it up later.” Copyright © 2009 SolutionsIQ. All rights reserved.
  • Lean Framework: Toyota’s 14 Principles 1. Decisions based on 8. Well-tested Technology long-term philosophy 9. Grow Leaders from within and teach to others 2. Move towards flow 10. Develop exceptional people 3. Use pull systems; 11. Respect partners, help them decide as late as improve possible 12. Go see for yourself 4. Level the work 13. Decisions slowly by 5. Culture of stop and fix consensus, then implement rapidly 6. Master practices 14. Become learning organization 7. Simple visual through reflection and management improvement Copyright © 2009 SolutionsIQ. All rights reserved.
  • Let’s take a Quick Break 5 Minutes Copyright © 2009 SolutionsIQ. All rights reserved.
  • Team Organization Looking at teams from another perspective Copyright © 2009 SolutionsIQ. All rights reserved.
  • Component Teams Copyright © 2009 SolutionsIQ. All rights reserved.
  • Conway’s Law • […] there is a very close relationship between the structure of a system and the structure of the organization which designed it. • … Any organization that designs a system […] will inevitably produce a design whose structure is a copy of the organization’s communication structure. “The software tends to mirror the structure of the organization that built it. If you have a big, slow organization, you tend to build big, slow software.” -- Brad Silverberg Copyright © 2009 SolutionsIQ. All rights reserved.
  • Component Teams • Programmer groups formed around architectural models or components of the system. • Team owns and maintains their component – single points of specialization success or failure. • Driven by assumptions or fears: – People can’t or shouldn’t learn new skills – Code can’t be effectively shared and integrated between people Copyright © 2009 SolutionsIQ. All rights reserved.
  • Advantages of Component Teams • People developed narrow specialized skill, leading to faster work when viewed locally rather than overall systems throughput • Specialists were less likely to break their code • No conflicting code changes from other teams Copyright © 2009 SolutionsIQ. All rights reserved.
  • The Problem with Component Teams • Promotes sequential • Causes long delays due life cycle development to major waiting and and mindset handoff • Limits learning by • Encourages code people working only on duplication same components • Complicates planning • Easier work rather than and synchonization most valuable work • Increases bottlenecks • Promotes “artificial • Fosters more poor work” code/design Copyright © 2009 SolutionsIQ. All rights reserved.
  • Feature Teams Copyright © 2009 SolutionsIQ. All rights reserved.
  • Feature Teams “The feature is the natural unit of functionality that we develop and deliver to our customers, and this it is the ideal task for a team. The feature team is responsible for getting the feature to the customer within a given time, quality and budget. A feature team needs to be cross functional as it needs to cover all phases of the development process from customer contact to system test, as well as all areas [cross component] of the system which is impacted by the feature.” - Telecom industry giant Ericsson Copyright © 2009 SolutionsIQ. All rights reserved.
  • Characteristics of Feature Team • Long-Lived • Cross-Functional • Cross-Component • Co-Located • Work on a complete customer-centric feature, across all components and disciplines • Generalizing Specialists • In Scrum, typically 7 +/- 2 people Copyright © 2009 SolutionsIQ. All rights reserved.
  • Values of Feature Teams • Empowerment • Accountability • Identity • Consensus • Balance Copyright © 2009 SolutionsIQ. All rights reserved.
  • Advantages of Feature Teams • Increased Value • Self-Managing Throughput • Better Code/Design • Increased Learning Quality • Simplified Planning • Better Motivation • Reduced Waste of • Simple Interface and Handoff Module Coodination • Less Waiting, Faster • Change Is Easier Cycle Time Copyright © 2009 SolutionsIQ. All rights reserved.
  • Challenges going to Feature Teams • Broader skills and Product Knowledge • Concurrent Access to Code • Shared Responsibility for Design • Different Mechanism to Ensure Product Stability • Reuse and Infrastructure Work • Difficult-to-learn Skills • Development and Coordination of Common Functional Skills that Span Members of Many Feature Teams • Organizational Structure • Defect Handling Copyright © 2009 SolutionsIQ. All rights reserved.
  • Transition to Feature Teams • Module “Shepherds” • Continuous Integration environment in place • Sharing Knowledge and Skills through Pairing • Create Automated Functional Tests to understand “intent” of the code • Relentless refactoring of code • Communities of Practice • Joint Design Sessions • Product Definition Team • Product Bug Triage Team Copyright © 2009 SolutionsIQ. All rights reserved.
  • Next Steps Takeaways from this session Copyright © 2009 SolutionsIQ. All rights reserved.
  • Create a Lean Product Development Organization – “Outlearn the Competition” • Develop Long-Lasting Engineers with Highest Skill and Craftsmanship • Managers Who Are Master Engineers and Teachers • Team Rooms with Visual Management • Cadence – Heartbeat of short regularly-timed cycles, with small batches of work • Set-Based Concurrent Engineering • Cross-Functional and Product Mindset • Entrepreneurial Hands-on Chief Copyright © 2009 SolutionsIQ. All rights reserved.
  • Where you will go • Architecture adapts and evolves incrementally • Natural feedback from top to bottom and bottom to top • Lean practices spread across organization • Systems and processes adapt and evolve from feedback • Teams continue to organize into Feature Teams that can deliver highest business value • Business measures value, cost, velocity, quality, agility Copyright © 2009 SolutionsIQ. All rights reserved.
  • Becoming an expert? • Realize it is a long journey • Focus on making incremental & iterative progress • Drive to full participation • Encourage education and experimentation • Hire the best • Inspect & Adapt CC 2006, Kathy Sierra’s - http://headrush.typepad.com/creating_passionate_users/2006/03/how_to_be_an_ex.html Copyright © 2009 SolutionsIQ. All rights reserved.
  • References • Liker – The Toyota Way (McGraw-Hill, 2004) • May – The Elegant Solution (Free Press, 2007) • Morgan & Liker – The Toyota Product Development System ( Productivity Press, 2006) • Poppendieck & Poppendieck – Lean Software Development, an Agile Toolkit (Addison Wesley, 2003) • Poppendieck & Poppendieck – Implementing Lean Software Development, from Concept to Cash (Addison Wesley, 2007) • Womack & Jones – Lean Thinking (Simon and Schuster, 2006) • Larman & Vodde – Scaling Lean & Agile Development (Addison Wesley, 2009) • W. Edwards Deming, Quality, Productivity and Competitive Position (MIT, 1982) Copyright © 2009 SolutionsIQ. All rights reserved.
  • Questions? Let’s review the Question board Copyright © 2009 SolutionsIQ. All rights reserved.