Is there life beyond SCRUM?

The simple answer is “Yes”, there is a lot of life (and people) beyond SCRUM.

Especially if we have the courage to ask ourselves the right questions and share them both within our organization and outside it. This is what I’ve tried to do to overcome some SCRUM constraints when it comes to share the Agile mindset across organizations: this article is about that to allow you sharing any feedback as you like to improve together on the field.

But let me start from the very beginning…

Innovation pace is #1 requirement for evolution

After many years spent (trying to) explain the value of change and innovation of large public and private projects, as well as having the opportunity (and the honor) to work on transformational ?programs of products, organizations and companies through the continuous technological innovation of the company have been working for about 15 years (Microsoft), I thought it could be useful to share the summary of my first 25 years of work all very different from each other but united by a single question that I keep repeating to myself in everything I happen to face.

This question is: why?

This simple word pervades, in my personal opinion correctly, many areas of our lives but the reason on which I would like to focus here is the one connected to the best way to use technology to allow people and organization achieve their objectives even if they are very distant both from those who produce that technology and from those who use it daily in their work.

This distance between technology experts and its end users, has created rather consolidated business models from the late 50s until the beginning of the 21st century that have allowed business advisory companies, system integrators, technology vendors (and of course end-user organizations, in any market segment) to thrive within an extended Value Chain of technological innovation that we could define as "static equilibrium". During this period, given a (rather small) speed of foundational technological innovations, the role that each actor in this extended innovation value chain came to play remained relatively constant compared to the others, allowing each to develop but without evolving into something profoundly different. In fact, the speed of innovation was such as not to question the timing of an investment plan (at least 5 years), nor the training of our own employees on technological innovations as well as the development of specific methodologies for the best use of the technologies themselves. It is no coincidence that despite multiple design approaches, Waterfall project planning and management methodologies were essentially the only model actually used at that time.

Not even the Internet, while enabling new business models, has not managed to undermine this static balance because, beyond the amplification of the opportunities for interaction that it was going to enable, it was not yet equipped with that speed that has been the real enabling factor of all the transformations (both process and business) that the Cloud and AI have instead managed to enable.

It was in fact the acceleration of technological innovation, mainly due to the increase in the processing power of the Cloud, the evolution of virtualization techniques and the availability of huge amounts of data with which to feed the new technological power available, to allow us to reduce the time with which the alternatives of choice we were used to managing (e.g. the inputs on the basis of which we made decisions) have been reduced so much?to make ineffective (as well as inefficient) the methods of planning and implementation of our projects.

Now that the evolution cycles of foundational technologies are themselves extremely reduced (think of the release times of the new application virtualization or Cloud Computing solutions or the new ready-to-use AI services such as ChatGPT[1]) the problem of the extended innovation chain (e.g. of all the actors from the basic technology to the end user) becomes how to manage these contractions of the time for a choice (and therefore of action) for their own?investment programs, the management of the evolution of the skills and, ultimately, how to configure their organization to still be competitive in the new "accelerated" world.?Obviously Waterfall approaches (unfortunately still widespread in 2023) are not the solution to manage this dynamic context and the concomitant absence of alternative solutions to the management of complexity related to the reduction of the validity times of our choices (as they vary rapidly the inputs of the same) has led to the definition of terms such as VUCA (Volatility,?Uncertainty, Complexity and Ambiguity) to summarize the problem that every company, and ultimately every person, is facing today.

But some solutions appear, and obviously they are not technological solution [2]....

Why SCRUM (despite customers don’t speak SCRUM)

A first answer to how to manage the speed of the context’s change in which we find ourselves making decisions for our projects is provided by the Agile approaches and in particular by the SCRUM methodology introduced by Jeff Sutherland and Ken Schwaber in 1993. The successes of companies such as Facebook, Spotify, AirBnB have contributed to the spread not only of the SCRUM operating framework but of the Agile mindset necessary to manage extremely dynamic situations of the contexts in which we operate.

