The First Rule of Agile is Don’t Talk About Agile

Posted on by in Product Management

I asked a group of fellow product managers if they’ve ever read through the Agile Manifesto with product owners / clients. They all said “no”, and the general consensus was that doing so wouldn’t be well received. This is interesting. Even though Carbon Five is well-respected for our process, and we definitely practice agile, we’re guarded about discussing it.

I think we only need to look at what’s being written about agile to get a sense for why this might be. If you haven’t read widely on agile, check out the list below. Agile has morphed from a single manifesto into an emotionally-charged minefield of principles and best practices. While there will always be twelve core principles of agile software, it’s difficult to imagine returning to a world with objective discourse about agile. I believe my fellow PMs and I are guarded about discussing agile because we’re not certain how “agile” will be interpreted.

That’s fine, we’re okay not discussing it with our clients. Customers and users ultimately pay for outcomes. In an ideal world, people who pay money to have a product built should not need to specify the path taken to build it. The product team could follow any process as long as it delivered the correct outcomes.

In fact, we frequently tell clients to expect their team’s process at the end of the project to differ from what they started with. Daily stand-ups might happen at the end of the day instead of the beginning, some of the team might be remote as opposed to on-site, or we might have moved from one-week sprints to ten-day sprints. The process could change without changing the delivered outcomes.

My favorite example of this led me to break an “immutable rule” of agile retrospectives. We were building a new data pipeline, and the team’s collaboration style was such that conversations and resolutions to issues usually happened immediately and spontaneously. Instead of running regular formal retrospectives at the end of each iteration, “micro-retros” occurred when problems arose. We quickly made corrections and moved on.

By realizing that rapid resolutions trumped adherence to a predetermined process, we deployed faster while enjoying our work. More generally, we relied on basic principles to derive a process that enabled us to deliver the correct outcome for the client. This is the reason I believe that my fellow product managers and I don’t talk about agile.

At Carbon Five we use Extreme Programming, Design Thinking, Lean Startup and other processes as implementations for our principles. Some of which include: delivering frequently, welcoming change, listening, empowering team members, ensuring shared understanding and continually improving. By choosing to focus on principles over processes we do better work and work better together.

All this talk of agile