BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Evo: The Agile Value Delivery Process, Where ‘Done’ Means Real Value Delivered; Not Code

Evo: The Agile Value Delivery Process, Where ‘Done’ Means Real Value Delivered; Not Code

Bookmarks

 

This article describes what ‘Evo’ is at core, and how it is different from other Agile practices, and why ‘done’ should mean ‘value delivered to stakeholders’.

‘Evo’ (just short for Evolutionary Value Delivery) is openly credited by many Agile Manifesto signers and other Agile experts as the ‘original’ agile method. And we all agree on short delivery cycles.

But the Manifesto, agile variants, and Scrum in particular, still lack a vital component, which Evo has always had. This is the focus on delivering measurable multiple value requirements to stakeholders.

Current agile practices are far too narrowly focused on delivering code to users and customers. There is no systems-wide view of other stakeholders, of databases, and anything else except the code. Agile, today, has no clear management of the qualities of the system, such as security, usability and maintainability: there is a narrow ‘bug’ focus, as the only ‘quality’.

What is Evo?

Our agile method, Evolutionary Value Delivery, ‘Evo’ for short, was used intuitively as a main project management method, by Tom from 1960 (20 steps of value delivery at ‘Brødrene Dobloug’, for Invoicing, in Oslo). The main idea then, and now, was that every step of the project delivered tangible value to stakeholders.

Let us, try to bring out the differences using a set of ‘Evo’ principles. The mechanical detail of Evo is available in our book chapter 1.

The following principles are detailed in a Systems Engineering Conference paper 2

E1: Decompose by performance results and stakeholders;

E2: Do high-risk steps early, learn how ‘unknowns’ really perform;

E3: Focus on improving your most valuable performance objectives first;

E4: Base your early evolution on existing systems and stakeholders;

E5: Design to cost dynamically;

E6: Design to performance dynamically;

E7: Invest in an open-ended architecture early on;

E8: Motivate your team by rewarding results;

E9: Prioritize changes by value, not place in queue;

E10: Learn fast, change fast, adapt to reality fast.

So let me explain each of these principles, briefly (8, if you want details) with particular reference to conventional agile teaching, today.

E1: Decompose by performance results and stakeholders;

Break down the overall architecture and strategies, into small (we like ‘weekly’) value delivery steps, so that each Evo step delivers some value (as specified in the project’s top-ten quantified value objectives 3, see ‘Top Ten’ and ‘111111 method’, 2 papers).

E2: Do high-risk steps early. Learn how ‘unknowns’ really perform;

One possibility is that the even high-risk steps might deliver the best available value, if they succeed. There are two ‘values’ here. The delivered value, if they succeed, and alternatively, the knowledge that they do not deliver value, if they fail; early on!

E3: Focus, on improving your most valuable performance objectives, first;

This principle assumes that we have quantified our critical few value objectives, and that we have tracked numeric progress towards them at each Evo cycle. In general the most valuable things to do at the next step are ‘whatever can close any remaining gaps to your goal level’; for the least amount of remaining resource or budget.

Figure (Source 1): Evo delivery cycles can have useful impact on two or more concurrent high value objectives. Clever architects will think in multiple dimensions at the same time; just like good chess players. Evo steps are similar to a series of chess moves. Winning is reaching all goal levels before resources (chess clock) run out.

E4: Base your early evolution on existing systems and stakeholders;

If you want to get value delivery going early, with real existing stakeholders, you have to make use of the current system (however awful it may be just now) used by those stakeholders. Revolutionary change takes too much time, and fails. You will probably get a more revolutionary result by evolving rapidly and early, from your current-state system. And by focussing on delivering value improvements early, rather than first recreating the functionality of the current system.

E5: Design to cost dynamically;

All architecture level ideas (like buy or build, outsource or do it yourself) need to be validated, tried in practice, with respect to their real costs (money, time, talent); before you have committed to them, and scaled up. If an architecture component fails in value or excessive costs, you need to dump it fast, and find a better idea that really works.

E6: Design to performance dynamically;

The same ‘design to value’ idea, as above, also applies to the management of all performance and quality (the values we want to deliver) aspects. We need to validate, in practice, the multiple, measured impacts of our architectures and strategies on the main values we seek, before scaling up and committing. What does not deliver expected value, needs to be dumped early. More imaginative architects need to find better value delivery architecture, and prove it.

Figure (Source 1): As we organize food supply into a ‘kitchen’ and ‘serving’ part of a restaurant, components that take longer than 1 delivery cycle to construct, can be prepared in the ‘backroom’ (kitchen). And delivered (served) on a later cycle when they are ready for integration.

E7: Invest in an open-ended architecture early on;

You are going to get some disappointments when you try out some architecture ideas at an early stage. You cannot risk a high cost, in time and money, for having to get rid of just-proven bad ideas.

So, your technical and organizational architecture must permit low-cost changes of new and better, unforeseen architecture. This means new suppliers, partners, and technical components. You will, face it, have to deal with this problem in the long term, hint: ‘technical debt’, so you might as well make sure you can change things easily in the short term.

