![Excerpts from a Harvard Business Review article Leaderships Online Labs
- May 2008 by Byron Reeves, Thomas W. Malone, and Tony O’Driscoll
"The organizational and strategic challenges facing players who serve as [online] game leaders are
familiar ones: recruiting, assessing, motivating, rewarding, and retaining talented and culturally diverse
team members; identifying and capitalizing on the organization’s competitive advantage; analyzing
multiple streams of constantly changing and often incomplete data in order to make quick decisions
that have wide-ranging and sometimes long-lasting effects. But these management challenges are
heightened in online games because an organization must be built and sustained with a volunteer
workforce in a fluid and digitally mediated environment.”
g
y
"Put simply, online games can be informal but realistic simulators for contemporary leadership
training… Perhaps the most striking aspect of leadership in online games is the way in which leaders
naturally switch roles, directing others one minute and taking orders the next. Put another way,
leadership in games is a task, not an identity—a state that a player enters and exits rather than a
personal trait that emerges and thereafter defines the individual.”
"Don’t get us wrong: Leadership stars do exist in games. Some guild leaders have successfully led
100-strong teams for a year or more—an eternity in this new medium. As in business, players with
exceptional relationship skills are p
p
p
particularly g
y good at forming effective teams, delegating responsibility,
g
,
g
g
p
y,
and keeping groups motivated and moving forward. However, games do not foster the expectation that
leadership roles last forever. Someone leading a guild today may grow weary of the stress and hand
over the reins after a month or two. The leader of a raid knows that someone else’s skills and
experience may be better suited to commanding the next effort. Even during the frenzied activity of a
raid, the leadership role can be transferred as conditions change or because the person in charge
doesn’t happen to be around when the need for a decision arises. Notably, choices about who will lead
and who will follow are often made organically by the group—frequently because someone volunteers
to take over—not by some higher authority.”
© 2008 - 2013 Leffingwell, LLC.
69
Excerpts from Leaderships Online Labs (cont)
"Nevertheless, our findings reinforced our basic premise that leadership in online games offers a sneak
preview of tomorrow’s business world. In broad terms, that environment can be expected to feature the
fluid workforces, the self-organized and collaborative work activities, and the decentralized,
nonhierarchical leadership that typify games. In more specific terms, we found several distinctive
characteristics of leadership in online games that suggest some of the qualities tomorrow’s business
leaders will need in order to achieve success.”
g
p
people’s backgrounds and natural
g
"Most writing about leader selection and development focuses on p p
talents. Whether leadership ability is inborn or acquired through training, the assumption is that expertise
resides within the individual. Our study provided us with an arrestingly different view: Perhaps the right
environment is what really matters, whoever the leader happens to be. This concept, which as far as we
know is absent from the academic and professional literature about leadership, wasn’t something that we
set out to prove. The notion arose from the experienced gamers on our research team, who were puzzled
by our initial preoccupation with the individual qualities of game leaders. “If you want better leadership,”
they asked, “why not change the game instead of trying to change the leaders?”
So we began to focus on identifying distinctive aspects of online game environments that could improve
p
g
pinpointed at least two p p
properties of g
games that
leadership in business and other real-world settings. We p p
we believe facilitate and enhance leadership: nonmonetary incentives rooted in a virtual game economy;
and hyper-transparency of a wide range of information, including data about individual players’ capabilities
and performance. These two elements—along with the rich mix of text, audio, and visual communication
in games—make it easier for leaders to be effective. Players know exactly what they should be doing and,
to a large degree, have the tools they need to manage themselves. This suggests that organizations can
benefit by selectively “gamifying” their work environments in order to improve the quality of leadership—
not in the future but right away."
© 2008 - 2013 Leffingwell, LLC.
70
35](https://image.slidesharecdn.com/tk-140128094646-phpapp02/85/Scaling-Agile-Up-to-the-Enterprise-and-Staying-Lean-37-320.jpg)
Scaling Agile Up to the Enterprise and Staying Lean
- 1. TK Half‐day Tutorial 6/4/2013 1:00 PM "Scaling Agile Up to the Enterprise and Staying Lean" Presented by: Dean Leffingwell Leffingwell, LLC Brought to you by: 340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com
- 2. Dean Leffingwell Leffingwell, LLC A renowned methodologist, author, coach, entrepreneur, and executive, Dean Leffingwell founded Requisite, Inc., which was acquired by Rational Software. As a vice president at Rational (now part of IBM), Dean’s responsibilities included the Rational Unified Process. As chief methodologist at Rally Software, he worked with large enterprises to achieve the business benefits of agility by helping to define and implement the tooling and practices needed to support large-scale agile development. Dean is the author of Agile Software Requirements, Scaling Software Agility, and Managing Software Requirements. His most recent project is the Scaled Agile Framework (scaledagileframework.com) which describes a comprehensive system for scaling lean and agile practices to the largest software enterprises.
- 3. Scaling Agile Up to the Enterprise and Staying Lean: A Workshop By Dean Leffingwell Agile Development Conference West Las Vegas, Nevada June 2013 © 2008 - 2013 Leffingwell, LLC. All rights reserved. © 2008 - 2013 Leffingwell, LLC. 1 Agenda Scaled Agile Framework Overview Be Lean Be Agile Scale to the Program: The Agile Release Train Scale to the Portfolio: Agile Portfolio Management Scale Leadership S © 2008 - 2013 Leffingwell, LLC. 2 1
- 4. About Dean Leffingwell Founder and CEO Creator: Scaled Agile Framework Fellow: Lean Systems Society Agile Enterprise Coach: ProQuo Inc., Internet ProQuo, Inc identity Senior VP To some of the world’s largest enterprises Rational Software Responsible for Rational Unified Process (RUP) & Promulgation of UML Chief Methodologist Founder/CEO Requisite, Inc. Makers of RequisitePro Rally Software Cofounder/Advisor Founder/CEO Ping Identity, Roving Planet, Silver Creek Systems Rally Systems, Software RELA, Inc. Colorado MEDtech 3 © 2008 - 2013 Leffingwell, LLC. The Scaled Agile Framework® (SAFe) The Scaled Agile Framework is a proven, publicly-facing framework for applying Lean and Agile practices at enterprise scale Synchronizes alignment, collaboration and delivery Well defined in books and now on the web Scales successfully to large numbers of practitioners and teams Core values: Alignment Code Quality Program Execution Transparency © 2008 - 2013 Leffingwell, LLC. 4 2
- 5. Contributors Associate Methodologist Principal Contributors Drew Jemilo Colin O’Neill Alex Yakyma Alan Shalloway Acknowledgements Enterprise Adopters Community © 2008 - 2013 Leffingwell, LLC. 5 © 2008 - 2013 Leffingwell, LLC. 6 3
- 6. Agenda Scaled Agile Framework Overview Be Lean Be Agile Scale to the Program: The Agile Release Train Scale to the Portfolio: Agile Portfolio Management Scale Leadership S 7 © 2008 - 2013 Leffingwell, LLC. Lean Thinking Provides the Tools We Need Respect for People Product Development Flow © 2008 - 2013 Leffingwell, LLC. Kaizen 8 4
- 7. Goal: Speed, Value, Quality Respect for People Product Development Flow All we are doing is looking at the timeline, from the moment the customer gives us an order to the point where we collect the cash. And we are reducing the time line by reducing the non-value added wastes. Kaizen ̶ Taiichi Ohno THE GOAL Sustainably shortest lead time Best quality and value to people and society Most customer delight, lowest cost, high morale, safety We need to figure out a way to deliver software so fast that our customers don’t have time to change their minds. ̶ Mary Poppendieck Most software problems will exhibit themselves as a delay. ̶ Alan Shalloway 9 © 2008 - 2013 Leffingwell, LLC. Respect for People Your customer is whoever consumes your work y Respect for People Product Development Flow Don’t trouble your customers Kaizen Don't force people to do wasteful work Don't overload them Don't make them wait PEOPLE Develop individuals and teams; they build products Empower teams to continuously improve Build partnerships based on trust and mutual respect p g Don't impose wishful thinking Equip them with problem-solving tools Form long-term relationships based on trust © 2008 - 2013 Leffingwell, LLC. 10 5
- 8. Kaizen Steady, small improvements Respect for People Product Development Flow C id ll data, then implement t Consider all d t th i l change rapidly Kaizen Reflect at key milestones to identify and improve shortcomings BECOME RELENTLESS IN: Reflection Continuous improvement as an entreprise value Use tools like retrospectives, root cause analysis, and value stream mapping Protect the knowledge b by P t t th k l d base b developing stable personnel and careful succession systems © 2008 - 2013 Leffingwell, LLC. 11 Foundation: Leadership Respect for People Product Development Flow Develop people. They will develop solutions solutions. Management understands and teaches lean and agile behaviors Kaizen Management is trained in the practices and tools of continuous improvement Lean-Thinking ManagerTeachers Management is trained in M ti t i di lean thinking Bases decisions on this long term philosophy Management takes responsibility for Lean success Teaches employees problem solving and corrective action Managers are expected to see with their own eyes © 2008 - 2013 Leffingwell, LLC. 12 6
- 9. Principles of Product Development Flow 1. Take an economic view Respect for People Product Development Flow 2. 2. Actively manage queues Kaizen 3. Understand and exploit variability 4. Reduce batch sizes 5. Apply WIP constraints 6. Control flow under uncertainty: cadence and synchronization 7. Get feedback as fast as possible Reinertsen, Don. Principles of Product Development Flow 8. Decentralize control 13 © 2008 - 2013 Leffingwell, LLC. PPDF #1 – Take an Economic View Base your decisions on economics Develop an economic framework for decision making Understand the full value chain Sequence jobs for maximum benefit Empower local decision making If you only quantify one thing, quantify the cost of delay Do not consider money already spent Cost f C t of Delay A High Weight First B C Reinertsen, Don. Principles of Product Development Flow © 2008 - 2013 Leffingwell, LLC. 14 7
- 10. PPDF #2 – Actively Manage Queues Email from a client service organization: “Thank you for contacting us. We are experiencing increased volumes and apologize in advance for the delay. Our goal is to contact you within….. Understand Little’s Law Wait time = queue length/processing rate Control queue sizes to control wait times Operating at high levels of utilization increases variability Measure cycle time and queue length with cumulative flow diagrams Reinertsen, Don. Principles of Product Development Flow 15 © 2008 - 2013 Leffingwell, LLC. PPDF #3 – Understand and Exploit Variability Risk-taking is central to value creation in product development We cannot add value without adding variability ddi i bilit VALUE Development variability can increase economic value Buffers trade money and time for variability reduction EPIC Schedule buffers convert uncertain earliness to certain lateness EPIC Managing variability By investing relatively more in beneficial areas and abandoning wasteful ones, the enterprise maximizes economic benefit – Planning and requirements forecasting are exponentially easier in short-term horizons – Research spikes, incremental value delivery and fast feedback are critical Reinertsen, Don. Principles of Product Development Flow © 2008 - 2013 Leffingwell, LLC. 16 8
- 11. PPDF #4 – Reduce Batch Size Small batches go through the system faster, with lower variability Large b t h sizes i L batch i increase variability i bilit High utilization increases variability Severe project slippage is the most likely result Reducing batch i R d i b t h size – Reduces cycle time; faster feedback – Decreases variability and risk Most important batch is the transport (handoff) batch Proximity (co-location) enables small batch sizes Good infrastructure enables small batches (build and test automation, ( , continuous integration, etc) Loose architectural coupling enables small batches Slippage in projects rises exponentially with duration Fig. Source: Poppendieck. Implementing Lean Software Development Reinertsen, Don. Principles of Product Development Flow 17 © 2008 - 2013 Leffingwell, LLC. Exercise – Large Batch Push Batch Push 1. Create groups of five with ten pennies per group. One person is the time keeper. The remaining four people process the pennies. 2. Person by person, flip all pennies one at a time, recording your own results (heads or tails) 3. Pass all pennies at th same ti 3 P ll i t the time to the next person 4. The time keeper records the time from the start of the first flip to the completion of the last flip © 2008 - 2013 Leffingwell, LLC. Timebox: 5 minutes 18 9
- 12. Exercise – Small Batch Pull Small Batch Pull 1. 1 Same four person process 2. Flip each penny one at a time and record your own results 3. Pass each penny as flipped 4. The time keeper records the time from the start of the first flip to the completion of the last flip Timebox: 5 minutes 19 © 2008 - 2013 Leffingwell, LLC. Discussion – Rework A defect is discovered on the third penny at station four. All pennies have the defect. Timebox: 5 minutes The defect was induced at station three, and requires 10 sec. of rework at station three How much rework i required i push vs. pull? H h k is i d in h ll? Push Pull 1 2 3 © 2008 - 2013 Leffingwell, LLC. 4 20 10
- 13. Finding Economic Batch Size Optimum batch size is an example of a “U-Curve optimization” Cost Optimum Batch Size Total Cost Higher transaction costs shift optimum batch size higher Higher holding costs shift it lower Holding Cost Transaction T ti Cost Batch size reduction probably saves 2X what you think! Items per Batch © 2008 - 2013 Leffingwell, LLC. 21 Agenda Scaled Agile Framework Overview Be Lean Be Agile Scale to the Program: The Agile Release Train Scale to the Portfolio: Agile Portfolio Management Scale Leadership S © 2008 - 2013 Leffingwell, LLC. 22 11
- 14. Agile Accelerates Value Delivery Documents Documents Unverified Code Software © 2008 - 2013 Leffingwell, LLC. 23 Accelerating Value Delivery V Value Delivery Early value delivery drives first to market, fast feedback, and profitability Time © 2008 - 2013 Leffingwell, LLC. 24 12
- 15. Exercise – Accelerating Value Delivery Scenario 1 – Serial Delivery Project A Project B Scenario 2 – Parallel Delivery Project C Time Project A j Project B Your team has three projects. Each will take the entire team one month and delivers one unit of value. Plot value delivery curves by doing the projects serially and in p y parallel ( (simultaneously) y) Project C Time – Assume 20% task switching overhead for Value each team member in Scenario 2 Hint: Plot the serial case first Time © 2008 - 2013 Leffingwell, LLC. Timebox: 10 minutes 25 VALUE DELIVERY Makes Money Faster TIME © 2008 - 2013 Leffingwell, LLC. 26 13
- 16. Reduces Risk Deadline Waterfall Risk ? Agile A il Time 27 © 2008 - 2013 Leffingwell, LLC. Avoids the Death March and Burnout Pressure Deadline Peak performance achieved and maintained indefinitely at a sustainable pace Time © 2008 - 2013 Leffingwell, LLC. 28 14
- 17. Delivers Better Fit for Purpose Measure of waterfall customer dissatisfaction agile (adaptive) plan, result waterfall plan, result Time © 2008 - 2013 Leffingwell, LLC. 29 Agile Teams Empowered, self-organizing, self-managing teams with developers, testers, content authority Teams deliver valuable, fully tested software increments every two weeks Teams apply Scrum (and Kanban) project management practices and XP technical practices Teams operate under program vision, system, architecture and UX guidance © 2008 - 2013 Leffingwell, LLC. 30 15
- 18. Agile Teams are Lean Scrum is Founded on Lean SAFe Scrum Cross functional teams Time boxes to limit WIP Sprints provide fast feedback Empowered, Empowered local decision making Colocation reduces batch size and communication overhead XP. Quintessentially Lean? XP Inspired Technical Practices Continuous g Integration TDD and ATDD limit waste and scrap User Stories Small batch sizes Test‐First: TDD ATDD Scalability Required XP Inspired Collective Ownership Agile Analysis Emergent Design Fast feedback: Test first Continuous integration Test automation Collective ownership © 2008 - 2013 Leffingwell, LLC. 31 PPDF #5 – Apply WIP Constraints WIP Constraints force capacity matching and increase flow Apply WIP constraints Force capacity matching Accelerate delivery Timebox Prevent uncontrolled expansion of work Make waiting times predictable Purge lower value projects when WIP is too high Increase efficiency and throughput of remaining work Constrain local WIP pools Constrains global WIP pools Make WIP continuously visible 1) Understand 2) take action It is far easier to start a project than it is to finish one. Reinertsen, Don. Principles of Product Development Flow © 2008 - 2013 Leffingwell, LLC. 32 16
- 19. Exercise – WIP Constraints 1. Above is a software teams visible information radiator 2. How are they doing? How do you know that? 3. What would be the effect of three story WIP constraint on development and test? Today Timebox: 5 minutes © 2008 - 2013 Leffingwell, LLC. 33 Agenda Scaled Agile Framework Overview Be Lean Be Agile Scale to the Program: The Agile Release Train Scale to the Portfolio: Agile Portfolio Management Scale Leadership S © 2008 - 2013 Leffingwell, LLC. 34 17
- 20. Scale to the Program Level An empowered, self-organizing, self-managing team-of-agile teams committed for continuous value delivery Cadence based, synchronized Aligned to a common mission g Fast feedback: fully tested, system-level solutions every 8-12 weeks Common sprint lengths and normalized velocity Face-to-face planning cadence provides development collaboration, alignment, synchronization, evaluation © 2008 - 2013 Leffingwell, LLC. 35 PPDF #6 – Control Flow Under Uncertainty Transforms unpredictable events into p predictable events Synchronization causes multiple events to happen at the same time pp Requires scope or capacity margin Scheduled, periodic resynchronization limits variance to a single time interval Makes waiting times predictable – If you can’t predict delivery, existing programs become “feature magnets” Manages load: When load and utilization become too high, you will p see a sudden and catastrophic reduction in throughput! Regular, system wide integration provides higher fidelity tests and objective assessment Synch events facilitate cross functional tradeoffs of resources, scope Reinertsen, Don. Principles of Product Development Flow © 2008 - 2013 Leffingwell, LLC. 36 18
- 21. Control Variability with Planning Cadence Cadence-based planning timeboxes limit variability to a single interval Max Deviation (3X) Asynchronous planning Max Deviation Cadencebased planning Time © 2008 - 2013 Leffingwell, LLC. 37 The Agile Release Train The ART is the primary mechanism for accelerated value delivery at scale Align teams to a common vision Manage interdependencies amongst teams Provide continuous flow Common training, common language, common schedule Self-organizing, self-managing Repeat until further notice. Project chartering not required. © 2008 - 2013 Leffingwell, LLC. 38 19
- 22. The Agile Release Train Organized around enterprise value streams Delivers Potentially Shippable Increments (PSI) every eight to twelve weeks © 2008 - 2013 Leffingwell, LLC. 39 Rules of the Release Train PSI dates for the solution are fixed Estimating, planning and asset integration coordinated with two-week sprint length, aligned cadence and normalized velocity Fortnightly (every two weeks) system integration and system demo milestones are enforced All “cargo” (code, docs, supplemental) goes on the train The system always runs © 2008 - 2013 Leffingwell, LLC. 40 20
- 23. Every Team Must Be on the Train What do we integrate here? Planned release Waterfall Doesn’t Iterate Doesn t Release docs MRD PRD SRS delay Drop 1 Drop 2 to QA to QA Dev Test drop 1 Test drop 2 Ports, certs Integration can’t work here PSI Actual release Agile Iterates Iterate Iterate Release docs Iterate Iterate Iterate Iterate Ports, certs 41 © 2008 - 2013 Leffingwell, LLC. Cadence Alone is Not Enough Planned system release date …the system is not sprinting ....time spent thinking you are on track……. track System External Release PSI Integrate I t t and slip! Release docs Iterate Iterate Iterate Iterate Iterate Iterate Port and certs PSI External Release Release docs Iterate Iterate Iterate Iterate Iterate Iterate Port and certs External Release PSI Release docs Iterate Iterate Iterate © 2008 - 2013 Leffingwell, LLC. Iterate 42 21
- 24. Synchronize to Assure Delivery Second System PSI or Release PSI System y Iterations Sys 1 Sys 2 Sys 3 Sys 5 Sys 6 Sys 7 Sys 8 External Release PSI Continuous Integration System Team Sys 4 Release docs Iterate Iterate Iterate Iterate Iterate Iterate PSI Ports certs External Release Continuous Integration Dev Teams Release Docs Iterate Iterate Iterate Iterate Iterate Iterate Ports certs PSI Continuous Integration External Release Release Docs Iterate Iterate Iterate Iterate Iterate Iterate Ports certs 43 © 2008 - 2013 Leffingwell, LLC. Develop on Cadence. Deliver on Demand. Scenario A: Release less frequently than cadence Deliver on Demand Major Release Customer preview PSI Customer Upgrade QA-Release to MarketGovernance Firewall Docs and certs Docs and certs PSI Major Release Feature Release PSI PSI PSI PSI Develop on Cadence © 2008 - 2013 Leffingwell, LLC. 44 22
- 25. Release Whenever You Like Scenario B: Release on cadence Scenario C: Release more frequently than cadence 45 © 2008 - 2013 Leffingwell, LLC. PPDF #1 – Take an Economic View Base your decisions on economics Develop an economic framework for decision making Understand the full value chain Sequence jobs for maximum benefit Empower local decision making If you only quantify one thing, quantify the cost of delay Do not consider money already spent Cost f C t of Delay A High Weight First B C Reinertsen, Don. Principles of Product Development Flow © 2008 - 2013 Leffingwell, LLC. 46 23
- 26. Features and the Program Backlog Features are services that fulfill user needs Features are identified, prioritized, estimated, and maintained in the Program Backlog The program backlog is the authority for what gets built by each train © 2008 - 2013 Leffingwell, LLC. 47 PPDF #1 – Take an Economic View: Prioritizing Backlog for Optimal ROI In a flow system, job sequencing is the key to economic outcomes To prioritize based on lean economics, we need to know two things: 1. What is the Cost of Delay (CoD) in delivering value 2. What is the cost to implement the value thing Principle of Product Development Flow E3: If you only quantify one thing, quantify the Cost of Delay. ̶ Reinertsen 2009 © 2008 - 2013 Leffingwell, LLC. 48 24
- 27. CoD Economics: Shortest Job First Cost of Delay When the cost of delay is equal, do the Shortest Job First Shortest Job First A 1x3= B (1 + 3) x 3 = C Time Cost of Delay Longest Job First A 30 10 x 3 = 3 3 10 3 B 39 (10 + 3) x 3 = 3 C C 1 B A Delay Cost Time From “The Principles of Product Development Flow,” by Donald G. Reinertsen. Celeritas Publishing: 2009. Copyright 2009, Donald G. Reinertsen 49 © 2008 - 2013 Leffingwell, LLC. CoD Economics: High Delay Cost First Cost of Delay High Delay Cost First When the effort is equal, do the high CoD job first A B C 3x3= (3 + 3) x 1 = Cost of Delay 6 Time Low Delay Cost First C B A 60 3 3 C (3 + 3) x 10 = 3 B 3x3= 10 3 1 A Delay Cost Time From “The Principles of Product Development Flow,” by Donald G. Reinertsen. Celeritas Publishing: 2009. Copyright 2009, Donald G. Reinertsen © 2008 - 2013 Leffingwell, LLC. 50 25
- 28. CoD Economics: Weighted Shortest Job First Cost of Delay WSJF = Cost of Delay / Effort y A B C 1x3= 3 (1 + 3) x 1 = When nothing is equal, do the Weighted Shortest Job First! High Delay Cost First 4 Cost of Delay Time Low Delay Cost First C A 10 x 3 = (10 + 3) x 10 = 130 10 3 3 1 C B 1 B 10 10 1 0.1 A Delay Cost Time From “The Principles of Product Development Flow,” by Donald G. Reinertsen. Celeritas Publishing: 2009. Copyright 2009, Donald G. Reinertsen © 2008 - 2013 Leffingwell, LLC. 51 Cost of Delay Components Relative value in the eyes of the customer User/ Business Value “They prefer this over that”. Revenue impact on the business? Penalty potential on the business? How User Value Decays Over Time Is there a fixed deadline? Time Value Will they wait for us or move to another solution? What is the effect on customer satisfaction now? Risk Reduction/ Opportunity Enablement (RR|OE) What else does this do for our business? Reduce the risk of this or future delivery? Is there value in the information we will receive? Enable new business opportunities? © 2008 - 2013 Leffingwell, LLC. 52 26
- 29. WSJF Prioritization Matrix Weighted Shortest Job First (WSJF) provides the greatest economic benefit WSJF = User Value + Time Value + RR|OE Value Job Size Scale for each parameter: 1, 2, 3, 5, 8,13, 21 Do one column at a time, start by picking the smallest item and giving it a “1”. (There must be at least one “1” in each column!) Highest WSJF is highest priority 53 © 2008 - 2013 Leffingwell, LLC. Exercise: Prioritizing Program Backlog Take 5 minutes and identify your top 10 personal backlog items As Lean Thinkers we can prioritize our work so that we can achieve the best economic outcomes for our stakeholders Then, Then using the prior page, prioritize three of your personal backlog items using WSJF Notes: 1. Estimate each backlog item one column at a time 2. There must be a “1” in each column: Timebox: 15 minutes © 2008 - 2013 Leffingwell, LLC. 54 27
- 30. PPDF #2 Control Queues for Fast Response Long queues, plus high utilization = unpredictability! Little’s Law: the average wait time equals th average queue l l the length th divided by the average processing time Long queues. Long waits. Slow delivery Backlogs are a form of queue (If items are committed, then it is a queue) Plus: Operating at high levels of utilization increases unpredictability For fast, reliable service: Keep the program backlogs short and uncommitted Limit WIP to keep planned utilizations at 80% or below Reinertsen, Principles of Product Development Flow, 2009. © 2008 - 2013 Leffingwell, LLC. 55 Agenda Scaled Agile Framework Overview Be Lean Be Agile Scale to the Program: The Agile Release Train Scale to the Portfolio: Agile Portfolio Management Scale Leadership S © 2008 - 2013 Leffingwell, LLC. 56 28
- 31. Scale to the Portfolio Lean principles emphasize sustainably fastest value delivery Centralize strategy. Decentralize execution. Local decision making Portfolio vision guides investments in solutions and the enterprise architecture needed to support customer and business needs Business epic kanban system provides visibility and work-inprocess limits to support continuous product development flow Objective metrics support governance and kaizen 57 © 2008 - 2013 Leffingwell, LLC. Lean-Agile Program Portfolio Management SAFe patterns provide a transformation roadmap #1 Centralized control Decentralized decision-making #2 Project overload Continuous value flow #3 Detailed project plans Lightweight business cases #4 Centralized annual planning Decentralized, rolling-wave planning #5 Work Breakdown Structure Agile estimating and planning #6 Project-based funding Agile Release Trains #7 Projects and PMBOK Self-managing teams and programs #8 Waterfall milestones Objective, fact-based measures and milestones Legacy PPM Agile PPM © 2008 - 2013 Leffingwell, LLC. 58 29
- 32. #8 – Decentralize Control Centralize control for decisions that – Are infrequent – Can be applied globally; have significant economies of scale – Age well Decentralize control for all others – Inefficiency of decentralization costs less than the value of faster response time – Local decisions have better local information Control the economic logic behind a decision, not the entire decision – Set the framework, empower others to make the decisions Reinertsen, Don. Principles of Product Development Flow 59 © 2008 - 2013 Leffingwell, LLC. Decentralize Control Investment Themes Kanban Market Feedback Port tfolio Backlog Central Decision Making Strategy Program Backlog Themes Drive Release Train Operating Budgets Program Backlog B Program Backlog Local Decision Making © 2008 - 2013 Leffingwell, LLC. One theme drives cross cutting Epics Value Stream feedback Value Stream feedback Value Stream feedback 60 30
- 33. Agile Program Portfolio Management Agile Program Portfolio Management fulfills key responsibilities Decentralized decisionmaking Continuous value flow Lightweight business cases Decentralized, rollingwave planning Agile estimating and planning Agile Release Trains Agile Program Management Objective, factbased measures and milestones © 2008 - 2013 Leffingwell, LLC. 61 Agenda Scaled Agile Framework Overview Be Lean Be Agile Scale to the Program: The Agile Release Train Scale to the Portfolio: Agile Portfolio Management Scale Leadership S © 2008 - 2013 Leffingwell, LLC. 62 31
- 34. Foundation: Leadership Respect for People Product Development Flow Develop people. They will develop solutions solutions. Management understands and teaches lean and agile behaviors Kaizen Management is trained in the practices and tools of continuous improvement Lean-Thinking ManagerTeachers Management is trained in M ti t i di lean thinking Bases decisions on this long term philosophy Management takes responsibility for Lean success Teaches employees problem solving and corrective action Managers are expected to see with their own eyes © 2008 - 2013 Leffingwell, LLC. 63 On “Managing” Knowledge Workers “Workers are knowledge workers if they are more knowledgeable about the work they perform than their bosses.” Workers themselves are best placed p to make decisions about how to perform their work and how to modify processes to improve how their work is performed. To effectively lead knowledge workers, the workers must be heard and respected Peter Drucker Knowledge workers have to manage themselves. They have to have autonomy. Continuing innovation has to be part of the work, the task and the responsibility of knowledge workers. © 2008 - 2013 Leffingwell, LLC. 64 32
- 35. Leadership Styles The effectiveness of your workers is determined in large part by your personal leadership style Leader as Expert Leader as Conductor Leader as Developer © 2008 - 2013 Leffingwell, LLC. 65 Leader as Developer of People A post-heroic, lean leadership style Change in orientation – Direct report-centric, rather than manager-centric Behaviors – Creates a team jointly responsible for success – Asks “How can each problem be solved in a way that further develops my direct reports’ commitment and capabilities?” – Allows leader to spend more time managing laterally and upward © 2008 - 2013 Leffingwell, LLC. 66 33
- 36. Drive: Surprising Truth About What Motivates Us M P Video Source: http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=youtu.be Book: Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink. 2011 Timebox: 15 minutes 67 © 2008 - 2013 Leffingwell, LLC. Another Perspective on Leadership Quietly read the article “Leadership as a Task, Rather than an Identity Underline any sentences that you find interesting or thought provoking Be ready to share your thoughts Source: Harvard Business Review article "Leadership in Online Labs” Byron Reeves, Thomas W. Malone, and Tony O’Driscoll. 2008. © 2008 - 2013 Leffingwell, LLC. Timebox: 10 minutes 68 34
- 37. Excerpts from a Harvard Business Review article Leaderships Online Labs - May 2008 by Byron Reeves, Thomas W. Malone, and Tony O’Driscoll "The organizational and strategic challenges facing players who serve as [online] game leaders are familiar ones: recruiting, assessing, motivating, rewarding, and retaining talented and culturally diverse team members; identifying and capitalizing on the organization’s competitive advantage; analyzing multiple streams of constantly changing and often incomplete data in order to make quick decisions that have wide-ranging and sometimes long-lasting effects. But these management challenges are heightened in online games because an organization must be built and sustained with a volunteer workforce in a fluid and digitally mediated environment.” g y "Put simply, online games can be informal but realistic simulators for contemporary leadership training… Perhaps the most striking aspect of leadership in online games is the way in which leaders naturally switch roles, directing others one minute and taking orders the next. Put another way, leadership in games is a task, not an identity—a state that a player enters and exits rather than a personal trait that emerges and thereafter defines the individual.” "Don’t get us wrong: Leadership stars do exist in games. Some guild leaders have successfully led 100-strong teams for a year or more—an eternity in this new medium. As in business, players with exceptional relationship skills are p p p particularly g y good at forming effective teams, delegating responsibility, g , g g p y, and keeping groups motivated and moving forward. However, games do not foster the expectation that leadership roles last forever. Someone leading a guild today may grow weary of the stress and hand over the reins after a month or two. The leader of a raid knows that someone else’s skills and experience may be better suited to commanding the next effort. Even during the frenzied activity of a raid, the leadership role can be transferred as conditions change or because the person in charge doesn’t happen to be around when the need for a decision arises. Notably, choices about who will lead and who will follow are often made organically by the group—frequently because someone volunteers to take over—not by some higher authority.” © 2008 - 2013 Leffingwell, LLC. 69 Excerpts from Leaderships Online Labs (cont) "Nevertheless, our findings reinforced our basic premise that leadership in online games offers a sneak preview of tomorrow’s business world. In broad terms, that environment can be expected to feature the fluid workforces, the self-organized and collaborative work activities, and the decentralized, nonhierarchical leadership that typify games. In more specific terms, we found several distinctive characteristics of leadership in online games that suggest some of the qualities tomorrow’s business leaders will need in order to achieve success.” g p people’s backgrounds and natural g "Most writing about leader selection and development focuses on p p talents. Whether leadership ability is inborn or acquired through training, the assumption is that expertise resides within the individual. Our study provided us with an arrestingly different view: Perhaps the right environment is what really matters, whoever the leader happens to be. This concept, which as far as we know is absent from the academic and professional literature about leadership, wasn’t something that we set out to prove. The notion arose from the experienced gamers on our research team, who were puzzled by our initial preoccupation with the individual qualities of game leaders. “If you want better leadership,” they asked, “why not change the game instead of trying to change the leaders?” So we began to focus on identifying distinctive aspects of online game environments that could improve p g pinpointed at least two p p properties of g games that leadership in business and other real-world settings. We p p we believe facilitate and enhance leadership: nonmonetary incentives rooted in a virtual game economy; and hyper-transparency of a wide range of information, including data about individual players’ capabilities and performance. These two elements—along with the rich mix of text, audio, and visual communication in games—make it easier for leaders to be effective. Players know exactly what they should be doing and, to a large degree, have the tools they need to manage themselves. This suggests that organizations can benefit by selectively “gamifying” their work environments in order to improve the quality of leadership— not in the future but right away." © 2008 - 2013 Leffingwell, LLC. 70 35
- 38. Inspire, Inform, Educate Inspire: Expect and challenge management to lead, not follow the Lean|Agile Transformation Form and support a Lean|Agile working group Lean|Agile leadership trainings and workshops Include management Scaled Agile Framework Training and Certification Create and work the transformation backlog Lunch and learns: Principles of Product Development Flow, Reinertsen • Agile Software Requirements, Leffingwell • Implement effective effective, continuous communication plan • Lean Software Development, Poppendieck © 2008 - 2013 Leffingwell, LLC. 71 Conclusion The foundation of Lean is leadership The foundation of SAFe is you © 2008 - 2013 Leffingwell, LLC. 72 36
- 39. Next Steps Browse the framework at scaledagileframework.com Read Agile Software g Requirements Get training, certification, courseware and implementation tools through Scaled Agile Academy Start/accelerate your Lean|Agile transformation now Implement your first Agile Release Train © 2008 - 2013 Leffingwell, LLC. 73 37