Why it is ok to cheat on frameworks to stay agile


Do you think it is ok to cheat on frameworks?

I am a pragmatist. Application over theory. Trial and error over study. Decisions instead of long speeches. Experimentation is part of everyday life for me, concerning our users as well as with the team.

Digital product management is a fast-moving business that confronts us with new requirements constantly. As a result, the systems we build are outdated as soon as we release them.

Our organism, the teams, and the company are also constantly developing. But do we work on ourselves in the same way as we work on our products?

The framework

I’m reading it everywhere now. What is Agile? What is the difference between Lean Startup, Design Thinking and Agile? We are talking about frameworks that, we hope, will provide THE solution.

Our discussions are sometimes strangely detail-oriented. How should we interpret the written word, we ask ourselves.

What fascinates me is that we talk more about the frameworks themselves rather than the intended change—the classic question of outcome vs output.

The Oxford English Dictionary defines a framework as follows:

A basic structure underlying a system, concept or text.

We are talking about a model and not a legal ruleset. A skeleton that serves as an impulse generator to give ideas and show patterns.

In a beautiful article, Jeff Patton has written about the problems of the Agile Manifesto, among other things. There it says:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Twelve Principles of Agile Software

Patton elaborates:

You can deliver what you said you would every sprint, and it may not matter if the work doesn’t result in the outcomes your organization predicted. Doing agile by the book may result in you being a great service provider, but not a successful product creator.

Jeff Patton – The Mindset That Kills Product Thinking

And this is precisely where our human problem lies. Of course, it is easier to take and copy a framework. First, however, we have to think about whether we are achieving our goals with it.

The adaptation

In my article ”forming a team”, I explained that each person comes with their history and experiences, both positive and negative. Accordingly, the most diverse organisms emerge.

A few years ago, I took over a team as a product manager, in which we lived two different release processes alternately. For the team, it worked well to handle the two platforms this way. However, the moment I became part of the team, new dynamics emerged. My expectations and experiences meet an organism that functions well.

Supposedly, it would be easy to transfer a framework or a particular way of working to the team. However, this will not succeed for several reasons.

Firstly, a change in processes triggers something in those affected. Often these are rather negative things, such as concerns about the unknown. However, change is complex, and therefore one has to proceed carefully.

Secondly, every organism is different. Each team has different needs. For example, a pure Android app team has different ways of working than a web team. In a cross-functional setup, non-developmental functions such as marketing or analysts also come into play.

So, we cannot transfer a blueprint from team A to team B. Let’s adapt, take the basic structure, and use elements that improve our organism.

The experiment

Before we release a new product or feature for our customers, we test. We talk to our users, try things out, and change the product again and again. So, we wouldn’t come up with the idea of copying a competitor quite bluntly. Instead, we use the impulses and market standards and adapt them to the needs of our customers.

In the team mentioned earlier, we ran an experiment aligning the release processes. The concerns were manifold, yet together, we introduced a change that positively impacted the team.

I always see changes that we tackle in the team in terms of our processes as a phase. We try things out and decide after a particular time whether we can live well with the changes. Occasionally, we iterate and improve even more. Every so often, we leave it alone. As soon as someone new joins the team, we have to adjust to that unique situation.

The outcome

Create value and do not blindly follow a framework.

We have to ask ourselves what goal we are pursuing. It is one thing to advertise with the label “Agile”. But, we also have to live it. For me, that doesn’t just mean blindly following a framework. Instead, we need to adapt frameworks to the needs of our team.

It doesn’t matter whether a team aligns its work processes to Scrum, Kanban or another framework. The crucial thing is that the team must produce valuable work for the company and its users and have fun doing it.

Outcome over output. Free yourselves from the constraints of the frameworks. Talk to each other and decide together which rituals you need for successful work. Review your ways of working regularly, but without force. Try things out, i.e., experiment for four weeks and see if the change has brought you forward.

In the end, I refer to the Oxford Dictionary of English:

Agile, able to move quickly and easily.

Image 1: Photo by Jack B on Unsplash

Image 2: Photo by Anne Nygård on Unsplash