Agile Tour Brussels 2014 - Empirical Management Explored
•
5 likes•1,360 views
The document discusses evidence-based management of software development using Scrum. It covers the history and evolution of Scrum over two decades from resolving complexity to expressing agile principles. It discusses debates around whether agile has failed or is the future. It explores challenges in scaling Scrum and emphasizes starting with optimizing individual Scrum teams before scaling. It outlines using Scrum to change enterprises by facilitating concurrent development across domains to optimize value and software development.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to Agile Tour Brussels 2014 - Empirical Management Explored
Similar to Agile Tour Brussels 2014 - Empirical Management Explored (20)
More from Gunther Verheyen
More from Gunther Verheyen (15)
Recently uploaded
Recently uploaded (20)
Agile Tour Brussels 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 EPHEC October 31, 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. © 1993-2014 Scrum.org, All Rights Reserved 3 "If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. -Steve Jobs Two Decades of Scrum 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. 2 MIN What is the state of agile and Scrum in your region, business or organization? © 1993-2014 Scrum.org, All Rights Reserved 6 The State of Agile (2014)
- 7. Fascinating opinions exist on the state of agile and software development © 1993-2014 Scrum.org, All Rights Reserved 7
- 8. © 1993-2014 Scrum.org, All Rights Reserved 8 Agile Is Dead “[Agile] has been greatly abetted by the legions of Agile consultants. By stressing the practices, they have corrupted what Agile was about.” http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698
- 9. © 1993-2014 Scrum.org, All Rights Reserved 9 Agile Is Not Dead “Fact is, most teams are doing Scrum wrong; plenty of people misapply Kanban; and most organizations have no idea how to introduce Management 3.0 practices. But that’s nothing new.” http://www.noop.nl/2014/06/agile-is-not-dead.html
- 10. © 1993-2014 Scrum.org, All Rights Reserved 10 Agile Has Failed “The original agile manifesto was very much about self organizing teams, it would be great if we could get back to that. In the meantime, the word ‘agile’ has become so abused, that we should stop using it.” http://java.dzone.com/articles/coconut-headphones-why-agile
- 11. © 1993-2014 Scrum.org, All Rights Reserved 11 Agile Is The Future “The Agile Manifesto was written to express shared values of people who saw a new way of developing software. […] many in our industry will continue to build better and better software based on these values.” http://kenschwaber.wordpress.com/2013/06/11/agile-fad/
- 12. 2 MIN Who is using or works in an organization that is using: • eXtreme Programming? • Scrum? • Lean (software development)? • DevOps? • SAFe? • DAD? • A custom agile process? © 1993-2014 Scrum.org, All Rights Reserved 12 What Processes Do You Apply?
- 13. A Craze During the First Decade of Agile? (2002-2014) scrum·pede © 1993-2014 Scrum.org, All Rights Reserved 13 /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 to scaling Scrum (or something that looks like it) because they need more software, now. Inspired by © Tomasz Włodarek.
- 14. © 1993-2014 Scrum.org, All Rights Reserved 14 Scrum. Ultimately.
- 15. People employ empiricism to optimize the value of their work. © 1993-2014 Scrum.org, All Rights Reserved 15 The Scrum Stance
- 16. © 1993-2014 Scrum.org, All Rights Reserved 16 If a problem cannot be solved, enlarge it. - Dwight D. Eisenhower Scrum@Scale Empirical Management Explored
- 17. 2 MIN A Compelling Desire to Scale? What challenges do you and your organization encounter when ‘scaling © 1993-2014 Scrum.org, All Rights Reserved 17 Scrum’?
- 18. © 1993-2014 Scrum.org, All Rights Reserved 18 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?
- 19. What if we would start with Scrum before attempting to ‘scale’ it? © 1993-2014 Scrum.org, All Rights Reserved 19
- 20. © 1993-2014 Scrum.org, All Rights Reserved 20 Starting With Scrum
- 21. © 1993-2014 Scrum.org, All Rights Reserved 21 Yes, We Do Scrum. And… Not Scrum Scrum High Benefits “ScrumAnd”
- 22. © 1993-2014 Scrum.org, All Rights Reserved 22 Yes, We Have A Product Owner. And… Product Owner role Expected benefits Yes, And… Not Scrum analyst proxy business mandate mini-CEO
- 23. © 1993-2014 Scrum.org, All Rights Reserved 23 Yes, We Have A Definition Of Done. And… Expected benefits Yes, And… Not Scrum Done Work Develop Test Integrate QA Release
- 24. © 1993-2014 Scrum.org, All Rights Reserved 24 Yes, We Are A Team. And… Expected benefits Yes, And… Team Collaboration Not formed storming co-operative committed collaborative Scrum
- 25. © 1993-2014 Scrum.org, All Rights Reserved 25 So Many Options to Maximize Scrum • Team effectiveness through collaboration, autonomy & self-organization • Skills (training) • Engineering practices & standards • Infrastructure, tooling & automation • Quality standards & guidelines • Elimination of low value • A definition of Done that reflects releasable
- 26. © 1993-2014 Scrum.org, All Rights Reserved 26 Serial Scrum is THE (only) Foundation to Scale
- 27. © 1993-2014 Scrum.org, All Rights Reserved 27 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.
- 28. © 1993-2014 Scrum.org, All Rights Reserved 28 Yes, You Can Integrate Multiple Products 1. Product Backlogs are aligned by the Product Owners. 2. A Team-of- Teams can consistently serve other teams. (Product Owner Team)
- 29. Choose wisely where to invest in first: © 1993-2014 Scrum.org, All Rights Reserved 29 – Dysfunctional Scrum – Maximizing Scrum – Scaling Scrum
- 30. © 1993-2014 Scrum.org, All Rights Reserved 30 But still… Delighting Customers? Are you looking to increase output, or optimize the value of your output?
- 31. © 1993-2014 Scrum.org, All Rights Reserved 31 Scrum Teams manage themselves. You don’t manage them. You set goals. -Ken Schwaber The Enterprise and Scrum Empirical Management Explored
- 32. © 1993-2014 Scrum.org, All Rights Reserved 32 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 }
- 33. © 1993-2014 Scrum.org, All Rights Reserved 33 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 }
- 34. © 1993-2014 Scrum.org, All Rights Reserved 34 Remember? “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” How is that for a purpose?
- 35. © 1993-2014 Scrum.org, All Rights Reserved 35 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
- 36. When rolling out agile, remember: – Agility can’t be planned – Agility can’t be dictated – Agility has no end state © 1993-2014 Scrum.org, All Rights Reserved 36
- 37. Revenue per Employee Employee Satisfaction Customer Satisfaction © 1993-2014 Scrum.org, All Rights Reserved 37 Start with Value 1. Direct Value Key Value Areas 3. Ability to innovate 2. Time to Market Release Frequency Release Stabilization Cycle Time Installed Version Index Usage Index Innovation Rate Defect Density
- 38. © 1993-2014 Scrum.org, All Rights Reserved 38 Add the Scrum Stance • Transparently inspect the value of software – Measured on the outcome of the work • To adapt how the work is done – By facilitating change to the organization, the environment, the teams
- 39. Secondary Evidence © 1993-2014 Scrum.org, All Rights Reserved 39 Scrum To Change The Enterprise Measure Facilitate Change • Skills, Knowledge, Understanding Product managers Managers Developers • Practices, Tools, Standards Primary Evidence
- 40. © 1993-2014 Scrum.org, All Rights Reserved 40 Domains to Reflect Accountability of Change 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
- 41. © 1993-2014 Scrum.org, All Rights Reserved 41 Concurrent Development of Change
- 42. Empirical Management – Implements the Scrum Stance – Optimizes Software Value – Employs Primary Evidence © 1993-2014 Scrum.org, All Rights Reserved 42 A Lasting Transformation
- 43. © 1993-2014 Scrum.org, All Rights Reserved 43 Or Try This Great Alternative Approach
- 44. © 1993-2014 Scrum.org, All Rights Reserved 44 Closing Empirical Management Explored
- 45. “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 45
- 46. © 1993-2014 Scrum.org, All Rights Reserved 46 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
- 47. © 1993-2014 Scrum.org, All Rights Reserved 47 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
- 48. © 1993-2014 Scrum.org, All Rights Reserved 48 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 put value at its heart; to be preferred over old, industrial parameters like scope, budget, time. Informed management decisions to maximize value cannot be made without collecting evidence of it. Such evidence is primarily found in the outcome of the work. Enter the need of evidence-based decision-making. Evidence thereby becomes the primary source for inspections, which connects to the application of the Scrum Stance in the managerial domain. Enter a new management culture, Empirical Management. Gunther is director of the Professional Series at Scrum.org and a partner of Ken Schwaber. Extended Abstract Scrum has been around for almost 2 decades. During the first decade of agile, the adoption of agile and Scrum have 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. This can be achieved by applying the Scrum Stance in the managerial domain, hence 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.
- Note: 2012-2014: the rise of ‘cargo cult’ scaling.
- March 18th, 2014 article.
- 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.
- 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 benefits an organization gets from Scrum largely depend on how the game us played. Yes, you do Scrum if you have a Scrum Team, including a Product Owner, Development Team and Scrum Master. And you will do even better when the team really collaborates: A team gets formed to start. It’s merely bringing a group of people together. Most are in observing mode. Formal arrangements and agreements get made, possibly including team agreements, engineering standards, a definition of Done, team values, meeting timings. A team goes through some storms as they get to know each other. They build a sense of trust. The group of people keeps jelling. The whole becomes equal to the sum of the parts. They co-operate, with with each other, align their individual work with the work of the others. The team knows each other, has grown confidence in understanding each other’s remarks, stop taking comments personally. They develop shared goals and show commitment to the team and these shared objectives. Individual benefits are being sacrificed for the good of the whole. The team has become a unit. Focus is on the whole. They have passionate debates, engage on opposing ideas, look for the best possible outcome and are proud to be part of the group.
- 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/.