Unleashed on the world 15 years ago, the Agile Manifesto ushered in software development methodologies such as Scrum, Lean, Kanban, and Extreme Programming (XP). More importantly, it created an entire mental shift in how software engineers approach their work and how businesses capture the value of that work. Like all successful things, however, Agile is subject to the principle of never-ending improvement.
The Victory of the Agile Manifesto
The authors of the Agile Manifesto encapsulated the philosophy with four declarations:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
They completed the manifesto by drilling down from these central tenets to twelve actionable principles that would go on to shape all Agile processes. These principles placed an emphasis on:
- Short turnaround,
- Tight collaboration and rich communication between developers and business stakeholders,
- Constant improvement of both product and personnel,
- An embrace of dynamism in design and implementation,
- Trust in the ability of developers to lead themselves.
Without a doubt these ideas have shaped modern software development and the technological landscape that has made rapid change possible.
The Need for an Agile Manifesto 2.0
It is very clear that the Agile Manifesto has irrevocably changed the world of software. However, keeping with the spirit of the manifesto itself, engineers and product leaders are constantly looking back upon it and trying to develop the next iteration. The rapid change engendered by both the accelerating effects of tech innovation and the proactive culture of Agile itself has led many to question if aspects of the manifesto have fallen out of scope. Technologists are starting to make the controversial case that Agile has led to outcomes contrary to its author’s intents. Has agile morphed into a business-driven process just as stifling as the waterfall it was meant to replace? The emphasis on quick ticket turnaround and transparency has reduced the role of the developer from high-level innovator to issue-processing drone. Whether or not you agree with this view, perhaps this is a sign that we need to revisit the manifesto in order to ensure that our business culture does not gradually re-purpose it to support the things it was created to oppose.
Agile Manifesto 2.0: Towards the Internet of Things
Despite the wide divergence on opinions of how to amendment Agile, one thing that virtually everyone can agree upon is that it must reflect the new reality of rapid organizational fluidity brought on by high-speed internet, social networking, mobile devices, big data, artificial intelligence, and the Internet of Things (IoT).
The IoT market is set to reach $1.7 trillion by 2020 which is “explosive” growth by anyone’s definition. With virtually every product eventually being IoT enabled, product development in the purely physical space comes to take on the connectedness and transparency of software and cloud projects. In all cases we will gain the ability to capture the value in:
- Knowing where [the] software product is running
- Understanding what it is doing
- Verifying that it is working
- Allowing it to provide feedback
Ultimately, this calls for Agile training at the business leadership level, among systems engineers, and between cross-functional teams. In the actual text of the Agile Manifesto, suppose all references to “software” could accordingly be struck out and replaced with “value.” Imagine for a moment that although the two-week iteration for product delivery may not be remotely possible for hardware teams, we gradually edge towards shorter deliveries in that realm as well. The insights gleaned from analytics and the IoT coupled with advances in 3-D printing and rapid prototyping will allow mechanical, electrical, and manufacturing engineers to take on the “Agile Mindset” that software developers began their journey towards 15 years ago.
For more information on Agile Methodologies, consider visiting our resource page.