Buzzwords. They seem to make their way into the vernacular via the process of regurgitation from folks farther and farther removed from the source. They start out as simple ways for tech folks to quickly communicate a concept to other tech folk and eventually become shorthand for explaining something to the business. The process of using analogy to describe something is not a bad thing, but when a shorthand term itself creates a cottage industry, one might want to dig deeper. In particular, let’s talk about the now Hackneyed term “Agile.” With the growing drumbeat of organizations trying to squeeze more efficiency out of teams, they have turned to the “magical pixie dust” delivered through the now buzzword of Agile. Heck, even people that helped create the Agile Manifesto are now having to respond to it (see Dave Thomas post here). All these certified scrum-master courses that are popping up like weeds in a bed of mulch after a rain are perhaps the tipping point for the overuse of a shorthand term.
Look, the guys that put together the Agile manifesto were just trying to cut through all the bullshit that happens in traditional corporate spaces to just ship some decent software fast. Taking simple concepts and creating a certification (Scrum Master) for it seem counterintuitive to me since, if it were actually simple, then why would there be a need for a certification rigor? It makes more sense to me to have a mindset of being an apprentice where you are constantly reminding yourself how to work efficiently by….
- Valuing Individuals and interactions over processes and tools
- Preferring Working software over comprehensive documentation
- Valuing Customer collaboration over contract negotiation
- Responding to change over following a plan
The reason the guys behind the Agile Manifesto came up with these simple terms, was precisely because all the damn project managers at large organizations were so locked into the doing massive “waterfall” style project plans and Gantt charts and dedicated people to do technical writing in bloated 6MB Word documents that software developers just couldn’t work quickly and without friction. Dave Thomas made the point that people should stop using the term Agile as perhaps a noun, and go back to using it as a action statement more akin to an adjective.
Dave says the following brilliant statement: “It’s easy to tack the word “agile” onto just about anything. Agility is harder to misappropriate.” So for him you aren’t and agile programmer – you are a programmer that programs with AGILITY. You don’t work on an agile team, you work on a team that exhibits AGILITY. You don’t use “agile tools”, you use tools that enhance your AGILITY.
Since I myself have been been trying to make people on my team act and work with more “agility”, I try to keep myself tuned into ideas and people that “get it.” So when someone tries to help convert traditional IT project managers and technical managers into working with more “agility”, it is worth taking note. Kamal Manglani’s book is trying to do just that. He is trying to get people to work with more agility. Having worked with Kamal in the past, I can tell you that he does get it. Kamal starts shaking his head when standups are taking too long and people turn them into bitchfests or psuedo spikes. He is known for being a bulldog that will search people out and sit with them at their desk in person to solve a problem and won’t leave them alone until the problem gets attention or resolution. He’s the guy that frown’s on large bloated Word Docs in favor of a wiki or a readme file in Git. His book at least doesn’t misuse the term agile, it’s called ‘The Apprentice and the Project Manager‘. So, while the devs hopefully get it, at least someone is trying to get those pesky project managers thinking and acting with more AGILTY, not being “agile”. If this helps teams ship things faster and gets teams more productive by reducing the number of folks in their path, I’m cool with it. Since we have to keep reminding ourselves how to do work with agility, perhaps being permanent apprentices is better than a scrum “master” of anything. Is anyone ever a master?
More and more we are starting to hear about how real transformation can happen for businesses using IT. For busineses like NetFlix or Twitter where IT is at the core of the entire business model, that has been clear for a while. What is changing are businesses that have heretofore leveraged IT as just part of the “backoffice” seeing incredible transformative possibilities by leveraging the same IT principles as technology startups. Those with deep IT knowledge have always intrinsically known this potential. However, convincing a non-tech business of this possibility has been a difficult historically. This is because non-tech businesses (and to be sure, even traditional large tech businesses) saw IT as a “cost center” and not a true “partner” with the business for achieving goals.
This perception has been changing over the past 5 years. It has been accelerated by advancements in infrastructure as a service, platform as a service, and software as a service offerings that have made business leaders aware of ways to get things both faster and cheaper in the infrastructure world. However, a funny thing has happened. When business leaders asked IT leadership to “take a look” at these new “n-as-a-service” offerings, they got feedback that there were still 3 main hurdles to being able to unlock real business value fast: infra and developer collaboration, technology freedom, and core IT and business processes. So, while you might be able to get servers fast from cloud providers, you still had the existing internal hurdles to overcome. These hurdles are not insignificant.
The real unlock for all these “n-as-a-service” infrastructure offerings is actually transforming the traditional way IT does business. Recently, authors Gene Kim, Kevin Behr, and George Spafford created a fiction novel called “The Phoenix Project” which outlines what a hypothetical Agile and DevOps transformation looks like. While the novel is a great way for people to understand how agile/devops change can happen, it might be great to hear about a real success story. Let me offer up Gap Inc as an example of how you can take massive legacy enterprise IT and make a real transformation happen. The actual implementation of Agile processes by a business with a heavily traditional structure and workflow is not without pain. Being successful requires a strong spine and executive leadership that is willing to put everything on the line. For Gap, the CIO (Tom Keiser) and VP of Infrastructure (Naveen Zutshi) were key to pushing the transformation through successfully.
I have taken the liberty of summarizing 2 main tracks of effort that made the massive Agile and DevOps transformation at Gap possible by using 2 documents. The first document is a paper written by Kamal Manglani which focuses on core Agile principles as applied to infrastructure. The second is a Meetup presentation I put together that focuses on the methodologies we designed at Gap to change mindsets about technologies. Hopefully, these documents will be useful for others with the gumption to take this journey on.