When companies discuss being Agile, it's very likely that each person has a slightly different view of what that means for him/her, for the department he or she leads or for the entire company. And each of them might very well be correct, individually.

You know what's definitely NOT correct? Thinking that one can take an already-defined framework, force it upon a department or a company and once that process is "done", consider themselves to be agile from now on.

Why is it wrong?

Two reasons: First, considering that agile is a process which you go through once, and then you are "done". Completely false. It's never done. Much like a good piece of software.

Second, not adapting the rules and the tools to your particular domain, environment, people etc.

I thought agile is only related to software

It's not. You can't put agile work into one single department and ignore the rest. Sooner or later every stakeholder needs to be in sync. And this is hard work.

It's hard because everybody needs to embrace insecurity. Everybody needs to change the way they work and approach things. It's uncomfortable. And you must also let go of certain tools which gave you an apparent sense of security. (I'm thinking about long term planning based on estimates)

So here was my perspective. In the last months I read and experimented and applied and got feedback and then iterated on a long list of items. All of them from the Agile world. Some from Agile Manifesto, some from SCRUM, some from extreme programming. And probably others which I am not familiar with.

Sidenote: this was actually one of the main reasons I was much more silent on this blog than last year.

In a way, my problem was that most of the advice, most of the articles, books, blogs, conferences where very much software-focused. Software-building focused. Even though in my head everything made a lot of sense, when explaining similar concepts or work styles to people not involved in software engineering I got no traction.

Continuous Integration, Continuous Deployment and Continuous Delivery all lead to the same road: Continuous Product Engineering.

But how can we talk about Continuous Product Engineering if Sales, Marketing, Customer Success/Support and all the other supporting actors don't understand and don't connect to this way. If they are still working in a Waterfall way, then... you are in for a really difficult time.

Empathy for the other stakeholders

To the best of my ability, I always try to keep an open mind and be as empathetic as possible. To see their points of views, understand then and reach a solution or a compromise.

Therefore, I am always asking myself what am I missing? What information was not communicated that would substantially change the way we work and make decisions? What things are not taken into account to have a clear image and provide the necessary context.

While performing these exercises, this morning at 4am (I couldn't sleep) I finally got out of bed and decided to continue reading a book that I started and didn't finish.

Getting confirmation

The book is called Learn to Build by Bob Moesta.

And I got really excited about it. Why? Because it came from different perspective, it used different words, but it conveyed the exact same agile principles.

Chapter 3 - Uncovering Demand

In the part called "Making it real", we have "Young Bob" who "wanted to scale quickly: how can I make this as big as possible, as fast as possible? Enlightened Bob, however, wants to understand how to add value one person at a time. Only then, when I can see the hidden patterns, can I think about scale". Emphasis is mine.

Chapter 4 - Causal structures

This chapter starts with a quote which goes magnificent as a follow-up idea

"If you can't describe what you are doing as a process, you don't know what you're doing." -- Dr. W. Edwards Deming

In this chapter we again have "Enlightened Bob" who has a goal called robustness. "I try to make things fail as opposed to waiting for it to happen like young Bob; I want to know its limits".

Isn't this precisely what we would like, ideally, to experience in software development? To fail fast to understand the limits? I believe the answer is yes.

I'm currently at Chapter 5 which is called "Prototyping to learn". So far it sounds like textbook agility to me.

Next steps

This books also has some specific advice which is not directly related to product engineering or Agile, but it still uncovers some pain points that we experience in the company. So the value this book provides to me at this point is time is really high.

I'm really happy that Valentin gave this one for me to read.