Often I come across questions like

  • Will agile help me to reduce bugs?
  • Will agile help me to reduce costs?
  • If I use agile will I be able to improve predictability?
  • Is it agile to have unit tests?

The list is endless, these questions come from the teams which undergoes transformation from waterfall and they like to have a term for their new way of working. The very first project in my career, our team delivered to production every week. Everyone in the team were developers but wore different hats on different days. Each of us learnt to write unit tests, build and release to different environments, monitor production systems, automate functional tests in a team of 10. People coming in and out of the team was always breezy, there were no dependencies on one single person. I would say that was one of the ideal projects I have ever worked.

What process or methodology did we follow? “Do what makes sense!” Yes, that was the only thing which was told to me the first day I joined the team. No process, no compliance; only sensible things. Now if I replace “Agile” with “Common sense” will I get the answers to the questions?

  • Will agile common sense help me to reduce bugs?
  • Will agile common sense help me to reduce costs?
  • If I use agile common sense will I be able to improve predictability?
  • Is it agile common sense to have unit tests?

We got so much used to having process and methods as a safety net and rely on work instructions created out of those to execute day to day work. In my observation it is only some sensible practices which are fine tuned to the present scenario works. There is no substitute for common sense.

A hunter watches a mountain goat grazing on the pastures on the side of a highway. A speeding truck loses control and starts veering towards the grazing goat, in split seconds it jumps off to a safe place. The hunter’s kid who was watching all this asked his dad, “Did the goat escape because it is agile?”. The hunter replied “It is just common sense to avoid a speeding truck”.

There was a question posted in programmers forum in stack exchange site asking Is agile the new micro management? I am not sure why such an impression about agile has been formed in that person’s mind. It could be due to some recommendations being wrongly interpreted. First of all the recommendations like “a quiet place to work” is a necessity for development teams anywhere following any methodology. Interpreting that as a no talking zone requirement is against improving communication between the team members. My perception about why these kind of wrong interpretations arise is due to wrong sense of accomplishment provided by having something tangible. If someone has to show any progress in adopting a new process or a method then it is natural for him/her to incline for a support in some form which could be seen or measured. This has led someone to believe that following some guidelines verbatim and measuring the level of adherence to it is equal being successful in adopting a new process or method.

I have not been aware that I was part of agile teams for a few years until I met someone who joined my team because it was an agile team. We were a team of 12 people doing weekly releases to production, wearing different hats of Dev, QA, BA and had everyday interaction with the customers. That is how I started my career and I never felt the value of it until I worked in a conservative setup. There was one golden rule of thumb we followed in the teams I worked, treat the team (client team included) as your own organization and do what makes sense to deliver the right value.

I asked one of the directors of a company that how come he never used the word agile though he was part of agile teams for quite long, he replied  “talking to your customers often; keeping the code well tested, integrated  and delivering the right value on time is all about common sense. There is nothing agile about it!”. He sure left me to figure out what agile meant.

Is there a prescription? Check the answers given out in that forum for that question.