Agile2013 sustainable change
•Als PPTX, PDF herunterladen•
18 gefällt mir•39,050 views
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ă„hnlich wie Agile2013 sustainable change
Ă„hnlich wie Agile2013 sustainable change (20)
Mehr von Dennis Stevens
Mehr von Dennis Stevens (15)
KĂĽrzlich hochgeladen
KĂĽrzlich hochgeladen (20)
Agile2013 sustainable change
- 1. Gaining Support for a Sustainable Agile Transformation Dennis Stevens, VP Enterprise Engagements Mike Cottmeyer, CEO & President LeadingAgile August 8, 2013
- 2. Agenda • Agile Basics • Scaling Agile • Why is it hard? • A Model of Agile Transformation
- 3. Agenda • Agile Basics • Scaling Agile • Why is it hard? • A Model of Agile Transformation
- 4. Agenda • Agile Basics • Scaling Agile • Why is it hard? • A Model of Agile Transformation
- 5. Agenda • Agile Basics • Scaling Agile • Why is it hard? • A Model of Agile Transformation
- 6. Agenda • Agile Basics • Scaling Agile • Why is it hard? • A Model of Agile Transformation
- 7. Agile Basics
- 8. Agile is About Teams
- 10. How Agile Teams Work
- 11. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story
- 12. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity
- 13. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability
- 14. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress
- 15. Managing Scope
- 19. Courtesy of Jeff Patton Increment Iterate Varying Scope to Meet Business Goals
- 20. Agile at Scale
- 21. Different Teams for Different Jobs
- 22. Team Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
- 23. Team Team Product Teams – These teams integrate services and write customer facing features. This is the proto-typical Scrum team. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
- 24. Team Team Team Programs Teams – These teams define requirements, set technical direction, and provide context and coordination. Product Teams – These teams integrate services and write customer facing features. This is the proto-typical Scrum team. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
- 25. Team Team Team Team Portfolio Teams – These teams govern the portfolio and make sure that work is moving through the system. Programs Teams – These teams define requirements, set technical direction, and provide context and coordination. Product Teams – These teams integrate services and write customer facing features. This is the proto-typical Scrum team. Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
- 26. Team Team TeamTeam Team Team Team Team Product & Services Teams
- 27. Team Team TeamTeam Team Team Team Team Product & Services Teams Scrum
- 28. Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams Scrum
- 29. Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams Scrum Kanban
- 30. Team Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban
- 31. Team Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban
- 32. Agile Governance
- 33. Done Develop and Test Ready To Build Detailed Planning Release Targeting Feasibility Study Market Research New Concept Development Flow Feature Complete Integration Testing Develop and Test Story Review Story Mapping Feature Breakdown Story Done Task Done Task In Process Task Ready Story Backlog KANBAN FEATURE STORY EPICS KANBAN SCRUM
- 34. The Portfolio Tier • Idea list generation from multiple data feeds and sources • Market Research • Customer Research • Field Feedback • Business Case & ROI • Competitive Analysis • High Level Estimation • Solution Cost • High Level Architecture • Risk Analysis • Feasibility • Detailed Architecture • Feature Mapping • Acceptance Criteria • Estimation • Backlog • All features are done • Regression tests are completed • Release Criteria are met • Forced Priority • Certainty Curve Done Develop and Test Ready To Build Detailed Planning Release Targeting Feasibility Study Market Research New Concept
- 35. Portfolio Tier Ownership R A C I Product Management Product Management Customer Advocate Portfolio Team R A C I Product Owner Team Product Owner Team Engineering Portfolio Team R A C I Product Owner Team Product Owner Team Engineering Portfolio Team R A C I Engineering Product Owner Team Customer Advocate Portfolio Team Portfolio Team R A C I Product Management Product Management Customer Advocate Product Owner Team R A C I Product Management Product Management Customer Advocate Product Owner Team • Responsible - Those who do the work to achieve the task. • Accountable - The one ultimately answerable for the correct and thorough completion of the deliverable. • Consulted - Those whose opinions are sought, typically subject matter experts; and with whom there is two-way communication. • Informed - Those who are kept up-to-date on progress, often only on completion of the task or deliverable. GATE RESPONSIBLITY Done Develop and Test Ready To Build Detailed Planning Release Targeting Feasibility Study Market Research New Concept
- 36. The Program Tier • Feature List for the Parent Epic • Story Writing • MMF • Estimating • High Level Design • UX Mockups • Estimate Sanity Check • Spike Identification • Review for Feasibility • Review of Acceptance Criteria • Story Spanning • Story Tasking • Feature Testing Non-Functional • Validation of Automated Tests • Detailed Design • Code • Unit Test • Code Review • Functional Test • User Story • Product Owner Acceptance Feature Complete Integration Testing Develop and Test Story Review Story Mapping Feature Breakdown • All Stories are done • Feature Level testing is completed • Defect criteria are met • Feature Check list from RDS template • Performance and Sizing Complete * Stand alone features must have these acceptance criteria (x, x, x)
- 37. Program Tier Ownership • Responsible - Those who do the work to achieve the task. • Accountable - The one ultimately answerable for the correct and thorough completion of the deliverable. • Consulted - Those whose opinions are sought, typically subject matter experts; and with whom there is two-way communication. • Informed - Those who are kept up-to-date on progress, often only on completion of the task or deliverable. R A C I Product Owner Team Product Owner Team Customer Advocate Engineering R A C I Engineering Product Owner Team Product Owner Team Product Owner Team R A C I Engineering Engineering Product Owner Team Product Owner Team R A C I Engineering Engineering Product Owner Team Product Owner Team R A C I Product Owner Team Product Owner Team Engineering Engineering R A C I Product Owner Team Product Owner Team Engineering Portfolio Product Owner Team GATE RESPONSIBLITY Engineering Team GATE RESPONSIBLITY Engineering Team GATE RESPONSIBLITY Product Owner Team GATE RESPONSIBLITY Feature Complete Integration Testing Develop and Test Story Review Story Mapping Feature Breakdown
- 38. The Project Tier Story Done Task Done Task In Process Task Ready Story Backlog • Story List for the Parent Feature • Approved task of 8 hours or less • SCRUM team completes the task • Task is done and communicated in the standup Documented •The User Story •Acceptance Criteria •Conversations •Level of Value •Level of Effort •Design Assumptions •Design Documented (optional) •UI Documented (optional) Coded •Checked Into integrated build •Simple Design •Documented with Comments •Automated Tests for New Features Tested •Testing is complete •Defect Criteria Met •Automated Testing Passed Approved •Feature Complete (Scrum Master) •Test Complete (QA Lead) •Accepted (Product Owner) * Stand alone stories must have these acceptance criteria (x, x, x)
- 39. Project Tier Ownership • Responsible - Those who do the work to achieve the task. • Accountable - The one ultimately answerable for the correct and thorough completion of the deliverable. • Consulted - Those whose opinions are sought, typically subject matter experts; and with whom there is two-way communication. • Informed - Those who are kept up-to-date on progress, often only on completion of the task or deliverable. R A C I Product Owner Product Owner Customer Advocate Engineering R A C I Engineering Engineering Engineering Engineering R A C I Engineering Engineering Engineering Engineering R A C I Engineering Product Owner Engineering Engineering R A C I Engineering Engineering Engineering Engineering Story Done Task Done Task In Process Task Ready Story Backlog
- 40. Why is it hard?
- 41. Its hard when… We show what it looks like But Not How organizations will get there safely
- 42. Safety • Successfully do your job • Feed your family / Kids in college • Viable over time
- 43. You have to align various perspectives Executive Management Performer
- 44. Safety is different depending on your perspective Executive Management Performer • Supported • Possible • Demonstrate success
- 45. Safety is different depending on your perspective Executive Management Performer • Supported • Possible • Demonstrate success • Role clarity • Success is measurable • Maintain organizational influence
- 46. Safety is different depending on your perspective Executive Management Performer • Supported • Possible • Demonstrate success • Role clarity • Success is measurable • Maintain organizational influence • Operational model aligned with the strategy • Credible plan • Demonstrate progress
- 48. Understand Business Drivers Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture •Predictability •Economics •Early ROI
- 49. Define the Operational Framework Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture • Built around teams • Product focused • Service oriented Change Management & Communication
- 50. Define the Operational Framework Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture • Portfolio • Program • Project
- 51. Define the Operational Framework Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture • Return on Investment • Throughput/Cost of Delay • Capitalization
- 52. Introduce Change Incrementally Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture • Independent • Small • Entrepreneurial
- 53. Introduce Change Incrementally Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture • Product definition • Project management • Technical and delivery
- 54. Introduce Change Incrementally Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture • Trust • Accountability • Adaptability
- 55. Measure Improvement Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture • Capability focused • Objectively assessed • Focus on sustainability
- 56. Measure Improvement Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture • Training • Workshops • Mentoring
- 57. Measure Improvement Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture • Demonstrable progress • Outcomes focused • Map to business drivers
- 58. Manage Change Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture •Quick wins •Identify champions •Centers of excellence
- 59. Tie Back To Business Drivers Change Management & Communication Structure GovernanceMetrics Assessment Targeted Coaching Measure Improvement Form Teams Teach Practices Guide Culture •Predictability •Quality •Early ROI
- 60. Slicing
- 61. Team Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban
- 62. Team Team Team Team Team Team Team Team Team Team Team Team Product & Services Teams Program Teams Portfolio Teams Scrum Kanban Kanban Agile Pilot
- 64. Intentionally Executive Management Performer • Supported • Possible • Demonstrate success • Role clarity • Success is measurable • Maintain organizational influence • Operational model aligned with the strategy • Credible plan • Demonstrate progress
- 65. Questions?
Hinweis der Redaktion
- Last but not least we have a product owner. They are the interface between the team and the business. They are the single wringable neck and responsible for the business outcomes of the product. They define requirements, set the priorities, and otherwise help the team converge on the best possible outcome to meet the business objectives. Agile teams have all these roles in some form or fashion… they are self contained and independent. This kind of team is the backdrop to almost everything you read about adopting agile. This is such an important concept because if this isn't’ the kind of team you are building as you adopt agile… some of the things you are learning about just aren’t going to work.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. Â We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. Â You might think of this as rolling wave planning or progressive elaboration. Â The idea is that we plan based on what we know, and plan more as we learn more. Â
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. Â We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. Â You might think of this as rolling wave planning or progressive elaboration. Â The idea is that we plan based on what we know, and plan more as we learn more. Â
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. Â We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. Â You might think of this as rolling wave planning or progressive elaboration. Â The idea is that we plan based on what we know, and plan more as we learn more. Â
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. Â We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. Â You might think of this as rolling wave planning or progressive elaboration. Â The idea is that we plan based on what we know, and plan more as we learn more. Â