The outcome of using Agile to run our small consulting business was the systematic development of OpenAgile… which eventually led to the creation of the not-for-profit incorporation of the OpenAgile Center for Learning (see www.openagile.com). This has been one of the things I am personally most proud of: giving back to the world a system for working that is based on Agile principles and practices, but adapted outside the world of software to be much more broadly applicable!
At Berteig Consulting, we used Scrum to run our business for quite a while – about one year. Over that time we struggled with a few different concepts and practices. As a Certified Scrum Trainer, I am very aware that Scrum requires us to use the framework itself to expose obstacles, rather than modifying Scrum to accommodate obstacles. However, over the course of that year, it became more and more obvious that there is something fundamentally different between writing software products (where Scrum is fantastic) and running a business. Scrum, the framework, just wasn’t good enough.
The main problem we had was with the types of work we encounter in running a business. We noticed patterns in the types of tasks we had every Cycle (Sprint). In this article I will look carefully at two of those types of work and then briefly describe the other three types of work.
We discovered that calendar items such as meetings, scheduled public events, and even personal appointments didn’t fit anywhere in Scrum’s Product Backlog or Sprint Backlog. At first, we tried to think of this as an obstacle and force-fit these into the Product Backlog. That didn’t work because that meant we couldn’t always prioritize by value. Even if the Product Backlog had something more valuable in it than the scheduled meeting, we sometimes couldn’t change the dates of the meeting to accommodate the more valuable work. So Calendar Items became a new category of work in addition to the new “features” that were in the Product Backlog. (I say “features” in quotes because we were running a business not writing software.)
We also noticed that we were struggling with applying the concept of the Definition of “Done”. This led us to explore the concept of Repetitive Work. For example, we need to clean our office on a regular basis – vacuum, water plants, take out trash, etc. If we left that until it became more valuable than anything else on our Product Backlog we would have ended up with a disgusting work environment. So we thought that this should be part of our Definition of “Done”. The problem then became a more conceptual one: what were we doing that needed cleaning so that it would be considered done? Well of course, it’s simply part of business operations. Cleaning is not independently valuable. We did decide that it was most cost-effective to outsource it, but it didn’t match the concept of Definition of “Done” as applied to the work in the Product Backlog. That led to an insight: actually, we were looking at a new category of work: Repetitive Items. These are those activities that we need to do to sustain our business and which should become habits, or which should be automated or outsourced.
After identifying Calendar Items and Repetitive Items as types of work, we decided that we needed to look at the Product Backlog more carefully. We decided that we needed to separate features, or as we called it “New Work”, from defects or Quality Items. We also formalized the concept of a queue of Obstacles, which is mentioned in Scrum, but about which is given very little guidance.
So after over a three years of trying to use Agile methods to run our business, we have finally come up with a stable and seemingly sufficient set of types of work:
We have written more about our experiences and their results in our e-book: The OpenAgile Primer (http://www.openagile.com/OpenAgilePrimer).
If you are trying to use Agile methods to run a business or any other kind of organization, please check it out and let us know about your experiences. We hope that OpenAgile will become an Open-Source method that we can contribute back to the world of work and life.
In the four years since this was written, some of the thinking around types of work has evolved further and the names we have given to these types has changed slightly to:
[This article was originally published on Agile Advice on 14-May-2009]
If you find this useful, please consider contributing with our
“Value for Value” model.