Technical ease-of-change can be engineered into the system. It can be quantified up front, as a critical quality objective 4. It can even be concurrently engineered in, years after it should have been, like Confirmit 4, but why wait?

E8: Motivate your team by rewarding results;

Do not reward, with praise or payment, mere effort, mere work, mere completed code. Tell people: effort is irrelevant! Did they, or did they not deliver measureable, pleasurable, planned results to the stakeholders! Rave about real results. Spotlight the team that delivered them! Pay contractors for value actually delivered, not for work done, hours spent.

E9: Prioritize changes by value, not place in queue;

It does not matter when an idea for change, or improvement, comes up. The decision, as to what to do in the next Evo step, should be based on the value (to cost ratio) of the idea.

One major built-in advantage of Evo is exactly that we can make the best possible agile ‘move’, immediately - even if we just saw the opportunity recently (say, during the last week). We are not tied down to committee-approved decisions from last year. The job of the committee is to pre-approve that the project makes the decisions, which give maximum competitiveness at all times. 5

Figure (Source 1): Evo is merely a specialized variant of the powerful PDSA cycle of Deming/Shewhart (1950 in Deming’s speech to JUSE, http://deming-network.org/deming_1950.htm). The key idea is learning and change. Not by ‘retrospectives’, but using hard measured facts (numeric feedback about real values and costs) each cycle, compared to an initial quantified hypothesis (requirements and budgets). It is called the ‘scientific method’.

E10: Learn fast, change fast, adapt to reality fast.

This above principle is a good summary of the Evo method. Victory is to the swift.

What Should ‘Done’ Mean?

There is a long-standing discussion in Agile circles on the meaning of “Done”. In our view the answers offered are the same levels of immature and narrow thinking that characterize IT in general, and Agile in particular, unfortunately.

The original Agile Manifesto had its heart in the right place. It tried to hint that we ‘preferred’ to deliver value to customers early and iteratively! Wonderful, except, most Agile teachers, gurus, coaches and practitioners do not seem to know what ‘value’ really means (hint, it does not mean bug free code, functions, or stories, or use cases). And the terms ‘customer’ and ‘user’ are far too narrow to encompass the larger set of project and system stakeholders, which we are in fact responsible for.

Let us define the concept of stakeholder value, since so many Agilistas seem to think it is the same as delivering ‘code’, use cases, and functions to users. It is not. We will then make the following assertion about the idea of ‘Done’.

Done’ (for agile projects) should mean:

“no more value can be profitably delivered to stakeholders with currently available resources”.

So what is this ‘value’ concept really about?

Here is our formal definition of value, from Competitive Engineering 6

Value is perceived benefit: that is, the benefit we think we will get from something.

Value Concept in More Depth

  1. Value is the potential consequence of system attributes, for one or more stakeholders.
  2. Value is not linearly related to a system improvement costs: for example, a small change in an attribute level could add immense perceived value for one group of stakeholders for relatively low cost.
  3. Value is the ‘perceived usefulness, worth, utility, or importance’ of a defined system component or system state, for defined stakeholders, under specified conditions.

An IT system has a set of basic ‘business’ functions, defined as ‘what it does’. These functions tend to exist, and to have existed for a long time, for the organization, or business, independently of the IT system. A bank lends money, and charges interest. A shop takes orders and expedites goods. The reason we build IT systems at all, is NOT to deliver that basic functionality. We do have, unfortunately, sometimes – a necessary evil in IT - to replicate the functionality, to begin serve the business or organization at all.

So business functions. or organizational functions, have no incremental value for a stakeholder. Nothing ‘improves’. It is not worth any investment.

They already have it, before the IT system. Banks traded before IT! Movies sold tickets before IT!

There are other system attributes we want, when we make IT systems. These are called (in systems engineering) ‘performance attributes’. They include all the quality attributes (how well the system performs, ‘-ilities’). We can safely assert that the only reason or justification for any IT system, the only stakeholder values of IT, are to be found in the improved performance characteristics of the system. How fast, how much, how well, how costly. This obvious point seems to have escaped IT coder’s attention 8, goes into detail on multiple values.

Some of our coder’s (they once tried to crown themselves as software engineers; now just ‘devs’) are confused conceptually. They think everything they code is a function. But there are in fact two distinct things we program:

  • Functionality: what the system does
  • Technical Solutions (aka design, architecture): which result in specific performance levels.

For example we might code an encryption, to get better security performance; we might design and program a user interface, to get usability; we might write tighter code to increase responsiveness; and we might ‘reduce technical debt’ to improve maintainability or portability.

So, some of the code, the code that is intended to implement a design, which is intended to result in specific performance improvements, will result in value to some stakeholders, like faster, safer, easier, cheaper.

It is not sufficient to simply credit the code itself, for value, of a design that intends to deliver value (improved performance attributes, such as security, to stakeholders).

Value depends on far more than code: it depends on particular users and other stakeholders. Value depends on the environment, economy, competition and politics. Value can be delivered in IT systems with no change of code at all, by for example teaching, motivation, and better databases.

This is the fallacy we have with burn-down charts, or with Scrum sprint velocity of coding alone. We have to be able to quantify and measure, in the real world, the effect that this well-intended code and design has had in practice. In its total real current system environment.

Did your project really improve required levels of (for example) security, usability, and maintainability, or reduce operational costs in the business? If not, it has no real stakeholder value. And this is not necessarily the fault of the designer or the coder.

The consequences of this idea of ‘total systems thinking about stakeholder value’ are:

  1. Designers (IT Architects) need to consider, and try to manage, all factors that determine real value generation.
  2. This means they cannot be software engineers alone, they, or someone else must in fact be a systems engineer, or systems architect. Code alone does not give sufficient control over value actually delivered.
  3. The primary method of delivering any value must be the systems architecture, and follow-up measures of its effects. Programmers cannot do much more than be good sub-suppliers of one of many necessary components of the system.

So, to conclude:

We software/IT people need to acknowledge that we are not done, until our software component’s attributes have successfully helped the system to deliver the stakeholder values that the software was intended to contribute to?

We need to get a lot more professional at consciously defining the necessary software attributes themselves (like security, usability, maintainability), at design engineering the attributes into the software, and at measuring in test, that we have succeeded in our own software component’s performance attributes. We are light-years away from having this software culture.

But even this capability, to really engineer reliability, security, usability, maintainability etc. into our software is just one necessary stage in delivering the results to stakeholders that they expect from computer technology; like productivity, cost savings, useful knowledge systems.

We as software ‘engineers’, need to learn to partner with the overall systems engineering effort to supply complete systems. There are serious efforts and practices in this direction (INCOSE.org, 7) but agile software culture does not know about this, care about this, or even try reject it explicitly. Unfortunately some areas where agile is being used or explored, and where we work, such as military, health systems, electronics, aviation, and banking are quite serious systems, and they need more serious engineering approaches than the agile community has ever tried to offer.

‘Agile Systems Engineering’, anyone? 9

Iteration, feedback and change (fundamental agile ideas) are powerful concepts for managing software and systems, but right now they are flying blind regarding systematic delivery of software value, which drives systems and stakeholder values. The change is not going to happen through intelligent leadership from programmers. We need intelligent technical management to step up and demand far more from software development.

Summary

Evolutionary project management, ‘Evo’, is based on some fundamental concepts:

  • Do some useful improvements for your stakeholders, early and frequently;
  • Learn from real user measurable systems experience, what really works and what does not;
  • Quantify your critical stakeholder objectives; no BS.
  • Estimate numeric impacts of design ideas on your requirements;
  • Measure the value and cost effects of each Evo value delivery step;
  • Prioritize delivering ‘highest available values for resources-used’ at every step;
  • Don’t plan too far in advance – you have long-term objectives, but you need to consistently react to short-term realities in order to meet long-term objectives. Like in football, tennis, golf, and chess.

Done should mean value delivered to stakeholders. We are not ‘done’ until we are considered ‘great’, in at least 95% of projects, at delivering real expected value to stakeholders. Today, IT with Agile, and even without Agile, are not even close to this ambition. Jeff Sutherland, Agile Warsaw 2013, claimed projects trying to use Scrum only failed 19% of the time! Something is still wrong!

References

  1. Evo Chapter. Free download from CE book 7 Chapter 10: Evolutionary Project Management;
  2. Fundamental Principles of Evolutionary Project Management
  3. Collection of Gilb’s Mythodology Papers on Agile, from Agilerecord.com. 
  4. Gilb: The Green Week: Reducing Technical Debt by Engineering. Case study at Confirmit. May 2013, In Agilerecord.com,   The Green Week Slides  The GREEN WEEK Video
  5. Power to the Programmers, as held Krakow ACE Conference June 2014, Video
  6. Competitive Engineering, Glossary CE Full Glossary 
  7. Gilb, Tom, Competitive Engineering, A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage, ISBN 0750665076, 2005, Publisher: Elsevier Butterworth-Heinemann. 
  8. Value Planning (an emerging book manuscript 2014-2015). This book is a detailed management view of Evo. Free download
  9. There is a serious exploratory effort to analyse current systems engineering culture and eventually develop ‘agile systems engineering’, spearheaded by Rick Dove, an early deep thinker on agile systems engineering. For example:
    1. Agile Systems Engineering, part 1
    2. Agile Systems Engineering, part 2

About the Authors

Tom Gilb and Kai Gilb have, together with many professional friends and clients, personally developed the Agile & value management methods they teach. The methods have been developed over five decades of practice all over the world, in both small companies and projects, as well as in the largest companies and projects. Their website offers free papers, slides, and cases about Agile, Evo, and other subjects.

There are many organisations, and individuals, who use some or all of their methods. IBM (quantify quality) and HP (Evo and Inspection) were two early corporate-wide adopters (1980, 1988). Recently (2012) over 17,000 engineers at Intel have voluntarily adopted the Planguage requirements specification methods; in addition to practicing to a lesser extent Evo, Spec QC and other Gilb methods.  Many other multinationals are in various phases of adopting and practicing the Gilb methods. Many smaller companies also use the methods. They have advised top management at UK Companies on Business Agile Methods

Rate this Article

Adoption
Style

BT