At BERTEIG, 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 accomodate 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 Activities. 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 Activities. 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 Artifacts”, from defects or Quality Problems. 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:
- Calendar Items
- Repetitive Activities
- Quality Problems
- New Artifacts
We have written more about our experiences and their results in our e-book: The OpenAgile Primer. 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. OpenAgile for business is a great match and is, in our experience, a much better fit than Scrum or Kanban.