This is my personal mainstream where I try to dump my brain. Topics I'm interested in are: agile development, enterprise 2.0, deep dynamics in development teams and architectures.

Sunday, April 06, 2008

Thought on how Scrum is addressing Stress.

In the next 2 weeks, I'll have to present Scrum in a Scrum Session in Florence. I'm thinking to focus on kinds of management Scrum can do:

  • formal side where task are clearly identified at the beginning, clearly estimated and clearly track in a day by day basis having all the Scrum Archetypes delivered;
  • process side where all the parties involved in Scrum become active parts in a production chain, having the all the Scrum Events implemented;
  • informal side having a way to address how relationship works and influences works

Formal and process is addressed by the Scrum methodology having the right role working with the right criteria and following the right Objective. There is ton of documentation explaining how to build a Scrum process in an organization.

Working since several years with Scrum as a Scrum Master and watching team deep dynamics, I've found that burndown chart can reveal more than the status of the delivery.

In modern project managing techniques, project is only managed watching Gantt diagram having relation between phases connected. On the Gantt bar there's no confidence on how really the project is going; this because feedback is managed by a stakeholder, typically a project manager, and are not managed by the team.

Stress in the same way is not addressed letting team to self organize without a Criteria and having it emphasized last at the end.

By self-managing, a team is planning in terms of hours how the sprint will be conducted in terms of task to be accomplished, of issues and of assumption.
By outlining a Sprint Backlog where members some hidden information can be revealed. I think Stress is one of those.

Stress like other "energies" is something that, consciously, a team spends to accomplish a Sprint Goal.

The total amount of hours identified at the sprint planning meeting can be thought as the energy to be spent and energy focuses on pressure and pressure focuses on stress.

So a burndown chart can be seen as the project addressable stress, and an ideal curve from the beginning to the end of the sprint should be the ideal leveling of stress during days.

A Sprint Backlog task is coming from a prioritized Product Backlog; the first task refers to the most important feature to be implemented and the more stressing feature for the customer point of view.

By anticipating stress resolution, stress decreases while each task is done and each feature is completed. The next feature is less "important" than the previous with directs implications on stress.

A scrum master should point out that having a

  • product backlog prioritized
  • sprint backlog discussed in terms of hours (4 to 10 each task)
  • daily scrum
  • daily updated Sprint Backlog

is not addressed only the delivery of the project, but it is delivered the consistency of a team in term of psychological health.

I'm not a psychologist, but I'm searching a way to improve team day by day living to work better in a stress free environment.

Endnotes
The team is focusing on Phase Archetypes because they continuously increase focuses every time on what bring them out of burning. Common Objectives are lost against Phase Objectives. Without the right priority and without the right self-management strategy, team is move to do fancy stuff at the beginning and run faster at the end spending all the energies, creating pressure and then moving to a negative environment.