This content is syndicated from VersionOne by VersionOne. To view the original post in full, click here.
I've used this theme before but I need to once again give my nods to Buffalo Springfield. It is absolutely time we "Stop Children, what's that sound, everyone look whats going down..."
I get involved in a heck of a lot of discussions about agile development and the methodologies that have grown from agile. In my travels around the world as an agile coach, I've met a lot of people that have interesting takes on what agile is. What seems to be missing in most of these discussions is the theme of *programming*. We talk about how to convince the executives it's worthwhile. We talk about how important a rhythm is. We have lots of discussions about what user stories are and how big or small they should be. But we don't talk about the code!
Now it is time for me to interrupt this rant with a couple of caveats and disclaimers. I believe very stongly that agile methods require discussions about project management. I believe strongly that we need to understand what stories are and how to create them. And I believe with every fiber of my being that one thing that differentiates agile software development from all other forms is that the value of all members of an agile team is recognized, not just one particular role.
The fact that agile has "elevated" the other roles to the same level as programmers is a good thing. But have we gone too far? Have we now gone to the extent that we are, in essence, focusing on everything except programming? I believe that we have.
Let's go back and consider what it is that makes agile special. We believe that change, even late in a project, is something to embrace, as it will add value to our customer's final product. We encourage customers and stakeholders to constantly review the priority of their stories and re-sort them. We state that we will only sign up for stories that are sized in a way that they can be complete in a single iteration. These are all good things, but they are predicated on one basic fact: The code has to uphold these changes.
Back in the early days of Extreme Programming, many of us were getting very excited because we had finally found a process that got the programmers in touch with the customers. We found that we can embrace change, because we are producing high quality software in small increments. This software is covered by automated unit tests so that if we want to change something, we can feel comfortable that the tests will catch any egregious errors. It is the very presence of these programming activities that make agile development work.
And yet, as I visit with clients and join in discussion groups, I am surprised by the absolute dearth of discussions about programming. I see teams that are 100% on the mark with all of the project management techniques in agile, and yet do none of the programming techniques. And guess what? They aren't seeing a huge increase in benefit.
So let's renew our commitment to great software. Let's keep doing the agile project practices that we hold near and dear to our hearts, but let's also focus on how can we write the best, cleanest code possible. How can we make this code so cohesive yet loosely coupled that it can be changed at the drop of a hat? How can we write code that will be so easily readable that *anyone* on the team can pick up any story and implement it, without having to rely on an expert or the original author? And for heaven's sake, let's make sure that the code we write does what the customer wants. After all, the customer really doesn't care what processes we used, they just want software that does what they need.