The OpenSpace Agility approach has created some questions. Some of these questions, collected from around the web, appear below. Some of the questions are very specific and very interesting (I think.) I’ve included them here. These particular questions are harvested from recent interactions with professional Agile coaches who are active on Twitter.
Q. Guide them through change, but not impose. What if they don’t want to change?
A. Respect the no. Let the org…the self-organizing system…figure out how to address this problem.
Q. Would you let a developer you were paying personally choose their own approach?
A. This is a non-starter kind of question. The typical context of an Agile adoption is an existing organization with an existing IT department or development team group.
Q. Are there any constraints you’d be willing to impose or mandate?
A. OSA tolerates the “imposition” of an Agile direction, even though that can be a problem. The Agile direction has to be in service to something- something besides Agile itself.
An Agile direction, articulated by formally authorized leadership.
Agile: in service to what?
Q. So you are willing to impose constraints?
A. The idea is to open up a conversation about how Agile ideas can help. We invite the folks to play with the various Agile practices. Iterations, Retros, and so on. We explain to them that they can try any practices they like which do not offend the majority of the Agile Manifesto’s 4 values and 12 principles. We encourage them to know the Manifesto well, and find practices that align with those values and principles.
Practices change, principles don’t. We explain that and turn them loose into a time of “authorized experimentation.”
Q. Deliver working software every two weeks?
A. Iterations are an Agile idea that aligns with the Manifesto: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Let (aka “authorize”) the teams to experiment with that!
Q. Work in a cross functional team?
A. Once again, allow experimentation. Do not “mandate collaboration. “
Q. Plan in functional slices of the product?
A. Allow experimentation. Do not mandate behaviors. Instead, ask them to align everything they do to the Manifesto.
Q. Those are constraints. They are also agile process. But we can’t say that we are mandating agile?
A. The output from an experiment is learning. In OSA we invite experimentation. We invite learning.
We make the distinction in OSA between the naming of an Agile direction, and the mandating of specific practices. Direction-setting is an important activity for formally authorized leadership. In OSA we stop short of mandating specific practices. Instead we invite the teams to experiment. Martin Fowler in 2006 writes the important essay “The Agile Imposition”. This is essential reading for anyone considering mandates of Agile practices. Quoting that essay: “So I hope I’ve made clear that imposing agile methods is a very red flag.”
Q. I’m starting to wonder if there is a nuance here that I am missing. This makes NO sense to me.
A. The nuance is: human engagement powers successful process change. Disengagement can slow down and eventually ruin your process-change plans. Therefore, engagement is essential. OSA is all about creating engagement on the premise that human engagement is absolutely essential.
Q. Are we really talking about an approach or disposition? We invite rather than mandate? Like non-violent comm.?
A. Invitation is respectful and can create engagement. Coercion and mandates are fundamentally disrespectful, and can create disengagement.
Q. “…I would place constraints on team such as I want X feature in 2 week Quality MUST be high. Outcome focused. “ What’s the difference between that and mandating agile?
A. The difference in the OpenSpace Agility approach is this: we place the people inside a period of time when the primary outcome is learning, through experimentation. The period of experimentation is actually a designed experience. It is designed as a rite of passage. See also http://en.wikipedia.org/wiki/Rite_of_passage
Q. Is it the social implications of agile we don’t want to mandate? Not the process aspects?
A. OSA is a sociological approach based on opt-in engagement. Remember, the premise is that human engagement is essential. Jeff Sutherland has data on Scrum (see http://assets.scrumfoundation.com/downloads/2/scrumpapers.pdf?1285932052) saying teams can double productivity and double again. A central hypothesis of OSA is that higher productivity is correlated with higher levels of human engagement.
Q. Like, I won’t mandate you trust someone? Or be vulnerable in a retrospective? Or create safety for someone?
A. I’m sorry if you think you believe that this kind of thinking and action can be forced on someone by some kind of external authority. I have never seen it done.
Q. I won’t mandate you like each other, or work as a high performing team?
A. High performance is mostly a function of self-organization. Self-organization is a goal of OSA. We create the conditions for self-organization to emerge. We do not pretend we can manufacture or mandate it. In OSA we create the conditions and the conditions always include a legitimate (opt out with no sanctions) invitation.
Q. I’d suggest there is no way to mandate that stuff anyway. You can only mandate behavior or process compliance.
A. In a prison, you can mandate behavior compliance and process compliance. Are workplaces prisons? I guess some kind of are…maybe.
Harrison Owen is fond of saying that the Law of 2 Feet is always active—that is, people are exercising their options, including the option to disengage. A central premise of OSA is that you cannot actually mandate behavior or process compliance, because people “check out” and disengage on you instead of playing your mandatory-to-play game. Good games have opt-in participation. That requires the consent of each player.
Q. Like, my desired result is you work in a team & deliver a working tested increment of product every two weeks?
A. Yes, this is much closer to the idea of OSA: we name the issues we are facing , we suggest some experiments with Agile practices. We inspect the experiment. The constraint is “use any practice that supports and is not obviously in conflict with the 4 values and 12 principles of the Agile Manifesto.”
Q. Again, we must be arguing some semantic nuance I don’t understand
A. Again, the central idea is very simple: Engagement is essential. Great teams, great products and great organizations exhibit very high levels of human engagement. Engagement is essential. Mandates tend to dampen engagement while invitations (such as an invitation to attend an Open Space meeting) tend to increase it. Engagement is essential.
Q. If you are willing to mandate team based iterative and incremental delivery, how is that not mandating agile?
A. First, learn to differentiate between mandating an Agile direction and mandating specific Agile practices. The constraint is is “use any practice that supports and is not obviously in conflict with the 4 values and 12 principles of the Agile Manifesto.” From there, common sense governs. Quote from Martin Fowler, Agile Manifesto signatory: Imposing Agile methods on a team is in conflict with the principles of Agile and have been since inception.” See also http://newtechusa.net/agile/people-then-practices/ and http://martinfowler.com/bliki/AgileImposition.html
Q. (say) they are failing now doing ad-hoc or waterfall. What if they want to do an 18 month waterfall process? Can I ask them not to do that?
A. See the above question. In OSA we start and end in Open Space. In between we experiment with practices, using the Agile Manifesto for guidance. Make sense? Quote: “An important consequence of these values and principles is that a team should choose its own process – one that suits the people and context in which they work. Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.” – Martin Fowler, “The Agile Imposition”, see http://martinfowler.com/bliki/AgileImposition.html
Q. Okay, you’re willing to mandate producing value every two weeks?
A. No. There is no mandate, there is an invitation to experiment and create learning. Again, the Agile Manifesto is the guide: Is the idea of producing value every two weeks consistent with the Manifesto? Yes, it is. The difference in OSA is that we are inviting people to play a game, we are not mandating this or that.
Q. What kind of result then can I mandate? Valuable software on some regular interval?
A. Why mandate a specific outcome like iterative delivery when you know you need the human engagement of the team? In OSA we teach the Manifesto and invite the teams to try an experiment, for example experimenting with Scrum. The difference between the mandate and the invitation is huge. The mandate is experienced as command-control and coercion, both of which reduce engagement. The invite is experienced as a respectful request to engage in a game. Every good game has opt-in participation. See also http://newtechusa.net/agile/how-games-deliver-happiness-learning/
Q. What if they want to do an 18 month waterfall process? Can I ask them not to do that?
A. In OSA, we “explain the why” of the Agile experiment, in an invite to attend an Open Space meeting. That invite is an invite to explore a theme, a theme like “Agile: In Service To What?” or “What Do We Want Agile to SOLVE?” We then schedule another Open Space about 12 weeks out. In between, we authorize experimentation with Agile, defined as using practices that support the Manifesto principles. Is an 18-month waterfall process consistent with that? No. And in this scenario, the folks themselves will not go that way, because an 18-month waterfall would not be in alignment with the Manifesto principles.
Q. Can we mandate that people show up and do work or do I have to invite them and coach them on that 2?
A. This is a silly question.
Q. I am desperately trying to understand the POV here. I am trying to understand that nuance. What is the difference between mandating agile and mandating some of the other outcomes that folks have suggested? Maybe you can do a post for me or something, because honestly, I am really, really confused.
A. A central premise of OSA is that engagement is essential. Mandates reduce the sense of control and belonging. This kills engagement. It is really, REALLY this simple.
Q. Is the nuance I am missing that people have to be invited to participate, but if they don’t I can coach them out?
A. The nuance you are missing is that the very people who are allergic to your mandate are often the people who have the very best ideas on how to make Agile work inside their team and inside their company. Inviting all the people to experiment and then inspect the results has a way of getting people in. Those who do not get in receive feedback from peers on what is working and what is not. A goal of OSA is to get everyone in.
Q. Is the nuance I’m missing that we have to take a disposition of invitation, we have to lead, coach, and help people along…
A. Yes, a premise of OSA is that engagement is essential and that mandates can kill engagement. Therefore, we replace that disengaging mandate with an engaging invitation to play a game: the game of experimenting with Agile practices to see if they actually work.
Q. …we all agree that they can’t do waterfall, not produce incremental value, allow defects to carry forward, else they leave?
A. We issue an invitation to attend a themed Open Space meeting. After that we play with practices and see if they serve. Quote: “Not just should a team choose their own process, the team should be control of how that process evolves.” – Martin Fowler, The Agile Imposition. See http://martinfowler.com/bliki/AgileImposition.html
Q. I’m not pushing a side, i am trying to understand and no one can explain to me what it means not to mandate.
A. To not mandate means to invite. To be inviting. To replace the coercive command-control mandate with an invitation to play a game of experimentation which will be inspected. This tends to engage people. The premise is that engagement is essential.
Q. Dan explicitly asserted that you cannot mandate an agile transformation. We have done this many times with great success.
A. I love success stories and I am sure you have many. Let’s run the numbers. Since 2001, the year of the Agile Manifesto, that’s about about 13 years, I’m guessing there have been over 10,000 attempts at successful adoption of Agile. (That’s probably low). I’m also guessing that 99% of these have been implemented as mandates of Agile practices. Right? Is that a fair and reasonable assumption? By that measure, the 500 or more legitimate success stories are actually outliers! Those 500 success stories represent about 5% of the sample, meaning there is a 95% lack of success is this hypothetical example.
Say there were actually 1500 verifiable success stories out there, about the mandate of Agile practices. In the language of wagering, that means you’d still be about a “6 to 1 dog” (with odds about 6 to 1 against you) when making that bet.
There’s loads of experience data. Where in that data is the overwhelmingly positive evidence that mandating Agile practices actually works? There is a lot of data from organizations like Gallup which shows that engagement is correlated with things that are really good, like employee retention and employee morale and better products.
Question: Where is the evidence that these mandates of Agile practices are actually increasing employee engagement?
Q. So I am trying to understand what he means. There is some nuance I am clearly missing. Trying to understand what that is.
A. The nuance is very simple. People have to be willing. You can create indirect opposition, resentment and so on by forcing agile practices on people without their consent. The clear solution is to replace the mandate of practices with a genuine invitation to experiment with them.
Q. I think you can mandate going to agile, but then have to win the hearts and minds of the people involved.
A. Almost. You can win the hearts and minds of the people involved. Mandates create feeling associated with a loss of control and belonging. In his book DELIVERING HAPPINESS, Zappos CEO Tony Hsieh explains how the senses of control and of belonging are essential for human happiness. See page Appendix A page 233. When people lose a sense of control, they may tip into the state of Learned Helplessness. Martin Seligman did experiments that exposed this dynamic. It stems from a lack of perceived control. Is this what we want to start happening inside our Agile adoption programs? See also: http://psychology.about.com/od/lindex/f/earned-helplessness.htm and http://youarenotsosmart.com/2009/11/11/learned-helplessness/
Q. But if they choose not to participate, and that is their choice, they may have to find employment elsewhere.
A. This is true. However, in OSA, the adoption is emergent and adaptive—not prefabricated and forced via a mandate or coercion. This is a very big difference from the mandated approach. In the OSA approach, the adoption has emergence baked in from the beginning. Everyone is invited and those who opt-in are co-creating it. Everyone has a decent sense of control and strong sense of belonging. The group senses things together, along with the person who no longer fits. Authority does not tell the person they are fired. Instead, emergent order creates a shared sense of agreement about reality by and between the members. When the new culture of learning takes root, the unengaged person and the tribe both realize what is no longer working.
Q. I’m not suggesting we enslave people, but if I decide to run my company using an agile approach that is not debatable.
A. As the owner, if a command-control approach works for you, great. Keep doing that.
Q. I will teach, coach, mentor, help them understand, be kind and gentle along the way and give them time to learn.
A. That is a good idea, consistent with the Open Agile Adoption approach.
Q. But if there is no option but to do agile or leave, that is fundamentally a mandate.
A. In OSA, formally authorized leadership works from a belief that people actually want to do great work, and will do great work if you create the conditions for it to emerge. Essential elements of these conditions include a sense of control and a sense of belonging. Invitations to engage can encourage both. The sense of control and belonging show up when people are actively making decisions about the customization and tailoring of practices they are choosing with others in the group. The co-created agreements associate with a sense of control and membership.
Q. Maybe as you suggested the word mandate carries some baggage for people that I don’t have. Like calling people resources.
A. What it is called does not matter: if you reduce the sense of control and sense of belonging below a certain level, or lower, the participants will stop playing the game and check out. When that happens, it’s “game over” and the Agile adoption is dead in the water.
Q. Ah, so mandate implies one-way communication. That is insightful… I didn’t interpret the word that way.
A. Yes, and an invitation is a two-way communication. The OSA approach replaces mandates (which can feel coercive) with an invitation (which can feel inclusive.)
Q. Okay, so that is insightful for me too. I think agile is a way of working, but it doesn’t require an agile mindset.
A. Yes, and if there is no Agile mindset at the beginning, that probably means the folks at least have to be consenting to what is happening. If there is no mindset and there and no consent, what is there? Answer: compliance, resentment, learned helplessness. See also http://en.wikipedia.org/wiki/Learned_helplessness#Summary
Q. If I act with agility, the feeling of agility will follow.
A. Maybe. If you are willing. If you are experimenting. If you have actively consented to play the game. If you have AGREED to “act as if”, to “suspend disbelief”, to “pretend this might work” for a little while.
Otherwise, maybe not. The feeling of agility is probably not going to happen if you are feeling compelled, coerced or forced. If you are feeling a low sense of control and a lower sense of belonging.
Where there is no consent, there is often a general feeling that something just ain’t right. At first, you may have difficulty being able to name and identify these feelings.
Q. I don’t believe that it is an effective strategy to transform 6000 people through cultural indoctrination
A. Open Agile Adoption is not a cultural indoctrination program. There are NO attempts at “persuasion” to get “buy-in” from teams, in OSA. This is because genuine engagement is deeper than that.
The OSA method is a way to introduce process-change through a consent-based approach that uses invitation and the use of Open Space to create an experience. The OSA experience is designed to encourage self-organization at scale. It creates the conditions for a rapid and lasting Agile adoption.
Q. I believe you have to get the systems in place to enable agility and that will allow the mindset of agility to follow.
A. A core premise of OpenSpace Agility is that people want to be part of creating the solution (sense of belonging) and want to consent to that (sense of control). When you force Agile practices, there is no experimentation. There is no belonging as there is no shared-agreement. There is simply a forced march to collaboration. A forced march to “mandated collaboration”. This is a terrible idea.
Q. I do believe [OpenSpace Agility] is very contextually sensitive, not impossible to do it the other [mandated] way.
A. Almost every big change in almost every organization is context-sensitive. Right?
A core premise of OpenSpace Agility is that engagement is absolutely essential. Another core premise is that a mandate of practices can quickly reduce levels of engagement by reducing the senses of control and belonging. If this is true, then OpenSpace Agility is widely applicable. It is applicable in almost any enterprise that wants a rapid and lasting Agile adoption.
Q. Dan just happened to say that my way doesn’t work and there were no examples of it working. I disagreed and offered to introduce him.
A. I say that mandates reduce engagement, and that engagement is essential for a rapid and lasting Agile adoption. If your way is to mandate, I am doubtful it creates rapid and lasting Agile adoptions.
I am sure you have some success stories in your sample. However, the sample size across the entire Agile experience is at least 13 years of mostly-mandated Agile adoptions, worldwide! That might be 10,000 or more attempts at mandated Agile adoption. So, if Agile-practice mandates are a good bet, and actually work, we’d by now be able to point with pride to thousands upon thousands of verifiable and unmitigated success stories. Right?
Thirteen years and thousands of attempts to force Agile practices. Where are the thousands upon thousands of verifiable success stories?
Why is it a crime to ask this question?
Where is the “mound of data” with verifiable results that strongly support the mandate of Agile practices?
Q. The only thing I wanted to assert here is that both ways can work.
A. If Approach-A works 15 time out of 100, and Approach-B works 85 times per 100 trials, both can be said to work. At issue is the expectation. One, Approach-A, has very negative expectation, we can expect on balance to fail (LOSE MONEY) most of the time. The other, Approach-B, has very positive expectation; we can expect on balance to succeed (WIN MONEY) almost every time. Both can be said to work some of the time. They have widely different “expected value.”
The mandated approach might work maybe 15 times per 100 attempts. Are those actually good numbers? Are we actually happy with that? Today, we are collecting data on a NEW approach. An approach that focuses on engagement, on the premise that human engagement is essential from the very beginning.
The OSA approach assumes human engagement is essential. It replaces the mandate with the invitation. It is an approach that attempts to improve the odds for success in getting a rapid and lasting Agile adoption, by acknowledging the reality of imposed mandates and replacing those mandates with opt-in invitations. The method includes leadership storytelling, the use of Open Space, deliberate experience design, game mechanics and more, all in service to the creation of rapid and more lasting Agile adoptions.