Mantenere sotto controllo il livello di stress, evitando ansia

 

Obiettivi

Nelle situazioni maggiormente critiche lo stress inizia a prendere forma e a introdurre uno stato ansioso che toglie lucidità nelle decisioni. Durante la conferenza un protagonista di competizioni di lunga durata (Endurance) parlerà del modo con il quale sono affrontati i momenti di maggior stress sia fisico che psichico, per riportare una situazione di crisi alla normalità ed aiutare se stessi a mantenere equilibrio, anche quando i fattori esterni sono tutti sfavorevoli, per perseguire e riuscire nei propri obiettivi. Un continuo processo di ispezione e di adattamento di se stessi permette di mantenere la fiducia, la capacità e la forza per poter continuare senza flessione.

Il costo di partecipazione è pari a € 600,00 a persona. Durante la sessione saranno previsti alcuni coffee break.

Data: 22 settembre 2009


Location: AtaHotel Contessa Jolanda,

via Murat 17,

20159 Milano,

SALA BEATRICE


 

Formazione Personalizzata

Per saperne di più e progettare in maniera mirata il corso, contattate:
Lucia Longoni
tel: 800.180.494
fax: 0623315403
e-mail:lucia.longoni {at} mondora(.)com
Durata: 1 giorno

 

A chi è rivolto

La conferenza è rivolta a chiunque voglia imparare a riconoscere ed affrontare le situazioni di stress in realzione alle proprie attitudini e conoscendo i propri limiti

A fistful of quality code: me and my colleague

Last edited by on September 28, 2008 6:52 am
The title can be more appropriate for a Spaghetti Western movie but is appropriate in each situation pair programmer are surviving theirs daily’s milestones enjoying work and maintaining a good environment outside them. “Pair programming” is identified by two words: Pair and Programming. Every developer knows exactly what is programming, but a pair requires some confidence with humans too. In this post I’m focusing on the Pair word of Pair Programmers, analyzing some successful factors like the Rhythm while working.  

Like two cowboys a pair must work with a single objective every day, watching each other and helping each other; the external environment is like the desert with rolling Joshua trees and with condors flying, waiting, and watching for the next lunch hopefully with someone “freshly died”.

Imaging all this with a Sergio Leone’s music that is creating a more characteristic environment, where the rhythm is perceived watching the movie and listening the drum.
Two developers are in the same situation: they help together in finding the best solution for the daily milestone and they need to find out a perfect rhythm.
Like in a movie, some of them are the principal actor, and the other is helping in surviving the scene taking care about the stress and trying to keep her safe from external interrupts.

The main actor in a pair is the one who’s typing on the keyboard and typically writing the line of code. In terms of development perspective the secondary actor has to discover bugs, to seek for documentation, to write documentation, to diagram, etc. While taking care of human feeling, the counterpart’s job is to help the principal coder in doing things including stress management.
She has to know when it’s time to take over and switch the scene acting as principal actor.
The frequency of a takeover implies the actors to watch each other, taking care about the health of the pair and trying to keep it good every time.

This is reflected on the quality of the code produced: every scene is played by the less stressed developer. Thus, the other can relax a little bit helping the next small iteration.

In this post I’ve examined three intra-personal factors that help a pair in staying consistent and durable over time:

 

  • Rhythm: developers play the scene and the rhythm too. Rhythm translates is directly related to speed team. Without rhythm stress increases in one developer and low commitment increases on the other side. This is against the milestone.


  • Watch the watcher: developers should watch them as Person and not as developers; programming skill is confirmed line over line, and more humans’ behavior (like stress) can easily hide. Watch the watcher if you want to be watched, is a protection guarantee for every developer that would like to work actively in a pair preserving her health prior to the colleague health.

 

  • Takeover when need: avoid to much stress exposure for your colleague? In software development stress is the first cause of low quality. Being the principal actor confuses the main developer and sometimes can drive to the wrong direction, then frustrating and then stress. When your counterpart is loosing her speed, grab the keyboard, and continue typing (of course at your speed). You’ll notice that this rapidly debriefs your colleague making her reacquiring her rhythm and then asking the keyboard again.


In a next post, I’ll discuss about the relation between rhythm and speed in software development.

Thought on how Scrum is addressing Stress.

Last edited by on April 6, 2008 6:00 am

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.