Tuesday, January 30, 2007

Sun Certified Java Programmer's logo

Although I passed SCJD on August 2005 I lost my logo :( I requested it once again and received it couple of days ago (I'm very happy about that fact :)

Regarding my SCEA (Sun Certified Enterprise Architect) exam - I'm stuck and don't know whether I'll manage to sit this exam by June 2007...

See also: SCJD logo

NOTE: Logo above belongs to Sun Microsystems and you are not allowed to use it for any purpose. For details refer to: Sun Trademark and Logo Usage Requirements.

Monday, January 01, 2007


Problem statement

Our team most often sets two-month iterations in which we commit to implement defined features as well as fix known and new bugs that will appear later on. This time is called iteration (we also call it release) in XP and is fine grained in my opinion. We define set of tasks (we use JIRA but any other issue tracking system is fine), bugs, improvements, etc., assign them to most relevant developer, estimate them and start working on the new release/iteration.

We've encountered big problem recently. If project manager does not track project progress on the regular basis project will delay. How it's possible? There can be many reasons but excluding wrong estimation I will stress problems I see in our project:

  • Developer working on issue can be (and often is) interrupted by other developers who assign him/her new tasks because they cannot cope with some problems.

  • Developer working on single issue can encounter more and more problems, add them to issue tracker and then prolong original issue

As far as the second bullet is concerned it is quite normal that undiscovered and new topics will expand to many small subproblems (issues). However, the first bullet can be really serious. Developer commits to his/her PM that he/she will deliver concrete issues by the end of the week (let's say XX-200 and XX-203). Unfortunately for this developer another developer assigns him/her new critical issue that has to be solved immediately. Developer has to stop working on committed issues and start working on the new critical issue. At the end of the week there is a big surprise because:

  • PM does not know nothing about the new critical issue

  • Developer who committed to finish issues XX-200 and XX-203 did nothing about them but finished new critical task

  • Project plan extends because two issue that has to be completed by the end of this week will be postponed for the next week

I see one reason why that happens: lack of communication. Very often developers and PMs trust too much tools they use. For example if we use JIRA I know that every new issue goes to the PM (by email), but I don't know whether my manager reads these emails and checks how it affects the release plan.
In example above PM received the email but did nothing about that. Also developers (one who created the issue and one who was assigned to the issue) made a mistake because they should communicate this change to the PM (DON'T TRUST TOOLS - COMMUNICATE).

Following Use Case diagram shows the responsibilities and indicates where is the problem and how to solve it:


I defined iteration earlier and now want to give my proposal how to solve problem presented above. Having one or two-moth iterations we can define MicroIterations that will always last one week. At the ending of the week the whole team meets (30 minutes is max - 15 minutes should be enough) and every developer commits to resolve/work concrete issues. PM has to write it all down (it can be done by the tool or in the individual developer's status report) and track the progress. Every change has to be communicated to the PM e.g.:

  • when developer sees that issue will take more time,

  • when somebody assigned the developer new critical task and working on current issues has to be postponed,

  • etc.

Having such knowledge PM can easily adjust release plan and move some tickets to the next release, assign additional resources, delay release, etc.

To recap my ideas I will write down responsibilities for the PM and the developers:

  • Project Manager is responsible for the project;

  • Developers are responsible for the project and for the communication between other developers and the Project Manager;

  • All team members are responsible for using they brains and well known new global buzzword, namely common sense.

As far as tools are concerned they should be used for generating reports, visualizing progress, as communication hub, whatever else, BUT tools DO NOT:

  • THINK for Project Manager and Developers,

  • COMMUNICATE problems,


Tools only HELP PM and developers.


Communication in the team is one of the most important success factor. Without good, efficient and effective communication it is highly probable that your project will be crap. MicroIterations concept should help in realizing and establishing some realistic lightweight communication patterns within project team. To recapitulate the most important aspects:

  • MicroIteration should always last one week

  • At the end of each week team members meets (15 - 30 minutes long) and each team member commits to deliver concrete outcome (e.g. solve some issues)

  • Project Manager tracks progress of each developer (not exactly track but check the real outcome next week)

  • Developers has to meet their commitments - if the developer knows that he/she will fail he/she MUST communicate that fact to the PM in order to change plans

  • Project Manager has to adjust release/iteration plan according to changes (e.g. new issues, prolonged tasks, etc.)

  • Developers has to communicate their progress (especially lack of progress) and every problem that can impact issue delivery date

  • If there is no tool available that can track developers' commitments PM cannot say that it is impossible to comply to these rules - if PM does not have relevant tool for that he/she should use Excel or just piece of paper and a pencil - it's really simple and every dummy can do that (and PM's are not dummies :)

  • Developers can and should assign other issues to other developers but they should communicate that fact to the PM - PM can then change assignee or adjust other issues - developers should not blame other developers for not having time for their issues (commitment is important and can be changed only if PM knows about it)

Yet another process?

What I tried to present is a way of working in a team I used to work. Our team was really successful and we were very flexible. We communicated every problem to the Project Manager and had no problems in delivering even complicated and experimental features on time. It was not only because we were great engineers, we estimated our effort precisely, etc... No - the reason why we were so successful was the COMMUNICATION. It is not any kind of process or methodology (even lightweight ;) - it's just piece of tips how communication within project team can boost productivity and make team successful.

PS. Happy New Year 2007