Tag Archives: innovation

Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should be assigning tasks to team members. Don’t do this!!! It is better to wait for someone to step up than to “take over” and start assigning tasks.

Assigning tasks can be overt or subtle. Therefore, avoid even suggestions that could be taken as assigning tasks. For example, no one should ever tell a Scrum Team member “hey! You’re not doing any work – go take a task!” (overt) or “This task really needs to get done – why don’t you do it?” (semi-overt) or “Would you consider working on this with me?” (subtle). Instead, any reference to tasks should be to the team at large. For example it would be okay for a team member to say “I’m working on this and I would like some help – would anyone help me?”

In the Scrum Guide, a partial definition of self-organizing is given:

Scrum Teams are self-organizing….. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

A more formal definition of the concept of “self-organizing” can be found here:

Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.

The key here is that there is no single point of authority, even temporarily, in a self-organizing team. Every individual member of the team volunteers for tasks within the framework of “the laws followed by the process” – namely Scrum. Scrum does define some constraints on individual behaviour, particularly for the Product Owner and the ScrumMaster. People in those two roles have specific duties which usually prevent them from being able to volunteer for any task. But all the other team members (the Development Team) have complete freedom to individually and collectively figure out how they will do the work at hand.

What If One Person Isn’t Working?

People who are managers are often worried about this. What if there is one person on the team who just doesn’t seem to be doing any work? Isn’t assigning tasks to this person a good thing? Scrum will usually make this bad behaviour really obvious. Let’s say that Alice hasn’t completed any tasks in the last four days (but she does have a task that she volunteered for at the start of the Sprint). Raj notices that Alice hasn’t finished that initial task. An acceptable solution to this problem is for Raj to volunteer to help Alice. Alice can’t refuse the help since Raj is self-organizing too. They might sit together to work on it.

Of course, that might not solve the problem. So another technique to use that respects self-organization is to bring it up in the Sprint Retrospective. The ScrumMaster of the team, Sylvie, chooses a retrospective technique that is designed to help the team address the problem. In a retrospective, it is perfectly acceptable for people on the team to be direct with each other. Retrospectives need to be safe so that this kind of discussion doesn’t lead to animosity between team members.

Remember: everyone goes through ups and downs in productivity. Sometimes a person is overwhelmed by other aspects of life. Sometimes a person is de-motivated temporarily. On the other hand, sometimes people become extremely engaged and deliver exceptional results. Make sure that in your team, you give people a little bit of space for these ups and downs. Assigning tasks doesn’t make a person more productive.

What If There is One Task No One Wants to Do?

Dig deep and find out why no one wants to do it. This problem is usually because the task itself is worthless, frustrating, repetitive, or imposed from outside without a clear reason. If no one wants to do a task, the first question should always be: what happens if it doesn’t get done? And if the answer is “nothing bad”… then don’t do it!!!

There are, unfortunately, tasks that are important that still are not exciting or pleasant to do. In this situation, it is perfectly acceptable to ask the team “how can we solve this problem creatively?” Often these kinds of tasks can be addressed in new ways that make them more interesting. Maybe your team can automate something. Maybe a team member can learn new skills to address the task. Maybe there is a way to do the task so it never has to be done again. A self-organizing Scrum Team can use innovation, problem-solving and creativity skills to try to over come this type of problem.

And, of course, there’s always the Sprint Retrospective!

Why Self-Organize – Why Is Assigning Tasks Bad?

Autonomy is one of the greatest motivators there is for people doing creative and problem-solving types of work. The ability to choose your own direction instead of being treated like a mushy, weak, unreliable robot. Motivation, in turn, is one of the keys to creating a high-performance state in individuals and teams. The greatest outcome of good self-organization is a high-performance team that delivers great work results and where everyone loves the work environment.

Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees). Even if this is true, it is still easy for a person to take offence. However, most of the time it is not true. People know themselves best. People are best at assigning tasks to themselves. And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team.

The ScrumMaster and Assigning Tasks

The ScrumMaster plays an important role in Scrum. Part of this role is to encourage self-organization on a team. The ScrumMaster should never be assigning tasks to team members under any circumstances. And, the ScrumMaster should be protecting the team from anyone else who is assigning tasks. If someone within the team is assigning tasks to another team member, the ScrumMaster should be intervening. The ScrumMaster needs to be constantly aware of the activity on his or her team.

I have added a video to YouTube that you might consider sharing with ScrumMasters you know about this topic:

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

At Berteig Consulting we have been working for 10 years to learn how to help organizations transform people, process and culture. The problem is simple to state: there is a huge amount of opportunity waste and process waste in most normal enterprise-scale organizations. If you have more than a couple hundred people in your organization, this almost certainly affects you.

