Chapter 2: Enterprise Agility – No value, no party!

Apply Agile techniques to build something useful, tangible and valuable to someone on the user or business side. An agile approach is based on the continuous delivery of value in order to verify the “sense” of what we are building and adapt the product as soon as possible, and thus guarantee that we are investing in the right place.

If we were talking about the software industry, it would be quite easy to identify the concept of “value”. However, what about HR processes, marketing campaigns, commercial funnel management or other activities where we would like to apply an agile approach? My opinion is that there is no single answer. I can only suggest a question that you can ask yourself when you are thinking about part of a big process that you want to transform:

Can I deliver something that could be paid for or appreciated by my client or user?

If you don’t get “Yes” as the answer, you need to reconsider how to organize the work. Applying Agile techniques, tools or methodologies to deliver something for which you cannot receive feedback (in terms of its value) from the business side, in my opinion, makes no sense. The power of Agile is to reduce (or remove) the distance between the people who build all the stuff and those in charge, in order to address the needs of our users or our clients.

The concept of value has been addressed by project and program management methodologies for a long time (for example, EVM – Earned Value Management by PMBOK) with good intentions. However, in my opinion, it has been defined in a way that makes it difficult to improve the quantitative value of ongoing projects and, moreover, to map the real value along a long chain of activities and tasks required to return something “tangible”. As we know, this set of work activities is not necessary allocated within a project.

When working with an agile mindset, our concern should be to identify how we can verify the real value of the work units delivered along the delivery chain from two aspects:

  • Who? Request and define the need. This should validate the understanding of the requirement, and the realization of the work delivered – always with the actual end user in mind.
  • What? The request should be designed with the purpose of returning something tangible.

Sometimes, the customer journey or value stream where we are thinking about implementing Agile is so big that it requires a huge effort to imagine how to structure the teams in such a way that they can deliver real value in a middle step of the process. Don’t be afraid, this is normal and common, and there are some tips for dealing with the problem. You could start by thinking about an escalation approach, or an agile strategy for the entire organization.

You can check the internet for information on “agile escalation” and “agile organization” and you can find lots of frameworks, or you can try to define your own way to scale thought experimentation based on Agile principles. Because no one knows your business, your organization and your people better than you, and you know who will make it work!

Next chapter: Enterprise Agility – Finding and managing business process boundaries

Chapter 1: Enterprise Agility – Agile 4 All
Chapter 4: Enterprise Agility – Help me help you!
Chapter 5: Enterprise Agility – Agile teams, those who make the things happen
Chapter 6: Enterprise Agility – Prioritization, taking an economic view
Chapter 7: Enterprise Agility – Collaboration as a key success factor