Transforming organizations: check out the Stoos Network. Wish I had been there! Some of my favourite people were there!
OpenAgile is similar to Scrum in many respects. Both are systems for delivering value to stakeholders. Both are agile methods. Both are frameworks that deliberately avoid giving all the answers. So why would we choose OpenAgile over Scrum?
The most important difference is in applicability: Scrum is designed to help organizations optimize new software product development, whereas OpenAgile is designed to help anyone learn to deliver value effectively.
OpenAgile is an improvement over Scrum in the following ways:
More effective teamwork and team practices, in particular the Consultative Method of Decision Making, and
applicability over a larger range of team sizes from a single individual on up.
Recognition of the individual capacities required for effective learning, namely Truthfulness, Detachment,
Search, Love and Courage. Scrum acknowledges a separate set of qualities, but does not show how they systematically connect with the requirements of a Scrum environment.
Systematic handling of more types of work beyond just “new artifacts” and “obstacles”. In particular, OpenAgile includes calendar items, repetitive items and quality items and acknowledges their unique qualities in a work
environment. OpenAgile also provides a framework to include additional types of work beyond these five.
Improved role definitions based on extensive experience.
There is only one role defined in OpenAgile (Team Member) vs. three defined in Scrum (Team Member, ScrumMaster, Product Owner).
There are multiple paths of service that allow Team Members and Stakeholders to engage with an OpenAgile team or community in different ways. There are five paths of service: Process Facilitation, Growth Facilitation, Tutoring, Mentoring, and Catalyst.
The Process Facilitator path of service is similar to the ScrumMaster role with the following major differences:
- is not responsible for team development
- is not necessarily a single person, nor is it a required role
The Growth Facilitator path of service is similar to the Product Owner role with the following major differences:
- is responsible for all aspects of growth including value (like the Product Owner), and individual and team capacity building.
- is not necessarily a single person, nor is it a required role
Integration of principles and practices from other methods. Two examples suffice:
From Crystal: creating a safe work/learning environment.
From Lean: build quality in, value stream mapping, root cause analysis, standard work.
OpenAgile allows interruptions during the Cycle. Scrum has the concept of Sprint Safety. This makes Scrum
unsuitable for operational work and general management.
The distinction between Commitment Velocity and other uses of the term “velocity” used in Scrum. Commitment Velocity is the historical minimum slope of a team’s Cycle burndown charts and determines how much work a team plans in its Engagement Meeting.
Flexibility in the length a Cycle. Scrum requires that Sprints (Cycles) be one month in duration or less.
OpenAgile allows a Cycle to be longer than that and instead provides a guideline that there should be a minimum number of Cycles planned in the time expected to reach the overall goal.
The Progress Meeting in OpenAgile does not require people to take turns or directly answer specific questions.
Avoiding conflict-oriented models of staff and management (Chickens and Pigs in Scrum).
Terminology changes to be more clear in meaning and applicable beyond software. A comparative glossary is
Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source
method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow.
Comparative Glossary between OpenAgile and Scrum
|Cycle Planning||Sprint Planning and Sprint Review|
|Team Member||Team Member or “Pigs”|
|Growth Facilitator||Product Owner|
|Work Queue||Product Backlog|
|Work Queue Item||Product Backlog Item|
|Cycle Plan||Sprint Backlog|
|Progress Meeting||Daily Scrum|
|Learning Circle w/ steps||“Inspect and Adapt”|
|Delivered Value||Potentially Shippable Software|
|Five Types of Work:
New, Repetitive, Obstacles, Calendar,
|- no equivalents -
User Stories, N/A, Impediments, N/A, N/A
|Consultative Decision Making||- no equivalents -|
|Sector / Community||- no equivalents -|
References on OpenAgile:
References on Scrum:
“Agile Software Development with Scrum” - Schwaber and Beedle
“Agile Project Management with Scrum” - Schwaber
“Scrum and the Enterprise” – Schwaber
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 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 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:
- Calendar Items
- Repetitive Items
- Quality Items
- New Work
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.
The word “Agile” refers to a type of method for getting work done. It’s all about doing valuable work with speed and quality. An Agile team delivers finished work frequently while working at a sustainable pace. Agile process consists of short iterations of work that deliver small increments of potentially shippable customer value. Frequent delivery ensures visibility of the work of the team, as well as its needs and obstacles, to all stakeholders.
Agile refers to a discipline defined as the middle way of excellence between chaos and bureaucracy. Agile also refers to the philosophy that humans do work in a complex world.
Although Agile has emerged out of endemic crisis in the software development sector (but not exclusive to it!) – mainly caused by the pressure built up from the strata of systemic dishonesty and distrust – it is not a software development process methodology. Rather, it is a system of learning that challenges deep cultural assumptions and catalyzes change in an organization.
Agile methods are made of processes, principles and tools. But most importantly they are concerned with people. Therefore, Truthfulness is the foundation of success in an Agile organization.
Although Agile cannot force people to be truthful, it reveals the direct consequences of opacity in an organization, confronts it and challenges it to change.
Agile prioritizes by value, not “dependency”. In fact, Agile teams are expected to break dependencies and are empowered by such challenges. Agile teams self-organize their own work - they are not “managed resources”. Agile is team-focused rather than project-focused. Agile responds to evolving requirements and avoids frozen requirements. In an Agile environment change is embraced as natural and healthy, rather than as something “risky” to be avoided.
In short, Agile is about overcoming fear, both on the part of individuals as well as collectively and culturally on the part of organizations.
As with any sincere effort to overcome habitual fear, Agile work is hard work. Becoming Agile can be an uncomfortable, confusing and frustrating process and can remain that way for a long time.
Agile is the art of the possible. It’s methods are idealistic, not dogmatic. Agile is about learning, adapting and striving for the ideal. Agile is based in reality – it relies on everyone to be truthful about the possible and to contribute honestly towards customer value.
Therefore, Agile requires a constructive and positive attitude. In an Agile environment, a state of crisis is an embraced opportunity to learn and improve.
An Agile team is empowered by its responsibility to self-organize. On an Agile team, people work together towards a common goal and coordinate their work amongst themselves. There are no managers or bosses on Agile teams. Correspondingly, no member of an Agile team reports to a boss or a manager. All team members report to the team. While working on a team, everyone checks their institutional titles, roles and responsibilities at the door. All members of an Agile team are responsible for one thing: contributing as much customer value as possible to the work of the team.
Agile exposes the true character of an organization’s culture and forces visibility on all levels.
At Berteig Consulting, we practice Agile. I am currently working in the role of Process Facilitator for our core team of 4. We work in 1-week iterations. As a couple of the team members have a 4-day work week, we have our Retrospective on Monday mornings at 10 AM, followed by the Planning Meeting for our next iteration at 11 AM. The remaining work days begin with a daily stand-up meeting using the reporting methods of the Daily Scrum (each member reports 3 things to the team – “What I did yesterday”, What I’m doing today”, and “What are my obstacles”). We work in a collocated team room, with product backlog items, iteration backlog tasks, obstacles, definition of done and a burn-down chart all up on the walls. We are currently in our fourth iteration of our current project (which, in this case, is the business itself!). As part of our retrospectives, team members actually demo finished work – i.e., Mishkin shows us some of the great changes he’s made to his course materials and Paul demos the latest edition of our beautiful newsletter (the one you’re reading right now!). Laila has even demoed some travel tools that she’s been working on for the coaches and trainers. We also decided to each write our reflections in order to share them with those who might find it useful as a way of wrapping up the retrospective for this iteration.
Agile can be implemented anywhere people do work together. Visibility of work, openness of consultation and a strong collaborative spirit feeds an overall feeling of excitement and optimism on an Agile team. Clear goals based on small pieces of prioritized value and sustainability of work ensure quality and speed of productivity. But of course, in order for a team to build up these capabilities, it must establish, maintain and defend a firm and immovable foundation of truthfulness.
My first iteration using Agile Work for my business development has come to a close. Here is what I did for a “demo” and retrospective.
I’m learning by example – bad example – my own!
We’ve all seen this. A one-year project in its 13th month, and the Project Manager has been reporting 80% of the tasks at 90% and has been doing so for the last 120 days. There’s no end in sight, and the customer is leaking cash every day the product fails to go into production. What can be done? Agile project management principles can help this all-too-frequent scenario.