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.
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.”
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.
For: Decision makers, leaders, managers looking to reground themselves in a context of 'agile'.
Typical Elapse Time
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.
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 (email@example.com) 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/.