The world of business is an ever-changing and hyper-competitive world. Agile was introduced to help survive in that world. However, that world is becoming more demanding. Agile as practiced 10 years ago is not sustainable. It is time Agile practitioners take their own medicine and accept change. Agile must change or die.
Agile has existed as an IT buzz word since 2001. The Agile Manifesto came to fruition at a time when software development teams were struggling with rapid development. The Internet was exploding. The Dot Com bubble burst. Companies were outsourcing their software development functions to India. Software developers all around the world, at least in the United States, realized they have to deliver and exceed customer expectations or risk being steamrolled by CIOs sending IT work to offshore firms.
Agile was born and it was great. IT professionals loudly proclaimed that the business didn’t understand how to do IT. IT professionals trumpeted the need for a new project methodology. Organizations appeared offering a way out of the Waterfall cycle of death in the form of Scrum. These organizations offered new certifications for roles like Scrum Master, Product Owner, and Agile Practitioner.
Much to the IT professional’s delight, organizational leaders agreed to their terms. Companies started toying with the idea of going Agile. Executives agreed to run a Scrum project here and a Scrum project there to test the waters. Across the IT industry, professionals proclaimed victory and did everything shy of spiking the proverbial football in the middle of their local PMO (project management office).
More teams started embracing Agile. Additional projects became Scrum projects. Everything was fine until projects started overlapping. Almost overnight there were an abundance of consultants knocking on company doors telling executives that they could implement successful agile transformations. These consultants used cool words normally taught in graduate school like competitive advantage.
Many an executive welcomed these consultants in because, well, let’s face it--these executives ran businesses that ran on IT systems. What executive worth his or her salt is not looking for a competitive advantage where technology systems are concerned? Answer: None.
Executives paid these consultants lots of money. The consultants explained how everything in the company had to transform—not just IT. The entire company structure had to be reconfigured around the concept of products and not projects. It was imperative, they said, that the entire company, from human resources to building services, must be trained on how to integrate with IT.
Many consultants assumed that current organizational structures were not focused on delivering quality products and services to customers. These consultants advised that entire organizations be redesigned around IT. Many organizations acquiesced. Oh, and by the way, organizational change takes years. Talk about job security as a consultant.
What these consultants never bothered to consider is: Is it appropriate to redesign a company’s organizational structure around IT? Many companies have complex supply chains, volatile value streams, and products and services that are not software. For many companies IT systems are important, but those same systems are only enablers. In other words, the systems are not the products and services being sold, they merely support the products and services being sold.
Imagine taking an airline company and reorganizing it around software development rather than transporting people and objects from one location to another. Or organizing a restaurant around software development rather than receiving, cooking, and delivering food to customers.
IT departments gained tremendous amounts of power during these agile implementations. IT demanded that teams be stable (i.e. you can’t add or remove people from the team—ever). IT demanded that organizations double or triple the IT staff. After all, only one team per product. If you have three products, then you need three teams. Some organizations could adjust and only hire a minimal amount, but other organizations ran into personnel problems almost immediately.
The pesky problem of running the business didn’t go away because of an agile transformation. Company leaders, at the end of the day, need to know how much money is coming in versus how much is going out. Much to IT’s chagrin, those darn executives kept asking questions. Questions like: How much are you spending on that project? What’s the ROI for this effort? What is our breakeven point after go-live? Most IT leaders can’t answer those questions. To make matters worse, IT usually leads with a statement like, “But we’re Agile.”
Agile practitioners made even more demands. They demanded that teams be co-located. However, the trend today’s hypercompetitive industries demands that organizations be flexible (read: agile). Leaders reap high gains and efficiencies by geographically spreading out their organizations. With geographically dispersed teams leaders can be closer to customers and create value across time zones. Leaders can quickly form cross-functional teams to tackle complex problems without restructuring departments. Leaders can hire diverse talent with specialized skills without worrying about local candidates only. Organizational leaders are finding ways to make areas like legal, marketing, sales, manufacturing, and engineering work across geographical distances. Sadly, the traditional Agile practitioner demands their IT teams be co-located.
This is not an argument that software development teams must be co-located. It is, however, a recognition that software development teams need to learn to be geographically dispersed. If other areas of an organization can learn to manage their work across distance then so can IT. Is IT incapable of doing so? Do IT employees lack the intelligence or ability to work across geographical distances? Of course, not.
Countless startup software companies work in geographically dispersed teams. If they can do it, then so too can software development teams in large established companies. Even more reason for Agile practitioners to adapt to changing work structures.
The problem with Agile isn’t the concepts of Agile. The problem with Agile is the religious devotion to utopian ideas of what Agile could be that practitioners hold. The rest of the organization is changing, and it’s time for Agile practitioners to adapt and change as well. Failure to adapt is certainly not Agile.