SCRUM provides many benefits to organizations requiring a project management framework for complex adaptive problems. These benefits include improved teamwork, reduced time to market, and a noticeable decrease in software defects (see here for details). It is designed to respond easily and positively to change, making it a flexible project management methodology and in this sense it is a perfect antidote to VUCA.

SCRUM can be applied almost anywhere and can help teams deliver products faster and more frequently. You can read a lot of papers, books and real stories from the field on how SCRUM can really benefit to your projects, to your team and your organization and everything is real.

So what’s the matter here?

The key point is that SCRUM was born for product (and in particular software) development, so when you engage with businesses quite far from software and product management you experience challenges in exploiting the full value of Agile and SCRUM. I used to say “customer don’t speak SCRUM” as a summary of may grey situations you may face when you start a project with bold ambitions and your best SCRUM team but you’re struggling moving forward as you planned and delivering that value customer is expecting “because we are working Agile”.

But the reality is that “customers don’t speak SCRUM”: being the Product Owner role the key role of SCRUM, where we are not delivering “internal-only” (meaning when we are engaging out of our company with a customer on an innovation project for them - to transform how they take care of their patients, or how to improve their sustainability impact, or how to allow a Bank being innovative to engage more their customers, etc.) it is crucial that our customer counterpart can play this role with max proficiency. And because this role is not only a technical role but also a very powerful role (also in terms of cost and resource management) is not simply a matter of training but it’s a matter of company Culture to allow the Product Owner not only all the competencies but the power needed to perform as expected to be successful (not the role, but the project we are delivering for them).

In a nutshell: SCRUM is not only on the side of your service provider but it’s on any organization’ side that really want adopt Agile mindset to change how they operate and make business.

At the same time, as a service provider working with customers leveraging technology to improve their operations and their business, we can’t wait for them changing their Culture, but we can (so in my humble opinion we have to) to ask the proper questions and act consequently to allow our projects being successful for them. And the key question is always the same: why?

This is the real challenge today in facing VUCA: can we ask the very important questions? And in particular when we engage with our customer: are we ready to share in a full transparent way the answers to the right questions to allow us being a real leverage for their success? And they are ready to have this kind of open engagement with us?

I can’t answer fully “yes”, but I believe that if you have a role to allow someone else to change, you have at least to try. In the following paragraph I’m sharing how we are trying to do all of that in real projects on the field.

Note: this in not to teach or any kind of lesson. I’m sharing that to get any feedback from everyone who agrees on “we have at least to try” to scale SCRUM beyond our own organization and having a more concrete discussions and reviews with our customers on how (but also if) we are really delivering something useful to their business (where their inner Why is – or should be).

BIOM – Business Impact Outcome Management

Everything started from my obsessed question: Why?

Every time we started a transformational project for our customers we used to have an internal kick-off in order to answer this question: why the customer is going to pay us?

And after that, how we can ensure our delivery is continuously connected (in an anti-VUCA style) to the reason why they are paying us?

The most interesting part of this conversation is not only about making clarity with the full team on the why of our project (typically not all of them have the chance to participate in all the discussions – included Sales process – ?before the project starts) but, and in particular, discussing if the customer was with us in this discussion. I mean, are we sure that we are really targeting their own goals (at the beginning and along the way)? How our methodologies are effective to them to change? Do they know (and understand) our Epics, User Stories and any other SCRUM activities? And finally: are they ready to work with us as Product Owner?

I think everyone of you is making similar questions and I’m quite sure you’re aware of the difficulties and issues of getting always the answers we would like to get. Here is how we are improving customers being better Product Owner and our team being more connected to them beyond ourselves (beyond our own methodologies and innovation practices).

We call it BIOM that stands for Business Impact Outcome Management.

