Maximizing the work not done!


simplicityRecently at a conference for Business Finance Managers I was asked to present about how Agile contributes to increasing the business success of the organization. Everyone seems to be busy to adopt an Agile style of working, although many are still struggling to implement Agile in a proper way.

While preparing for the conference, I again had a look at the Agile principles at And my eye fell on the tenth principle: ‘Simplicity – the art of maximizing the amount of work not done – is essential.’

So, Agile is all about simplicity. And to consciously do things simple and with a clear scope. In this regard, Agile, as you know, is not unique. Lean, for example, is all about solving, or rather preventing, ‘waste’. And Prince2 and PointZERO are also about ensuring that you do exactly the things that are necessary and nothing more. Now this is something that is not yet practiced by everyone. American research indicates that thirty to forty percent (!!) of the effort during the application lifecycle actually is rework and, thus, waste.

I interpret this tenth principle of Agile in two ways:

  • we do the necessary things right first time, so we avoid rework
  • we have to pursue that we do not create unnecessary things

How can the Agile team contribute to this?

Preventing unnecessary work can for example be done through early reviews, with a particular regard to the contribution that the system parts as described will bring to increasing the business success. Stakeholders (especially if not yet used to the Agile way of working) often have the tendency to simply write some ideas on a napkin and then expect that it provides all information necessary for a perfect system to be built. And after it turns not to be true, we, IT-people, all will do our best efforts to rebuild and recover.

This must change. The Agile team can work on ‘maximizing the work not done’ by asking critical questions to the stakeholders and first have them think about what they really need. Spending slightly longer time on the requirements will be gained back twice over in the further activities of the application lifecycle. And so it prevents ‘waste’.

In my view, the principle of ‘simplicity’ is often lost in the ambition of IT-staff to create things as nicely as possible. We make the best applications with the most beautiful nifty extras. Creativity is good, of course, but ‘too good’ is also ‘too expensive’ and not ‘fit for purpose’. Not building unnecessary things is essential to ‘maximizing the work not done’.

Moreover, extra nice features also introduce additional risks. Agile teams are (or should be) accustomed to think based on risks. By performing a Product Risk Analysis they investigate where the benefits outweigh the risks (i.e. contribute to the business success of the organization). Where the risks are too high, we should simply not do it. That also is ‘maximizing of work not done’!

The tenth principle of Agile is very much something to constantly keep in mind. Please contribute to the maximizing of things not done, and then save your time for fun things, such as riding the waves on a surfboard (or would you rather be surfing the internet ;-).

Have fun!

Rik Marselis


Rik Marselis is principal quality consultant at Sogeti in the Netherlands. He has assisted many organizations in improving their IT-processes, in establishing their quality & testing approach, setting up their quality & test organization, and he acted as quality coach, qa-consultant, test manager and quality supervisor. Rik uses his more than 40 years of experience in systems development and quality and testing to bring fit for purpose solutions to our clients. He focuses at three major tasks: * Consultancy on Quality engineering & Testing in the broadest sense (quality & test policy, project startup, process improvement, coaching, second-opinions, etc…) * Develop and give training courses for both novice and experienced testers (Rik is an accredited trainer for TMAP, TPI and ISTQB certification training courses) * Research and development of the quality engineering & testing profession. Rik has contributed to over 20 books on quality and testing, of which 5 as an main author and 5 as project leader. His most recent book in the TMAP body of knowledge is “Quality for DevOps teams”. Rik is a much-appreciated keynote-speaker and workshop-host at conferences (he has presented at conferences in over 15 countries).

More on Rik Marselis.

Related Posts

Your email address will not be published.

  1. Jos Punter March 19, 2014 Reply

    Hi Rik,
    Nice read !
    I would like to add one other way of ‘maximizing the work not done’ .
    Its simple just don’t take all the request in to the backlog. Hire a good Product owner who says NO to stakeholders.