One for the environment !

It all started when I was sticking a story card up on our story wall, and someone shouted "Dude, how many trees are cut because of our story wall !"

Today our team planted around 21 saplings near JP Nagar 7th phase with the help of TreesForFree The team outing was unique and immensely satisfying for everyone. In fact we decided that from now on we will plant one tree per story we deliver in a release ! (Sripad, who played a key role in organizing this outing, wanted to go to the extreme of 1 tree per story point !)

Apoorv has blogged more about the outing here.

I strongly urge all you agilists out there, who love your story wall so much, atleast plant one sapling, to heal the earth !

(It is hard work in the sun !)

Understanding project risks in a self organized team

Risks and Issues for a project is often a matter of worry for a project manager in a team. When you start asking your team to self organize themselves, one of the challenges is to get each individual team member to start thinking of risks and issues for the project/team.

One of the things which helps during the start of a release is to run through the project plan
through a small group of people in the team, to make them understand what they are signing up for. So if your team has 6 pairs of developers it will be nice to run the plan though with 2 pairs of devs, a BA and a QA, and again repeating it for the remaining set of people. It does not matter whether they are freshers or experienced people, they start thinking about what can go wrong in the project. People start asking more questions on "Why the capacity is so much ?" , and "Why are we planning for these stories in Iteration 2 instead of 1 ? ". More importantly you sign up for a release/project plan as a team and not as a project manager/tech lead.


The team also needs to keep an eye on the risks and issues that they identified and constantly seek solutions to mitigate them. There might also be new risks poppng up. What a team can do in this case is to have a mini risks and issues wall near the team area. It can be an X-Y graph of Risks posted on Likelihood v/s Impact.





Even a white board with risks being updated will do , but what matters is that it resides in the team area. A developer taking a break or a stroll around the team area should look at it and wonder "What can we do to tackle that high risk item ?"

Watching open feedback session helps people to open up

Soon after we did a feedback workshop in the team, we gave everyone options to either use a group open feedback session, a one to one session, or a written medium to gather feedback.

As anticipated, a few of the team members were skeptical about the open group feedback and opted for a one on one session. But we kept the group feedback session open to this set of people as well, so that they could witness how it works.

And quite nicely, a few of the team members who were quite skeptical at one point about being given feedback in the open, decided immediately to have an open group feedback instead of having one on ones.

That move felt that the team dynamics were indeed headed in the right direction ! :-)