With a brand new name we wanted to clarify to everyone we are not focusing on improving something internal but we wanted to scale WITH the customer all the SCRUM and Agile approach we are using since many years with very great results for our business and our people.

So we put first Business Impact in order to clarify the intent (the Why) to stay focus beyond us on what customer matters more, just after Outcome because SCRUM is focused on product and product is something customers understand (even if “they do not speak SCRUM”) and finally Management because this is not a single time event (it is not like making a Business Case to justify an investment and then no tracking on that) but a continuous review and adjustment of any change along the way toward the final (customer) goals.

?

We focused a lot also on the choice of the name because, at the very end, we are changing how we communicate among us and, in particular, with the customer: in fact, if we consider why projects fail when you’ve already more than clever resources allocated on that, it’s because we are not communicating in the proper way (meaning we are not asking the proper questions). In some cases is because technical people and business people do not have the same background (that is not a problem itself, the problem is that we don’t consider listening the other more) but the key reason is we are afraid of the person(s) in front of us. I will not enter the long list of reasons behind this fear as I’m just considering the fact that usually we don’t trust so much to tell the full truth.

So we realized that, in order to communicate better overcoming any issue in fully sharing the information and listening more on the other’s way of speaking, we did need a simple way to “connect” SCRUM beyond our own delivery organization and allow the customer understanding why we are working that way. This is BIOM.

On a more practical way, instead of discussing with the customer on our own methodologies, tools and activities segmentations and organizations, we identified 5 pillars for every person on the team to know and agree with no doubt.

Then we structured our ongoing activities (included our internal delivery tool – Azure DevOps) to allow the customer and each of our person in the delivery team to have a full clarity on the why of each activity as part of a larger (and clear) program to final customer goals.

Finally we implemented a fully trusted (meaning shared with no filter) ongoing reporting leveraging tools like Microsoft PowerBI on the progress we are having on each single Why (Customer Goal).

Because we are looking for something simple, to be used by everyone in his/her ongoing working day with no additional effort, and being a strong believer of question as the best communication “protocol” we create 5 questions as the building blocks of BIOM. Here are the 5 BIOM pillars (questions):

1. Customer goal: what final goal are we going to contribute to? [Note: this comes from customer – we ask this as an input of our delivery planning]
2. Outcome: what is the product of our delivery? [Note: product is only on customer hands]
3. Final users: who is going to use our product?
4. Benefit(s): what benefit(s) will the customer (final user) get from our delivery? [Note: this is the benefit for final user using the product. This should be different from customer goal] How are they going to use/take advantage of the product?
5. Measurement: how we are going to measure the impact of our delivery? [Note: impact measurement has to be linked to customer’s goal(s) as much as possible]

Nothing but that? Yes, nothing but that. I’m quite sure you can an easily read here the core principles of Product Management and SCRUM, and you are right, they are: the key point here is that Product is not our own product but it’s something directly connected to final customer goals for that specific project.

With this simple structure we managed to:

1. Help customer playing the Product Owner we need: also those business customers very far from software can take fully advantage of Agile and SCRUM linking any project to their business goals;
2. Easier requirements definition: at customer interface we manage only 3+1 (Outcome, Final Users, Benefits + Measurement [3]) clear, effective and simple to discuss items that guide any further activities, from backlog management to implementation;
3. Improved and clear engagement for every person (towards clear results): large projects’ team, especially transformational ones, are made from many people working in parallel on challenging tasks. With BIOM we allow everyone in our team to answer the question on how he/she are doing will improve customer activity, process, products or any other priority they have. And the most important value of it is that if we ask the same question to the customer we will get the same answer;
4. Larger Value through shared Why: connecting our SCRUM delivery (and additional innovation methodologies) to customer goals in the ongoing activities allows engaging business customer counterparts in working with us not only in defining and testing what we deliver, but continuously checking priority, business alignment and resource management (including cost management) to ensure our outcome is the best one for them to use and take advantage in their work environment for their goals. Leveraging Trust we gain not only better products but also the best usage of resources we have along the entire project duration.

