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

  7 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.”

 Leave a Reply

(required)

(required)

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=""> <strike> <strong>