Who is with me?

The Adaptive Manifesto for Value Creation...

As many of you already know, the global landscape on highly qualified ways to manage projects and/or changes is extremely vast. From the leanest, most flexible models, to extremely extensive models for mega changes, projects and programs.

Many of you also know the Manifesto for Agile Software Development from 2001. Historically, it has had quite an impact on organizations’ ability to execute and how organizations have chosen to execute software development projects. Some organizations even tried – with varying degree of success – to take the positive results from the Agile Software development methodologies, and apply that to complex hardware and systems development projects and programs. It seems, lately, as if the mantra is “When we don’t know exactly where we want to go – let’s go Agile”. I believe we are ready for something new, and a good place to begin could be with what is (rightfully or wrongfully) accepted as a flexible way to handle unknowns and changes, namely Agile. So I have taken the liberty of using the Manifesto for Agile Software Development as a starting point, and take that to the next level…

The history...

Without stating the obvious, 2001 is a loooong time ago, and a lot has changed. In 2001 there was roughly 500 million frequent users of the internet, worldwide – in 2016 the magical number 5 billion was reached. In 2001, close to no devices (other than PCs) where connected to the internet – in 2016 that number exceeded 20 billion. To develop an entire operating system in 2001 (Windows XP), 40-45 million lines of code had to be written – today it takes more than 100 million lines of code just to get a car moving. Complexity has increased to an extend where the human brain has a hard time wrapping itself around it (read: my brain has). In addition, we are no longer just developing software, databases and websites. Devices and device technology (IoT, Smartphone and applications, self-driving cars, etc.) is a critical factor that has to be accounted for, when we decide how to organize our development/change efforts.

The present...

How about disruption – is that a factor to consider also, when evaluating our ability to handle projects and/or changes? Well, yes and no. Disruption is a misused word, and we should remember Clayton Christensen’s definition of it. A new and novel way to implement a technology or reiterate on existing technology, is not called “disruption” until that technology step renders some established solution or system obsolete, by offering a solution that is “better” (cheaper, faster, simpler, environmentally friendlier, etc.). Netflix disrupted Blockbuster, but not until Netflix started online streaming, which became possible by constant technological advances in broadband internet connections. Those advances had absolutely nothing to do with Netflix, and where driven by ISP customers. Until that point in time, Netflix and Blockbuster where “just” competitors. So, when it comes to our ability to embrace changes in development and/or change management, is it really disrupt or die? Are there really only two options:

1. Maintain products by continuous evolution and die
2. Disrupt competition, and maybe even ourselves, and survive?

No! As Tim Fielding told us: There is a 3rd option. And that is to develop ourselves and our products by innovative thinking, based on a combination of "external disruption" and the vast knowledge we already have on our own products and where markets might be moving – knowledge that outsiders do not have.

Have you noticed that whenever we mention the word “disrupt”, we talk about technology in the same sentence? Is it not possible to “disrupt” an industry, a field of service, or some other area, by completely rethinking the way we manage and lead? I think so – but maybe that is a topic for a later discussion?

What does all of this has to do with our ability to execute changes and/or development? How do we handle the below in a good way:

• Exponential increase in systems/solutions complexity.
• Exponential growth in global device base.
• Exponential growth in data accessibility.
• Constant technology advances that could affect what we do and how we do it.

The future?

When you are a small team or organization, often the choice of methodology is obvious. You choose what works best for you, and your methodology is an evolutionary thing, based on best practice of the people in the organization.

However, what about larger – or even mega – organizations? Maybe we should stop trying to methodologize (no, it is not a word, I have looked it up – but it should be) everything we do, and start approaching development and changes in a different way? Any specific methodology is no longer sufficient for all situations. Maybe Agile is good for a small team doing a new smartphone app to warn you when the temperature and humidity in your wine cellar gets out of range, and maybe a waterfall based model is best for developing the IoT device that convey the temperature and humidity information to your smartphone app through “the cloud”.

In addition, what about that scary situation mentioned above, being “disrupted”? Can we agree that true disruption is a good thing? Someone found a way to implement a technology, a solution, or part of a solution, that significantly reduces either time spend for the user, time spend for the supplier of goods or a service, the cost of the goods/service itself, or another commonly valuable parameter. That is good for us all, as a society. Therefore, a disruption, which falls within the realm of what your organization is doing, is an extremely good pointer to where we might move in the future. Since we are the ones that have the best knowledge of our products and/or services, we have the ability to take that significant piece of disruptive innovation, consider it, and make it useful for the common good of our customers, users and society. However, it requires the organization has someone that has the responsibility of monitoring global technological advances. In addition, it requires you to be able to handle such disruptive innovations is a good manner. Enter:

