Skip to main content

Heads-Up and Eyes Open: Skills an Agile Developer Needs

The days of the "heads-down coder" who spent all of his time in a cubicle writing code from spec are numbered. Today, developers need a skill set that goes beyond cranking out code and includes such things as actually talking to other people. ("How can you tell someone is an extroverted programmer? He looks at your shoes when he talks to you!")

I like Agile software development. I think that it is the best way to produce working code that your customers actually want. The nuts-and-bolts of how to get this done are certainly up for debate, and there is no shortage of opinions on the subject. More to the point, I don't believe that there is such a thing as an "Agile" skillset, only skillsets that do (or do not) help you successfully create good software. This article is about the skills that I think are most essential to software professionals as we're nearing the end of the first decade of the 21st century.

Agile vs. Traditional Development - A Straw Man
Look around on the various blogs and forums, and you'll see a debate still raging around this subject. Which is better? Agile or traditional development? The answer is simple: development by skilled people who stay current, learn quickly and follow some methodology will be more successful than teams who don't have all of these elements.

Agile is just a methodology, and a fairly simple one at that. Like XP (which is itself considered agile), RUP and their distant ancestor SSADM, Agile is a set of steps to follow and a way to measure progress on a project. In my opinion, it is more useful than it's predecessors, but it certainly isn't a panacea. If you have a group of unproductive developers who don't agree that Agile is the way to go, forcing it on them will probably have a negative effect.

External influences being equal (management support, product management, customer commitment, etc.), a team that follows Agile practices and has skills to support these practices will be more productive than one that does not. These two concepts are not independent. If you have a productive team doing RUP or XP, you should stick with that because they have the skills (and the support) to make it work.

If your team is less productive than they would like to be and wants to move to Agile, what should they focus on?

Agile Skills
The Agile Manifesto describes the guiding principles in three sentences and four bullet points. The Agile Principles are also a very quick read. These statements don't describe a methodology, but instead served as the basis for developing what I and many others call "Agile Methodology", and which has been described in numerous books.

My focus here is on more detailed activities of creating software, and the real-world skills that software professionals need to grow. Time to learn new things is a very scarce and precious commodity, so I'm summarizing what I think is important. I do think that being able to program in more than one language is important, but I left that part out of this post because its pretty obvious and well-covered elsewhere.

This is my list of the most valuable skills a developer can have. Resources for learning more are in the links.

Gathering Requirements: Sharing and Playing Well With Others
Get up and talk to people! Make a connection. This sounds warm & fuzzy and very "Dr. Phil", but it is essential to getting good requirements. The people you must connect with include your customers (internal or otherwise) and your development team.

Building friendly and productive relationships pays off enormously because you no longer have to guess what the customer wants - you can ask. Likewise you don't need to guess if your solution is a good fit or not - air it out in front of other developers and see if it hold up.

If you're an introvert, force yourself to get up and start a conversation. Trust me, even if you don't see the value in terms of better requirements right away, it will make your work environment much better and raise your value in the eyes of your boss and your customers.

So what do you talk about?
  • User stories are easy to create and easy to review - spend a few minutes writing them on 3x5 cards, post-it notes or plain paper.
  • Take notes as you design & write code. Write down questions. Write down assumptions. Translate them into simple statements and questions, then go over them with users.
  • Draw pictures. Even if yours are only worth 200 words, you'll gain insights by showing them to people. Stuff the ones that weren't very useful into a drawer. Take the ones that brought the most insights and pin them on your cube walls or in a team room. Re-draw them if your rough draft is hard to decipher.
  • Do it often - if you dump 40 hours worth of your questions and assumptions on someone, they'll be overwhelmed. Talking for half an hour every day or two is better than four hours every other week.
  • Email doesn't count, and phone is only slightly better than email. Save these conversations for people who aren't in the same building with you.

Adapting to Change: Organizational Skills
A primary thrust of Agile is adapting to changes in requirements. You will always learn more about the problem you're trying to solve as you go, and this will give you insights into better ways of doing things from a user or customer's perspective.

A personal time/task management system that you can quickly adapt (changing to-do lists, sorting through important / unimportant emails, etc.) is key. Keeping track of the torrent of ideas that you and the people you talk to come up with and organizing them tells you where you were, what assumptions you made, and where you are heading. The simple acts of writing things down (or typing them) and prioritizing gives you a level of clarity that eliminates a lot of the stress of any job. Even if you never share your notes, creating and reviewing them will make you an expert on your project.

