Agile Retrospective, An easy way to misunderstand Agile

Retrospective generally means to take a look back at events that already have taken place. In Agile Software Development, at the end of every iteration a retrospective is held to look for ways to improve the process for the next iteration.

Few years ago, I came across something called AI (Appreciative Inquiry) Retrospective. This type of retrospective focuses on “celebrating the good result” and “gathering necessary improvement” for coming iteration.  Since I knew about it, I never had thought about the classic retrospective meeting until someone said to me “s/he feels like sitting in Jeremy show (This is where people come to argue and my assumption is, no one wise human ever watches these shows, at least I haven’t)” while sitting in this kind of meeting.

Here is what I suggested them.

1. Look for alternate types:
It’s easy that few people who has got art of speaking will speak more and dominate the meeting. In something like AI retrospective, everyone gets their turn to speak and make suggestion.  Some detail about this method can be found here.

2. Collect enough data during the iteration.
It’s important to have enough data so that any changes required in the team and process can be forced to the sponsor.

3. Don’t forget Agile Manifesto (Self Organized Team)
As the manifesto says, agile team is self organized team. Face to face communication between the team is important. When one of the team member sees any problem, it’s important to raise this with team.  So, don’t wait until team of the management is in the meeting to mention the problems and No, it doesn’t prove you smart.

4. Never blame a team member in retrospective
I assume, as a team, you run daily stand up, reviews and all other quality testing tools, methodologies which should give you an idea of issue within the iteration. So, don’t wait until retrospective to improve things. If you are waiting, its your mistake. So, don’t blame other member of team.

5. Don’t involve sponsors in these meetings.
It’s my very personal view but it may be that, blame culture can be developed just because one of team member is trying to get an attention of sponsors.

So, whole point of adapting Agile methodology is to have self organized team, increase communication and visibility and improve the results all the time. Doing it wrongly, only lower the moral of the team, even if it’s half an hour meeting every two weeks.
Hope It was a help for the struggling team.

Posted in Agile Development Methodology | Comments Off

How to add color and GIT Info to command line

If you are thinking, it would be nice to have some information about GIT when you are in one of the directory cloned from git repository, it’s possible and yes, it’s very useful.

This is how you do it.

add following to ~/.bashrc

export PS1=’\[\033[00m\]\u@\h\[\033[01;34m\] \[\033[00m\]\w \[\033[31m\]$(~/bin/vcprompt/vcprompt) \[\033[01;34m\]$\[\033[00m\] ‘
source /etc/bash_completion.d/git

This will show your terminal to look like this.

~/My/Project/Directory [git:Branch-Name?]

Where ‘Question Mark’ is for uncommited changes. So, it helps to show you which branch you are in + what is status of you local copy.

That is it.  Little things help to make you productive.

Note: Tested only in Ubuntu 11.10
Posted in GIT | Tagged | Comments Off

How much do I agree with story of Woodcutter

A very strong woodcutter desperately looking for a job, got one at the end. The pay was really good and so was the work condition. For those reasons, the woodcutter was determined to do his best.

His boss gave him an axe and showed him the area where he supposed to work.
The first day, the woodcutter brought 18 trees.
“Congratulations,” the boss said. “Go on that way!”

Very motivated by the boss words, the woodcutter tried harder the next day, but he could only bring 15 trees. The third day he tried even harder, but he could only bring 10 trees. Day after day he was bringing less and less trees.

“I must be losing my strength”, the woodcutter thought. He went to the boss and apologized, saying that he could not understand what was going on.
“When was the last time you sharpened your axe?” the boss asked.
“Sharpen? I had no time to sharpen my axe. I have been very busy trying to cut trees…”

So, how is a developer can learn from this story?
In development, it is important to sharpen the axe. Keeping knowledge of latest and greatest technologies, keep up to date with newer version of software, being aware about changing demand of market, always learning more stuffs  are supposedly sharpening the axe for a developer.

I always hear the conversation about “using cool technologies”. But it’s not about just using cool stuffs. But latest stuffs has more likely to fill up the current demand, solve more problems and give benefit over classic software by improvement over existing alternatives.  It’s obviously developers job to choose the right solution for right problem in right time. Trying out new things to solve the problem should surely benefit.

Long story shot, if we don’t take the time to sharpen the “axe”, we will become dull and lose our effectiveness.

Source of story:

Posted in General | Comments Off