This year marks the 31st birthday of "The New New Product Development Game," a paper by Hirotaka Takeuchi and Ikujiro...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Nonaka arguing that the "old sequential approach to developing products simply won't get the job done."
And it makes me sad.
It is sad that Agile practices are still thought of as something developers do.
It is sad that the term Agile is still used to describe things -- to wit: fixed vs. growth mindset -- that are not related to agility.
Saddest of all? Nothing has come along to disrupt Agile.
It's time to invent a post-Agile framework. Let's start with what agility is and isn't.
Agile is more than a development practice
Becoming agile (the small "a" is intentional) is much broader than adopting a software development practice. If your organization is really going to be agile -- able to change as fast or faster than the changes happening in your business context -- that means your organization has agreed to fundamentally change the way it conceives of work, plans work, assigns work, and markets, sells and supports work.
Adopting agility is about admitting that the future is unpredictable and shifting. As Yoda said, "Difficult to see. Always in motion is the future." When organizations practice agility, they are making a statement about the nature of their business reality.
Think with me for a minute. Can your development teams be Agile if your leadership isn't agile? Or if your planning isn't agile? Or if your budgeting isn't agile? To repeat: The goal of agility is to adapt to changes as fast as or faster than the changes happening in your business context -- and that means the whole business context.
Team-only agility is not agile
Let's start at the team level. Your organization is not agile when developers are able to adapt to changes but only within a small scope -- i.e., the confines of their teams. If you think of agility as a funnel, the tight end is where the teams are. The teams are trained in Agile but ultimately are constrained by the boundaries of what is planned by the business. If the planning process is not agile then the teams may not be able to exercise agility in when a product is released, what is released and in what order. And if the budgeting process is not able to adapt to change quickly, the whole project may never happen and the agility of the teams is a moot issue.
This team-only version of agility is the most common type of agility and the most limiting. I see it all the time. It is like baby step No. 1 -- and frankly, it gives Agile a bad name. Business leaders hear about organizations getting 400% more work done by using the Agile framework and so they tell their development teams to "do Agile," but they don't see the dramatic improvements and wonder why. This is why. The organization is implementing agility only at the team level.
Moving beyond team-only agility
Getting past this rudimentary level of agility requires rethinking the organization's planning and budgeting functions.
The planning function decides what will be released and in what order. Budgeting determines how much is possible to spend in an effort to serve your customers, effectively determining the breadth of agile development available.
If we modify the way planning is done, making it more adaptable to changing inputs from the business, then the organization gains another degree of freedom. Its agility now includes the ability to respond to those business changes -- whether customer insights, market shifts or technology advancements, etc. Agile planning means being able to reprioritize the when and what and in what sequence a product is released based on customer feedback.
If we modify the way budgeting is done, making it more adaptable and ready to respond to the changing requirements of the business context (see planning above), then we gain even greater flexibility. In many organizations, traditional budgeting is done annually or bi-annually and allocations are made to specific project buckets. If we admit that the future is unknown, then just as the planning function needs to adapt to the current reality, so does budgeting. Budgeting must become more nimble. Agile budgeting is being able to make completely different project investment decisions mid-year, mid-month even.
This is not to say you just throw budgeting to the wind, but using an incremental funding model and making strategic investment decisions is one approach to a more flexible budgeting approach.
Once organizations make their budgeting and planning more flexible, they've gone way beyond agile at the team level and the benefits really start to take hold. When the budget and planning functions are freed of strict ties to specific deliverables and instead are open to adaptation and just-in-time decision-making, suddenly other areas of the company are impacted, including:
The sales team has to develop agile sales practices in order to sell products that are constantly evolving. Marketing must adopt agile marketing practices that can take input and accept changing requirements even late in the process. With more releases happening more quickly, each customer may have a different revision, depending on when they upgraded. So, training has to account for multiple versions of the version of the product that requires support. Certification in training becomes much more difficult, but it also becomes much more useful because it becomes a dynamic process. You see where I'm going. Being a truly agile organization entails wholesale, radical change.
You can get 400% improvements in productivity with Agile, but it takes more than just telling your teams to start doing scrum.
Now, don't get me wrong. Even just having your teams use Agile practices will have a dramatic improvement on predictability, quality, speed to market, team morale, and a host of other areas. But if you really want the most bang from Agile, it needs to be more than just a development practice.
A post-Agile world
The first Industrial Revolution (18th and 19th centuries) brought mechanization of tasks, the creation of factories and a need for leadership of large groups outside of the military or the church. The second industrial revolution brought the assembly line and the need for management and control to create uniform large batches of products quickly. The third industrial revolution was driven by electronics, computers and the internet. This revolution brought with it the need for structured innovation and agility.
Today we stand on the precipice of the fourth industrial revolution. Maybe it is the internet of things, maybe it is artificial intelligence, or virtual reality/augmented reality, maybe it comes to full flower in the realm of biotech, or maybe it is something yet to be discovered. Whatever the case, you can rest assured that this fourth industrial revolution will bring with it -- like the others before it -- the need for new methods, new processes, new thinking in management and leadership. It will require innovative management and leadership as much as it will depend upon technical innovation. It will almost certainly require CIOs to institute a post-Agile framework.
Many people missed the management-leadership innovation that was required with the advent of microcomputers and the internet. Agile was thought of by many businesses as a fad or a lack of discipline. It was ridiculed and marginalized. Yet, it has proven to be the best way to leverage the full power of this third revolution. And the organizations that fully leveraged it are the disruptors that are driving innovation today.
Look onward, Agilist
Agile was a specific response to the needs of a management paradigm that wasn't working with knowledge workers. The management and control model of the factory-centric second industrial revolution wasn't working with innovative fast-changing technologies and customer needs of computer and internet-centric third industrial revolution.
Indeed, every industrial revolution has brought with it a commensurate innovation in management. The fourth industrial revolution will be no different.
What will be your stance when this innovation in management comes? Will you hold to the past, resisting the need to change, will you go along with the change as it happens or will you be in the front, developing new methods, new approaches, new ways of thinking about work and the people who do that work?
What I don't hear much in the Agile community is the passionate search for what's next.
If you are an Agilist, take a good hard look at your allegiance to this way of working. Are you more excited about spreading the use of Agile or are you interested in whatever is effective, wherever you can find it?
If you are interested in what is effective then it is time to give serious thought to a post-Agile framework. You won’t find new answers inside the box. What comes after Agile will not come from the same influences that are part and parcel Agile.
Who would have thought that the organizations of the third industrial revolution would apply management and processes from automobile manufacturing to software development? But that is what happened.
If you want to ride the next wave, I have some suggestions:
- Look at what is and is not working in politics and society.
- Look at what is and is not working in businesses outside of the one you're in.
See what you can learn, steal and apply in a creative new way. Think post-Agile and give us a new manifesto for the fourth industrial revolution.
About the author:
Joseph Flahiff has more than two decades of experience executing, coaching, consulting and training in traditional and agile delivery across large-scale complex enterprise IT organizations, as well as smaller boutique agencies. Email him at email@example.com or text Joseph at (206) 276-1386.
Getting past this rudimentary level of agility
Recent advice from Joseph Flahiff:
Four letter words that will transform your workforce
Hierarchy versus power grabs in the workplace
Tellers and askers: What kind of boss are you?