Mar 042014
 
Agility 2008 May 04

Agility 2008 May 04 (Photo credit: Cynthia Blue)

Mere days ago, Mike Cottmeyer wrote an article called “Managing Risk and Uncertainty in Agile.”  I think the main ideology is captured in the following quote:

I think [treating software as inestimable] is a mistake. If we keep pushing to treat everything like R&D, without understanding the delivery context we’re working within, the whole agile movement risks loosing [sic] credibility with our executives. If you remember from our earlier conversations, most companies have predictive-convergent business models. We may want them to be adaptive-emergent, but they aren’t there yet. We’ll [sic] can talk about how to move these folks, but for now we have to figure out how to commit. (Emphasis mine)

In other words, since most organizations aren’t ready to be agile, we need to ditch agile presuppositions and practices that would make them scared or uncomfortable and treat software development like deterministic work.  He also explains how the metaphor of building a house should inform our understanding of agile software development and what an impact that metaphor has had on his own understanding and practice.  Ultimately, what he wants agile teams to do is give up-front project commitments and estimates.  He (rightly) anticipates that people will say this is not agile, but answers this objection with something along the lines of, “Yeah, so?”

I certainly agree with Mike that just because something doesn’t line up with Ye Olde Agyle Orthodoxye, that’s not a reason to reject it out of hand.  “That’s not agile” is actually not a valid criticism of anything – you have to go on to explain how the idea or practice would hamper agility or has some other harmful impact.  But my interest here is not to refute the practice of up-front project estimates, commitments, or explain the dozens of ways in which developing software is completely unlike a house and why that is a very wrong-headed and misleading metaphor for software development.

My interest is in those emphasized statements: the idea that we have to learn to cater to an organization’s established, outdated worldview and practices until they change into an agile organization – somehow.  This kills me, and it’s disappointing to see it coming from a company that purports to train people in agility and transform their organizations (who’s transforming whom, exactly?).

It’s like that John Mayer song, “Waiting for the World to Change.”  That song has the worst message, which is, basically, “There’s a lot of institutionalized power opposing good social change, so I’m just gonna quit trying until something changes that situation – somehow.”  When you try to shape agility into the old processes and expectations, that’s basically what you’re saying.

Agility is a challenging and transformative force.  It’s meant to create pain points.  It’s meant to challenge processes and how we think about creating value.  This is what’s supposed to happen.  If greater agility is difficult to manage with an existing budgeting process, guess what’s supposed to happen!  The budgeting process needs to be examined.  If greater agility is difficult to manage with your established project management practices, then you need to look at how your PM processes should change.  Agility is something that affects an entire system.  You can’t just agile up a development team, leave everything else intact, and call it good.

So, I call upon agile coaches, consultants, advocates, and well-wishers to challenge rather than accommodate.  Don’t look for ways to make agility more palatable.  That doesn’t mean everything needs to be uprooted all at once, but it does mean that greater agility should be pushing outward to change existing structures, not the other way around.

If you make agility work in the ways an organization is used to, then you’ve made it irrelevant.  You are an enabler.  You are part of the problem.  They have cancer, and you’re trying to get them to smoke a nicer brand of cigarettes.

If you think you won’t be able to get clients if you rock their boat too much, then do us all a favor and let the market naturally select you out of it so people who can actually help your clients can pick them up.  Nobody needs you to institute daily standups and a backlog and allow them to think they’re ready for unbridled productivity.  Some of you are CONSULTANTS for Thor’s sake.  CONSULT!

All of you who, even now, are thinking of how to change your practices around to fit better with older presuppositions forged in an older business environment – all of you who think agility needs to learn to deliver what project managers expect in order to be viable – all of you who think scaling agile needs more command and control – all of you who have never stood up to a client because it’s in their best interests – I call you to courage.  I call you to challenge those presuppositions instead of accommodating them.  I call you to war against high-risk delivery, false and harmful metrics, misanthropic management philosophies, and waste rather than collaborating with the enemy.

As you work with your organizations, ask yourselves, “Am I doing this because it improves the value delivery process, or am I doing this because it’ll work more easily with the way things are?”  In most organizations, if it isn’t subversive, it probably isn’t agile.

