[1] http://danielwildt.wordpress.com/2011/05/18/spike-solutions-why-the-world-would-be-better-if-development-teams-use-this-as-a-default/

Thanks,
@dwildt

One thing that really bothers me is when a company wants to go agile, but they put the process in a position to fail. Either not allowing it to be used to its fullest potential (afraid of the short term risks/slow down as their teams learn the process and make it their own) or they only allow it to be used by a small team on a project that’s not overly important to the company. In both cases I’ve seen upper management state that agile isn’t all that effective because it didn’t produce the results they were expecting. Sadly at that point their minds are made up and it becomes even more of a struggle to introduce agile.

A couple of months ago I was talking to a guy about the software development practises in the company he contracted to. He was saying that it was a mess and that the teams hadn’t delivered anything in months. He was brought in to “sort it all out”, and was looking at Scrum as a way to do this.

He had his work cut out for him, management “fully” supported agile, loved the concept, seemed to know a bit about it and its successes. So what was the problem? Unfortunately they saw it existing only within the development team, and did not feel they needed to change at all. And this is where he was fighting his biggest battle.

We continued talking for a while and I finally asked him the name of the company he was contracting to. Reluctant at first, when he told me I could have died. This company had been promoting for some time that they were agile.

The team I work with live and breathe the agile principles, but we do not yet call ourselves “agile”. We have external forces that constantly challenge us and strongly believe that our practises are not yet to the standard of what would be considered agile. We are happy to tell people we are working hard towards agile and I believe we have the right people and company structure to get there.

We do have a greater dream though, that one day we won’t need to be branded “agile” or “waterfall” or “Scrum” etc… and just be known as a team that consistently delivers kick-ass software that exceeds the expectations of the market.

1. Read “What Got You Here Won’t Get You There” by Marshall Goldsmith.
2. Give the book, and these instructions, to your boss.

;-)

My problem with a gradient model is that it implies they will get there eventually. I don’t think there’s much evidence to support that, and there are a number of reasons to think otherwise, including the Crossing the Chasm model and the extent to which Agile approaches require different power structures. So I would rather we have a model that conveys the truth of the situation as best we can discover it, rather than what we have now, which is the one most useful for promoting adoption efforts.

I’m curious what the road to Agile looks like and believe in assessing maturity along a gradient more than making a binary distinction of Agile or not. That said I think you make an important point that we can easily get lost in the weeds if we are not keeping a focus on the creation of valuable software.

We agree that there are basically two products. Where we disagree is whether both of them are truly Agile. I think the post-chasm product — the one that people have purchased when they say they are “doing Agile” — is not in fact what any of the early adopters had in mind. In particular, I don’t think continuous improvement is enough to be Agile.

The Agile Manifesto comes with a very specific set of values and principles. A key one is, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Many, many of the alleged Agile adoptions these days don’t qualify. Other priorities are primary, but nobody calls this out as a problem.

Which I understand: pointing out uncomfortable truths is hard and rarely profitable. Hell, even noticing the uncomfortable truths is hard. As Upton Sinclair wrote, “It is difficult to get a man to understand something when his salary depends upon his not understanding it.” And right now, the salary of a lot of Agile consultants and certified-in-two-days Scrum Masters depends on not understanding that what they’re doing is not Agile as meant by the people who created it.

I started off applying Agile in startups (as you know – you heavily influenced my early thinking over Thai curry one afternoon in Oakland) and I now apply it mostly to larger companies as a coach for Rally Software.

It occurs to me that these two groups map somewhat to Moore’s distinctions of early and mainstream markets pretty well. That said I’m sure there are many startups that are more conservative and mainstream than early adaptors.

I think both groups have significantly different needs and in a sense Agile is a different product for each market.

For early adopters it’s relatively easy to keep the “why” of the Agile conversion in sight. The teams are small, the pain is well understood (or acutely felt) and they are open to experimentally applying solutions. They learn naturally through inspection and adaption and their cultures are less entrenched and calcified.

For larger companies the catalyst for (and champions of) an Agile adoption is often difficult to pinpoint. Is it predictability, speed-to-market, defect reduction or simply keeping-up-with-the-Googles that fuels the push to transition. Without solid management backing it can be difficult to get things to move. And even with it the organizational antibodies are a force to be reckoned with. Once things are moving the pace of adoption can be slow – painfully slow.

To my mind though as long as you are incrementally improving your process, through regular periods of inspection and adapting, you are essentially doing Agile. No process change in any organization is perfect over night and we, as Agilists, need to keep focused on steady incremental improvement. This process benefits of course from a serious look in the mirror, however Agile maturity, like emotional maturity, exists on a gradient.

As long as we are making steady progress does it matter if we are not perfect? The question is of course, are we making progress?

I don’t see Agile approaches as incompatible with leadership. Indeed, Wikipedia is a fine example of how far you can get with self-organization, which allows individuals to lead as they feel moved, and as others see them as able. If anything, I think Agile approaches allow for more true leadership, something that traditional dominance hierarchies tend to crush.

The Agile movement, however, lacks the unifying purpose of a software development team, which is to make a specific thing for a specific audience. Although the Agile Manifesto was a great statement of common principles, it was definitely not a statement of a common goal. Since they didn’t aim to get anywhere in particular, we shouldn’t be surprised that’s where they got to.

I appreciate the suggestion for the future article, and it’s one I definitely want to write. Whether it ends up here or elsewhere, I’ll definitely make sure there’s a pointer from our RSS feed so that you can be notified.