Changing Agile Roles – The Programmers

Many people don’t see that there are many changes to the programmers’ life when it comes to moving to agile software development.  I personally see quite a few changes.  Some of these changes are basic, like moving to test driven development, or getting into the habit of continuous refactoring.  Other changes are a little more subtle, and yet much more challenging.  These changes apply whether you are doing extreme programming, scrum, or any other agile process.

Lets start with the obvious ones.  We as programmers are going to be spending a lot less time planning and writing design documents.  This isn’t to say that there won’t be any design going on, just that it won’t be in big paper diagrams that require an expensive plotter to be able to print them out.  So with all this free time, what will we spend our time doing?  Lets talk about a few of the basic agile programming concepts, briefly, and then look at what they add up to.  As with most things in agile, we will find that the whole is much greater than the sum of its parts.

Test Driven Development
There are volumes and volumes written on what TDD is and is not.  At its most basic, TDD is one of the fundamental practices that make agile software development succesful. We create a set of automated tests that must pass for the software to be “done”.  These tests are run every time we check in code.  These tests provide a safety net, so that when we start changing things willy nilly on the whim of our customer, we will be able to know quickly if we have broken something.  This in turn reduces the set of suspects for the broken code.

Continuous Integration
Several times a day, whenever we have produced some small piece of code that does something, and all the tests still pass, we will check in our code.  We are not going to have a set of code checked out for weeks at a time until a large chunk of functionality is “ready”.  Change will happen rapidly, and the system will evolve rather than just appear at the end of the development project, just in time for test.

Refactoring
Every chance we get, within code we are actually working on, we will make small changes that improve the design, but do not modify the behavior, of our software.  Great designs will emerge as the system grows.  We can safely make these changes because we are test driven.  We see something that could be improved, so we write a few unit tests, then write the code to make those tests pass, and our software is now slightly better than it was thirty minutes ago.  The cumulative effect will become rather extraordinary.

Teamwork
There is a long-enduring myth that programmers are anti-social people.  Just give us our assignment, and we will go off into our caves and produce something.  The more junk food you throw into the cave, the happier we are.  While this is a very fun image, it just isn’t true.  It is, however, so prevalent that we need to put extra emphasis on this change.  We are going to be working in a close knit team.  Not just of programmers, but of members of the development team who don’t program.  They might be testers, or documentation specialists.  They might…good heavens…be managers.  This is a Good Thing.  We need to embrace all of the components of a software development project, not just the folks who write the code.   This is probably the biggest and hardest part of moving to agile for programmers.  In my travels I periodically hear the question “What do we do about the fact that the story is done on the last day of the iteration, so there isn’t time for testing?”  The answer is that the story isn’t done until the testing is done.  The shift is subtle and strong.  We estimate as a team.  We develop as a team.  We celebrate our success as a team.

The Bottom Line
So what does this all add up to?  We have some technical things we need to do differently.  We have to step down from the exalted position of “Developer” and become programmers again.  I didn’t talk about pair programming, but there is another opportunity to become more agile and will also require more social interaction.  These changes in how we do business add up to two “buzz words” that encapsulate what we are aiming for.  The first is Craftsmanship.  We are creating something.  In most cases, there is much more art than science to what we are creating.  Just as the masters of old did with wood and iron, we must approach our software with a passion for a great product.  Not just something that is brilliantly made, but something that is well made, sturdy, and pleasing to the consumer.  The other word that was drilled into my head as a young Midshipman, and I believe applies far more than we give credit, is Professionalism.  We are professional software developers.  Our particular skill is writing code, but we are part of a larger profession.  Software development, especially agile software development, requires professionals with many different skills.  A true professional learns how to work with all of those other people, and in many cases on their terms.

So how we write code is changing, mostly based on extreme programming practices.  How we treat our projects and planning is changing, mostly based on scrum practices.  All of these changes are giving us the freedom to create great software.  The price of this is that we now have to step up as craftsmen and professionals, members of a larger software development team.

This entry was posted in Agile Adoption, Agile Development, Agile Teams, Continuous Integration, Extreme Programming, Test Driven Development. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

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>