BT

Evidence-Based Managing of Software Development

| by Ben Linders Follow 29 Followers on Jan 29, 2015. Estimated reading time: 7 minutes |

If organizations want to make informed management decisions to maximize the delivered value they will need to gather evidence about value as Gunther Verheyen explained in his talk about evidence based management at the OOP 2015 conference in Munich, Germany.

InfoQ interviewed Gunther about evidence based software management and finding evidence, how Scrum relates to evidence-based managing, challenges in scaling agile, and advice for enterprises that want to adopt Scrum.

InfoQ: Can you explain what you mean with evidence-based managing of software development?

Gunther: With the term “evidence-based managing” we refer to the (mal)practice of basing management decisions purely on guesses, assumptions, hierarchy, gut feel, seniority, and other opaque and subjective factors.

Our society is becoming increasingly dependent on software products and services. Software development delivers products that are often critical, to society, and for the survival of its producing organizations. The act of managing such critical activity should not only thrive on these elements alone.

The act of managing software (I prefer the activity over the role or title) should rely on more profound insights. Hence the practice of using ‘evidence’ for managerial decisions over software. The use of such evidence does not rule out experimentation, intuition and experience, but rather complements and completes it.

InfoQ: Can you give some examples of ‘evidence,’ where to find it and specifically in a context of software development?

Gunther: In evidence-based managing of software, ‘evidence’ should primarily reflect the impact an organization’s software is having on its market, with its users, against its competitors. It should reflect the value the software brings to the organization, to the organization’s ecosystem. Evidence of the value of software is collected on the outcome of development.

In the wonderful but highly complex and diverse world of software development there is obviously no such thing as universally applicable ‘evidence’, in the scientific sense. It is however possible to collect and measure indicators of the value of software. Unfortunately most organizations are overly focused on how the software is being produced, not on the outcome. In terms of value of software, such evidence is of secondary importance. It serves internal organizational purposes only, with little meaning over the outcome.

InfoQ: Can you elaborate on primary and secondary evidence?

Gunther: Absolutely. Allow me to elaborate on the primary evidence of value first. It is most important to know whether value is actually being created and how much value.

However, the current value of software in itself might be high, but holds no guarantee that a high value can be sustained, nor that new (high) value can be discovered. So, complementary primary evidence of value adds indicators of market releases and an organization’s ability to innovate.

Many management decisions are still oriented toward the internal operations and processes of the software development organization, indicators of secondary importance without setting them out against the purpose of improving the actual value of software. Such secondary evidence in general reflects how well teams are performing, in terms of volume of software produced, how well they adhere to the organization’s defined process, etc.

InfoQ: We know Scrum as being applied by many software teams. But how does it relate to evidence-based managing of software?

Gunther: Scrum is indeed a framework for complex product development, and brings empirical process control to software development. However, the empirical foundation of Scrum can be similarly applied in the way the product development organization is being managed.

‘Empirical management’ brings the core stance of Scrum, people employing empiricism to optimize the value of their work, to managers. Empirical management, like empirical product development thrives on inspection and adaptation, feedback loops, iterative-incremental progress and validated learning.

Evidence-based management is a core practice of empirical management. Evidence of value is the primary source for inspection, bringing transparency over the value of software. Scrum.org has defined 11 tangible measurements that, combined, give an indication of current value, time to market and ability to innovate.

Managerial decisions over the creation of the software, the selected process and practices, can then be made against the assumption of improving the value. Assumptions obviously need to be frequently validated, hence the need for regular updates of evidence, the detection of patterns, and the correlation with the adoption of process and practices as reflected in secondary evidence.

Empirical management offers a way out of predictive management. Empirical management thrives not on predictions, and long-term detailed plans, but on frequent inspection and adaptation. It allows organizations a validated way of continuous adaptation, business agility.

InfoQ: Scaling agile seems hotter than ever before. How would you relate empirical management with the desire of companies to scale agile?

Gunther: Many organizations are indeed under gigantic pressure, either through the market, either by their shareholders, to deliver more software, faster. That in turn becomes the main driver for scaling efforts or programs.

Empirical management is a splendid way to guide such efforts. It provides a better purpose to scaling efforts, i.e. optimize and maximize over blindly increasing volume. But it also provides the means to measure and to direct the scaling efforts.

InfoQ: Which challenges have you seen in organizations that try to scale agile?

Gunther: Many organizations have adopted Scrum to be agile in their software development, but fail to use Scrum to grow Scrum. The pressure is so high that entire development organizations are turned around toward agile development with Scrum at a pace that is not feasible.

The challenge of most organizations that want to become agile and subsequently scale agile is to understand agile first, and subsequently become agile by being agile.

An important aspect of agile is emergent, concurrent development, performed in short iterations. A scaling effort towards increased agility should thrive on those principles. Agility cannot be planned, nor dictated. And agility has no formal end-state. Agility is achieved through continuous adaptation.

InfoQ: You stated that professional Scrum is the only foundation to scale. Can you explain this?

Gunther: Ha. Here’s another challenge for many organizations. How can you improve your implementation of Scrum so it transcends the initial mechanical way of doing Scrum?

Every organization, every team starts by implementing the rules and roles of Scrum. They have the roles in place, organize the meetings, and follow the process. Yet, the creation of releasable software in a Sprint of 1 or a couple of weeks remains extremely difficult.
We refer to ‘Professional Scrum’ as an implementation of Scrum that not only formally implements the Scrum process, but does so through the lens of the values and principles expressed in the Manifesto for Agile Software Development, building on the empirical foundation of Scrum and including room for and facilitating technical excellence.

We have found Professional Scrum to be extremely important with regards to a Scrum Team’s ability to create releasable Increments of software, Sprint after Sprint after Sprint.

If one Scrum Team is unable to produce releasable software in a Sprint of 30 days, or less, let alone on a daily base, how would multiple Scrum Teams working on the same product be able to do so?

Therefore we state that “Professional Scrum is THE (only) foundation to scale.”

InfoQ: Which advice do you want to give to enterprises that want to adopt Scrum?

Gunther: Maximize Scrum first in order to grow to Professional Scrum.

Facilitate existing teams with better and more means to create better software. The means to maximize Scrum first are countless. They relate to how the roles are implemented, how product management is involved, which engineering practices and infrastructure is in place, the stability of teams and many other aspects of working in teams. Use the intelligence, knowledge and creativity of your teams. Facilitate bottom-up knowledge creation with guidance, vision, objectives, and evidence.

Invest in professional Scrum, the Scrum framework implemented from its values and principles, and with a strong emphasis on technical excellence. If you then need to add teams, you can do so on a solid foundation. It allows increasing the benefits created through Scrum through horizontal scaling, without adding complexity, without the need to add roles, or re-introduce phases, hand-overs and layers.

And even if your complete development organization is being transformed toward Scrum, or has transformed, look for those teams that are Professional Scrum, or are most advanced. Allow them to laterally seed other teams with their professionalism.

And if you guide the scaling effort with evidence, the value of the software is maximized, which works a lot better than blindly increasing the volume of software produced.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss
BT