You as a team: is it so vulnerable?

Project management practices introduce the coordinator of a project who's main responsibility is to manage and facilitate the project flow removing any impediments. Agile introduces the concept of self-organizing teams, where all the people manage themselves.




Project managers iterate on a Planning sheet and even a Gantt chart updating information on it, while Scrum identifies a Sprint Backlog as a driver for the current sprint and the product backlog as driver for the project. While things are pushing with a rhythm, team is delivering and project manager is governing each situation everyone is happy and the project feels good; but, someone in the team can lose the control of what is being delivered. It doesn't matter who is responsible for the matter, but the situation starts making all the rest suffering until crisis. This kind of problems emphasizes and become bigger time over time: like what happens in a domino.This can be still managed at last by the Project Manager that will solve the problem removing any impediments. But, what happen when the domino starts from the Project Manager or involves the Project Manager too? This is a case of the unreliable management, where the perception that a problem is occurring is not emerging and emerges only when the entire project is failing. Traditional software management practices tries to solve this problem by creating an hierarchy inside teams, where on top resides the project manager, than the team leader, and then all the others.

The team leader is clustering around the project manager to maintain good health for the project. This is a good way to establish a balanced monitor in the team management staff. But, what happen where the cluster is itself not reliable? Well, the domino effect occurs again. Agile software development is addressing this lack by promoting the entire team as a project manager and bringing a way to share daily a snapshot of the project feeling. A Sprint backlog is the driver for an iteration (Scrum identifies a sprint as an iteration), a sprint backlog is written by all the team members and is estimated daily. Every day all the team's player must re-estimate the work in progress with the hours remaining for the specified task, and every day the team must respond to the customer (in scrum is the product owner), on what they have done the previous day, what they will do in the current day and which is the problem they're finding on their way. The daily meeting is useful for the team too, because they can observe every day the remaining work to do and they can start anticipating some problems.

What happen if someone in the team is exploding?

The problem is faced in two ways:

1) At least through conversation during the daily scrum, when the exploders is not able to commit a task because his problems;
2) Formally by watching the sprint backlog and seeing the team feeling is not so good. Estimated hours should decrease while the time is passing; if a team is not feeling good, the decrease speed can be less than the expectation.

A daily meeting involves, three actors: the scrum master (who makes thinks happening), the team and the product owner. Every day one of them, can feel how the project is going formally - through the spring backlog - and informally through the daily scrum conversation.

This is the way Scrum and more generally agile is avoiding the Single Point of Failure where a Project Manager and a Team Leader cannot perceive a project failure.

A good Project Manager will discover that she is already doing something similar with her team. Scrum is all about common sense and shares the experience in managing complex situation. The Sprint Backlog is the driver for the sprint and to gain benefits must be updated regularly daily.

The daily estimation can produce a graph (in Scrum called Burndown chart) that visually represent the hours remaining. This can be good to check with only a sight the entire feeling of the team.