Great article about goals and how they might not actually be as important as we have all believed for so long. Does this also apply to Agile teams? The article is focused on individual goals and processes rather than team or organizational goals. I’d love to hear if anyone has experience with this!
The ScrumMaster is responsible for ensuring the correct use of the Scrum process. Because the ScrumMaster is usually the most well read on Scrum, always trying to improve the team’s understanding of Scrum, facilitating the Scrum meetings, and developing new ways to develop relationships and structures that allow Scrum to thrive, he is the most able to guide the team in its use of Scrum. This authority holds within the Scrum Team where the ScrumMaster is a member and overrides any external authority as applied to that team. However, this does not mean that the ScrumMaster becomes a guru that withholds learning and understanding and guards it as if it is a treasured jewel. Instead, it is also the responsibility of the ScrumMaster to enable understanding, learning, and action so that the team advances together. Having this authority allows the ScrumMaster to stop any argument about the Scrum process, and ensure that the team is focused on action. If the ScrumMaster does not have final authority on the correct way to use the Scrum process, it is very likely that the Scrum Team will flounder, argue, and limit the progress of the team by not continually improving how they use and interact with the elements of Scrum.
To learn more about the correct way to use the Scrum process, visit the Scrum Team Assessment.
Scrum Team Members, excluding the ScrumMaster and Product Owner, must be completely open-minded to learning new skills. Skills can be technical, business, personal, tools-based, etc. A Team Member is sensitive to the needs of the Scrum Team and will learn skills by multiple means as the needs of the team evolve. A Scrum Team where people are not willing to learn new skills will suffer from bottlenecks, time pressure, quality problems, and often will become generally demoralized as the willingness of some people on the team turns into apathy and cynicism when others refuse to learn. In a team where everyone is willing to learn new skills, there will be a consistent raising of capacity and the team will be able to do more and more work more effectively. This attitude is a key requirement for the formation of high performance teams.
A few weeks ago, David Parker and I had a conversation about some of the differences between Scrum and OpenAgile. We hit upon one really interesting thing: Scrum strongly emphasizes that it is a purely empirical approach to doing work… and OpenAgile does not make that claim. In fact, OpenAgile, while it includes empiricism, is definitely not an empirical process framework.
Ken Schwaber has long been adamant about empiricism with his phrase “Inspect and Adapt” which is the core of Scrum. All the artifacts, meetings and roles of Scrum are meant to be supportive of the inspect and adapt approach in a product development environment. A Scrum self-organizing team inspects and adapts on the product it is building. It inspects and adapts on the obstacles that arise as it does its work. It inspects and adapts on all the organizational processes, technical tools, team dynamics,… everything! This is Good.
But Scrum, in its pure empiricism, also lacks something.
OpenAgile has components of Scrum’s empiricism. Certainly, OpenAgile owes a great deal to Scrum. The concept of “Systematic Learning”, one of the foundations of OpenAgile, is similar to Scrum’s empirical framework. The process structure of OpenAgile is also similar to that of Scrum with short cycles of work delivering value on a regular basis. The main difference comes from a simple concept: Guidance.
In OpenAgile, guidance is a critical component of systematic learning. Guidance allows someone outside the team to intervene. This might be a manager, a stakeholder, a family member… anyone who sees things from an “outside” perspective. It might also be someone within the team pulling in guidance: asking for advice, doing a web search, reading a book, or even meditating in the hope of inspiration.
In Scrum, there are some very strong boundaries around outsiders providing guidance. No changes mid-sprint. All requests for work go through the Team’s Product Owner. The ScrumMaster “protects” the team from outside interruptions. ”Chickens” cannot participate in the Daily Scrum. The team self-organizes with individuals volunteering for specific tasks. Team members discard all organizational titles when working within a Scrum team. All of these boundaries support a pure empirical approach to working. They also provide a form of safety for the team. This safety is deemed necessary with the implication that stuff from outside the team is dangerous.
In OpenAgile, guidance comes to the team through the conduit of love. Yes… love.
The team develops a love for its work. This love then opens the team members to guidance. Think of the opposite: if I hate my work, I’m not likely to be interested in taking any advice about how to do it better. If I love my work, I will always be seeking ways to improve it.
Of course, love is not binary. It’s not on or off. In that continuum, the more an OpenAgile team loves its work, the more receptive it will be to guidance. The more receptive to guidance, the more sources of guidance will be “safe”. And the less reliance on pure empiricism will be necessary.
Let’s be frank: pure empiricism, in its most extreme form, means that Scrum teams would re-invent things that may have already been invented many times before. In the Scrum community, the most obvious example of this is the Agile engineering practices that come from Extreme Programming. Scrum teams seem remarkably resistant to adopting these practices at the outset… despite the fact that eventually most Scrum teams working in software succeed or fail based on their eventual adoption of these practices. Scrum teams are often left without the guidance that XP practices can help them. Instead Scrum teams seem expected to re-discover XP practices on their own.
For what it’s worth, I don’t think that Scrum is fatally flawed. In fact, I think that in some environments, where teams truly are unsafe, where people tend to hate their work, where dysfunctional bureaucracy is deeply embedded in the organizations culture… in these environments Scrum is actually the right place to start. Scrum is great for product development in high-crisis situations: save your product with Scrum!
OpenAgile, by accepting guidance into its framework, allows teams to progress rapidly when they can leverage other people’s learning. Scrum does not dis-allow this, but it sets up an environment where the team culture tends towards the “Not Invented Here” syndrome. OpenAgile puts teams on the other path: the path of allowing for greater and greater learning from others.
Cross-posted from the personal blog of David D. Parker: A Changemaker in the Making
I. Agile Volunteer Team Process
- The meeting begins with reflecting on the results of the previous Cycle. These observations and lessons are an important part of the planning process.
- Next, the team of volunteers works together to create a Cycle Plan by taking the highest priority Value Driver and breaking it down into tasks. Tasks are represented by sticky notes on the wall.
- Third, the volunteer team counts the number of tasks needed to complete the highest priority Value Driver. If the past Cycle showed that the team can complete more tasks, then the team takes the next Value Driver in the list and breaks it down into tasks. This process continues until the team makes a unified decision that it has taken on the amount of work it can actually accomplish.
- The last part of the meeting is commitment. Everyone shares the responsibility for completing the Value Driver (represented by multiple tasks) by the end of the Cycle of work. Therefore each volunteer must truthfully commit to completing the work. If a volunteer is not comfortable committing to all the work on the task wall, then some tasks must be removed until everyone is able to commit.
- Volunteers are free to take whatever task is of interest to them. If they need more information about the task, they ask the other volunteers or the staff for details.
- When a volunteer begins a task, they sign their name on the bottom of the sticky and move the task into the “in progress” column.
- When a volunteer completes a task, they move the task into the “done” column.
- There are weekly conference calls where all the volunteers check in. They answer 4 simple questions
- What did I do last week?
- What will I do this week?
- What did I learn/observe?
- What obstacles, if any, are affecting my ability to do work?
- New tasks can be added to the wall based on any of the volunteers’ observations, obstacles, clarifications, questions, urgent new tasks, etc. If you add a new task to the wall, add your name to the bottom of the task, so that other volunteers can know who to go to for questions. Note that these new tasks must also be completed by the end of the 5 week Cycle.
II. Communication Tools
- Login and read new messages
- Emails in the Inbox means there is work to be done (if the task is complete, archive the email to remove from the Inbox aka the To Do List)
- Apply Labels – Gmail doesn’t use folders; it uses labels instead. Apply labels to emails to assist other volunteers with how to treat the content of that message.
- Write up volunteer tasks for the task wall (Note: Label as “Task Written & Posted”)
- Get work done:
- Move the task on the wall to in progress
- If the task came from an email, label the task with your name
- When the task is complete, label as “Task Complete” and archive the email so it doesn’t appear in the Inbox
- ??? – this means more information or context is required to understand the request –> ASK QUESTIONS, or get help, to complete the task
- By Volunteer Name –> This means the task/email is in progress; A volunteer labels the email with their name when they accept responsibility for a particular task
- FYI (For Your Information) – these are emails that contain information that is relevant to volunteers, but does not necessarily require action be taken. If action is required, write up a task and post it on the wall)
- Task Complete – Use this to label When a task is complete; archive the email so it doesn’t appear in the Inbox
- Task Written & Posted – apply this label after you write up the task and post it on the wall
- Social Media – these are emails that apply specifically to social media like Twitter, Facebook, etc.
- Website – these emails are relevant to website updates
III. What is 60/40 Time?
- Belief in the mission of the charity
- Desire to “give back”
- Meet new people
- Make new business contacts
- Invited or inspired by another volunteer or staff member
- Improve resume
- Learn new skills
- Benefits such as free events
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
This is my first post on the Agile Advice blog. In fact, it’s my first blog post ever. Before joining the Berteig Consulting team, I had never even heard the words Agile, Scrum, Lean, or OpenAgile. After all, my background is marketing, community relations, and sustainability! Needless to say, I’ve gone through some intense learning about the role of the Growth Facilitator.
The responsibility of the Growth Facilitator is about more than simply prioritizing New Work goals and tasks. I see the role as contributing to the organizational culture, and helping to build the business in a sustainable way. “Sustainability” is an important concept at BCI. It means that we are committed to conducting business in a way that is respectful of the environment, society, and the economy. At the same time, it means that the BCI team operates at a sustainable pace, finding ways to balance our work and life so that we don’t burn out.
As Growth Facilitator, I am also responsible for guiding the team toward delivering greater value for our stakeholders. At Berteig Consulting, our stakeholders don’t just include the company’s owners. Our stakeholders include a wide range of groups, including customers, suppliers, employees, and our families, all without whose support nothing we do would be possible. Delivering value to our stakeholders requires that we keep them in mind when we commit to our tasks each week.
One of the important lessons I learned was to give the team S.M.A.R.T. – Simple, Measureable, Achievable, Relevant, and Timebound – goals and give them space to come up with the tasks to meet the goal. When I first started, I made goals that were broad, saying for example “to take care of our clients” or “to work at a sustainable pace.” Rather than stating goals, I realized that I was making statements of the team’s shared values. And while the team integrated these thoughts into our behavior, it was nonetheless challenging to spin off specific tasks that we could work on. Now, I try to ensure the goals I create conform to a user story format and meet S.M.A.R.T. criteria. For example “Berteig Consulting can update the Certified ScrumMaster course content so that all CSM course participants receive the best value in the market.” As soon as I made the direction clear, the team self-organized and generated tasks required to achieve each goal.
Another key lesson of developing the direction for the team was allowing the Team Members time to review the next Cycle’s goals in advance of the Cycle Planning Meeting so that they could provide feedback and seek clarification. This became particularly important when one team member jumped on a business opportunity that created a significant amount of New Work. We simply could not overlook this great opportunity, and we moved it to the top of the New Work priority list and put it in the next Cycle Plan.
Last, I learned that the Growth Facilitator and Process Facilitator have a complimentary relationship that requires frequent consultation. As the Process Facilitator goes about helping the team overcome obstacles, it can become clear that the team needs to address a systemic challenge during one of the upcoming Cycles. The Growth Facilitator then states the need as a Cycle goal in a S.M.A.R.T. format, allows the team time to give feedback, and prioritizes the goal in the New Work list. When the goal is brought to a future Cycle Planning Meeting, the team breaks the goal into tasks and solves the systemic obstacle that the Process Facilitator identified.
These lessons have helped me understand how the Growth Facilitator role extends beyond prioritizing New Work and guiding the team’s value delivery. The role also fosters the culture in which the work gets done – working at a sustainable pace, taking care of our customers, and maintaining unity of vision.
I would love to hear your thoughts about anything I’ve expressed here. Berteig Consulting is a deep-learning environment, and your feedback is invaluable.
David D. Parker
VP Marketing and Sustainability
All credit for this is due to Mary Poppendieck as this is entirely cribbed from her Agile2007 talk on agile leadership.
A man walks into a quarry and sees three people with pickaxes. He walks up to the first one and asks, “What are you doing?” The first quarry worker irritably replies, “I’m cutting stone, what does it look like? I cut stone today, I cut stone yesterday, and I will cut stone tomorrow!” The man asks the same of the second person who replies, “I’m making a living for my family.” The man turns to the third person and asks him, “so what are you doing here?” The third worker looks up for a moment, looks back at the man with a proud expression and says, “I’m building a Cathedral!”
The moral of the parable is likely clear, but it bears applying to organizational dynamics. Basically, consider that everyone gets annoyed with aspects of their jobs. The question is one of response. Basically, if a person is annoyed with his job, does he:
- Complain? He is probably a stonecutter.
- Ignore it? He is probably a paycheque earner.
- Fix it? He is a cathedral builder.
Cathedral builders are absolutely critical to a healthy organization. They push the organization towards a vision, often propagating the high-level vision throughout all levels of the organization. Unfortunately, these are also people who annoy the stonecutters and paycheque earners, because they won’t participate in the complaints, and they agitate for changes which make it hard to ignore things and just “do the job.” But your success will rely on them… find them, shelter them, and grow them. And whatever you do, don’t “promote” them into positions where they aren’t effective. Empower them, and if you need to add salary and title that’s fine, but let them find their own area of maximal contribution. Guaranteed you, Mr. business owner, aren’t smart enough to see what that is.
Organizations that fail to see this remain mediocre or failing organizations. Organizations that find ways of harnessing their workforce and coaxing people into the next level of engagement, succeed.
The fact that agile methods increase return on investment, accelerate learning, increase stakeholder satisfaction, and enable better control of work are all an interesting result of this final benefit: responding to change.
Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.
The Project Management Institute refers to three variables that can be negotiated or constrained for a given project: scope, resources and schedule. Schedule is an interesting “variable” in that we have no choice about how time flows. We can control how much scope to ask for, we can control how much money to put towards the work, but we cannot actually “buy” more time than, say, our competitors. This has important implications which deeply challenge the PMI’s PMBoK model of project management.
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.
Last night I was thinking more about the analogy of technical debt. In this analogy, design and quality flaws in a team’s work become a “debt” that must eventually be paid back. This analogy is fantastic because it can be taken just a little bit further to understand just how bad defects are…
Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.