The Agile DilbertThere’s a lot of focus on agile methodologies. And the coices are almost endless: Scrum, extreme programming, feature driven development, the crystal family, agile RUP and many, many more. Although they all have their own domain, their own rules and tricks, they’re also well connected through the Agile Manifesto (www.agilemanifesto.org).

In short, agile development is about creating quality software according to what the user wants, not necessarily what the customer has specified up front. To do this, the agile team strips down the requirement spesifications and starts working on it, piece by piece. Every part is discussed, tested, developed (in that order), refactored, tested again and acknowledged by the customer. The agile teams are self-organized, transparent in their work and with a great team-spirit attitude.

But for the lone programmer, who want’s to become a member of this agile party, what can he do? What happens when the team member commits to a task and goes back to his desk, asked to come back with some working code that meets the requirements? This is what this blog is all about. Welcome to the agile developer: the guy who delivers quality software within a changing environment of uncertainty, excactly as the customer wants it.

This blog will go through the different areas and techniques the agile developer will use. His tools, but just as important the principals of being an agile developer. Lets start with the abstracts first, the agile developers core values.

The agile developer must be…

  • Disciplined: nothing is complete before the test passes. No code is small enough. No user story easy enough.
  • Communicative: Identify who’s calling the shots with the customer. Talk to him to clearify every issue. Make sure any changes are communicated and accepted up front.
  • Test-oriented: most importantly this means that you know the expected outcome of everything you implement
  • Result-oriented: The code must pass the customers standards. When it does, celebrate!
  • Committed: Make sure the job gets done. Claim responsibility for the outcome.
  • Open: All work must be visible. All progression must be tracked.
  • Allowed to do mistakes: Failing is learning, someone once said.
  • Able to improve: don’t bother failing if you don’t learn from it. Read,watch, listen: just learn!
  • Team-oriented: discuss solutions, share your code, attend reviews and learn from others mistakes and success.

Some useful practices that the agile developer must master. These will be covered in future blogs:

  • User Stories: What are we really developing?
  • Domain walkthroughs: The practice of walking through the domain area
  • Brainstorming: How do we solve this issue?
  • Planning: Do we have an idea how the new code fits into the overal model?
  • Automated Unit Testing: create the tests for all features / user stories
  • Peer / Pair programming: implement with a peer. Make sure someone else gets a fresh view of your code
  • Refactoring: make that code as simple as possible. Remember Einstein: “all things should be made as simple as possible. But no simpler”
  • Reviews: Share your solution with your peers. Get feedback and applause for your innovative solutions.
  • Party: Don’t underestimate the need for celebration!