Crossing the Chasm & Pull-based change interactive workshop handouts
1 like2,032 views
This document outlines principles and practices for an Agile organization, including: 1. Using a "push-pull" model where work is either pushed from central management or pulled by autonomous teams and individuals. 2. Emphasizing frequent feedback loops, collaboration, shared accountability, and team performance over individual goals. 3. Implementing strong engineering practices like continuous integration, automated testing, collective code ownership, and reducing technical debt. 4. Empowering self-organizing teams to manage their own work through daily stand-ups and choosing tasks to pull based on their capacity.
Crossing the Chasm & Pull-based change interactive workshop handouts
- 1. The AgileSparks Way h1p://www.agilesparks.com/agilesparks-‐way
- 2. Enterprise Journey Board ImproveBacklog F H E C A I DecideProspects Recharge G D B Initiate & Plan Kickoff Stabilize J KL M N O Q R Each LOB Pulls Market/Sell the change to LOBs Market/Sell more depth
- 4. Jurgen Appelo -‐ h1p://www.management30.com/product/delegaFon-‐poker/
- 5. Push Pull – applies at several levels… Central Management PMO Change/ Coaching team LOB/Group A Management Team1 Lead Team2 Lead Team3 Lead David Karl Mike Daniel LOB/Group B Management
- 8. 5. Build & Deployment 1. Con&nuous Integra&on – automa&c build running at least nightly 2. All code and ar&facts are versioned using a single scheme 3. Build is trigged automaFcally upon code checked in 4. Automated regression tests run as part of build and give a green/red binary answer (no need for analysis to determine success/failure) 5. Frequent check-‐ins to common branch 6. Build failures are addressed immediately. Repeated build failures trigger a stop the line event 3. Individuals & Interac9ons Feedback Loops 1. All people involved in a work item work on it more or less in the same &me period (Developers, Testers, Func&onal/Product) minimizing the overhead/waste from context switching/recalling past work. 2. All people involved in a work item (even across silos) can collaborate directly with each other without third parFes like team leads in every coordinaFon/communicaFon loop enabling faster decisions and more scalable operaFon. 3. People working together act as a team with shared accountability to end to end delivery thereby decisions are more value than silo-‐ focused 4. Significant aspects of goals and rewards are oriented towards team performance/goals (rather than individual performance) driving collaboraAon not just individualism. 5. Team environment is as collaboraAon friendly as possible 6. Individuals are involved in performance feedback of the people they are working with, to encourage teamwork 4. Engineering Prac9ces 1. There is a clear defini&on of what "Coding Done" means and people are working according to it 2. People are expected to write SOLID/CLEAN code and es&ma&ons reflect it 3. Automa&on coverage is planned and implemented as an integral part of produc&on code implementa&on 4. Defects created as part of new development are fixed as early as possible and in any case before considering that work item as done 5. There is a Test AutomaFon Pyramid strategy guiding AutomaFon coverage decisions (Preference to Unit Tests>>API tests>>UI tests) 6. People are expected to refactor smelly code as part of "Coding Done“ and esFmaFons reflect it 7. FuncFonal Design is specified Test-‐Driven (ATDD/BDD) 8. Sustained or improved code coverage is verified at build Fme using code coverage analysis tools (e.g. Sonar) 9. Team is pro-‐acFvely and methodically improving collecFve ownership 10. All code is reviewed in small batches, gaps are closed within hours 11. People have access to the tools they need to do effecFve SW engineering 12. A prioriAzed backlog of Technical Debt (ugly code, missing tests, etc.) is available and capacity is allocated to reducing it 13. Team maintains a high level of CollecAve ownership -‐ most tasks can be pulled by many members of the team without a major effect on efficiency 14. Technical Code Design is Test-‐Driven (TDD) 15. Regression cycle costs days at most (due to high level of automaAon) 6. Empowered Teams and Individuals 1. Daily planning mee&ngs (a.k.a. Standups) are used by people to manage their day to day work (instead of work scheduled by supervisors and pushed onto them) 2. Autonomy -‐ People have a high degree of control over the project day 2 day execuFon -‐ Choose tasks to pull, where to focus 3. Reason/Intent is communicated as part of every requirement/work item, to increase moFvaFon as well as empower people to do the right thing for the context rather than blindly follow a plan 4. People pull to capacity -‐ by using Team EsFmaFon approaches or just pull to WIP 5. Autonomy -‐ People have a high degree of control over their personal & professional desFny 6. The behavior that is incenFvized (formally and informally) is aligned with lean/agile thinking -‐ Flow, Improvement, Trust, Whole Team, Low WIP, Safe to fail experiments, etc. 7. People work in small teams (not more than 10, ideally around 5-‐7) enabling good communicaFon and direct collaboraFon as well as effecFve meeFngs and interacFon 8. Managers are pro-‐acFvely and methodically seeking ways to improve autonomy of teams and individuals as a way to enable faster decisions as well as higher engagement/moFvaFon 9. People are given opportunity to improve their mastery of areas which interest them 10. People can shape their work environment – technologies, faciliFes, etc. 2. Business Value Driven Development 1. Product owner sees working soTware frequently and uses the feedback to adapt the scope/&meline plan 2. Work items are integra&ve and testable cross-‐cuXng across the architecture if necessary (e.g. User Stories). Done = Deployable and Performant/Secure, enabling real feedback/ learning. 3. Work items are integraFve testable & SMALL -‐ can be delivered in days thereby Fghtening the internal team level feedback loop 4. frequent feedback from stakeholders/users is used to adapt the scope/Fmeline closing a real feedback beyond the product owner. 5. Escaping Defects and other kinds of Failure Demand (Waste) are analyzed using Five Whys or another kind of root cause analysis process in order to determine reasons for missing them earlier in the process. 6. Value is delivered in iteraFve chunks using Minimally Marketable Features (MMFs) thereby achieving business agility – faster Fme to market and keeping more opFons open to what will be delivered aier the current MMFs. 7. Requirements that are Hypothesis are validated Using MVP/MVF in a fast learning loop that includes Beta/Early Access programs or ConAnuous Delivery, in order to enable safe/cheap-‐ to-‐fail experiments about risky but worthy ideas. 8. Feature Usefulness and Successfulness is evaluated as part of the development lifecycle. Learning is applied to improve the feature and future ideas. 9. Frequent Delivery to real users -‐ up to 8 weeks apart 10. ConAnuous Delivery -‐ work items are deployed/acAvated/validated as part of the work life cycle -‐ in a ma`er of hours/days thereby minimizing the work done without feedback that it is in the right direcAon 1. Visualize & Manage the Flow 1. Visualize main Work types (using Kanban Board or similar) to create flow awareness 2. Defini&on of what Done (Working Tested SoTware) means is clear and adhered to (“DoD”) so real flow is measured and so excep&ons drive discussion/improvement. 3. Visualize who is working on what in order to be aware of level of mul& tasking and dependency on specific people. 4. Commitment to finishing work over star&ng new (eventually reaching a WIP level that “feels OK” for the team) to start to “weakly” constrain and improve flow. 5. Use flow diagrams/charts (e.g. CFDs) to provide predictability and insight into flow 6. Visualize and focus on blocked work so major flow efficiency issues are addressed 7. Visualize work that is queued/waiFng between people/workflow states to start raise to awareness reasons for queuing and idenFfy opFons for reducing 8. Awareness of Work Types and Work Items and differences in handling, in order to enable expectaFon sekng with different stakeholders for different needs & allow people to make intelligent flow decisions according to the context 9. Some areas in the flow have local work in process (WIP) limits -‐ leading to lower WIP and cycle Fmes and more explicit opportuniFes to learn from the (lack of) flow 10. Visualize work variability and seek to reduce it (e.g. using Cycle Time Control Charts) so that overall average cycle Fme is improved and there is less uncertainty about velocity/ cycle Fmes enabling more aggressive planning 11. Explicit WIP limit at workflow level -‐ Single workflow full pull – catching more flow problems and driving WIP/cycle Fme even lower. 12. Next is re-‐prioriFzed conFnuously (no commitment in Next)-‐ Deferred Pull decisions (dynamic prioriFzaFon) in order to enable business agility. 13. DefiniFon of what “Ready for work” means is clear and adhered to in order to minimize rework or blocks due to unready work occupying the WIP. 14. Guidelines for how to pull work (selecAon from ‘Next’/prioriAzaAon of WIP) are clear to everyone and adhered to so that most decisions can be decentralized and made faster as well as driving discussion about how to work and resulAng in experiments/ improvements 15. Capacity is allocated to Investment Themes using work in process limits so that it is possible to ensure certain investment in each theme. 7. Improve 1. Regular Lessons Learned events (frequency of no less than every 1-‐4 weeks) with ac&onable outcomes (e.g. Retrospec&ves/Kaizen) 2. People at all levels are highly aware and involved in improvement acFvity 3. AcFonable Improvement Work is visualized and managed using “Stop starFng start finishing” 4. Leaders are aware of the current operaFonal capabiliFes (may require metrics) 5. Leaders have an operaFonal capabiliFes goal 6. Team/Group knows the current process challenge they are targeAng 7. Team/Group knows what obstacles are prevenAng them from overcoming the current process challenge, what is currently being addressed and how 8. Team/Group allocates capacity/Ame slots for improvement work 9. Team/Group uses models to look at their condiAon and suggest experiments Agile Depth Team: Date: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 2 3 4 5 6 7 1
- 9. Further Reading h1p://www.infoq.com/arFcles/open-‐agile-‐adopFon-‐2 h1p://www.slideshare.net/yyeret/leanagile-‐ depth-‐assessment h1p://bit.ly/LKUK13-‐Yuval h1p://www.infoq.com/arFcles/kanban-‐Sandvik-‐IT-‐2 More at h1ps://www.diigo.com/list/yyeret/Lean-‐Agile-‐Change-‐Management & h1p://www.agilesparks.com/learn-‐your-‐own-‐using-‐our-‐resources StarFng w/ Managers Kanban h1p://bit.ly/DARE13-‐Yuval