I’ve been passionate about Extreme Programming and Agile Software Development Practices since first hearing Kent Beck speak back in 2002. But it took five years, and finding a job where I was expected by management to be Agile every day (TDD, paring, etc.), before I was able to actually call myself an Agile Engineer.
I’m sure that there are more of you out there who want to be more Agile. And you want more Agile engineers so that you’ll have reasonable people to work with and learn from.
In the past 18 months I’ve picked up a lot of effective small practices that you won’t find in the White Book. Things like making sure you pick the next story no matter your comfort level. Or fixing a red CI build ASAP.
In order to spread the knowledge, I’m working on a presentation about the ‘practices that work’ to share with potential Agile Engineers at a future software conference near you.
So what day-to-day practices make you more Agile?
Thanks @Brian & @Chad!
I especially like rotating pairs. Good one.
I’m really looking for things that condense well, sort of Poor Richard’s Almanac aphorisms. So how about this: “Pairs and fish stink in 2 days”
Anyone else?
August 8, 2008 at 5:30 am
Distilling my points a bit, ala Poor Richard’s:
– Don’t pull the trigger until you can hear the sound of their voice.
– Side-out rotate! (volleyball anyone?)
– Write to be read
The latter one tends to be said when describing good writing. There are lots of longer anecdotes to this point, like Matz “Treating Code as an Essay”, and other words we used to describe this perspective (terse, clear, concise, descriptive, etc.). These terms however can be very subjective. Writing code to be read means thinking about your audience. Your team or the team that will take over the project, etc.
If you heard Kent Beck’s talk at RailsConf (not sure if there is a video anywhere), he talked about using the term “Responsible Development” as a more intent-oriented term to describe what we’ve been calling Agile (or XP). I’d love to see that term used a bit more, to remind us all why we strive to be “agile”.
August 8, 2008 at 4:14 pm
Damp musty jungles may have their charms, but you should strive to code like a [Zen rock garden](http://en.wikipedia.org/wiki/Image:Portland_Japanese_gardens_zen_garden.jpg).
Delete anything code you don’t need *immediately*; you can always retrieve it from source control if you need it again later.
If you find commented-out blocks of code or disabled tests, delete them and make cranky noises at those responsible. (If you’re the one responsible, make cranky noises at yourself. :-)
You should feel dirty whenever you copy/paste/modify a block of code; factor out the common parts ASAP.
Refactor your tests. Try to make your tests as declarative as possible, but balance this with making them easy to understand at first glance.
Names are important. Don’t be afraid to rename something a few times ’till you settle on the right name. If you and your partner are having trouble settling on a name, elicit other opinions.
Try to use names that match your customer’s/user’s terminology, so that naming is consistent from the UI down to the model. But be careful: users often overload words or use multiple terms for the same thing, and terminology often drifts over the life of a project. I find it worthwhile to rename things in the code as user terminology drifts rather than deal with the disconnect.
Get up and walk away from the computer at least once an hour.
When pairing with a newbie, talk a lot, ask them lots of questions and don’t hog the keyboard. A lot of people are very uncomfortable with someone else watching while they code: try to decrease their discomfort. Be critical of yourself but not of them. Don’t jump immediately on every mistake or typo — let your unit tests catch them (this will help reinforce the value of testing). Let them code up something messy, then refactor it. Don’t say “this code is a mess” but rather “I find this code hard to understand — let’s extract this block into its own method”.
Two keyboards are better than one.
August 8, 2008 at 5:41 pm
One thing that can’t be said enough is to pick up the phone. I have frequently seen developers, solo or while pairing, wondering out loud about a particular feature. The shortest path between your question and a reliable answer is the telephone. Those few minutes spent on the phone will greatly improve your velocity, and improve the likelihood that the feature is built right. Certainly face-to-face communication would be preferred, but I’ve (unfortunately) never been lucky enough to be in that situation with my business partners.
I’d also recommend constantly rotating pairings. It’s so easy to get in a comfort zone of pairing with the same people. This leads to a few bad things. Team dynamics are thrown off, pairing becomes less intensive, and cliques emerge. Additionally this can lead to a grouping of developers that are more familiar with a certain area of the app. This is always trouble. Each team member should be able to pick up a story in any part of the application. While you may be less proficient at first with this approach, it will pay off in time.
Another tip that may pay off more for Java and the like:
Write code documentation for a human to read, not just for a tool to parse. Javadoc can be very hard to parse if it’s written “correctly”. If you have something quick to say about a method, it is typically better to aim for easy readability vs. formatting for a tool.
August 7, 2008 at 9:26 pm
Always keep the app in a production-deployable state.
This is one of those easily overlooked (or ignored) things which is the basis for many more imporant things. If the code is not always deployable, you cannot do frequent releases. If you cannot do frequent releases, you cannot get rapid and wide feedback on new features. Etc. and so on…
It is also one of the harder things to learn and accomplish, and requires you to have a few tricks in your bag. For example, when I start a story, I always think about how I can break it up to maximize frequent commits while avoiding any breakage in the app. Sometimes this backfires, and I end up rolling back changes when I change my mind, and I tend to move a bit slower, but the benefits of frequent integration are worth it, in my opinion.
You also should learn tricks to “hide” the feature until it is ready to use. If your code is well-factored and follows good OO practices, this usually isn’t too hard. For example, you can have two view-layer versions – one which is live and shows the old functionality, and one which is only enabled in development which shows the new functionality. Of course, everything old and new should be thoroughly tested from the view layer on down, so you don’t accidentally break the old functionality. Then, when you cut over and make the new version live, you can remove the old code and tests. If you can follow the skinny-controller fat-model approach, and push all the differences between old and new down into your model, and TDD all the new functionality in the model layer without changing the old, that is even better.
Of course, this approach isn’t always possible, especially for big view-layer and visual layout changes. In that case, you should use “Task Branches”, and perform the breaking changes outside of trunk/mainline. However, you still want to integrate as frequently as you can. For example, wrap up the new design for an initial page or two, and go ahead and merge back to trunk, integrate and deploy, then start a new task branch for the next bit of changes. Yes, this is harder in some cases, but often very possible if you put some thought into it. Plus, if you are pushing new features often, customers and users are often more than happy to live with some minor inconsistencies and “under construction” areas, especially if you have a fast, solid and stable site in other respects.
So, start adding tools to your Agile Toolbox which allow you to do frequent integrations and commits in the middle of your stories, while still maintaining an always-deployable app.
– Chad
August 8, 2008 at 4:22 am
@Brian,
I totally agree with your first two points, and every team should constantly remind themselves of them (they came up in my team’s last retrospective, as a matter of fact).
On your third point, I’m just glad I rarely do Java anymore :)
– Chad
August 8, 2008 at 4:27 am