The road so far….

April 17, 2010

Confessions of a new Agile Developer

Filed under: Agile — Rahul Sharma @ 8:15 am

I had worked in waterfall model for most of my time and now I started working in Agile model. It has been quite some time now, but the transition has not been one of my best ones.

I joined a team of 8 pros and contrary to my expectation 6 of us had none experience of Agile methodology. So we started under the guidance of our 2 experienced pros. Initially there were few ups and most downs. We found out Agile is not just about sprints and no documentation, there are more subtle aspects which you have to learn the hard way. Here is an account of the what went:

  1. If you have not been in sync with the market technologies be prepared for a lot of pain.
  2. Your code is not your baby, so be prepared to throw it again and again until it matches the standards. The code quality is a team’s responsibility and people on the team will re-factor or possibly rewrite it, time and again. So no emotions attached 🙂
  3. Test driven development is all about writing tests first and then deriving much business logic from it. It is not the other ways round writing logic first and then making sure the test do cover them. I would call it Development Driven Tests (DDT). DDT does not add much sense. Why make a test if you know your code will work fine ? For just proving your point that it works(there should be more to that)
  4. In waterfall, design emerges first and then the code, but in Agile design and code emerge simultaneously. So you must not litter your code else you would be writing a crap out of it. TDD also helps here because as soon as you make your tests run you think about generalities that should make it better. DDT also helps rather no tests at all but often it is too late to do some quality betterment. So you must throw you code first and then start in the TDD manner.
  5. In waterfall requirements are signed in blood when you move but here the requirements evolve simultaneously and this helps to make things clearer as you go, but they also ask for redesign of the systems at times and this will happen quite often in the initial sprints(1-4).
  6. Planning meetings are bound to be brain-whacking and exhausting. Sitting in the chair for 4 long hours and deciding on the story points feels like playing roulette. The numbers will decide what will go in the sprint and what will not but how to decide the number when you had no experience at all? You are bound to lose !!!.
  7. Retrospectives look like speeches given at the Poll time. We should have done this or that and in the next sprint we will do this or that, but nothing emerges out if tasks are not taken in the sprint.
  8. Pairing while coding(most of the time you will be following DDT approach) is not the best way to go forward. Either or the partners have no idea how to go forward ,what the system design will look like, so you will have a lot of noise and then what emerges is a bunch of source files that must be rewritten going forward.
  9. Are stand-ups Sacrosanct ? Should you say we were banging brains against each other or I did nothing yesterday or we re-factored it and now we do not know what is what ? These would create an awkward situation with the new ranger.

Here are some of the preparations that one can do before plunging into Agile based developement:

  1. Get in sync with market technologies esp testing like JUnit, Fitnesse etc
  2. Read “the craftsman series on”,”Principles, Patterns, and Practices of Agile Software Development, Robert C. Martin” and “Clean Code by Robert C Martin”. You will not give it much priority at first but after you get a hang of the pain you will know your priorities.
  3. Understand this Tests are not just for code coverage or quality measure. They also provide a sort of documentation, that is up to date . People can look into the tests and see how to use this piece.
  4. Automate everything in the build at the start. If any thing as small as Checkstyle gets left out then it will have the same fate as in any other model, most talk and little action.When you realize this it is often too late to take any damage repair tasks.

You have learned to speak A to Z so learning Z to A will take its share of pain but eventually you will learn it. After you are done you will know it is worth the effort, after all if there is no pain then there is no gain.

So Go team! 🙂


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: