For 90 Seconds You Have Little Control - After That it is up to You !

I learned something very interesting this week at my therapist. She told me that scientific studies have found that when a person is exposed to negative emotional situations like anger, surprise or stress it takes 90 seconds for it to pass through your system. During this time, you have very little control.  This is a physical fact, like gravity.

Our mothers told us to count to 10 when we get angry before we do or say anything. Turns out, we should count to 90. Even though our mother was off by a few seconds, the idea was the same, hang tight for a while before you do anything.

How does this relate to Agile process and servant leadership?

We all have encountered situations that invoke negative emotional feelings. With this knowledge under our belt, we know to wait a bit before we begin to formulate a response and then act. After this 90 seconds passes, we do have control but we have to wait.

Let the 90 seconds pass, then figure out what to do. After the 90 seconds, it is up to you!

Read More

How to Control Your Emotions in Any Situation

Exploring Three Agile Principles - Design Excellence

This article explores three of the Agile Manifesto Principles that I have categorized as Design Excellence.

If we hope to maximize an agile approach we need to design and build excellent software solutions. These principles emphasize these points and allow us to accommodate change. Design excellence is not a once-and-done thing. Like most of agile it is a journey that requires vigilance and attention to changing events.

Continuous attention to technical excellence and good design enhances agility

We need to pay close attention to technical excellence and design as our product evolves. There is a balance between “Building the Right Thing” and “Building the Thing Right”.

We must also be wary of delivering fragile systems. If we make a few changes and our application falls apart like a house of cards we are not in a good place.

Extreme Programming and to some degree Scrum recommend Test Driven Development and automated builds as a way to avoid fragile solutions.

When we have a set of proper automated unit tests that are included in some sort of automated build, we see problems every time the build runs. The higher our code coverage is and the closer we get to continuous integration the better our solution will be. It is all about balance.

Over time, our solution will accumulate technical debt. As we weigh the tradeoffs between building it right and building the right thing, this is bound to happen. It is best to only include a few technical debt features in sprints when they are required so each sprint is delivering business value.

Simplicity--the art of maximizing the amount of work not done--is essential
Agile is all about doing the right amount of something at any given time and no more. We should author user stories with the detail necessary to get the job done and no more. We should build what we know we need now. We should not build some huge framework we think we may need someday.

It is critical to have a complete and thorough understanding of the software frameworks we use. Code is evil and we can eliminate quite a bit if we have a good understanding of our chosen frameworks.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
This principle will scare teams who are used to waterfall projects. It first glance, it seems crazy to welcome change late in the development process.

First, we must be successful at implementing the first two principles in this section. If this is not happening, welcoming change is impossible.

Late in development means late in the release of the complete product. Scrum delivers features in short sprints. We do not welcome changes in a sprint that has already begun. Because we are delivering features in short cycles, change is part of the whole process.

In scrum, the change is directed by the Product Owner. It is up to the Product Owner to understand what the competitive advantage is for the features in the backlog.

Learn More

·         Agile Product Ownership in a Nutshell

·         Coaching Agile Teams

Agile Estimating and Planning