The Adaptive Manifesto for Value Creation

We are uncovering better ways of delivering true value by doing it and by showing the way for others. Through this work, we will come to value:

• Teams of empowered individuals over chosen methodologies and ideologies.
• Value Creation over following a singular path.
• Challenging perception over continuous alignment on agreements.
• Embracing disruption over managing change.

Principles behind the Adaptive Manifesto for Value Creation

We follow these principles:

• Our highest priority is to deliver value through continuous integration.
• We welcome disruption as a way to learn about a potentially different future.
• We demonstrate working solution(s)/system(s) continuously.
• We are ready to review our solution and challenge our perception at any given time.
• We build systems and solutions as a team.
• We acknowledge all team members’ right to challenge our perception.
• We never assume that what we perceived as valuable yesterday is valuable today.
• The adaptive approach promote continuous focus on value creation.

I told you it would look familiar...

What does this mean, in practice?

Firstly, it means that we have our eye on the value created, and we – in principle – do not care which methodology realized that value. This could be a situation where we develop a system where the different components build, are best build by following different methodologies.

We know we have to make the best climate control system ever made for a wine cellar, and that is what we hold ourselves accountable to. This means that when we follow a waterfall model for the IoT device component of the system, we make just as great an effort to make sure the requirements, the interfaces, the components, the verified component, the validated component, etc., are in accordance with this value proposition, as the effort to make sure requirements are in accordance with system interfaces, are physically possible, are testable, etc. And when we use an Agile approach to create the smartphone app, we focus on the integration of the output of the waterfall development, just as much as we do on working towards a nice usable app, with first class user interaction. 

The ability to adapt could also mean that we are prepared for any imaginable situation at any point in time in execution. 

When moving on the cutting edge of technology advancement in our development (e.g. the “a” path towards integration point #1), we could – at any given time – find ourselves in a position where an integration point could yield many different paths forward, without having enough information on which path forward is the best, until we have done the actual integration. From a development standpoint, this is nothing new, and part of the project work in many organizations. But it requires us to be able to foresee different paths forward from the integration point, and have a defined plan forward (e.g. “b”, “c”, or “d”) for each foreseeable outcome, so we – at all times – are able to predict where and when a complete solution/system is complete, and the quality level. In other words: We have our eye on the value we set out to deliver, and we are very flexible on how to get there - technology and methodology does not matter. This can only be realized when working in a team of dedicated people that share a view of where we want to go, and where all team members have the right to challenge the knowledge we expect to have at any point in time. And this is where good leadership comes into the equation…

Even in the case of “disruption”, our ability to adapt, while remaining focus on what we set out to deliver (the value), will make a difference.

A major technological advance can be thrown into the equation at any given point in time, and completely change the map of the possible paths we envisioned.

This is a welcome situation where we have learned about a better future, and after integrating the system/solution we know, we immediately thereafter will be able to map out the possible paths to follow, if we feel the advance will be good for us. Again, value counts, path and methodology is less important.

Why?

Why do I write all this - it is obvious! Yes – but too often have I seen organizations stuck in discussions on which methodology to follow, organize themselves based on which methodology makes sense for a specific discipline, and try to implement “one methodology fits all” – and at the same time try to prepare for any unforeseeable future. Why waste time with such discussions? Why not let teams decide themselves, and maintain focus on the value you try to deliver to the world – I believe you will be better off.

Lastly, please remember that the ability to adapt has nothing to do with the size of an organization, and has everything to do with the mindset of an organization. One of the most adaptive teams I have ever had the privilege to work with was a team of more than 200 people, working on a program with a budget of more than USD45m. This team developed cutting edge technology in a never before seen compact size, with numerous changes, integration points and failed attempts, and even changed the starting point several times during the program – but succeeded to manifest a solution, never seen before, that improved the quality of life for hearing impaired, and which took years for other organizations to match.

Feel free to comment. I might be stating the obvious, I might be reiterating on known theories, I might be describing Program Management with other words, and I might be wasting your time. I sure hope not, and I will be happy to hear from you, and hear what you think about this...