Return to site

Step 8: Quality as A Faster Route to Value

· 12 Steps

Plenty of obstacles get in the way of creating value. Of course every lean and agile project out there believes it is more efficient than ever but we are often guilty of being very efficient at creating little value or maybe even destroying it.

Seeking value is a multifaceted activity. We've already pointed out that In Lean and Agile there's a real struggle to define value. In Lean, value is an absence of waste. In Agile, value appears to be a step along the way to completing a project.

The weakness with both is that neither really defines whether or not the work you are doing is adding value to the customer. To do that you need that multifaceted approach we just mentioned.

When you look at value in a multifaceted way it forces you rethink how you test for quality. In point of fact, it forces you to do a lot more. You need to reappraise many team roles too. The idea of a "multidisciplinary team" is the wrong term for this as everybody has to become multidisciplinary. It is not a feature of the team but of everyone's role within it.

But back to quality. At the very least you need to know that work is of consistent and good enough quality to deliver value and you'd be surprised how that simple idea gets distorted in many organisations.

We got talking about the quality problem with Alan Murphy who has a major role to play in defining quality at Paddy Power, one of the stars of DevOps and Flow.

Alan specialises in software quality control and is passionate about it but above everything else, he is passionate about unit testing.

It might seem anachronistic to think of value stemming from applying tests to very small units of work, so let's look closer at what Alan has to say.

