FROM THE ARCHIVES OF PRAGPUB MAGAZINE FEBRUARY 2011
I Went for the Skiing
By James Grenning
From Agile @ 10: Ten Authors of The Agile Manifesto Celebrate its Tenth Anniversary
When I first learned about extreme programming back in 1999 I was very excited about it. It provided logical solutions to many of the problems I had experienced over the prior two decades of software development. I was not quite sure about pair programming and test-driven development; that all seemed promising but a bit… extreme. But after a little experience I found both practices productive, and fun.
In 2000, while I was with Object Mentor, we were early adopters and advocates of extreme programming. We knew that we had discovered something that could help many development teams get out of their rut. Organizations hired us to help them change. We had visions of walking in the door, explaining XP and having everyone embrace it like we did. Wow, what a shock: they were not ready to change.
Current practice was not delivering quality software on time, but XP was too extreme. Just look at the name. “Will we need elbow pads and helmets?” our clients would joke. Developers and product managers of the day thought that the solution to their current woes was to do more upfront work, not less. The idea of fast feedback along with evolving design and requirements was too foreign. Well, we persisted and helped many organizations get started. XP was new then. Agile did not even exist by that name.
In the beginning of 2001 Bob Martin invited me to join him at Snowbird for a meeting with the guys that started XP and some of the other “Lightweight” development processes. My answer was, “Yes, I want to go (skiing).”
The snow was fantastic, with two feet of fresh powder and plenty of avalanche danger. Hanging out with the software development personalities was affirming, inspiring, and thought-provoking. There were many competing and complementary perspectives discussed: code-centric, model-centric, and people-centric. Rather than trying to define the one true software development methodology and practice, someone had the bright idea that we should make a statement of the things we have in common. With some good discussion, careful word tweaking, and the snow falling, the four values were distilled.
Before we could hit the slopes, we needed one more thing, a name. Lightweight was the banner we flew under on our way to Snowbird, but who wants to be known as a lightweight? Good point; we could not have that. After a while we settled on Agile Software Development. Of course organizations would want to be agile. You can explain that to your CEO or customer far more easily than proclaiming you are extreme.
We had a name, we made a statement, but we were not sure if anyone would know or care. Over the following years we found that people did care. Many creative and passionate people were attracted to agile, and agile continues to grow in popularity and depth. After ten years, you can see that much has changed, but much remains the same.
Many developers are still unaware of agile or only know the misconceptions. The idea that more upfront work is needed is deeply ingrained in the software development mindset. Code bases are a mess, dragging teams and products to a standstill.
Happily, people are discovering agile everyday. Embedded development, where I spend much of my time, is awakening to agile with interest — and skepticism. The questions and concerns are essentially the same that non-embedded application developers cite, though on the surface they sound very different. Dependence on hardware is a big conceptual hurdle for embedded developers, but non-embedded developers have dependencies on UIs and databases. Those sound like very different problems, but they have similar solutions in the technical practices of XP and Object Oriented Design.
Incremental delivery is another conceptual hurdle. How can you deliver a washing machine incrementally? Embedded development is not the only place where product completeness requires that the top ten (priority 1) features must be in the product for it to be useful or marketable. But even when value cannot be delivered incrementally, we can still benefit from measurable, visible, and incremental progress.
There is at least one new problem ten years after. Now we have organizations that have a few Scrum Masters and proclaim themselves agile, but who continue to spend months in analysis and design and similar amounts of effort in test and fix. They have stories and iterations, but ignore relative effort estimates and velocity. Code is deteriorating. Tests are not written. And they wonder why agile is not working for them.
Change is difficult, but the only way to improve is to change. I show teams the careful way of working, with clean code, tight feedback, and plenty of tests. They say “That takes so long. We want to know the fast way, show us the fast way,” as if I am holding back some secret. The careful way is the fast way. Get good at careful; that’s how you can go fast. My hope for the next ten years is that more people accept this tough lesson. Now it’s time to get out the ski gear for a tenth anniversary trip to Snowbird. I’m going for the skiing and looking forward to the next ten years. Will there be another revolution? Maybe, but I know for sure there will be more evolution.
About James Grenning
Meet the author of this article and his book, Test-Driven Development for Embedded C, from The Pragmatic Bookshelf.
James Grenning trains, coaches, and consults worldwide. James’s mission is to bring modern technical and management practices to product development teams, especially embedded systems development. He is the author of Test-Driven Development for Embedded C. He is a co-author of CppUTest, a popular unit test harness for embedded C and C++. He invented Planning Poker, an estimating technique used around the world, and participated in the creation of the Manifesto for Agile Software Development. This article first appeared on his blog, and if you have any comments, he’d love to continue the discussion there.
