A number of things have reminded me of Agile lately. The new HBR article on The Agile C-Suite only emphasizes that the little agile cults we formed in the early 2000s to build software was the right direction. As one of the executives interviewed for the study, it’s great to see agile evolving to managing entire companies.
I can remember the exact day I started my Agile journey, it was January 2, 2003. I was long enough into my occupation as a software engineer to know that the dominant Waterfall methodology was painful, slow and often resulted in poor outcomes. I had been working as a consultant for about two years at this point, and on the first workday of the new year, we were starting a project to rewrite a 25 year old mainframe application for workforce management. West Telemarketing in Omaha, Nebraska was the largest outsourced call center manager in the world with over 25,000 agents across the globe. It was a big project for everyone and we had just hired two new consultants with Agile backgrounds to help us on the journey.
I was certainly skeptical up front, but as we got into the daily processes and mindset it felt like someone had finally designed a process that fit the real world. It didn’t take long until I was a convert and devoured Alistair Cockburn’s Agile Software Development to get a better understanding of the process.
For the last 17 years I’ve only worked in Agile shops. Sometimes I had to create them, sometimes I joined existing agile teams. But through it all, I think I’ve sent the URL to the Agile Manifesto 1000 times to engineers and managers to get them introduced to the concepts.
But I hadn’t really read it for many years. When I was first introduced to the manifesto, I was a consultant and the “this over thats” made sense. We recently went through product training that brought the manifesto back in front of me, and was drawn into a discussion about it.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Reading and discussing them again as Chief Architect for Target, I find that they don’t resonate as well. Target has converted to largely in-house product and engineering, so no more contracts. When working within an enterprise where hundreds of product teams rely on mutual timeframes to deliver large scale initiatives, sorry, we need some type of plan. We also need documentation for long term ownership of the products. However, many people and teams read the manifesto and said “no more plans, no more docs!” The manifesto struck me as very oriented towards outsourced engineering practices.
Here’s a modern take on the manifesto learned while building high scale distributed platforms through the digital transformations of Best Buy and Target:
People matter most, processes and tools are enablers
Working software, maintainable over time
Continuous collaboration across all teams, always
Plan, build, learn, change, plan
Platform Centric 