Enhanced by Zemanta

  10 Responses to “A Call to Courage”

  1. Thanks for your comments on my post. You’ll find if you continue to read my post that I am focused on the process of transformation. We are not trying to encourage revolution, we are trying to help companies deeply entrenched in old ways safely make the switch. If you knew me beyond a few of the posts you mentioned, you’d find that we probably have the same end goal. I suspect we’d disagree on the best way to get there. The companies we help don’t have a problem with our approach and I’m happy to explore any of our case studies with you. I think you presume too much about me and my company.

    • Hey Mike, it’s a totally fair criticism that I’m not too familiar with you or your company’s actual work in the trenches. My critique was purely based around something you wrote, and I do stand by that critique of what you wrote while also acknowledging that, in practice, you might end up being a lot better than one blog post might imply. Lord knows I’ve written things that deserve similar criticism.

      I would suggest, however, that of course the companies you work with wouldn’t have a problem with the approach outlined in your post. You’re basically affirming all their incorrect assumptions. There’s nothing uncomfortable about any of that other than the general disruption that comes with changing practices. Who wouldn’t love that? Our consultant is basically telling us we’re right. The real benefit of agility is changing the way a company understands their work, not changing this or that individual practice, and just as you have your own experiences, I also have my experiences, and I can tell you that agility does not need to provide traditional estimating to achieve credibility.

  2. Different companies need different approaches when adopting agile. I stand by my post as well but you have to realize the kinds of companies we work with can’t do a radical switch to agile or it will get crushed. I’m not telling people they are okay where they are, we are laying out a path to get them where they need to be. I don’t have the luxury of being an idealist, folks are willing to go down the path, but they need that path made clear. They need to understand how to make and meet commitments while they are learning to become more adaptable. We advocate a fundamental refactoring of the entire organization and underlying tech stack, not painless I assure you, but you don’t start with radical culture change and anarchy. It will get crushed… you’ll find my my writing that I don’t advocate leaving people where they are, but I’m not naive about what it will take to transform a major company. I write about transition states and transition patterns. I use my blog to explore ideas and willing to learn. When you read my stuff, think about how you’d change 1000 people, functionally soloed, tightly coupled legacy software, etc. It is a non -trivial exercise. I promise you we have more courage than you give us credit for. We tell people that if they are not ready for the pain, to make radical changes, don’t hire us. We clearly articulate what their journey will look like and walk away from deals if we don’t have the right level of executive aponsorship. We will wait to sell the deal until we get the level if influence we need to make meaningful change. I tell my sales guys to walk away from deals all the time. That said, we have no problems selling work. People respect our honesty and integrity in the sales process. I think it’s too easy to attack people on the web… the ine blog post I wrote should be taken in the context of the previous 500+. We are doing good work, the right work, for the clients we work with. Most folks don’t sell I to the clients with the breadth if support we are able to get. We are in the eye if the storm every day doing the hard work. I’ve got no time for dogma. I have to help these clients where they are and help get them where they need to be. Thanks for your posting my comment and your reply.

    • Hi Mike,

      Well, I think the largest company I consulted for was 3000 people distributed worldwide. So, not enormous, but not insignificant, either. I want to say that I totally agree with the concept of evolutionary change. I firmly believe that you need to take a company where they are at and make evolutionary change from there in 90% of the cases.

      However, my main issue with your blog article is that you quite clearly state that agility has no credibility unless we can provide up front estimates like companies are used to. I think that’s completely wrong. No, I know that’s completely wrong. Maybe it isn’t fear driving that position for yourself, but it drives it for a lot of consultants. It was only made worse that you used the house-building analogy to support your point – an analogy which has caused tremendous problems for agility because it defines software development as deterministic work. These are points on which organizations are entrenched in wrong thinking, and that thinking needs to be challenged, not affirmed.

  3. You’re digging quite a hole for yourself here Mike. Your support for authority imposing Agile practices on teams is in complete opposition to Agile principles.

    Reference: Essay by Martin Fowler, 2006, The Agile Imposition:
    http://martinfowler.com/bliki/AgileImposition.html

    Quotes from that essay:

    “Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception.”

    “Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.”

    “Not just should a team choose their own process, the team should be control of how that process evolves.”

    “…I’d rather have a team work in a non-agile manner they chose themselves than have my favorite agile practices imposed upon them.”

    “So I hope I’ve made clear that imposing agile methods is a very red flag.”

    Sorry, forcing teams to adopt specific Agile practices kills engagement. It’s dumb and misguided and off by a mile.

    If these mandates actually worked, we’d be pointing to thousands and thousands of ongoing success stories. We’re not.

    Something has to give.
    http://newtechusa.net/agile/deviation/

    Here one way out of the mess: replace those awful mandates with genuine invitations to write the story of the Agile adoption.
    http://www.OpenAgileAdoption.com

    • Dan,

      If you simply left it to your children to eat whatever they wanted, what do you think they’d eat? They aren’t born knowing what a balanced diet is, and have to be shown that by their parents. As parents we have to reinforce positive choices and dissuade unhealthy ones. We also have to learn when it’s OK to let them have something “bad”.

      While there are tons of issues with current management practices, saying that all “imposition” is bad is at best an attempt to create a false dichotomy. Someone, somewhere in an organization is trying to improve somehow by suggesting that their software development efforts should try using an agile approach. That’s a totally reasonable thing to expect, and any company not trying to improve is doomed to failure.

      As a coach & practitioner, I have seen “organic” or “grassroots” approaches fail and “imposed” approaches yield good improvements. I’ve also seen success from organic/grassroots and horrible impositions.

      It depends on the organization and the people within it. Just like Agile.

      Dave Rooney

  4. Dave,

    Thanks for your comments. I appreciate your interest in the issue of invitations vs impositions in Agile adoptions.

    Adults are not children. The assumption is that adults want to do great work and will, if they are engaged.

    The hypothesis is that engagement is essential, if people are to do great work. Another hypothesis is that mandates and impositions reduce engagement.

    In the olden days, teams intentionally chose Agile, often without asking management for permission. They made a choice, and engaged. The teams consented to experiment with Agile practices.

    That’s why it worked!

    In the current day, Agile is mainstream and formal authority assumes is it correct to impose Agile practices on teams. This is a well-intentioned yet gravely serious error.

    Everything good depends upon human engagement. The imposition of Agile practices was warned-against by Martin Fowler in 2006. He is a Manifesto signatory. Presumably he is a believable person. I believe his logic is valid.

    That Essay:
    http://martinfowler.com/bliki/AgileImposition.html

    Quotes from that essay:

    “Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception.”

    “Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.”

    “Not just should a team choose their own process, the team should be control of how that process evolves.”

    “…I’d rather have a team work in a non-agile manner they chose themselves than have my favorite agile practices imposed upon them.”

    “So I hope I’ve made clear that imposing agile methods is a very red flag.”

    Related Link: THE POWER OF SCRUM
    http://www.amazon.com/The-Power-Scrum-Jeffrey-Sutherland/dp/1463578067

    Quote from that book: written by Jeff Sutherland. Sutherland, a Manifesto signatory (like Martin Fowler,) the co-creator of Scrum…

    “You know as well as I do that if the team really doesn’t want to use a methodology, IT WON’T WORK. (emphasis added.) Let them make their own assessment.” -POWER OF SCRUM book, page 31 (page 37 in earlier versions)

    Related Link: People Then Practices
    http://newtechusa.net/agile/people-then-practices/
    “Open Agile Adoption [3] is a sociological technique that uses invitation instead of mandates to get a good and lasting Agile adoption. It focuses on engagement of people, THEN practices. It incorporates invitation, Open Space, game mechanics, storytelling and most importantly, a “rite of passage” structure to help actively manage the substantial fear and anxiety that comes with new ways of doing and being.

    “Any technique you want to use is OK, provided you show respect for the people who do the work. That usually starts with an invitation. If you issue mandates, you are asking for trouble.”

  5. Before I ever begin contemplating doing something to grown adults which I think is “bad”, and before I start comparing myself to the parent role in a consulting relationship with my client’s workers that casts them in the role of “children” I always want to check in with reality, as a kind of sanity check.

    Experiments are the best way to allow reality to penetrate my thick, dusty skull. It’s really important to climb down out of my head, the agreement reality its running on, see what is so with the particular setting confronting me, rather that resorting to judgements, comparisons, classifications and default coping policies…and observe what people ACTUALLY DO when given the free choice of opting in.

    Open Space Technology is the best way I know how to empower everyone involved with ANY kind of transformation (above and beyond agile per se) with free choice. It’s all about informed consent, folks!
    Remember that thing you demand from your physician? -Yeah that thing! All the clients and their workers want that too.

    My real-world experience has been totally different than what my imagination conjures up. Historically, the vast majority of each set of cohorts, the adults who do the work, choose agile. -With all its risks and uncertainty.

    So, after you’ve done some form of real world experiment based on Open Space Technology, in the theoretical case where all the workers decline or defer trying agile, then and only then do your rationalizations of committing “bad” acts even begin to become relevant.

    I will add just one point here: I have not yet observed Mike Cottmeyer or Dave Rooney counter the Invitation Based Change movement with, “I tried Open Space and it ruined everything. The client never go agile after the damage Invitation had done to them.”

    Maybe they never rebuttal with such claims because deep down, they know that nobody would ever believe them. Maybe if their clients even knew Invitation Based Change was an (low cost/no cost) option, they would want to try it before resorting to coercion.

    • Hi Jon,

      Since I’m a consultant, I have to operate entirely out of informed consent. I can’t force anybody to do anything, even if I wanted to. I sometimes joke with my colleagues that organizations pay me a lot of money to ignore me, sometimes.

      At the same time, while I agree with most of what you said, experimentation does not happen in a vacuum. While every organization is different and you can’t just go in and drop a bunch of “best practices” on them, they also aren’t the first organization ever to deal with these issues such that we have to re-establish every concept from the ground up, and in fact, it’s this body of expertise that is at least partially the reason organizations bring in a consultant.

      You used the analogy of a physician. Well, when I go to the doctor, I don’t want her to say, “What do you think is wrong? What do you think the best way to fix it would be?” I want her to give me her advice. It’s still up to me whether I take it or not, and I’m free to do my own research or what have you, but at least part of the reason I went to the doctor was to get the benefit of their expertise that comes from their education, their experience, and having seen the same symptoms in dozens of other patients.

      I think there’s a balance to be found, here, between authoritarian models (like parent-child) and therapy models where an agile coach just facilitates a client talking through their own issues. I realize not every agile coach works that way, nor do I expect all of them to do so. However, in this article, I was addressing the issue of coaches not challenging the assumptions of their clients. Challenging assumptions is an incredibly valuable thing to offer anyone.

  6. Hello Philip,

    I’m keen to add to your thoughts on client assumptions, and follow your lead and join in on the recent conversation on this subject.

    Client Assumptions

    One core client assumption and one that is deeply implied is:

    “Engagement of the employees in the actual process of changing is not actually essential for lasting success.”

    This assumption is typically reinforced by the Agile service delivery salespeople in various ways. There is reassurance that the big-bang approach is going to work– without any need to check on what the people in the organization actually want, think, or feel about it. This seems misguided to me since “Respect for People” is a core pillar of Lean/Agile thinking. I admit I may be missing something essential in my line of thinking on this.

    The basic assumption is that the practices (customized though they may be) will prompt good results from both the willing and the unwilling, the engaged and the disengaged alike. Everything will be OK. As long as we do the practices and make “structure” changes to support them, everything will be OK.

    But wait. Really? Is that really true? Doesn’t the Manifesto encourage trust in “motivated individuals?” That said, I admit I may be barking up the wrong tree.

    But maybe not.

    To put a fine point on it, is there *any* lasting KPI improvement that comes from disengaged people? People who resist the change in part because they have no say in the writing of the new story?

    Put another way, is engagement of the affected employees actually a critical success factor in any genuine and lasting Agile change?

    Or is employee engagement completely incidental to the process of successfully changing?

    Or is there some shade of grey here I am missing?

    I’m eager to learn more about your thinking about on this question. I experience you as a keen thinker and a person who builds opinions and conclusions on very sound premises.

    And so it is with some anticipation that I await your reply to my inquiry.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)