Why empirical management works?

I'm just back from my training course in Florence with the intuition on why empirical Management works. Yes, it's true. I figured out a simple explanation on the reason of it. Before giving my impression I would like to present an exercise I proposed to my attendee to help them in having confidence on estimation. They come from the same area, and they really know well what is there including best ways to drive in when there's traffic congestion. I've started creating a Product Backlog having four routes to cities around Italy and requesting them to plan where they can bring me in 30 minutes. I've prioritized all the routes in the way. The first is really understandable, and the last is an Unknown City for them. Having it on the backlog I've started asking them which of those features can be implemented in the next 30 minutes. Consciously they've chosen the first feature. Before analyzing the Sprint Backlog of the selected featured with them I tried to do an Experiment about the Empirical Approach. To do this I've given a complexity rate of five points priority to the first feature and asked them to rate all the requested feature without thinking to much. Exercise took 3 minutes. - Second complexity was: 15 points of complexity; - Third complexity was: 25 points of complexity; - Fourth complexity was: 45 points of complexity. Having the feeling they can do five complexity each "sprint" I assumed a team velocity of five points of complexity per sprint. This mean that: - Second feature is approximatively estimated three sprints; - Third feature is approximatively estimated five sprints; - Fourth complexity is approximatively estimated nine sprints. Well the possible feature I asked them to estimate was the four cities I've touched coming back home and they gave me a reasonable idea of how many time or sprints it takes to get back. The surprise is that, even the team doesn't know some of the place (third and fourth), they did a reasonable plan making me think that from Florence to home it takes 4.30 hours. Well it has taken 4 hours and 15 minutes. The magic is they've said 45. Why they haven't said 100 or 1000 or 10000? This empirical approach work because, there's no machine, no algorithms that predict things. There is a key element that is a Sum Of Super Computer that is the group and their brain. They did the estimation thinking about their experience discussing each other and sharing knowledge. They superiority - in respect of computers and algorithms - is the ability to think by metaphors and to regulate optimistic and pessimistic position in an intelligent discussion. Becoming familiar with estimation like this need time, than experience. It was the first time they did an empirical estimation and they still think there a sort of trick behind. It's shocking how could be easy to give a projection on how things empirically will go. Every sprint they will commit their velocity, and every sprint their knowledge increase making complexity simpler and having things optimized on the experience.

On Priorities with Scrum: a Product Backlog with Penalties and Benefits

One of the worst thing is when you're facing a customer with no idea which feature must be implemented before the others.
The question is, how can I help a customer in figuring out the 20% of feature is doing the 80% of business each iteration and sprint over spring she realizes the most important feature for the next iteration. At beginning, I've started asking to complete on a basis of 10 points. Each feature where 0 is the LOW priority and 10 is the MAX Priority. After raw estimation on how complex is the feature, I figured out an ordered Product Backlog with lots of MAX priority feature and the priorly implemented are the minor complex one and then move again. With this approach, I discovered there's no rationales on the Product Owner side to decide what is really need priorly. Well, after lots of thinking I've tried to formalize a mechanism that push the Product Owner to think about the Benefits on having the feature and the Penalties on not having it. With this approach, I've pushed the Product Owner mindset from a selectable option to a selection on consideration. When thinking, I found an Algorithm similar to the "Wiegers Relative Weighting Approach" where I computed which is the less complex feature with major benefits and minor penalties. Three variables influence the priority:

• the Benefits of having the feature;
• the Penalty of not having the feature;
• the Estimation (I prefer Complexity - but is another thing) of the feature

The priority is computed on:

priority = [(relative benefit + relative penalty) / (sum of relative benefit + sum of relative penalty)] / ( relative estimation / sum of relative estimation)

The bigger priority is the most important feature in terms of easiness, penalty, and benefit. In this way, I discovered that Product Owners put in an ordered way their Feature List.

Endnotes

It is useful to work with this approach on attributing priorities. Product Owner works on the Product Backlog and integrate the new feature with this approach and reorder them. This is how a team should commit on a bunch of feature that is really valuable for the Customer.

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.

Oblique Scaling™

I'm just back after a weekend on the snow, and I'm happy to know that Oblique Scaling is producing the correct result in mondora.com. Mondora's engineers thought Hardware could be thought as Software, like Virtualization does.

Having Sense as a common infrastructure, they've just released a component called Scent that meets Hardware availability and Software suffering.

During last past 2 weeks they stressed the Sense Workshop on a 4 core HP starting with 1 core switched on and the rest switched off. An endurance test of 12 hours has been run, to check how Sense self regulate having Hardware considered as an High Available Service with an identified Service Level Agreement.

When system increased in suffering by switching from good Service status to worst, Sense has anticipated lack of performance by working with the Hardware Virtualization Platform and asking to Scale Up.

In terms of Business, benefits gained are:

1. This approach that Predict system performances and do some actions to make the system surviving.
   
2. This approach let to Scale when unpredictable things occurs. This is the case of a Campaign that is producing more than the expectation and if the system is not adaptive, Campaign is loosing all the Customer, both the predicted and the unpredicted.

In terms of Manageability, benefits gained are:

1. Vertical Scaling is predicted by Application Constraints and matched with Hardware Service Status
2. Policy can be configured (ex. switch a CPU after a 15 minutes of suffering)
3. Scaling policies are described as Algorithms and implements different strategy. This let to configure a strategy where network latency is compared with Service metrics. By comparing Sense can avoid Horizontal Scaling versus Vertical Scaling

In terms of Development, Hardware is saw as a Service itself and can be allocated runtime when business constraints need it, like another Service on the Net.

By having this building block certified, Sense is becoming a real implementation of a Future SOA where Services:

• are available over the network in a cluster environment
• are self federating
• are balancing on SLA policies
• are balancing on Business Constraints by flocking
• can balance on most productive in terms of ROI
• are multi protocol invokable
  
• can be perceived from the outside environment as inside components
• are physical resources

This is a really implementation of what SOA can be.