Incremental Agile

One of the fundamental properties of Agile is the concept of incremental, empirical change. Teams change little things all the time—leading to a gradual transformation. With this in mind, I am always surprised that Agile and Scrum are so often introduced in one big lump. I have taken several two day Agile training courses. I have learned something valuable from each of them. I have also seen my coworkers’ eyes glaze over during these two day session. How you introduce Agile to a team (or company) depends on where the team is at the time you introduce it.

In a previous engagement, I was part of an Agile roll-out that was feet-first. We started by introducing a couple of teams to Agile in a two day session. We reduced it to one day session for the leadership team. Though pockets of the organization adopted Agile, it was never fully adopted, and the concept was ultimately abandon. Agile implementations fail and for a variety of reasons. What I took from this and other previous engagements was a desire to try an incremental implementation of Agile.

Here at the Solutions Group, we started incrementally. One of the most helpful reminders I received was from Mike Cohn’s excellent white paper on assessing your team’s readiness level. He detailed the permission to dictate method at the beginning. In the past, I have erred on the side of insisting the team start to come up with their own solutions right away. If a team is not used to Scrum, a lot of Agile concepts do not come naturally.

Agile is huge change for most companies. As we are learning, introducing too much change at once can take a toll on employees and customers. I have observed when people get too much information on a topic at once, they don’t really take it in. It’s an interesting question: is it best to introduce all the concepts before you start coaching them? Agile is greater than the sum of its parts, but that doesn’t mean each concept does not have value on its own.

In my current engagement at The Solutions Group, I have been introducing Agile concepts slowly; letting each one become habit before introducing the next one.

Working with small companies—TSG in particular—has several advantages. First, they hired me because they were looking to change how they approached their work. Like many small companies, there was already a culture of change in place. Finally, there are three teams here and each of them is well within the recommended three-to-nine of a scrum team.

The plan was to start with one team, and begin building trust in the concepts and Agile ideas. The first thing I introduced and enforced was time boxing. I chose a sprint length of 1 week based on the size of our projects and how the team was already working. They already did their planning (roughly) in a weekly manner, so time boxing was easy to adopt. Next up came story points. I was asked to produce some productivity metrics, which made story points a logical choice. The team took to story pointing and voting quickly, so I decided it was safe to move on to the next idea.

The third piece was weekly retrospectives. Retrospectives are a major asset to an Agile team. They’re typically done after each sprint, and they help the team identify three things: what went well, what did not go as planned, and what will we do differently in the future? Retrospectives gave our team the chance to call out great work, provide feedback to each other, and prevent future mistakes.


While working with the team on Agile ideas, I also worked with leadership to promote the Agile model. With the support of our leadership team, I continued to hone our workflows and introduce new Agile concepts. The incremental way in which I introduced these new ideas was crucial to my team’s adoption.

Agile allows our team to stay flexible and adapt to the unexpected. We’re better able to assess our capacity for development, learn from each project, and maintain the innovative spirit the Solutions Group is known to have.