Tag Archives: agile

Don’t tell me how – tell me your intent

Since I have founded my own company, I have worked for/with multiple companies. During those times I made a few observations I’d like to share. This is one observation.

TLDR: Give a team an intent and the team will give you the best path to that intent (goal). A much better path (how) than you could ever figure out yourself.

A lot of (it) organizations work in iterations (so called ‘Agile’). Often using a process (but not limited to) called Scrum.

Whatever you’d like to call the process, there is a need to build things. This need is often presented as a list and is (should be) ordered by priority. In Scrum this is called the Product Backlog. This list is often discussed in so called refinement sessions where the Product Backlog Items are being prepared for the next (coming) iteration.

One of the questions I’ve heard is: “how much work/effort would it cost to do [backlog item] ?”.

This is a very useful question, but also a dangerous one.

Business/Product Owner/Managers – Be careful what you ask for! – Example #1

Lets use a more concrete example:

[Backlog Item] says: “As [Organisatie X] I’d like to have a JSON implementation so that I can work with [party Y]”.

Considering the question we posed (“how much effort..” etc), the answer will be a quantity expressed in Story Points, hours or whatnot. This is valuable information, as a business owner you can make the translation (roughly) to the amount of money this feature will cost. You can then evaluate if this ‘is worth it’.

You have the answer to your question. But did you actually get that much further? What did you miss?

Business: Use your team’s brainpower! – express intent! (business value) – Example #2

Lets reformulate the Backlog item so we express intent first:

[Backlog Item] says: “to offer service X to our customer(s) we’d like to send order information to [party Y] so that we can deliver orders to our customers.”.

Ah, so the intent is to ship orders to a customer which (apparently) party Y is only able to deliver!

This is a totally different question.

So where does JSON come from? Is it really required to send orders? Could we perhaps export a CSV (which might be way easier to do?)? None of these possibilities are explored in the first example. Simply because the question was asked differently.

Business: Be careful how you ask things to be done on your product backlog.

Team: ask for the intent when you’re presented with an ‘implementation’ question

Of course, with Software Development not only ‘the business’ is playing a role. In fact, working Agile simply means that we’re working together. As long as there is an ‘it’ and ‘business’ as separate entities you will never get the full potential and effectiveness of your people. True collaboration means that all ‘entities’ (people!) within the organization are (should be) working together to make that organization as successful as possible, right?

If that’s not the case for you, just get to know each other better (grab a beer?) first. 🙂

So back to the Backlog item. Considering you get a question as in the first example. How do you get to the intent from there?

One of those ways is to ‘ask why 5 times’. If you take that to literally you might sound like a spoiled brat. (although there is some sense in asking why all the time).

A bit more practical would be to ask questions like:

  • what will [implementation] happen?
  • what do you need [implementation] for?
  • once [implementation] is finished, what will it be used for?

Usually this leads to the intent. As in: “once we have a JSON message, we can send it to [party Y] so they can process orders”. The ‘so that’ part is important. If it’s not clear, don’t be afraid to ask. You don’t ask them because you doubt the business or their competences. You want to be professional, not wasting money, and delivering the actual value.

Business value usually is represented in money. When it is not about money, it usually is tight to the company vision. If you don’t think this is the case, keep asking.

Sometimes there are exceptions. Lets say your product needs a payment provider. And the company has a certain agreement to use Buckaroo for payments. Then in that case you might get the “build buckaroo to process payments” story. Although ideally it is not the story you want. (Especially if it is critical and getting buckaroo to work takes ages, while you know some other payment provider can be implemented with a fraction of the effort).

Team: By exploring intent, you can answer the ‘true’ business need.

This eliminates ‘waste’ on several levels. Waste in time, technology and missed opportunities.

So what does this boil down to? – trust your team

So what does this all mean? That you as manager involve your developers sooner? Preferable before you need to build up services/couplings with 3rd parties? yes!

Before you get into contract negotiation with these parties? yes!

That the team tells you how to process payments? you bet!

That the team decides when to go live? Yup!

Let the team think of how to do cross selling? Or how to make your checkout flow easier? (so don’t hire an external party to deliver a ‘report’ in the team, so they can ‘fix’ it). yes!

Give the team autonomy. (= responsibility). Give the team an intent, and the team will do their best to fulfill that role.

You have to get used to it.

It is exciting.

But above all, it’s awesome in many ways!

Go forth and be great!