Some variations on different task-management and note-taking systems:
  • GTD ("Getting Things Done") is an overall framework for managing your time and tasks. I think that every developer should read the book...and then come up with his/her own system from scratch. GTD is, quite frankly, designed for idiots and CEOs - people who either can't remember anything without writing it down, or who have to juggle so many priorities that it is impossible to keep track of "the main thing" at any moment.
  • In 2008 I blogged about using OneNote to take daily notes and keep track of tasks, and this still works well for me.
  • For people who don't use OneNote (which works fine on a Mac using VM software), Evernote is a pretty good alternative.
  • Paper notes have a place in all of this. You can easily capture your scribbles from meetings on paper, then scan or photograph them and add them to your note software as images.

Creating Iterations: Planning and Estimation Skills
Iteration planning is core to Agile, and there are several concepts that all agile developers need to be comfortable with. At base, these include:
If you're not familiar with these (or just want an overview) I recommend Head First Software Development as an excellent introduction. Plenty of pictures, and you can skim your way through the book in an afternoon, or spend 1-2 days on a deeper read. (I really like the "big board" chart described in this book & have co-opted it for my own projects.) For an overview of the different agile methodologies (XP, Scrum, Unified and Evo), I liked Agile and Iterative Development (the link lets you read the critical sections online at Google Books).

There are too many books on specific methodologies to list them all out - search Amazon for Scrum, etc., and read the reviews.

Choosing Optimal Solutions: Study Skills
You can't choose what you don't know about. Being Agile means having a handle on what options are available in languages, frameworks, development and testing tools. Any developer - agile or not, must have good study skills. If you're not reading a technical book of some sort every week, you're falling behind.

This pdf by U of M's Paul Edwards is a good overview of how to read a non-fiction book, but I would add the following caveats:
  • Read what is interesting first. If you have an immediate problem (Ex: "How do I run a nightly job using the Spring scheduler?"), read about that first. You may stop there.
  • If you don't like it, read something else. If you don't like the author's writing style or the subject matter bores you, find a different book on the same subject. If at all possible, I try to preview an e-book first, then buy the one I liked best so I can write in it.
  • Buy a lot of books. This goes along with trying out different authors and topics to find whatever helps you learn best.
  • Read a variety of topics. Frameworks, languanges and methodologies are important to your craft, but it's also good to read some "meta" topics from time to time. I strongly recommend Andy Hunt's "Pragmatic Thinking and Learning" and Neal Ford's "The Productive Programmer" to improve your study skills.
I would really like to hear your thoughts on this subject. What skills do you think are most important to a developer? What books or sites have you found particularly useful?

(face-in-the-computer image by "dumbledad", acrobatic dog image by "thegiantvermin")
Post a Comment

Popular posts from this blog

Agile Performance Management: Why Performance Reviews Suck

Many thanks to Mary Poppendieck, who wrote about this topic in 2004, and proposed a comprehensive solution.  She is the inspiration for much of my thinking on this subject.  She is also a better writer than I am a cartoonist.

Performance reviews suck.  I don't know of anyone who goes into their appraisal without some trepidation.  Your boss is guaranteed spring some surprise criticism on you that is ill-informed or misses the point as you see it.  It's a real challenge not to get defensive about that.

The only thing that makes your own performance review suck less is having to give them.  As a manager, I have dished out quite a few, and some of them went pretty badly.  (To the people at my first management job: Thanks for helping me learn how to get better at them.  Your sacrifice was not in vain.)  Since then, receiving one isn't nearly as gut-wrenching, if only because I try to make it easier for the guy on the other side of the desk.  I've been there, and I know how …

Do. Not. Optimize.

You've probably heard this quote before:
Premature optimization is the root of all evil.
 - Tony Hoare
Speculative optimization is always wasted time.  In the absence of an actual performance problem, you're just burning time that could be better spent on refactoring your code to make it clearer.  This is exacerbated because performance-optimized code is usually harder to read than code which hasn't received such treatment.

Here is what you're doing when you optimize:
Adding code that now must be maintained.Obfuscating the existing code.Spending time writing code that doesn't add value. But what's that you say?  You have the experience and know-how to decide when optimization is needed?  Maybe, but probably not.   The people at Sun and Oracle may or may not be smarter than  you or me, but they certainly know more about optimizing Java bytecode than we do.

For example, some people think that having a large number of classes is slower than the alternative.  This …

Showing Off: How to Do a User Demo

Rather than repeating what has been said elsewhere, here is a nice short post on agile-for-all that covers the basics.

Here are a few things for my own future reference and teams that I'm working with...

Try to keep each demo to 5 minutes or less.   If it's longer than that, it's possible that you should be demoing more than one story.  More likely, you're just being too wordy.

TALK LOUDLY.   No, louder than that.  Louder.  Do you feel like you're yelling?  OK, that's about right.  You need to put your voice in public-address mode for 5 minutes.

Focus on why your audience should care about the story  This is particularly important for back-end work.  For example: Your story generates a feed of XML that will be consumed by another application. Show the output, and point to a couple of salient features in it.  Then be done.

The important part of the above is "show the output."  Showing the end users how to interact with your service is a separate sit-d…