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


Anonymous said...

The real problem is management philosophy, try reading on TOC ( rather then reinventing the wheel.

Przemysław Bielicki said...

MicroIteration concept is not an invention - it's an observation. TOC is high level theory and I don't see many connections with what I wrote...

Theories are good - in theory :) Try solving any concrete problem with TOC and I will congratulate you.

Anonymous said...

Your critical issues or tasks are constraints. Weekly progress tracking and tasks reestimating is part of TOC applied to Software Engineering, but using TOC you estimate the whole project in a different way. Really, read:

Anonymous said...

Let the bird fly as high as he wants to! I'm really curious what comes next ;) All the best in 2007!

Anonymous said...

Looks quite reasonable (agile enough :)). However I don't agree that good tools do not facilitate communication. I still believe that if you have some issue - it is better to report it down in some tracker (like JIRA or bugzilla) then send an e-mail (often ignored, lost in clutter and untraceable) or chat (the latter often disturbs developer and he loses concentration). But you should not fully count on the tool. If you see that there is no reaction (e.g. the peer has not commented on the issue, start working, etc.) you can (and should) always enforce reaction.
Concerning TOC - I don't like theories :). I would prefer seeing some practice basing on this stuff.