am i delivering value?

can i deliver value?

Our industry is obsessed with value. We’re always asking others what the value is of the actions they are taking. Agile coaches, however, seem to be on a scale as to whether or not they consider the value they are bringing to an organisation. Asking ourselves, “Am I delivering value?” is a powerful question, and one we perhaps don’t want to ask ourselves.

I have been at my current organisation for nine months now. At this point, I understand the scope of my role well and what others are expecting from me. I even have a couple of projects that I’m leading on. Now is a good point in my journey to consider the value I could potentially deliver, and the value I am actually able and allowed to give.

First, what I can potentially deliver. I have a wealth of knowledge and experience, and I’m working with those who are early on in their careers or are lifers within our organisation, and as such, do not know what I have learned either from reading books or real-life experience. There are moments when I am giving anecdotes to back up my point, and I can see that I’ve shocked the audience that such a thing could possibly happen in a workplace. I find this a great source of comfort, as it likely means I won’t be experiencing some of the toxicity I’ve seen in other organisations.

However, the answer is very different when it comes to what I’m able to deliver. I am encouraged to reuse materials previously created by others, even when I don’t understand them or think they are incomplete, misguided, or just plain wrong. I am given unreasonable time constraints, so I can’t explore topics to an in-depth level that would enable genuine understanding in my students or in an engaging manner that would more likely embed ideas so they stick.

I often feel my delivery is based on rushing through material I don’t understand.

I know I’ve seen similar things in development teams, where a stakeholder asks for something to be delivered, doesn’t understand the amount of work that is required to deliver that work to a professional standard, and insists that it is delivered immediately. This ultimately leads to a development team cutting corners, not achieving the expected professional standards, and ultimately forcing them to deliver a low-to-no-value product.

How can we, as leaders and coaches, better support stakeholders in understanding the hidden depths of their requests?

In Scrum, we use the Sprint Review to communicate more closely with our stakeholders. Unfortunately, this is often reduced to a show-and-tell demonstration of one or two things the team has delivered in the past Sprint. This falls so short of what we should be doing in this meeting, though, and is a great disservice to everyone involved. Not only are we meant to inspect the outcomes of the Sprint, but also review what has changed in our environment. This allows the development team and the stakeholders to collaborate on what to do next and how to do it. It’s a great opportunity to look at the working processes between the two parties and the benefits and limitations they bring. It also allows us to look at the broader plan and perhaps change that, even if it doesn’t directly impact the next sprint.

So, what am I going to do about my current situation? Probably nothing immediately, as putting the theory into practice is always much harder than it looks. For the time being, I will deliver the value I can in the restrictions I have been given. As I prove myself within these constraints, I will likely be given more freedom and flexibility to deliver the value I think is needed in the manner I believe will extract the most value from the content.