Matt Heusser’s Blog
Testing at the Edge of Chaos
Why Agile? Why Now?
I’ve noticed something really odd in the past three months – I’ve started to write articles about Agile Software Testing.
Oh, this is no big surprise, I mean, I work at a shop that releases working software to production every two weeks, uses pair-programming, test-driven development, plans releases using stories and story-points. Typical Agile stuff.
While I have always been interested in lightweight methods, fast feedback, and personal excellence, a quick check of my old published articles finds all of three with “Agile” in the title – one was for a magazine issue with an Agile theme, a second was an interview, and the third, “Peril and Pitfalls of Agile Adoption” was not entirely complementary to the subject.
At the same time, there has been an explosion of Agile Books, Agile Consultants, Conferences and Advice. This morning on twitter, my writing partner, Chris McMahon claimed the Agile Advice ‘market’ was ’saturated.’
It’s pretty easy to argue that if you are a thinker looking to not become part of the herd – that Agile in 2009 is probably not the place to be.
And yet, all of a sudden, here I am talking about Agile Testing. In the two months I’ve published:
Using Automation to speed up Agile Testing
Test-Driven Development Face Off: Part I
Test-Driven Development Face Off: Part II
And I’d like to keep going. Why the sudden energy? Why am I suddenly interested in the ‘Brand’ Called Agile, when I typically suspicious of labels in general?
Here’s what I think is going on. The Agile Manifesto is getting on ten years old. Since the manifesto was developed, we’ve had at least two generations of dogmatic thinking – the XP years, then the Scrum years. We’ve had a fair amount of chest thumping and experts talking about the “right” way to do it and the “wrong way.” We’ve seen practices (someone) doesn’t like labelled #notagile, followed by someone else pointing out that it’s not the practices, it’s the principles, followed by … you get it.
And, quietly, over in the corner, some people were actually shipping working software to customers, and continually getting better and better and it – and – in some cases – developing the skills to talk about it.
After a decade of Agile development, we’ve got anecdotes, we’ve got stories, we’ve got experience. And I can start to reply to the chest-pounding and dogma by saying “really? Let me tell you about my experience. What was yours?”
In other words, I believe the Agile movement has a chance to move beyond dogma and into actually talking about systems thinking and tradeoffs.
We have a chance to have an entirely different kind of discussion around Agile Software Development and, about that, I am excited.
… but what do you think? Has the ‘Agile Software’ movement hit a brick wall or just gotten started? Do we have opportunities to move it forward?
Comments (10)
1 Trackbacks/Pingbacks
at November 5, 2009, 9:56 pm:
Hi Matt,
I’m new to Agile, as you know, and I think why now is because the other process driven methods aren’t working in this economy. To be blunt, the huge overhead involved with the “let’s be like manufacturing” derived methodologies is too expensive and is not good for keeping a motivated and highly productive team together.
Agile is beautiful when done well because it builds teamwork and grows people better than the “every cog is micromanaged in the well oiled machine” methods (fishing maturity model). Also, human beings like being important, good testers and engineers are too clever to enjoy being managed, and want to be enabled, have resources to make great software, and a good scrum master can make that happen.
[The well-oiled machine thing is bigger than software - it's about the way to run a company - it's based on an ideology. And I may finally be getting to a point where I can do some writing on that. Thank you for the encouragement.]
When I question you about “Why is THAT Agile?” I really want to know. I want to know because it has more potential than the other things we’ve tried and it just feels better than the overly bureaucratic alternative.
at November 5, 2009, 10:12 pm:
Five years ago, the Agile guys spent a lot of energy trying to convince people that their software dev process was a revolutionary step beyond traditional waterfall methods. Now I find them arguing over details and refinements of the process. Meanwhile, a growing number of companies are embracing Agile.
This, to me, is part of the evolution of Agile and an indication that it is really taking hold. Over the past year or so, many Agile consultants have told me that, previously, they had to convince clients to accept their development process. Now, the process is often a given.
Sure, ‘Agile’ has become a bit of a buzzword, but that’s largely due to the non-technical/management people finally letting go of the traditional approach.
at November 6, 2009, 1:08 am:
I’m at a point where I want to limit the number of times I use the word ‘agile’ in a conversation at work because of the level of abuse it’s getting from others. They’re throwing the word around without truly understanding what it means (not to say I know what it truly means)
“Let’s agile this, agile that…”
It reminds me of the Dilbert comic about Agile Programming: http://farm4.static.flickr.com/3062/3345485483_8e1816fa9f_o.gif
I don’t think Agile Software movement hit a brick wall. I think the hype might have, but agile adoption is still making its rounds and growing.
at November 6, 2009, 2:18 pm:
I am one of those people who have been evangalizing agile methods for years.
[Matt too, but I think I took a more system-thinking, less "branded" approach.]
I drank the koolaid fully because I have seen it work, and truly believe it is a good way to deliver software.
[I think I know what you mean, Janet, and I think I agree, but I feel obligated to say "Drinking the koolaid", as a metaphor, is entirely opposed to everything I am trying to do. The people who drank the koolaid at Jonestown /died/ because of that choice.]
I think that the dogma years was necessary because people were trying to explain what it was, and how to use it.
[Were they? I'll give you two examples - XP and Scrum. XP came out of a big corporate beuracracy that couldn't get anything done because, to do anything, you needed to spend two years writing a big thick 3 ring binder spec, that you would pass off to implementors, who would have no idea what you were on about. So they wanted a method to do /something/ right now, and adjust. Scrum, on the other hand, was popularized at Easel corp, where they had the opposite problem - the marketing people had flavor of the week disease and they couldn't get anything done because the tech team was always changing direction. So Scrum had the idea of the 30 or 90 day iteration so the customers would leave the developers alone to actually get something done. Two subtly different solutions to two very different problems. Now say it's 2001 and I'm dogmatically recommending a specific implementation of XP. Is that the right approach? Do I even know what the problem is that I'm solving? (I used to ask this kind of question five or ten years ago; I find that today, I get a different response.)]
We now know so much more than we did 8 – 10 years ago. Each of the ‘prescribed’ methods have strengths and limitations, so organizations have combined and chosen practices that meet their needs. And yes, there still is a lot of dogma out there.
[If you are saying the body of experience has evolved so we can tell the subtleties apart, then I think I agree.]
I am consulting these days, and am usually called in because the testers aren’t getting it. I find that usually isn’t really the problem and that there is something else that needs to be addressed to fix the real issue. Agile isn’t easy, and sometimes it helps to follow the practices in a particular method(s) exactly to get into the groove rather than finding out by trial and error.
[I hear this argument all the time. I think I sort of vaguely understand where you are coming from, and I have some concerns. I suspect we should talk more, and reason together.]
Organizations have been using it for a while and are now finding their groove, and determining what they need. That may be ‘why now’.
It’s now become a matter of regularly delivering good software that meets business needs. I liked Lanette’s comment “Agile is beautiful when done well because it builds teamwork and grows people better”. I think that says it all. The trick is … to do it well.
[Point taken, and it's a good one. Thank you.]
at November 6, 2009, 4:15 pm:
I think the point about the body of experience is important. It seems like we can understand more when we compare two things that are different ways to accomplish something than when we simply try to assess the value of one in isolation. As we have learned what does and does not work in “agile” for a given context and can compare it to what does or does not work in “waterfall” for that context, it sheds light on the real underlying issues for that context.
[I agree. I'd would even go so far as to say that the strongest opposition to lightweight methods I have seen are with people who's arguments boil down to "but we only have one kind of tool. If you take away our process, our templates, and our documentation, we don't know what else to do." Somehow, I expect that a deeper tool belt would have helped.]
It is like looking at the challenge of building and delivering software that meets our needs through two different lenses that help us understand different things. To the extent that those lenses highlight different interesting things (people, motivation, communication and coordination, trust, etc.), we gain more value from the comparison. YMMV.
[Good point. And please tell Andy I said Hello.]
at November 6, 2009, 9:16 pm:
Great post Matt. I look forward to many more.
To answer your question Agile is nowhere near dead. I know a large number of companies that are looking to either add more agile into their existing processes, or extend agile principles and practices into other areas of their business. I do believe that we are past the point where marketing is needed for the Agile movement, and now we need more people like you talking about their experiences with Agile and how it’s worked best for them.
at November 6, 2009, 10:27 pm:
I think that there are often two kinds of early adopters to any new idea, those who see its potential and adopt it seriously and those who want the success without actually committing to the approach. In the UK we saw this a lot with teams adopting “RAD” because they didn’t want to do any testing. As you suggest, 10 years has been sufficient time to allow the genuine proponents of Agile to learn, make mistakes and develop a base of knowledge and write some excellent books and online resources that has allowed later adopters such as myself to vastly improve our chances of success. Hats off to you for that.
at November 7, 2009, 5:18 am:
I sure hope it’s not hitting a brick wall because we just started to adopt Scrum in our company on a new green field project. I am promoting Agile practices because our heavily-laden waterfall-driven company approach does not work for the most part. I’m convinced that software development needs to be fun and done within a framework that promotes strong collaboration and builds up people as the continually enjoy successes instead of a constant pattern of failures due to missing arbitrary deadlines. The strength is in the people on the team and, IMO, Scrum enables and promotes and embraces building a strong team who them goes on to build great software. Interestingly, as I evangelize Agile practices, I’m running into colleagues that are testing the waters themselves on thier teams. I believe our team is fully embracing Scrum “by the book” so to speak because I want to try it like it “supposed” to be done and I guess I have the right alignment of the stars right now to do that. Others seem to believe their is some inherent benefit to the thing called /Agile/ but don’t quite know how the get started. So, there seems to be a coalition of the willing, or should I say, of the desperate. No, it’s not hitting the wall – it can’t be. Because, I feel like I have a brand new exciting job by adopting Scrum and I don’t want to end!!!
at November 9, 2009, 8:27 am:
I think your making the point that every ideology is wrong. (Even when it’s more right than any other ideology.) The map is not the territory and we’ve got about a decade’s worth of experience that partially confirms, and partially undermines the Agile Manifesto. We’ve got the experience in the world that’s messy and reality doesn’t fit into any neat box we try out for it. With experience in hand there’s less need for preaching the shining path to glory, and more citing lessons learned.
Meanwhile, someone who likes ideologies will devise the next big approach (Software craftsmanship anyone?) and everyone will start preaching that. By fits and starts we take this infant engineering discipline we work in (It’s less than a century old.) and we advance the state of the practice and the state of the theorizing about practice.