As with all elements of Flow we believe the principles apply to all areas of a company's work. Very often we work alongside colleagues who claim a special degree of expertise and won't be challenged (or put another way, won't be tested). They can be pretty vocal about what they know to be true.

In Flow we say every proposition can be tested. There's a way to do it - experiment. So let's look at unit tests and then think about how the principle of small unit quality testing applies elsewhere.

Managers fail to realise the benefits of unit testing

The big issue for the unit testing advocate is that management generally see unit testing as a waste of time and an activity that holds up coding.

Managers and other stakeholders perceive unit testing as adding cost but that idea, and the elimination of unit testing, is a completely false economy because you will be breaking something in production later and then you will have to fix it in production.


It is very easy to look efficient by pushing code into production quickly but it will just be coming right back at you as bugs.


There's also a tendency to allocate test development to inexperienced developers, often people who are young and new to the company, who you are asking to write quite complex test suites for acceptance testing. It never, never works and it always ends up needing more development work. When you have broad unit testing coverage you can blaze into production with very small changes and very little blowback.

The Testing Environment

Breaking work down into small units allows for better unit testing.

Unit testing is made possible because Flow teams break work down into very small units. In Paddy Power that meant 3.-5 day units, though now Fin works in 2 day units, and shorter if possible. Mastercard recently revealed that they allow a 12 hour window to respond to micro trends!!


Small units of work are very relevant to DevOps. Because DevOps incentivises getting work right as it goes into production rather than reworking later, you need methods that ensure quality as far upstream as possible. That's what unit testing gives you.

In fact, According to Alan, this approach creates a unique test-driven environment.

We allied unit testing with acceptance testing and really departed from industry standards when we did that, as well as by getting the developer to code the test. We have a just-in-time discussion of acceptance criteria but very light weight. We quickly convene the product owner, tester and developer, build up 4 or 5 use cases and ask the simple questions, given x, when y, then z should happen.

Just-in-time acceptance testing is only possible when you have small units of work. But combining these two means you can run tests on the unit and get reliable consistent results and then quickly get acceptance for it in place of designing acceptance tests weeks in advance.

J-I-T acceptance testing means you are more likely to be testing work of value. Those 4 or 5 use cases are a checkpoint for work-of-value not just quality and acceptance. And in good organisations the developer takes on a bigger role - querying whether a unit of work actually creates value. 

The longer term acceptance testing model forces everybody to stick to a plan regardless of whether or not the plan is creating real value and regardless of changes needed within the plan, but often ignored. In Alan's experience there are often enough occasions where code never passes acceptance testing - sometimes because the tests are too difficult to write! - but nonetheless goes into production.


Redesigning work practices in this way, often on the fly, comes with a cost. It causes a lot of friction as developers need to learn new roles. But so too do testers. And product owners have to become more sensitised to the real time nature of the work.

One of the biggest inhibitors to unit testing is developer ignorance, Alan says. Developers haven't been exposed to this type of thinking. Testing has been treated as a separate discipline.

So developers need to learn how to write and code automated tests. Testers need to learn to operate with developers in writing smaller, automated unit tests. But what about product owners.

According to Alan that role can change almost on a weekly basis. The best product owners become embedded within development teams and have a voracious appetite for networking the developer team with stakeholders, constantly seeking out points of view and liaising when the business objective needs to change, rather than the development track. The product owner becomes pivotal but not in any grandiose sense. She becomes pivotal because of her energy and skills in identifying the right balance between changes in business objectives and changes to units of work.


Some of the grief that comes with change is also caused by confusion in those upstream roles. Product owners need to reappraise how they work but so too do project managers and product managers. The most difficult work structure for Flow practitioners is the project.

Projects get green lights from far off, they get a budget and they get momentum and that makes them almost like a missile when they get into the IT sphere, unstoppable. They resist all the logic of small units of work and unit testing because they have been mandated to work.

The Benefits of Unit Testing

Here is the summary of our conversation with Alan, mixed in with some of our own observations about quality, testing and value:

  1. Traditional testing suites bite off more than they can chew. They test a matrix of code that is in reality is too complex to test. Very often code will not pass acceptance tests and that means projects go forward already compromised.
  2. Code often gets pushed into production too early and conflict between development and production goes up another notch. 
  3. This is partly because, traditionally, work was considered "done", in agile terms, too far up the value chain when we don't know if it will be adding value or if it functioned properly in the wider project. Work is not done until you have evidence it has value and that usually means once a customer has used it and provide feedback.
  4. Unit testing is an answer to software quality problems and hence to keeping work flowing instead of suffering blowbacks.
  5. At the unit test level it can also be coupled to just-in-time acceptance tests that are a rough and ready consensus that it meets our current understanding of requirements.
  6. Unit testing is what really makes DevOps work; it's what allows you to blaze code into production with minimal changes.
  7. Units of work are the smallest unit you can break work down to (see our article on units of work, here).
  8. Good practice should involve a broad coverage of unit testing.
  9. It should also involve developers challenging product owners about the value of any increment of work; given a unit of work as a responsibility a developer can ask cogent questions about its value to business outcomes.
  10. That means everyone if focused on value.
  11. It also forces a continuous reevaluation of key roles like product owner, product manager, project manager.
  12. Software quality tests have to be coded by the developer. They can be designed along with a tester but the developer needs to take the responsibility of coding them.

So those are the key points of Alan's experience.

Applying Unit Testing Elsewhere

How can these experience and thoughts be applied outside IT?

The first thing to say about that is they help the relationship between IT and the rest of the business. They are a way for IT and the business to skilfully parse the elements of projects (multiple units of work) that really add value and to reject those that don't.

In contrast, lean ideas about value-stream mapping - review all processes to reduce waste - are a post-facto review, when waste has already occurred. The Agile approach to value.... well it is difficult to see what that might be.

But other areas of a business also now work in small units. Anybody planning a marketing campaign has gone from: let's blitz the media with TV ads and outdoor to: how can we balance the use of mainstream media with mobile ads, in-app or contextual advertising, Twitter, Facebook, Instagram, Snap, influencer marketing etc.

The marketing universe is was complex as the IT universe yet it appears to function through her stories - the stand out social media campaign, the pivot during a Super Bowl ad and so on.

Good marketing is no different from good IT. It is essentially made up of many small units of work which should all detested regularly for the value they are adding to business objectives.