Defining “Scaling” Agile, Part 6: Creating the Agile Organization

We might start to think about agile approaches as a project change. However, if you want to “scale” agile, the entire culture changes. Here is a list of the series and how everything changes the organization’s culture: Defining “Scaling” Agile, Part 1: Creating Cross-Functional Feature Teams. Without feature teams, I don’t see how you can …

Team Size Matters, Reprise

Several years ago, I wrote a post for a different blog called “Why Team Size Matters.” That post is long gone. I explained that the number of communication paths in the team does not increase linearly as the team size increases;  team communication paths square when the team increases linearly. Here is the calculation where N is …

Stuck in the Middle with Your Agile Transformation? Part 1

Here’s something I see in many organizations: Management wants to “control and manage” the projects/efforts/work (whatever they call it) in the same way they did before the organization started agile. They want Gantt charts. They want commitments. They want assurances that the work will proceed in the same way they thought of it before the …

Stuck in the Middle with Your Agile Transformation? Part 2

In Stuck in the Middle, Part 1, I discussed possible management problems with agile. Those aren’t the only stuck problems I see. Sometimes, I see team problems. What if the teams are “almost agile”—they still have too many experts, their stories are too big, they don’t always deliver value on a regular basis? You know …

Stuck in the Middle with Your Agile Transformation? Part 3

In part 1, I addressed some management challenges with an agile transition. In part 2, I addressed some team issues. In this part, I’ll discuss why agile is a culture change and ways to consider a system change to agile. Agile looks something like this image. The responsible person (often called a product owner) collects …

Change is Learning: No Silver Bullets or Quick Fixes

Way back when I was a developer, my professors taught me structured design and design by contract. Those were supposed to be the silver bullets for programming.  You see, if you specified things enough, and structured things enough, everything would all work out. I thought I was the only idiot that structure and specification didn’t …