Agile Turkey summit 2014 - Empirical Management explored
•
5 likes•3,412 views
One of the core principles of the agile movement was to shift the focus of software development to creating more valuable software, sooner. It can be expected that the managing of software in an agile environment would put value at its heart; over old, industrial parameters like scope, budget, time. Informed management decisions to maximize value cannot be made without collecting evidence of it. Enter the need of evidence-based decision-making, which is a great start in bringing the Scrum Stance to the managerial domain, leading to a new management culture, Empirical Management. Gunther Verheyen uses ‘Evidence-Based Management’ to go into an exploration of empirical management as the best fit for the age of agile. Gunther is director of the Professional Series at Scrum.org and a partner of Ken Schwaber.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Agile Turkey summit 2014 - Empirical Management explored
Similar to Agile Turkey summit 2014 - Empirical Management explored (20)
More from Gunther Verheyen
More from Gunther Verheyen (18)
Recently uploaded
Recently uploaded (20)
Agile Turkey summit 2014 - Empirical Management explored
- 1. Evidence-Based Managing of Software Empirical Management Explored by Scrum.org – Improving the Profession of Software Development Gunther Verheyen Shepherding the Professional Scrum series Scrum.org Istanbul October 24, 2014
- 2. 3 MIN How would you describe your contribution to the wonderful act of software creation? Raise your hand if it is: • Coding • Testing • Architecting • Designing • Analyzing • Documenting • Coaching • Managing © 1993-2014 Scrum.org, All Rights Reserved 2 Short Survey About You Thank you for thinking in terms of activities and (multiple) skills, not titles and positions.
- 3. Two Decades of Scrum (1995-2014) © 1993-2014 Scrum.org, All Rights Reserved 3 Empirical Management Explored
- 4. © 1993-2014 Scrum.org, All Rights Reserved 4 Scrum Resolves Complexity (1995)
- 5. © 1993-2014 Scrum.org, All Rights Reserved 5 Scrum Expresses Agile (2001) • Empowers people • Controls risk (time-boxing) • Enables validated learning • Is goal driven • Thrives on discovery • Delivers Value • A bounded environment for action
- 6. A Craze During the First Decade of Agile? (2002-2014) scrum·pede © 1993-2014 Scrum.org, All Rights Reserved 6 /skrʌmˈpiːd/ 1. Sudden frenzied rush of (panic–stricken) companies to do Scrum because they want to be Agile, too. 2. To flee in a headlong rush back to prescriptive ways of doing things because Scrum is hard work. 3. To massively scale volume because changing the organization and eliminating wasteful activities cannot be done. Inspired by © Tomasz Włodarek.
- 7. 2 MIN What is the state of agile and Scrum in your region, business or organization? © 1993-2014 Scrum.org, All Rights Reserved 7 The State of Agile (2014)
- 8. © 1993-2014 Scrum.org, All Rights Reserved 8 Scrum. Ultimately.
- 9. People employ empiricism to optimize the value of their work. © 1993-2014 Scrum.org, All Rights Reserved 9 The Scrum Stance
- 10. © 1993-2014 Scrum.org, All Rights Reserved 10 If a problem cannot be solved, enlarge it. - Dwight D. Eisenhower Scrum at Large Empirical Management Explored
- 11. © 1993-2014 Scrum.org, All Rights Reserved 11 Observed Scrum Adoption Challenges • Isolated Scrum Teams • Flaccid Scrum: – A lack of engineering standards – A distant customer – The belief in magic • The difficulties of frequent releases • Predictive management Are you scaling Scrum? Or are you scaling dysfunctions?
- 12. What if we would start with Scrum before attempting to ‘scale’ it? © 1993-2014 Scrum.org, All Rights Reserved 12
- 13. © 1993-2014 Scrum.org, All Rights Reserved 13 Starting With Scrum
- 14. © 1993-2014 Scrum.org, All Rights Reserved 14 Yes, We Do Scrum. And… Not Scrum Scrum High Benefits “ScrumAnd”
- 15. © 1993-2014 Scrum.org, All Rights Reserved 15 Yes, We Have A Product Owner. And… Product Owner role Expected benefits Yes, And… Not Scrum analyst proxy business mandate mini-CEO
- 16. © 1993-2014 Scrum.org, All Rights Reserved 16 Yes, We Have A Definition Of Done. And… Expected benefits Yes, And… Not Scrum Done Work Develop Test Integrate QA Release
- 17. © 1993-2014 Scrum.org, All Rights Reserved 17 Maximizing Scrum • Team effectiveness through collaboration, autonomy and self-organization • Skills (training) • Engineering: infrastructure, tooling & automation • Quality standards & guidelines • Elimination of low value • A definition of Done that reflects releasable
- 18. © 1993-2014 Scrum.org, All Rights Reserved 18 Serial Scrum is THE (only) Foundation to Scale
- 19. © 1993-2014 Scrum.org, All Rights Reserved 19 Yes, You Can Add Teams 1. A product has one Product Backlog managed by one Product Owner. 2. Development Teams often align work via a Scrum-of- Scrums.
- 20. © 1993-2014 Scrum.org, All Rights Reserved 20 Yes, You Can Integrate Multiple Products Requirements and expectations are aligned across products by the Product Owners. (Product Owner Team)
- 21. Choose wisely where to invest in first © 1993-2014 Scrum.org, All Rights Reserved 21 – Dysfunctional Scrum – Maximizing Scrum – Scaling Scrum
- 22. © 1993-2014 Scrum.org, All Rights Reserved 22 But still… Delighting Customers? Are you looking to increase output, or optimize the value of your output?
- 23. © 1993-2014 Scrum.org, All Rights Reserved 23 Scrum Teams manage themselves. You don’t manage them. You set goals. -Ken Schwaber The Enterprise and Scrum Empirical Management Explored
- 24. © 1993-2014 Scrum.org, All Rights Reserved 24 How IT Is Typically Managed • IT is a cost center. • Software development is an expense, some of which may be capitalized. • Expenditures are ‘managed’ through projects. Success = f { Planned_Time, Predicted_Scope, Allocated_Budget }
- 25. © 1993-2014 Scrum.org, All Rights Reserved 25 How Scrum Is Typically Used • Scrum is the new methodological flavor for delivery from IT to business. • Delivery is done through projects. But we now measure and compare at the team level, no longer the individual’s level. • The goal is more Scrum, more scope. Success = f { Practices, Velocity, Performance }
- 26. © 1993-2014 Scrum.org, All Rights Reserved 26 Basics: Simplicity and Bottom-up “Scrum promotes bottom-up thinking with top-down support to discover and emerge what works best for you, your organization and your context.” Source: Gunther Verheyen, “Scrum – A Pocket Guide (A Smart Travel Companion)”, 2013
- 27. © 1993-2014 Scrum.org, All Rights Reserved 27 Remember? “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” How is that for a purpose?
- 28. Foundational principles when ‘scaling © 1993-2014 Scrum.org, All Rights Reserved 28 agile’: – Agility can’t be planned – Agility can’t be dictated – Agility has no end state
- 29. © 1993-2014 Scrum.org, All Rights Reserved 29 Start with Value Employing the Scrum Stance in the managerial domain: • Transparently inspect the value of software – By measuring the outcome of the work • To adapt how the work is done – By facilitating change to the organization, the environment, the teams
- 30. © 1993-2014 Scrum.org, All Rights Reserved 30 Scrum To Change The Enterprise Primary Evidence Secondary Evidence Measure Facilitate Change • Skills, Knowledge, Understanding Product managers Managers Developers • Practices, Tools, Standards
- 31. © 1993-2014 Scrum.org, All Rights Reserved 31 Concurrent Development of Change Enterprise Facilitate Change Process Value Productivity Quality Domain Functions Enterprise All domains and business functions Process The effective use of Scrum, Scrum Masters Productivity Software and product development, Development Teams Value Product management, release management, PMO, Product Owners Quality Infrastructure, architecture, tools, standards, conventions, QA
- 32. © 1993-2014 Scrum.org, All Rights Reserved 32 Or Try This Great Alternative Approach
- 33. Empirical Management – Implements the Scrum Stance – Optimizes Software Value – Employs Primary Evidence © 1993-2014 Scrum.org, All Rights Reserved 33 A Lasting Transformation
- 34. © 1993-2014 Scrum.org, All Rights Reserved 34 Closing Empirical Management Explored
- 35. “The future state of Scrum will no longer be called ‘Scrum’. What we now call Scrum will have become the norm, and organizations have re-invented themselves around it.” Source: Gunther Verheyen, “Scrum – A Pocket Guide (A Smart Travel Companion)”, 2013 © 1993-2014 Scrum.org, All Rights Reserved 35
- 36. © 1993-2014 Scrum.org, All Rights Reserved 36 About Gunther Verheyen • eXtreme Programming and Scrum since 2003 • Professional Scrum Trainer • Directing the Professional series at Scrum.org • Co-developing the Scrum@Scale framework at Scrum.org • Author of “Scrum – A Pocket Guide (A Smart Travel Companion)” (2013) Mail gunther.verheyen@scrum.org Twitter@Ullizee Blog http://guntherverheyen.com
- 37. © 1993-2014 Scrum.org, All Rights Reserved 37 Connect with the Scrum.org community Twitter @scrumdotorg LinkedIn LinkedIn.com /company/Scrum.or g Facebook Facebook.com /Scrum.org Forums Scrum.org /Community RSS Scrum.org/RSS
- 38. © 1993-2014 Scrum.org, All Rights Reserved 38 Thank you
Editor's Notes
- Short Abstract One of the core principles of the agile movement was to shift the focus of software development to creating more valuable software, sooner. It can be expected that the managing of software in an agile environment would cnter around value, over old, industrial parameters like scope, budget, time. Informed management decisions to maximize value cannot be made without collecting evidence of it. Enter the need of evidence-based decision-making, which can be achieved through the application of the Scrum Stance in the managerial domain. Gunther Verheyen uses ‘Evidence-Based Management’ to go into an exploration of empirical management as the best fit for the age of agile. Gunther is director of the Professional Series at Scrum.org and a partner of Ken Schwaber. Extended Abstract During the first decade of agile, its adoption has grown incredibly. But the dependence of businesses and society on software has increased even more. Software is eating the world. The survival and prosperity of many people and organizations depend on software. Complexity and unpredictability continue to increase. Yet, many organizations are stuck with old thinking like productivity, performance and blindly pushing more requirements out to the market. The focus of managing has not shifted to optimizing the value that the software brings to the organization. The urgency to do so grows. The agile movement has left the act of managing largely unaddressed or -at least- under-focused. The agile values and spirit are more needed than ever, but it's time to include management in the empirical thinking, and promote empirical management. Gunther Verheyen directs the Professional Series at Scrum.org and is a partner of Ken Schwaber, Scrum co-creator. Gunther and Ken have developed a framework for empirical management based on the principles of Scrum, agile and Evidence-Based Management. EBM has its roots in medical practice. In his presentation Gunther will look at the state of agile through the lens of EBM, and introduce how to apply its principles in a context of software. “If no evidence is collected on the value of software, informed management decisions to maximize it cannot be made. Software development deserves a professional way of managing, a way of managing that is more than mere intuition, opinion and position.” Learning Objectives Inspire by challenging some common understanding of ‘agile’ Participants will be challenged on their understanding of agile, and the purpose of agile at a business and management level. Participants will be challenged to shift their focus from how the development work is done, to the outcome of the work, and its impact on the market. Participants will get an insight into a possible future of agile, the future of agile in its next decade of existence. Audience For: Decision makers, leaders, managers looking to reground themselves in a context of 'agile'. Typical Elapse Time 1 hour
- The Agile movement successfully established a set of values and principles that better fit the creative and complex nature of software development. The focus is on teams, collaboration, people, self-directed discovery. The Scrum framework provides a great foundation for organizations to grasp ‘Agility’. The adoption of the Agile thinking via Scrum represents a major and on-going shift in our industry. Even without Scrum having prescriptions for management, it is clear that the self-organizing fundaments of Scrum have a profound impact on the role, approach and act of managing. The challenge is to discover and implement the new needs and demands for managers.
- Based on „stam·pede„ ( /stʌmˈpiːd/ ): Sudden frenzied rush of (panic–stricken) animals. To flee in a headlong rush. Followed by a rush toward scaling Scrum.
- Note: 2012-2014: the rise of ‘cargo cult’ scaling.
- Scrum, ultimately can only be fully comprehended when its rules and roles are read as an expression of the values and principles of the Manifesto for Agile Software Development. is an operating system for the values and principles of the Manifesto. The kernel of the OS is the Scrum Stance.
- The degree of performance achieved with Scrum, i.e. how well is Scrum being applied: Not Scrum – Teams are doing something they think is Scrum, but it isn’t. They are doing something, and maybe it even works for them, but it isn’t Scrum. Scrum – These teams are often using Scrum, and getting some advantage from it. However, they aren’t seeing the true changes and advantages Scrum offers. These teams are often living the mechanics, and not the values of Scrum. High beneficial Scrum – Scrum Teams in this categorization are the rare beast. They are living the dream, increasing productivity, quality, and value delivered deliberately over time. Scrum Teams in this area live in a broader agile organization, giving very real context to the use of Scrum within the teams.
- The benefits an organization gets from Scrum largely depend on how the game us played. Yes, you do Scrum if you have a Product Owner. And you will do even better when the role is fulfilled by: A (business) Analyst: limited benefits. But control is safe, as it remains with IT. However, for many decisions the analyst doesn’t have the answer, needs to revert to the real business responsible, look at the project manager, wait for an external decision like the steering committee. A proxy for the business: Slightly better. Control remains with IT (‘Can’t trust business people!’) but with a person more connected to the business. Less delays, less waiting time, less hick-ups. A person from the business: Better. Direct availability of functional knowledge and stakeholder expectations. Yet, still much waiting time for decisions by the real authorities. A business person with a mandate: Much better. A person authorized to take decisions on the spot, using the Sprint Review to demonstrate results to stakeholders. A mini-CEO: a business person with full responsibility over the product. They don’t come much better than this.
- The benefits an organization gets from Scrum largely depend on how the game us played. Yes, you do Scrum if you have a definition of Done. And you will do even better when the definition of Done reflects ‘releasable’ ànd that work can be done in the Sprint (not after a Sprint has finished): Development: essential, but hardly enough. Only the start. Without development, no progress as there can’t be working software. Test: all testing is done within the Sprint, requiring testing skills in the Development Team. Testing is needed at a unit and a functional level. It does help additionally if the work can be automated and is done progressively in the Sprint, not just toward the end of the Sprint. Integrate: All integration, regression and alike testing is done in the Sprint, and across multiple teams working on the same product. It does help additionally if the work can be automated and is done progressively in the Sprint, not just toward the end of the Sprint. QA: All organizational guidelines for quality are available and the Development Team has the skills, access and mandate to perform the work in the Sprint. It does help additionally if the work can be automated and is done progressively in the Sprint, not just toward the end of the Sprint. Release: all work to prepare for an actual release (like traditional stabilization work) is performed in the Sprint. It does help additionally if the work can be automated and is done progressively in the Sprint, not just toward the end of the Sprint.
- The simplest situation of doing product development with Scrum is to have one Product Backlog capturing the desirements for that Product, and having one Scrum Team implementing that Product Backlog in Sprints. The Development Team has all skills to turn several Product Backlog items into Done per Sprint upon the definition of Done. The Development Team manages its work in the Sprint Backlog and has a daily inspection to safeguard direction and alignment via the Daily Scrum. The Product Owner provides right-time functional and business clarifications. The Scrum Master coaches, facilitates and serves the team and the organization. The Sprint Review is easily guaranteed to be fully transparent, an important prerequisite to make the empirical approach of Scrum work.
- For larger products, the need to build a product with multiple Scrum Teams will arise. The multiple Scrum Teams build one Product, i.e. work on the same Product Backlog. Each Scrum Team (Product Owner + Development Team + Scrum Master) derives its Sprint Backlog from selected Product Backlog items, does its Sprints and has its Daily Scrum. The need for a transparent ‘inspect’ at the Sprint Review remains. The Increment presented for collaborative inspection should still live up to the definition of Done, i.e. have no undone, hidden work left, and it should represent the complete product that the Multiple Scrum Teams are jointly building. It is expected to be an integrated Increment. To have an integrated Increment by the end of every Sprint implies at least regular communication and information sharing across the multiple Scrum Teams within the Sprint. The Scrum Teams have regular Scrum-of-Scrums meetings besides the Daily Scrum that they have per Scrum Team. In the Scrum-of-Scrums, the best placed Development Team members of the Multiple Scrum Teams gather to exchange integration information, so that each Scrum Team can optimally plan and re-plan its Sprint Backlog. When working as multiple Scrum Teams, the Sprint Backlog of each individual Scrum Team will obviously need to hold integration tasks to live up to the quality expectation of integrated Increments, upon a shared Definition of Done. The multiple Scrum Teams will most likely work upon the same Sprint Length to simplify planning of an integrated Sprint Review. Depending on the number of multiple Scrum Teams, a common Sprint Planning meeting part 1 may be considered, but probably a separate Sprint Planning meeting part 2. They might want to consider to do (part of) the Sprint Retrospective together. What works best for them to build integrated Increments.
- In more complex situations, a mere Scrum-of-Scrums meeting, although being performed, might not be enough to keep the multiple Scrum Teams’ work fully integrated. Maybe there are too much Scrum Teams building the same product. Maybe multiple products are closely connected or technically linked, while each has its own Product Backlog and one Scrum Team or multiple Scrum Teams implementing it. For clear empirical reasons, Increments are expected to be technically complete, no undone work, integrations included. No unknown remaining work should impede the Product Owner in the decision to ship upon the assessment whether the Increment is functionally complete or coherent enough. This situation might reveal the need for a team that doesn’t works as a feature team. A feature team typically is a vertically sliced Development Team having the skills and authorization to work on all components and layers needed to build features that are actually usable by end-users. This specific team does not implement functional desirements from this end-user perspective but has the other Scrum Teams as ‘customer’. Key is that this is a full-time team that performs its work for the other Scrum Teams on a daily base. It is essential that work is not postponed, as it will accumulate and result in unpredictable and uncontrollable efforts. The specific team performs inspections that enable the other Scrum Teams within the Sprints to adapt their Sprint Backlog plan for producing integrated software by the end of each Sprint. A common purpose for such a team is technical integration. An “Integration Team” in this setup regularly collects checked-in code of the multiple Scrum Teams, merges, runs and tests it on specific systems in order to feed back the results to the multiple Scrum Teams. This inspection reveals important development information that needs to be taken care of during the Sprint, not be postponed to some later phase. However, the model is also applicable on highly specialized skills that cannot be injected in every Scrum Team.
- An activity without value. The ideal victim for cost cutting.
- About Gunther Verheyen Gunther Verheyen (gunther.verheyen@scrum.org) is a seasoned Scrum professional. He works for Scrum.org, the home of Scrum. He represents Scrum co-creator Ken Schwaber and Scrum.org in Europe. Gunther ventured into IT and software development after graduating as Industrial Engineer in 1992. His Agile journey started with eXtreme Programming and Scrum in 2003. Years of dedication followed, of working with several teams and organizations, of using Scrum in diverse circumstances. Building on the experience gained, Gunther became the driving force behind some large-scale enterprise transformations. Gunther left consulting to partner with Ken Schwaber, Scrum co-creator, at Scrum.org in 2013. He is Professional Scrum trainer, directs the ‘Professional Scrum’ series and co-created the framework for Evidence-Based Management of Scrum.org. He shepherds classes, trainers, courseware and assessments for the programs of Professional Scrum Foundations (PSF), Professional Scrum Developer (PSD), Professional Scrum Master (PSM), and Professional Scrum Product Owner (PSPO). In 2013 Gunther published his highly appraised book “Scrum – A Pocket Guide,” a ‘smart travel companion’ to Scrum. Gunther lives in Antwerp (Belgium) with his wife Natascha, and their children Ian, Jente and Nienke. Find Gunther on Twitter as @ullizee or read more of his musings on Scrum on his personal blog, http://guntherverheyen.com/tag/scrum/.