The Agile Manifesto is the founding document of the Agile movement. It can be found at http://www.agilemanifesto.org and if you haven’t read it, it is strongly recommended! Living values and principles is an act of striving for excellence. There are no mechanisms in Scrum to force people to live the values and principles of the Agile Manifesto. Scrum relies on individual team members to strive to develop an understanding and practice of Agile values and principles in and of their own volition. If Team Members do not live the values and principles of the Agile Manifesto in their team many other things will take priority such as creating a complex document. The team could think of Scrum as a tool for project delivery, without really working to change the culture of their organization. Since Scrum empowers individuals and makes obstacles visible, if the team doesn’t live the Agile Manifesto principles then they may be disconnected from the roots of Scrum and make it a lesser version of itself, sometimes known as Scrumerfall (where you blend some elements of Scrum with other elements of waterfall which provides little to no benefit).
Many of you have heard that Scrum does not solve problems… it just exposes them! Mike Caspar has written a great in-depth article about why Scrum exposes problems (and why this is good!) with lots of great examples. I like his concluding remark:
Scrum does not have answers for not following Scrum.
I just finished reading an excellent article about a UCLA prof who, for his game theory class, allowed the students to cheat
I strongly recommend reading this because this points to one of the big cultural barriers to using Agile methods effectively: we are focused on individual performance instead of the outcomes of a group (team) of people!
The manifesto for agile software development (http://agilemanifesto.org) consists of 4 basic values:
1. Individuals and interactions over processes and tools?
2. Working software over comprehensive documentation?
3. Customer collaboration over contract negotiation?
4. Responding to change over following a plan
I’ve been thinking about how this manifesto applies outside of the world of software, for which it was originally created. These concepts are so engrained into various agile methodologies, which these days don’t explicitly refer to software any longer, that it begs the question: how does a team apply these four values to their work outside of software development; specifically, what would replace delivering ‘working software’? The other three values translate more fluidly to differing spheres of work. For example, whether in the field of business, sales, medicine, etc. placing greater value on all the items on the left over those on the right will produce a transformed culture and working environment. But what does ‘working software’ translate into in these various realms? Particularly relevant for non-profit organizations, the next possible question would be: what if we are not creating a ‘product’ or something that is ‘shippable’? What I’ve found to be the methodology which most aptly addresses this question is OpenAgile.
On its website: www.openagile.com it is noted that: OpenAgile is a learning system designed to help individuals, teams, and organizations build capacity for rapidly delivering value to their stakeholders. Rather than the focus being on a product, the aim shifts to learning and value. Yes, the ‘product’, if there is one (software or other), is important, but now there are even greater possibilities for the use of agile outside of software.
Though almost deceivingly simple, the principles animating OpenAgile are extremely profound. Through practicing the core foundational principles of truthfulness, consultative decision making, and systematic learning (through reflection, learning, planning, and action – all in light of guidance) the potential ability to ‘deliver’ something valuable is extraordinarily enhanced. Indeed, the greatest value could even be the learning that has taken place from the team or individuals themselves, the changed culture now animated by consultation engendering collaboration rather than competition, the regular and ongoing practice of truthfulness in a team resulting in accelerated transformation (potentially also allowing for that team to be more committed and driven to delivering a ‘product’) and the creation of a space where continual learning is the hallmark.
In an Agile culture, it is considered rude to refer to people as “resources”. People are not fungible – you cannot just take any old developer and plug them into any old project. Skills, personalities, likes, talents, potential all are so dynamic and unique for each individual person. So any management theory (including traditional project management) that treats people as “resources” like oil, gold or computers, is making an unjust simplification at the expense of the people working in the organization.
Yet organizations need to be able to plan where to spend money, and certainly the people working in an organization are often one of the largest costs. From a financial perspective, from a business perspective, it makes sense to somehow treat people costs in the same way as other operational costs… and this often leads to dehumanizing people to the point of treating them like resources.
So how can these legitimate organizational needs for budgeting mesh with the equally legitimate approach of Agile to treating people as unique actors be merged? It is actually quite simple, but the ramifications are deep: treat TEAMS as resources. Teams become the fundamental building blocks of an organization. Teams move from project to project or program to program or operation to operation. There is still a need to support the individuals in an organization, but it is done in the context of teams.
An Agile team is cross-functional, but also constantly learning. Individuals on the team learn skills based on their own interest, but also based on the needs of the team for redundancy, parallelism, and expansion of capacity to take on new, more challenging work. Cross-functional teams can more easily (and more sanely) be compared for their value to the organization by looking at things such as their ability to produce finished product/services, their flexibility in serving the needs of the organization, and the quality/consistency of the work they produce. Teams can compete in a healthy way by striving for excellence in delivering value to the organization, whereas often competition between individuals can be quite unhealthy.
From a budget perspective, teams are easy to manage: each team has a fully loaded cost based on salaries, space, equipment, etc. The cost is (or can be) relatively stable or grow predictably, and can still be handled operationally. As well, unlike individuals, it is much easier to treat a whole team as a fungible unit: you feed work to teams based on their availability rather than based on a detailed analysis of their skills/capacities/allocations.
In Agile organizations, teams are resources, people are not.
As many who have tried know, an Agile Transformation in a company is not always an easy process. Although most people at first are keen to participate in the idea of “changing” the company culture and working environment to “something better”, many do not realize how much work it can actually be.
For some of you, you will be fortunate enough to be in an “Agile” environment already.
Perhaps you are using OpenAgile, or Scrum. You may be using a unique variation such as the Pomodoro technique.
For those of you that are new to the idea of Agile Processes, no matter what your flavor of framework or tool, there is something you will not be able to avoid. Politics.
There is no getting around this. Agile transformations are about change in an organization and not just change in one small section of the company.
Although many Agile teams start as “pilot projects”, even in such small situations, the effect on the departments or culture at the “edges” of even the smallest teams can start to cause ripple effects in an organization.
The first secret is to acknowledge and accept that this is going to happen. Life will be easier for you this way. The job of any one assisting with an Agile implementation is to provide honest information and advice to help those who will be directly or indirectly impacted.
Don’t think you will be able to just hide in development and not be noticed. Be prepared with slides, web site links, and open to talking about your processes and ideas with anyone who wants to know. You must be transparent and open about what you are trying to accomplish.
OpenAgile for instance is defined as a “Learning System” because it deals with the realities that no one can work in a bubble and that more than just the “development team” needs to be involved in Agile practices for them to work. The entire organization will be learning with you.
Scrum has a well defined set of guidelines to follow in regards to the development process and is ideal for new software development projects.
Lean is a more gentle approach to changing an organization in small, progressive steps.
Don’t kid yourself. No matter how small the changes will be, there will be resistance from someone, somewhere, from where you least expected it.
The important thing to remember is what your goals are. The goal of the framework is an open and honest discussion between all those involved in your organization and general culture shift to a blameless, team based shift in thinking.
However, what is the real goal here? Happy customers, happy employees, and therefore, a profitable, progressive organization. You must remember the purpose is not to make teams, but to make a good product for the customer. Sometimes, you may find it hard to remember.
I recently read The Wisdom of Teams: Creating the High-Performance Organization (Collins Business Essentials) by Jon R. Katzenbach and Douglas K. Smith. It clearly explains, with examples, how an organization with the courage to change their culture can really benefit from an overall culture shift towards Consultatative Decision-Making and team work based approaches.
Consistently, companies who simply “say” they have teams under-perform those that actually “just have teams”. One type of company has them by edict or decree, and the other just has them because the culture is that way. The ones with the naturally team based cultures do much better financially. Hmm..interesting.
Change is usually started by some kind of need to change because things aren’t working out “the old way”.
Buggy software, unhappy customers, late releases…Whatever the pain, the results are always a “desire to change”.
Those who have the courage to admit they need to change, should be applauded. If you are new to Agile and reading this, please pat yourselves on the back for having the courage to learn more.
Now, it should be “easy” to stay on the path if you keep at it. The act of Starting is the first big step. Congratulations!
One thing you will find as you proceed is a continual list of “it won’t work because of this”, “it won’t work because of that”. But, hey, you’re not selling snake oil here. You’re talking about people in an organization taking control of their work and working together for the best solution possible for the company and it’s customers. Keep it simple.
Agile processes are just that … Processes.. They are not there to replace common sense. Agile is not a silver bullet to cure a company’s culture. That part of things is still a human thing and will take time. Please don’t think of Agile as a cure for a bad culture. It is simply a way to help the culture to change.
To me at least, what is important is a consistent message. I believe this is the key to helping an organization to be an Agile one.
Let’s take the Daily Scrum (for Scrum teams). I worked with a company where the Daily Scrum was considered a waste of time and a nuisance for those involved (at first).
The daily scrum is a quick recap of where everyone on the team is. For more information about the Daily Scrum, just do a quick search. There is an abundance of information about it. Try the Scrum Alliance for definitive information.
At this company, the owners and senior managers considered the scrum to be a nuisance. The senior developer of the team found it to be a hassle. Then, after a few weeks of doing daily scrums, any team member could be asked by someone passing in the hall what was going on and that person could easily tell them what the status of the project was. There are many other advantages to the scrum, but that’s not what this article is about. Maybe another time.
When I first started at this company, there was a weekly “developer meeting” which at first was the only way to exchange information. It was generally 2 hours/week. The team was now doing daily scrums and having small “mini-chats” (for lack of a better word) occasionally when needed. Team members knew from the Scrums what was going on and who needed help with what and then self-organized to solve their problems and arranged “mini-chats” as needed to help each other out.
The “weekly 2 hour developer meeting” just became a thing of the past. The team just stopped having them.
Waiting until the end of the week was far too cumbersome for something they could get from a 10 minute scrum and occasional ”mini-chats”. The team had unknowingly switched into a mode where they practiced regular consultative decision-making and regular re-assessment of their situation.
Then a remarkable thing happened.
One day, I was in a meeting, and the senior developer who at first was reluctant, banged on the window of the board room I was sitting in for me to come to the 10:00 AM Scrum which was 2 minutes away. I excused myself from the meeting and returned approx. 13 minutes later. The owner of the company said “Why do you do those daily meetings. They are such a waste of time. You have that big Developer Meeting every Friday”.
My response was “I’m sorry, but we don’t need to waste our time with that big 2 hour meeting every Friday anymore… We haven’t needed them for a few cycles now”.
What a remarkable experience! In one quick step, and after considerable pain, not only was it evident that the senior developer embraced the Agile Scrum Meeting, but also the owner who was previously unsure suddenly came to realize that the team was far more effective than he knew and he hadn’t even noticed the shift.
The developer culture had changed to a more team based one without his knowing. All team members knew what was happening and Expected to be kept in the loop from now on.
The key is, keep doing it ! Be consistent. If you’ve implemented a standard Agile practice, stick with it.
Be realistic though. There will be people who consider it to be “stupid” and there will be people who don’t want to participate. As a new implementor, NEVER humiliate anyone in the process. Simply encourage open discussion and ask everyone to contribute. At first, people will be shy or nervous about this. Over time, it will be the norm to participate.
The point is that as time passes, people and things change. The new processes will become Common Place and not so foreign and people will start to appreciate the fact their opinions are important and they have an impact on the bottom line of the company and the customer. This is what drives people to be happy and succeed.
Then, with a bit of luck and perseverance, someone in a different department will say “Hey, I think that seems like a good idea. Tell me more”. “Do you think this Agile stuff might work in sales?” might be the kind of question you suddenly receive. Do yourself a favor and be prepared for this with some links to a few Agile Methodologies at-hand!
This is your opportunity to introduce the new “culture” into a different part of the company.
With a bit of patience, others will come on board. It will be a great experience for you once you have others helping out.
The day will come when someone will try and remove an Agile process somewhere in the organization and team members will lobby for their cause. This is the day you will know… I have succeeded with step 1… Getting started !
From here forward, it’s just a matter of consistently trying to improve things one cycle or iteration at a time, and watching things get better for the customers, employees, and of course, the stakeholders.
If I can give one last bit of advice. Please do a bit of research before implementing something. Ideally, you want the teams to come up with how to do their daily work, not yourself. Let any process be the team’s process, not yours. Of course, if you have a new team to Agile, you will need to help them get started.
Consider your job as one of just guidance and coaching. That will work the best.
Review your environment carefully before deciding about methodology and do some reading or contact a coach about the differences. Should you be using Scrum, OpenAgile, XP, Lean, etc? Think about it carefully. They have different levels of organizational change and are for different applications. Use Wisely. :->
If you’re courageous enough and have an experienced Agile team, why not ask the team which Agile Methodology will work best for them? I personally enjoy learning something new all the time. :->
Mike Caspar, CSM, OpenAgile Certificate Holder, ATPL
- OpenAgile - http://www.openagile.com
- Scum - http://www.scrumalliance.org
- Lean – http://en.wikipedia.org/wiki/Agile_software_development
- Pomodoro Technique - http://www.pomodorotechnique.com/ (thanks Fred for telling me about this ;->)
- The Wisdom of Teams
Myself, Paul Heidema and a few other people we work with have now participated in several assessments of organizations who are either looking at adopting agile methods or improving existing use of agile methods. We have developed several tools for running these assessments. The following things are critical to the assessment process and the results we get:
The success of an agile transformation is primarily driven by connection that transformation makes with the existing culture of the organization. We know that doing an agile transformation includes cultural changes. The critical piece is understanding the culture so that you can determine what in the culture supports agility and what in the culture is going to hinder agility. A culture that focuses on individual accomplishment and freedom will not support agility well, while a culture that supports doing the best possible thing for customers will support agility. Of course, any given organization will have a mix of cultural aspects that both support and hinder agility. There are a number of methods for examining culture including an excellent corporate culture workshop described in the book “The Corporate Culture Survival Guide” by Edgar Schein.
Value Stream Mapping
A high level value stream map is an excellent tool for identifying both an overall need for improvement by making the current state of affairs visible, as well as pinpointing where big improvements can be made quickly. More often than not, when we do an assessment for an organization, we are finding that the efficiency of their process is at about 20-30%… in other words, 70-80% of all effort is expended on wasteful activities. This level of waste is often surprising for stakeholders. And of course, making that level of waste visible is a large motivator for the kind of continuous improvement that agile methods such as OpenAgile and Scrum make possible.
Of course, even if an organization is not doing agile officially, there are often existing practices that can be considered part of the overall umbrella of agile. A comprehensive assessment that rates a team’s or an organization’s level of use of agile practices gives a good picture at a very practical level of what things you can build upon. For change to be successful, a significant factor is to tie new practices to existing practices. This is a great way to do this. There are lots of lists available of agile practices. We publish one fairly comprehensive list of agile practices on the Berteig Consulting site (it’s near the bottom of the linked page).
There are of course many other things that are done during an assessment, but these three form an effective foundation for any agile transformation plan.
I have started composing a series of articles on my blog A Changemaker in the Making that are intended to briefly explain how to apply different agile practices to the work of social innovators, non-profits, charities and volunteer organizations.
The first article covers Self-Organizing Teams an important consideration for organizations that want to use their people resources more efficiently and to create a culture of empowerment.
The second article explores The Agile Workspace and ways to create an environment that is conducive to fruitful interaction.
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
One of our partner organizations, HBI Leadership, has launched a blog called SustainabilityCulture.com. Check it out!
Last week I taught an introductory course on Agile Work. Normally this is pretty easy stuff. However, I was teaching this course in Bucharest, Romania (cool), and I have come across a substantial, strong and vigorous objection to agile (also cool, but challenging too). Several people in my class are asserting that agile is just like communism and since communism failed, agile is not likely to succeed either. I’m looking for help on this!
Personally, I’m strongly on the side of “polychronic”… and I’m being strongly encouraged to move to a more “monochronic” approach to time management. All my life I have struggled with calendars, PDAs etc. We’ll see how it goes!
Here’s a slightly off-topic, but nevertheless excellent read: “The Inner Ring” by C S Lewis. This is a talk given by C S Lewis to what seems to be a group of university students. In it, he describes the notion of the inner ring and the desire to be “in”. It is amazing how much our culture in North America and our corporate culture is driven by this desire. I’ll leave it to you to decide if this is good or bad.
It occurred to me to ask: If the “invisible hand” in the free markets of capitalism is making for efficient markets, efficient work… then why is there some much room for improvement when we start using non-competitive, collaborative techniques such as lean and agile?
And if these collaborative techniques work on a small scale to improve efficiency, does this mean that we could do this across organizations as a “replacement” for capitalism somehow?
In agile methods, we “assume positive intent” on the part of individuals. What if we could do this across organizations? I’m not living in a dream world yet, but I think I have an inkling of what it might look like: Toyota and its collaborative, leaned-out supply chain.
Dmitri is only looking at one side of the cost/benefit equation. He’s laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn’t even mentioned arguments for the other side: the important sale that will be lost.
Okay… I’ll bite.