Tuesday, April 26, 2011

Agile is Fun

Whenever I ask any person in an interview or in normal discussion, “What is Agile and what are your thoughts on it?” The Answer I always get is, “There is no Documentation in Agile and we have a morning meet every day.” Is that Agile all about?

What I feel, Agile is about “Inspect and Adapt”, “Continuous Feedback”, “Collaboration” etc.
My first “Sprint Planning”. Before we began the actual Sprint planning, we declared the available number of days of each of us and that gave the Scrum master the estimate amount of Man hours he has for the present Sprint. We used to consider 6.5hr productive for a resource in a day and estimations were done considering the same hours. The participants in the planning were, Solution Architect, Senior members, BA team, UI team, Scrum master, Development, and QA. Sometimes the Product Owner also joined use in the planning. Each one of us was given cards bearing numbers 1 to 10 and a question card. Decided list of PBI’s are shown to the team and the BA explains all the items to the team so that all have the insight and scope of each PBI. On declaring a PBI by the scrum master, all the Dev raised a card declaring that if he has to do the task he will take this many hours, if the task is of Dev. Two members, having the highest number of hours and the lowest number of hours then justify why they think it will take their selected amount of time. It’s quite possible both of them overlooked few things or underestimated/overestimated the task. After the discussion, the cards are raised again by whole team and a mutual agreed estimate is noted down by repeating the above exercise. It takes almost a day for Sprint Planning but it’s worth it considering the whole sprint.

In Normal circumstances when a person says I am “Done” with a particular task, what does he mean by the term done? E.g. he was given a task to write a test case for a particular module, and he is “done”. This means he has written the test case? He got it reviewed by someone? He got the coverage calculated?. What do you mean by “DONE”? Here comes the other best thing we used to do is “Definition of DONE”. When a developer says I am done with this task and he moves the card from Dev to Dev-Review what are the things he should have done to call it DONE or move the card?
1. Written the code to meet the requirements
2. Written the Unit testing for all procedures and functions
3. Written proper comments
4. Verified the UI matches the standards etc.

Once he does all the things, he will call it “Done”. The most important thing is, in the “Sprint Planning” the estimate was done based on the steps you define in the “Definition of Done”.

Why should we have “SCRUM”?. We say the following things in the morning scrum.
1.       I was doing this yesterday: This ‘in a way’ was my commitment to my team for yesterday. Did I do it? Yes-Great. No-why?
2.       I will be doing this today: This is my commitment. I will do it. I like when someone says, “Hey don’t do it, I did some portion of it yesterday in my part of work, and you can reuse that bit”
3.       Impediments: I am facing this issue. Anyone knows the solution? Mr. X, I need you to finish that code today as I am waiting for it to do my job (and it was planned and estimated so). OR I am waiting for the feedback on this PBI from BA/Scrum Master. Once I get it I will start working on it.
It is required that the team understands the reason why this is important. The idea is not to monitor any person and grill him, but being positive and trying to find out what the problem is and take care that those things are considered too in the next Sprint Planning meeting. This way we get good collection of points which needs to be addressed in the Sprint Retrospective meetings too. Believe me SCRUM helps and being positive in SCRUM helps more.

The best practice we followed after SCRUM was to update the “Task board”. This gives the whole team what is going good/bad/worst just by a glimpse of the board. Even people know what task is coming up next. The members come to know the Review’s coming up for the day and discuss who will pick up review of what. It’s easy. (The Code review roaster also helped a lot in this case)

We also used to update the “Burndown Chart” on day to day basis. It was not decided in the Sprint planning that who is going to work on a particular task until the new task is completely dependent on the previous one. Updating the Burndown chart also allowed the team members to pick a new task by themselves, without anyone telling him. This is flexibility and collaboration helps at this stage. Burndown chart allows the Scrum master and the Team also, to monitor them against the Planned Tasks VS Time for that particular Sprint. This raises early flags or alarms if you will, in the team to take precautionary measures (If possible) to move the team back on track. This helps to find out the Team velocity, which leads to accurate Sprint planning’s at the later stage.

One of the activities done at the end of the sprint is “Spring Review”. This activity was interesting as the person who developed/tested a particular bit of functionality, proudly demonstrated that to the client and receive instant feedback. The whole team used to sit in a room with the client may be physically present in the room, or over live meetings and do the presentation. Normally Sprint review and Sprint retrospective are done on the same day.

Sprint Retrospectives” was held at the end of each sprint. The motto is to discuss among the team members what went right, wrong, worst in the sprint. I still remember the host of the Sprint Retrospective asking a person who didn’t look happy for the sprint, “Mr. X what do you have to say about this sprint?” The reply was “This sprint sucks”. On asking “Why?” he had a legitimate list of points. The points were discussed and Action points were noted which were followed by all team members. The next sprint Mr. X was certainly happier. Again, the aim of the retrospective is to discuss such points in more matured and professional manner. This is “Inspect and Adapt

According to me, these terms and methodologies we followed were very adequate and at the end of the day everyone used to be satisfied. There is a thinking that, just do your work with any kind of process you need, and as far as it works for us, the terms or the rules doesn’t matter. This is like “Customizing the Customizations”. Would you allow yourself being called by other name? Stick to things which have been proven and studied upon.

For Indian friends like me, the only thing I want to point out is, it’s in our blood that we cannot listen to criticism, feedback in a positive manner. It’s not always true that when someone tells you to improve in a particular area means he is pointing at you, but take it positively and try to improve on it. Learn from the criticism and take it in a constructive manner. Try to work with more collaboration and ownership. Communicate more with people and share the knowledge. I am also learning.

Disclaimer: May be I am not good at writing the things, but just sharing my thoughts from the learning in my past experience.