In a very nutshell, leveraging BIOM we can be simpler towards what matters more and through this simplicity we communicate better and work better together (our team and the customer team).

A clear sample of this simplicity is the most important “test” (The BIOM sentence) we introduced in our Work Streams’ setting, to ensure we (our team and the customer) are walking together in the proper path for each group of activities. This allow our Work Stream owner to discuss and agree with the customer’s counterpart the reason why of each work stream for them.

Here is the BIOM sentence.

"Leveraging our <outcome> customer’s <users> will get <benefit> that contribute to their <customer goal(s)> for a value/total impact of <measurement>"

Discussing and finally agreeing (between our team and the customer) on the specific application of the BIOM sentence to each work stream allow full clarity on the Why we are delivering and, consequently, on what and how needed to deliver that at best. ?

On a more SCRUM-oriented side, we use the BIOM question to create the Epic into our development environment (Azure DevOps). Then we work following our internal Agile/SCRUM and Innovation methodologies with no additional overhead. Finally, in addition to SCRUM stand-up and backlog management, we track impact and progress on customer goals with the most suitable tool for the customer context (typically Microsoft PowerBI).

Everyone is more satisfied and less frustrated because “now SCRUM works” but not just we are delivering internally but because we are more connected to the Why of the customer: each delivery person has a clear path to deliver and this provides a full sense also on day-to-day activities… And the wonder of it all it’s just because we are communicating better (much better I would say).

The Data and AI SCRUM-extended sweet spot

This kind of approach facilitate also the customer in taking advantage of transformational opportunities new Data Era is allowing. In fact, allowing customer people engaging with us on “SCRUM in their shoes” enables those kind of initiative to extend the Product Management approach they are having when using BIOM to their day-to-day activities. As said above, even if we are not to change their Culture, these product-driven approach typically activate/amplify discussions on the customer side on how they can adopt/scale the same approach to products and services management they already have.

This is particularly effective for all those initiatives where customers are struggling to extract value from their Data: SCRUM is the perfect fit for software product development but in it’s extended version (any BIOM-like approach) can allow customers not only in accelerate and being effective in their own Data and AI initiatives, but also to structure those into new products, new services and in many cases new organizations, providing (and also selling) these new data-driven solutions to their internal and external final users.

Conclusion

Trust is the real antidote for VUCA and it is the basement to build effective and successful projects to convert in people and organizations business stories. We have wonderful technologies to support all of that but are (still) people to use that to leverage the best from each party avoiding competing on who is right but just on the why.

In this VUCA period everyone needs to evolve and, in my humble opinion, this evolution means to have the courage to stay focused on what you are best of and take advantage of others where they are better than us. This require a strong effort named Trust, both on you than on others, but if you can manage that you will have the opportunity to improve our job and our life experience because we could answer to the question “Why”.

What I learned with BIOM but also from my most satisfying transformational projects before BIOM is that where you can allocate your full resources to work better with others, taking advantage of your differences and their ones as multiplier of each own strengths, we can really allow humans to take advantage from continuous acceleration of technology innovation to improve the world we live in (despite any technology acceleration).

So yes, that’s a lot of life beyond SCRUM if we manage SCRUM to connect different people working really together towards unique goals.

[1] The adoption of?ChatGPT by the first 100 million users has set a new record for the adoption of services / apps such as Spotify or Instagram – see link

[2] Technology is never itself the solution to a problem, but only one means can be used (and therefore must first be known and then wisely used) to solve that problem.

[3] Measurement is a long part of the discussion we had and I could spend a lot of time between KPI, OKRs and a lot more of methods we use to manage this item. The key point to consider here is how much detail you need in comparison with the cost of measurement: in a nutshell the kind of measurement you adopt for measuring the impact of a benefit towards a customer goals as to ensure the proper ROI