We like to call this problem “the Bureaucratic Beast”. The Bureaucratic Beast is a self-serving monster that seems to grow and grow and grow. As it grows, this Beast makes it progressively more difficult for business leaders to innovate, respond to changes in the market, satisfy existing customers, and retain great employees.

Real Agility, a system to tame the Bureaucratic Beast, comes from our experience working with numerous enterprise Agile adoptions. This experience, in turn, rests on the shoulders of giants like John Kotter (“Leading Change”), Edgar Schein (“The Corporate Culture Survival Guide”), Jim Collins (“Good to Great” and “Built to Last”), Mary Poppendieck (“Lean Software Development”) Jon Katzenbach (“The Wisdom of Teams”) and Frederick Brooks (“The Mythical Man-Month”). Real Agility is designed to tame all the behaviours of the Bureaucratic Beast: inefficiency, dis-engaged staff, poor quality and slow time-to-market.

Studies have proven that Agile methods work in IT. In 2012, the Standish Group observed that 42% of Agile projects succeed vs. just 14% of projects done with traditional “Bureaucratic Beast” methods. Agile and associated techniques aren’t just for IT. There is growing use of these same techniques in non-technoogy environments such as marketing, operations, sales, education, healthcare, and even heavy industry like mining.

Real Agility Basics: Agile + Lean

Real Agility is a combination of Agile and Lean; both systems used harmoniously throughout an enterprise. Real Agility affects delivery processes by taking long-term goals and dividing them into short cycles of work that deliver valuable results rapidly while providing fast feedback on scope, quality and most importantly value. Real Agility affects management processes by finding and eliminating wasteful activities with a system view. And Real Agility affects human resources (people!) by creating “Delivery Teams” which have clear goals, are composed of multi-skilled people who self-organize, and are stable in membership over long periods of time.

There are lots of radical differences between Real Agility and traditional management (that led to the Bureaucratic Beast in the first place). Real Agility prioritizes work by value instead of critical path, encourages self-organizing instead of command-and-control management, a team focus instead of project focus, evolving requirements instead of frozen requirements, skills-based interactions instead of roles-based interaction, continuous learning instead of crisis management, and many others.

Real Agility is built on a rich Agile and Lean ecosystem of values, principles and tools. Examples include the Agile Manifesto, the “Stop the Line” practice, various retrospective techniques, methods and frameworks such as Scrum and OpenAgile, and various thinking tools compatible with the Agile – Lean ecosystem such as those developed by Edward de Bono (“Lateral Thinking”) and Genrich Altshuller (“TRIZ”).

Real Agility acknowledges that there are various approaches to Agile adoption at the enterprise level: Ad Hoc (not usually successful – Nortel tried this), Grassroots (e.g. Yahoo!), Pragmatic (SAFe and DAD fall into this category), Transformative (the best balance of speed of change and risk reduction – this is where the Real Agility Program falls), and Big-Bang (only used in situations of true desperation).

Why Choose Transformative?

One way to think about these five approaches to Agile adoption is to compare the magnitude of actual business results. This is certainly the all-important bottom line. But most businesses also consider risk (or certainty of results). Ad-Hoc approaches to Agile adoption have poor business results and a very high level of risk. Big-Bang approaches (changing a whole enterprise to Agile literally over night) often have truly stunning business results, but are also extremely high risk. Grassroots, where leaders give staff a great deal of choice about how and when to adopt Agile, is a bit better in that the risk is lower, but the business results often take quite a while to manifest themselves. Pragmatic approaches tend to be very low risk because they often accommodate the Bureaucratic Beast, but that also limits their business results to merely “good” and not great. Transformative approaches which systematically address organizational culture are just a bit riskier than Pragmatic approaches, but the business results are generally outstanding.

More specifically, Pragmatic approaches such as SAFe (Scaled Agile Framework) are popular because they are designed to fit in with existing middle management structures (where the Bureaucratic Beast is most often found). As a result, there is slow incremental change that typically has to be driven top-down from leadership. Initial results are good, but modest. And the long term? These techniques haven’t been around long enough to know, but in theory it will take a long time to get to full organizational Agility. Bottom line is that Pragmatic approaches are low risk but the results are modest.

Transformative approaches such as the Real Agility Program (there are others too) are less popular because there is significantly more disruption: the Bureaucratic Beast has to be completely tamed to serve a new master: business leadership! Transformative approaches require top-to-bottom organizational and structural change. They include a change in power relationships to allow for grassroots-driven change that is empowered by servant leaders. Transformative approaches are moderate in some ways: they are systematic and they don’t require all change to be done overnight. Nevertheless, often great business results are obtained relatively quickly. There is a moderate risk that the change won’t deliver the great results, but that moderate risk is usually worth taking.

