The importance of working with requirements

Two weeks ago (and the week before) I held a couple of sessions of Product Owner training in Sweden. 

As you know, I’m particularly interested in Product Ownership, being such a critical (and often underestimated) activity for the success of an Agile organization.

Anyway, regardless of this, every time I facilitate a PO training, one of the most interesting discussions happens around the subject of requirements. And the reason is that even experienced analysts or system engineers are sometimes not used to work with requirements properly.

The first important concept, which looks straightforward and totally sensible, but happens to be pretty hard to apply, is that a requirement is expression of a need, not a specification to implement.

It is an item in the space of problems: it is a problem to solve, not a function to deliver. 

On the other hand developing SW is just about solving problems, not writing code, right?

For instance, if one says: I want a bridge, is this a requirement? Is it a problem to solve or a solution?

A right conversation would then be: 

- What is the need behind this request?

- I want to cross a river without getting wet.

Eureka! This is a requirement and, as you might guess, this opens up more than one option to find a proper solution. One solution is definitely the bridge, other solutions could be a boat or a raft or even swimming. And you don’t even need to build anything in the latter case.

This is a very important job: understanding the real need behind a customer request. That’s why we don’t say writing requirements or defining requirements, but eliciting requirements, because it is about digging out real problems and helping the customer understanding her real need (or at least making a hypothesis on the real need, which must be validated through a fast feedback loop).

Then you as PO use your brain, your skills, your domain knowledge and the brains in your team to translate the need in business solutions, you can write in forms of User Stories, which is the language you speak with your team.

Requirements are instead the language the Product Owner speaks with customers, but it would be too easy and not profitable downloading the requests on the team as they are. Challenging customer needs is a very crucial activity for a Product Owner to be able to find a solution compatible with business and maximize the Return on Investment. 

I repeat many times to my PO team: your job is not to push your team to do as much as possible – your job is to challenge requirements, so that your team can do as little as possible.

Cutting some scope because it is not needed has an effect that no efficiency program whatsoever can ever beat: effectiveness eats efficiency at breakfast every morning.

Unfortunately I saw too many times the pattern of jumping directly into solution mode as soon as a request arrives and business solutions masked as requirements.

Buddhist masters know that, if you spend enough time in finding and formulating the proper question, the question itself will contain the answer. But how do you feel is the ratio between the time spent on defining the problem and the time spent on the solution in your context?

5 things you should know about Organizational Coaching

Some days ago I was having a coffee with one of my colleagues.

While answering to his request of feedback about his work as a Scrum Master, we ended up in talking about what organizational coaching means in practical terms, what it is really and what it takes to be effective.

I cannot report the whole interesting discussion, but here are some takeaways as summary for you: 5 things you should definitely take into account, if you want to become an organization coach.

1. Use a system approach

An organization is a complex network of people, who are complex beings. If you really want to leverage on all potentials to affect it, either to make it better or simply to help your team, you must look at it as a whole system. Try to sketch a strategy of the possible options you have ahead, possible impediments and way to overcome them to reach your goal: you might realize that a single isolated step is not enough, but you need to take many steps, in order to get any progress.

2. Know your organization

Try to understand your organization very well. Learn not only about the official and visible structure. Learn much more about the invisible networks, the inner relationships among people, who is friend of whom, who is most sensitive to certain subjects and who counts more or is more decisive on certain tables, whether he has a formal power or only a subtle influential leadership. You cannot imagine what competitive advantage this will give to your effectiveness.

3. Act on different levels

Challenge the status quo and don’t limit yourself to the most obvious actions. Prefer actions who affect the environment around or the process to do things, instead of addressing directly a specific problem: they will have more and lasting impact.

Talk to people, with a preference for informal chats - coffee machines are a perfect place sometimes :). Try to find initiators and innovators to help you and sponsors to support you in difficult situations. And, whatever level you want to affect, consider acting also one level up.

4. Understand the effect of your actions

Before taking any steps in your strategy, try to guess which effect it will have in relation to your goal. Make a hypothesis and try to validate it as quick as possible. Find even people who to share your thoughts to and get feedback. The sooner you know if your strategy can work well or not, the better it is: you will then be able to adjust it if necessary and speed up the achievement of your goal.

5. Try things out

Finally organizational coaching is not mathematics and the system to act upon is many times far too complex to draft a strategy since the beginning, indentify any viable action or understand the effects of possible actions. That’s why sometimes you must simply try things out. And that's not wrong, stated that you try to fail fast and reflect on what you learned to find a different path.

That’s my experience. What did you learn in yours?