Monday, October 26, 2009

Need for matured developers in Agile Teams – A Myth

I have heard many times from in-experienced scrum coaches saying Agile projects need matured team members.

The Big myth
The above statement is as big a myth as the one which says Agile projects follow no documentation

The answers I got…
I had asked one of those in-experienced scrum coaches the following questions,

  What do you mean by Matured team members ? 
  Why do you think Agile projects need more matured team members ?

The answers surprised me a lot, the answers were

   Matured team means, a team with more experienced people  
   The reason we need matured teams is because, concepts like self organizing teams and self managing teams are easily understood and implemented  by experienced developers as compared to juniors.

They also say that the junior developers mis-use the freedom and trust shown in Agile projects and so, they are not suitable !!

Does maturity comes with Age ?

My view is, maturity to a person does not come with age or more experience at work.  Secondly, concepts like self organizing and self managing teams need the fundamental value, trust to succeed than any software development skill or experience.

I strongly believe that, individual team members shouldn’t be blamed. This is because, the culture followed within the team is strongly influenced by the person leading the team.

According to the greatest thinker, Peter Senge,

We must look beyond individual mistakes or bad luck to understand important problems. We must look at the underlying structures which shape individual actions and create the conditions where types of events become likely

So, if a junior team member is not doing his/her assigned job, instead of blaming him/her, we should look at the system which is driving this character within them.


Success of Agile projects does not depend on the experiences of the team members but on the fundamental value driving the system.

Tuesday, October 20, 2009

Key Do’s and Don'ts in Scrum


Cafe Pouring


Even though there are several  rules and practices in Scrum, but still they don’t  cover all contexts. Practitioners keep coming back with several questions like,

  1. We don’t have a scrum master yet, can we   make the Product Owner as the scrum Master ?
  2. Can we have a single Scrum Master for several projects ?
  3. and several others ….

So, here are some of the answers to questions like the ones mentioned above 

Here are some of them

  • Scrum Master ideally should lead only one team and the same thing applies to Product owner.  If they are leading more than one teams, their effectiveness decreases by the same fold
  • Don’t let Scrum Master to wear the cap of  product owner too
  • Don’t let one of the team members to take the role of Scrum Master
  • Even if there is a large team, ensure that there is a final product owner making final decisions about the product backlog
  • When Scrum says, team size should be 7 +/- 2, this number does not include then Scrum Master and the Product Owner

Thursday, October 15, 2009

Test your knowledge on Scrum


Ken Schwaber, co founder of Scrum has come out with an online program to assess Scrum Knowledge.

This assessment checks purely "What" scrum is all about.

Here is the link to the program with the password

password : "assessment2"

Tuesday, October 13, 2009

Agile and Model of Concurrent Perception

Dr. Rubinstein is professor of engineering and applied science at the University of California, Los Angeles, has written articles and books on Concepts in Problem Solving and Tools for Thinking and Problem Solving.

As per Dr.Rubinstein's model of concurrent perception, if we start with trying to keep the order from the beginning it leads to Chaos at the end.

For example, in traditional waterfall model, the stakeholders try from the beginning to keep order by
  • trying to gather all the requirements and freezing them
  • creating project plan written on stone with exact dates of release and delivery
  • building the design and architecture and freezing them
Since there is no room for a retrospection at any time in between, the traditional waterfall model leads to chaos at the end with the delivery of the poor quality product, missed deadlines.

Dr.Rubinstein, suggests that try to have chaos as much as possible in the system. Chaos here, does not mean a havoc/uncontrolled nature, but a sense of openness to receive feedback.

Dr.Rubinstein quotes the example of car manufacturing. Before building a new concept car, engineers from various departments are invited for a discussion and their views are taken. At regular intervals, feedback from respective departments are taken, even if it leads to many changes to the design. The system which is open for changes in the beginning, ultimately ends with Order.

If we look at the recommendation from the above model, i.e. have chaos to have order , don't you think this is where the principles of Agile fits in ? .

In case of Agile, the chaos stays in the system by virtue of practices like
  • Open to receive new requirements at any time
  • Collaboration with the customer on a daily basis and open to receive feedback
  • Self Organizing and Self Managing teams as opposed to command and control
  • Weekly review and demo for the customer to get feedback
  • Retrospectives at the end of iterations to learn from past mistakes and plan for the future

Dr.Rubinstein says
concurrent perception feeds vitality, while sequential perception saps it

Friday, October 02, 2009

Agile Project Management Tools

During the early days, while Agile methods popularity was still at infancy, there were hardly one or two project management tools that catered to the needs of Agilists. Nowadays, I hear atleast a new tool almost every other week. I thought let me list them out here.

The following list has both Open source/freeware and commercial tools and the listing is not in any particular order.

1. Rally
2. VersionOne
3. XPlanner
4. Extreme Planner (Don't get confused with XPlanner mentioned above)
5. Mingle from thoughtworks
6. TargetProcess

OpenLogic in turn has done a nice work of comparing the following(7 through 10) 4 open source Agile PM tools
7. AgileFant
8. IceScrum
9. Agilo
10. eXplainPMT
11. SilverCatalyst
12. GreenHopper with JIRA
13. Agilebuddy
14. WoodRanchTech
15. PivotalTracker
16. BrightGreenProjects

17. XPlanner+ (Thanks Sezam20 for referring this tool)

Additional Information
You can also get additional details for some of the above tools from here.
Mike Cohn maintains the list of Agile PM tools here . (Thanks Phil for sharing the link)

Feel free to share the names of any other Agile PM tools that you might have come across and is not present in the above list.

Thursday, October 01, 2009

Applying Pomodoro technique during Pair Programming

What is Pomodoro ?
Recently I learned a technique to improve the productivity and efficiency of my day to day activities. This technique called Pomodoro technique is not a new one, however I have rarely come across people practicing it. It has been two days since I learned this technique and started practicing it, trust me, it is a life changer.

The 5 minute overview of this technique could be found here. Interesting thing I found about this technique is, it has some of the characteristics of Agile methods.

To name a few,
  • Time boxed Iterations
  • Review at the end of the day and feedback to improve for next day
  • Sustainable pace
Applying it on Pair Programming
I also found that this technique could be used while pair programming. As we know, during Pair programming, one of the recommended practices is to change the pair's role once in a while. By applying Pomodoro during pair programming, one could change the roles every 25 minutes with 5 minutes break after that. Even though 25 minutes rule is just a recommendation, I felt that to begin with 25 mins time boxing is really optimal. More information about applying this on pair programming could be found here

The Challenge
During the initial pomodors, I found it really hard to work continuously without getting distracted, either mind comes with new thoughts , some work, etc or some one comes to disturb.

Software influence
The author recommends using Pencil, Paper and the kitchen timer (pomodoro) for tracking the sessions. However being a software person, it is tough to keep your eyes off the spreadsheet/word doc. I don't have a kitchen timer at home, however I am using a software timer to keep track of the time.