Regardless of adoption strategy (Transformative or otherwise) there are a few critical success factors. Truthfulness is the foundation because without it, it is impossible to see the whole picture including organizational culture. And love is the strongest driver of change because cultural and behavioural change requires emotional commitment on the part of everyone.

Culture change is often challenging. There are unexpected problems. Two steps forward are often followed by one step back. Some roadblocks to culture change will be surprisingly persistent. Leaders need patience and persistence… and a systematic change program.

The Real Agility Program

The Real Agility Program has four tracks or lines of action (links take you to the Real Agility Program web site):

Recommendations: consultants assess an organization and create a playbook that customizes the other tracks of the Real Agility Program as well as dealing with any important outliers.

Execution: coaches help to launch project, product and operational Delivery Teams and Delivery Groups that learn the techniques of grassroots-driven continuous improvement.

Accompaniment: trainer/coaches help you develop key staff into in-house Real Agility Coaches that learn to manage Delivery Groups for sustainable long-term efforts such as a product or line of business.

Leadership: coaches help your executive team to drive strategic change for long-term results with an approach that helps executives lead by example for enterprise culture change.

Structurally an enterprise using Real Agility is organized into Delivery Groups. A Delivery Group is composed of one or more Delivery Teams (up to 150 people) who work together to produce business results. Key roles include a Business leader, a People leader and a Technology leader all of whom become Real Agility Coaches and take the place of traditional functional management. As well, coordination across multiple Delivery Teams within a Delivery Group is done using an organized list of “Value Drivers” maintained by the Business leader and a supporting Business Leadership Group. Cross-team support is handled by a People and Technology Support Group co-led by the People and Technology leaders. Depending on need there may also be a number of communities of practice for Delivery Team members to help spread learning.

At an organizational or enterprise level, the Leadership Team includes top executives from business, finance, technology, HR, operations and any other critical parts of the organization. This Leadership Team communicates the importance of the changes that the Delivery Groups are going through. They lead by example using techniques from Real Agility to execute organizational changes. And, of course, they manage the accountability of the various Delivery Groups throughout the enterprise.

The results of using the Real Agility Program are usually exceptional. Typical results include:

20x improvement in quality

10x improvement in speed to market

5x improvement in process efficiency

and 60% improvement in employee retention.

Of course, these results depend on baseline measures and that key risk factors are properly managed by the Leadership Team.

Your Organization

Not every organization needs (or is ready for) the Real Agility Program. Your organization is likely a good candidate if three or more of the following problems are true for your organization:

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

I recently had the opportunity to help facilitate a client’s “Innovation Challenge”. Basically, the concept is to get a bunch of people in the room, give them a business challenge and see what they come up with.

I have to say that the format of the workshop that I used is heavily inspired by a training that I did recently called Specification By Example by Gojko Adzic. I strongly recommend this seminar as well as the book. Another strong influence is The Inmates are Running the Asylum… by Alan Cooper. The workshop that I have developed is a sort of hybrid approach, with my own flavour added to the mix. During an early iteration of the workshop, I didn’t have a title and one of the participants suggested “Agile Inception”. I think that title works in a space where Agile is established and well understood (e.g. hopefully this blog). At the same time, this workshop can be run with people who have no prior experience or knowledge of Agile and without even mentioning the word Agile. This is also good in certain environments where people have developed an Agile allergy.

Anyhow, my goal for the day was to facilitate the building of shared understanding of the challenge itself as well as some ways that the organization could innovate around that challenge through conversation and collaboration.

From the opening remarks it became clear that the product at the centre of the “challenge” was actually in deep crisis: a shrinking market combined with shrinking market share. The product had generated approximately $18M in revenue in 2009, compared with $10.4M projected for 2014. That’s half dead in some people’s books. The clear Goal was to reverse that trend, starting with at least $11M in 2015. They needed a powerful jolt of life-giving innovation energy to defibrillate their failing product’s heart.

There were no shortage of ideas about how the product could become better & more profitable. In fact, there were many, many ideas. Too many, perhaps. Once we had established our working agreement for the day, we did a Starfish Retrospective exercise to make visible all of the things that the group wanted to keep doing, start doing, stop doing, do more of and do less of. Many post-it notes were stuck on the board and we left them there as a reminder of all of the things that people were thinking about that could help us to consider how the product and ways of working on it could be improved.

Then we talked about the Goal. True innovation—that is, tangible, innovative results with clear benefits—requires a group to focus on a single, clear, SMART (Specific, Measurable, Achievable, Relevant and Time-bound) Goal that everyone in the organization understands and is committed to achieving. Often times, as was the case with the group on Thursday, taking time to establish shared understanding of the goal can seem redundant and tedious (“we already know what the goal is…”). However, as we learned through the process of working in small groups to re-articulate understanding of the Goal back to the “customer” (the person paying for everyone to be there) this often requires some further conversation. Indeed, when the groups presented their understanding of the Goal, there were gaps that needed to be filled by the “customer”. It took less than 30 minutes to discuss, adapt and confirm the Goal with the customer. The value of this investment of everyone’s time was tremendous. The conversation made it clear that shared understanding had already been established to a degree and enabled the group to build on what was already there to make the Goal “SMARTer” in the minds of all of the participants.

