My Five on Agile and the famous Myths

4 events today and I end up writing the famous Agile Myths....

Event 1 : Developer walks to me and asks me to change a requirement, Quick decision expected

Event 2 : Someone emails me over and says "Do you know any Developer who knows Agile?"

Event 3 : Back home I have a guest who turns to be a IT Pro and says "Our company is going Agile now, I need to learn it now"

Event 4: I hear that a scrum has to be only 5 minutes.

So I thought I would write something about the myths that people carry when they enter the Agile arena... Eventually I faced the same issues when I first moved Agile way and had similar myths in mind....

So to start the post I would like to say..

1. Change of requirement across the development cycle is must, As long as the developer is in the area of development he can accommodate that change, many times we hear the changes and put them into the iteration plans immediately or in further releases...

2. Agile is a methodology, A Principle.. not a technology.. somebody can know what Agile is.. but not as a technology but as a foundation to a process..Agile Developers are expected to be Independent, Intelligent brains that can take things up on their own, split them to some level and build it iteratively to be accurate (Remember Code , Test , Code and Refactor algorithm)

3. Please don't learn Agile. Read it , adapt it , evolve it.. but never try to fit what is written on Agile web sites to what you do... instead fit what you do into the Agile principles... e.g. Agile says iterative development , break up items that can be released frequently... But what if your product doesn't demand it? for instance if you have a thick client that needs to be rolled out every release, would a clear agile help you? No it would add overheads.. OVERHEADS do you hear me?

4. Scrum maybe of 5 minutes.. but imagine if I say

"I worked on Java yesterday, I work on Java today and I have no obstacles" I am sure you would know as much enough as the word says and nothing more... A standup to me is a place where the Project Manager really gets to know whats going on with each of the developer.. , what blocks is good to know but not necessary that what not blocks you may not block others... moreover it is important if the PM knows what can potentially affect others too?

So in a chocolate wrapper if I have to say this I would say that Go Agile, Not by books.. take the Lean principles and then start putting them in the flow, evolve, learn and evolve. Eventually I gather it may be interesting for you to know the myths I had when I got into the Agile principle adoption...

My List of Myths I had

1. Agile, Where is the process?

What I learnt over years : In a Agile mode you are into the process, every day , every hour... You dont start doing the design at first and then start development, instead you define your design iteratively.

You don't run into the age old Initiation, Planning , Executing, Controlling and closing phases... instead you get into a combined phase into shorter periods which in short term is a working feature and in long term becomes a working product.

You dont write a 10 page document to define a requirement, instead you write a one line behavior .

You dont log a change request, you adapt the change in the Iterative feedback.

2. Agile? where is the Project Plan?

There is nothing called a Project Plan... your story board is your Project plan, your story chart is your project plan. We define a master list with members allocated and thats the high level plan. Every thing that we code is in some form of user story, sometimes functional sometimes technical.

3. Agile? Chaotic Development?

Yes.. Indeed. It is to all those who are not involved. Agile demands involvement and ownership. If you own something and are involved, you wont feel chaotic. Read the famous Chicken and Pig story.

4. For any development methodology , there has to be a minimum process

Agile is a value system. Care about the values and principles. Take inputs from the manifesto... but NO there is set of rules / processes that would make you agile. Agility comes with the principles, not with processes.

5. Not Co-Located ? Not Agile?

Agile works well distributed. If you just have the right set of people. it just works well with co-located teams.. but can work better with distributed teams too :P

Now shall I leave you to go visit the Agile Manifesto and ask yourself one question if you really want to be Agile...

WHAT MAKES ME AGILE?

If you dont get an answer.... Lets talk!!!!