The importance of team retrospectives

One of the core components of team adaptation theory is that for teams to increase their adaptability (read: agility), they must reflect on past activities. If you look at any high performing team you will notice they all have one thing in common. All high performing teams take time to reflect on past activities so they can find ways to improve. This shouldn’t come as a surprise. All high performing teams do it. If you look at high performing teams in sports, business, law enforcement, the military, etc., then you will find teams that perform some type of retrospective. Those teams may not call it a retrospective, but they still reflect to answer the same basic questions: What did we do? What have we learned? What should we do differently? Where can we improve? Sadly, many teams view retrospectives with disdain. People are rarely motivated to do the hard work that retrospectives demand. The result is a meeting that produces very little in the way of learning let alone strengthening a team’s adaptability.

Read More

Measuring Agile

One challenge of working with organizational leaders and Agile teams is leaders want to know when a team is considered agile. The question leaders want answered is, “How Agile is the team?”

This is not an easy question to answer on its surface. There are many variables that can affect a team’s level of agility. Below I outline a few variables that all organizations should consider when trying to assess a team’s agility level.

Read More

Time for Agile to adapt

The Agile Manifesto is an outdated relic. Agile practitioners must systematically overhaul it. As written, the manifesto constrains whole organizations from becoming truly agile.

The above paragraph is a radical proclamation sure to ruffle the feathers of many Agile purists. I did not arrive at that conclusion lightly. Years of studying and practicing Agile lead me to that conclusion.

Read More

Requirements Gathering in Agile Scrum

Two years ago I was involved in a large software development project that included developers, architects, and systems analysts. The team was organized into a scrum team along with corresponding product owner and scrum master. There was a lot of optimism and energy during the forming stage, as usual, but all of that quickly came crashing down in execution. 

Read More

Software development is like creating a TV show.

One of the challenges with software development is that non-technical people in organizations are the ones who solicit software projects. Business leaders, particularly those in marketing positions, demand software and also demand that the new software is not released until it is "done." However, name one person who actually believes that software reaches a done state where zero updates and upgrades are needed.

Go ahead, I'll wait.

Read More