A single, transparent business Goal helps us to innovate with focus—to create the right thing. In addition, we need to develop a single Persona—the ideal, “imaginary” user of the product. The larger group broke into smaller groups for the subsequent discussions. The groups worked separately and generated a the details for a few personas. All 3 personas added value to the conversation. The Persona of “Lisa” was particularly compelling to the “customer” because she had a clear goal of her own and through innovation, her goal could be aligned with the overall business Goal to create a powerful, “new” product that just might reverse the downward trend.

The next step in innovating with focus in order to generate the best ideas possible: build shared understanding of how Lisa can pursue her goal through her experience of the product in order for the business Goal to be achieved. In other words, Lisa needs a story. Her story needs a beginning and an end (for now, until the next story) and all the stages of her journey need to be integrated into a coherent whole.

The last step was for the groups to brainstorm and come up with different ways that the product can deliver Lisa’s story in order to realize the Goal.

I wish I could say more about the really cool ideas that the group came up with, but I am erring on the side of caution when it comes to protecting my client’s competitive advantage.

To wrap up the session, we took a quick, anonymous gauge of how confident the participants felt about achieving the Goal. Of the 13 participants, two gave their confidence a score of 8/10, six gave a score of 7/10, four scored themselves a 6/10 and one was a 3/10, for an average of 6.5/10. Not bad, but clearly some work still to go. So what’s next for them?

Next steps:

Get the technical folks involved in the conversation (ideally, they are there from the beginning)

Build an increment of their solution

Review

Continue the conversation and collaboration to build shared understanding

Re-gauge the confidence score

Iterate

Repeat

The likelihood of achieving the Goal increases with every iteration

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

I am engaged in a learning process with a charity that has undertaken to implement a new model of volunteer coordination based on OpenAgile, an open source agile method. We recently held an orientation with our new volunteers. In the hopes that this information will be useful to others who are trying to innovate on their model of volunteer coordination, here are the instructions I shared with the volunteers. In summary, they cover our process for sharing tasks, the tools we use to communicate with each other, and our use of what we are calling “60/40 time” a twist on Google’s “20 percent time“.

ORIENTATION INSTRUCTIONS:

I. Agile Volunteer Team Process

We are all here to support the charity. We are inspired by its mission and goals, and we want to help in a way that draws on all of our abilities, knowledge, skills, and creativity.

Our team uses a specific system for producing valuable results. We work in Cycles of 5 weeks. The charity’s staff talk with the stakeholders and decide what steps are necessary for accomplishing the organization’s goals. Each one of these steps, called Value Drivers, add up to providing value for the stakeholders once they’re delivered. The staff also decide the priority order for completing the Value Drivers.

In week 1 of the Cycle, there is a planning meeting with all the volunteers who are committed to doing work during the 5 week Cycle. All volunteers are urged to attend and participate.

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.

In week 2, 3, 4, and 5 of the Cycle, the team of volunteers complete the tasks in the Cycle Plan (aka “doing work”).

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.

At the end of the 5 week Cycle, the team presents the valuable results it has produced to the charity staff/stakeholders. Any insights, observations, corrections, etc. are factored into the next Cycle Plan.

II. Communication Tools

Over the time we have worked together, the volunteer team has decided to use a few tools to help us communicate. The main tool is the task wall and sticky notes. The secondary tool is a shared Gmail account.

NOTE: This list of instructions is a working, evolving document; it is not set in stone. Volunteers are encouraged to work together and adapt the way we do things to create a system that works well for all of us.

ACCOUNT INSTRUCTIONS:

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

CURRENT LABELS:

??? – 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.

We want all of our volunteers to get the most out of their experience here. Rather than insisting that every moment of a volunteer’s time be spent on completing tasks on the wall, we ask you to split your time 60/40. We want to give our volunteers freedom to spend a large portion of time doing things that satisfy their motivations while still providing value to the organization. For example, if someone has an interest in building skills in using social media, but there aren’t currently any tasks on the wall related to social media, the volunteer would be encouraged to use 40% of their time using social media to benefit the charity. The remaining 60% of the time is essential for delivering other important results to the organization. We aspire to having a trusting environment, so it is up to you to monitor how you’re spending your time. During progress updates, all volunteers are encouraged to share what they’ve accomplished during their 40% time. This will help other volunteers to learn what motivates their teammates and will give the team information that can be integrated into future Cycle Plans.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

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:

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
included below.

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.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.