Storytelling in SAFe

Let me start with a bit of theory: There is an Agile framework called SAFe ® that allows enterprises to scale and deliver value faster by optimizing how it flows through different systems and sub-systems, using the principles of Lean-Agile.

One of the primary artifacts of that framework is something called a Big Room planning where all of the teams working on one program get together for a while and discuss open items, groom stories, and plan the objectives for the next 5 sprints.

PI planning

I will not get into the details explaining what a sprint is or what grooming is, I assume, if you clicked on my boring title, you should know that already. If not, well, feel free to DuckDuckGo it and find out.

Let me get back to the topic. During that planning event, I, as a Release Train Engineer or say as a facilitator, am responsible for explaining some of the metrics so anyone can understand it. One of those metrics is the PPM.

Define: PPM

I have a piece of good news for you, I don’t expect you to know what that is, because is SAFe specific and I’ll try to explain you in by copy and pasting something from the SAFe website (yes I want to make a point here)

“Each team’s planned vs. actual business value is rolled up to create the program predictability measure”. 

SAFe Website
Author: Collab

To decode that. I’ll share with you that each team defines their own objectives during the PI planning, and the Business Owners are assigning the value to each one of them, based on the assumption of the amount of value that the team will deliver in the next few sprints.

Pardon the interuption. I have a gift for you.
I know you are busy but curious. Join 73 people like you and get notified when there is a new Agile article avaiable.
I hate spam. Your email address will not be sold or shared with anyone else.

What does it mean to be predictable in this case? (as in Program Predictability Measure)

I will not talk about how to change the ways you define and measure your PPM now, but I would definitely write another article about that. 

  • Reduced time-to-market that can be elevated to faster value delivery.
  • Increased flexibility for changes in scope with minimal cost.
  • Value delivered in the way the customer expects it.

If we drill down to the specifics, this could go all the way to how much time yous pend on a defect and how efficient is your CI/CD pipeline or how well defined are your Acceptance Criteria.

Per “Blogagility”. The effectiveness of the business outcome of our collaboration and alignment either builds Trust, or it destroys it. 

Blogagility website

I totally agree with that statement. That’s why I focused my story on how trustable we are in the eyes of our Business Owners.

Why Trust matters.

I used a storytelling approach to explain why it matters and tried to connect it to our own software development world.

Here comes the story:

It was one Friday night, and after a hard day at the office, I went home and met some Balkan friends. We did some things that Balkan people do, drinking some liquids that Balkans people drink and when we started seeing Balkan dictators at some point there was this voice behind me:

My son: Dad, where is the pizza.

Me: grabbed my phone, opened the app I used for home delivery and clicked on my order. 

The app: Time for delivery: 18:45; Status: Preparing

Me: looks at my Ikea clock on the wall: It was 20:00.

Me: clicks on the contact us icon and enters my order id.

The app: Order not Found

Me: uses my so-amazing Czech language and checks the status on the phone

The app support: Oh, we apologize, the supplier forgot about your order, here’s your money back.

The time: You lost 40 min of your life.

The app: Your order has arrived.

Me: ?!?

So we ended up with pizza (not so warm) and money in my pocket. You could way that this is a win-win situation, but I mostly care about the experience, not about the money.

Let’s go back to the Trust.

This happened twice, so my Trust with the process of that company went down. 

I really don’t care about who’s fault it is.

  • is it the cooks (developers) that were too slow?
  • or it’s the delivery guy (the CICD pipeline)?
  • or it’s the misalignment (program manager) between different departments?
  • or something completely different?

At the end of the day, the Trust in your product matters, and your product is a complex system that should work well together.

I can imagine that this problem doesn’t happen just to me, and it happens to other people, and they complain differently. Then the company receives that feedback, and they can say what their trust score as we can say as a team of teams (a Program) what our PPM is.

I saw some people nodding their heads in agreement with me this time, so I believe that it was one small step forward to explaining some of the terms in a way that makes sense.

I consider that a success.

Read more…

How I run Ideation workshop to hear “the voice” of the team.

I missed a step in my previous article on purpose. I was planning to write a separate article about that and here it is.

When I was completing my UX training by Chris Nodder I liked a technique called “Ideation” and I have decided to hack it and to use it for my own purposes – as a product person.

So here’s what I did:

Booked a room:

I booked a meeting room for 2 hours. There is no special requirement for the room – you just need a table, a few chairs and a projector. You can also do it in a quiet working space with no cubicles or in a non-smoking bar.

Provided some sweets:

I’ve bought some sweets, to help people concentrate on the topic while doing something with their brains, their hands and their jaws. Later I realized that it would have been nicer if I had brought fresh fruits or something more healthier (I’ve red that in a book called (Design)“Sprint” written by a couple of Google Venture folks).

Provided the tools:

I bought colored pencils and I printed out lots of templates to be used during the workshop.

The template

Ran the workshop:

So, yes, the workshop – the idea was to get different people together working on a task to get some ideas and fresh views.

I invited people from different teams – I got a couple of QA guys, a few of Business Analysts and a bunch of programmers.

Then I randomly divided them in teams. And I gave them the task – a short list of user requirements with the question: How would you do this? Use your imagination and the template to create a simple prototype for just 15 minutes.

There were a few basic rules:

  • The requirements must be always visible on the screen
  • You can ask me questions if you have any (I was the customer)
  • Don’t talk, just prototype and eat sweets.

After this 15 min period, every team had 2 min to present their work in front of the others. There was no opportunity to ask questions during or after the process.
Here are some of the results:
A few ideas A few more ideas more ideas

and even more ideas

As you can see – you can do whatever you want, but you have to be able to explain it after that to the rest of the team and to focus on how it fits the customer requirements.

Anyone can prototype!

We repeated this with a few more requirements and at the end we had a lot of ideas to discuss with the rest of the team.

The outcome:

The goal of this workshop was to hear “the voice” of the whole team. Some guys are shy (mostly the developers, oops) and can’t share their ideas while we are discussing in a meeting.

The output was to generate ideas and to show great approaches on how we can solve a customer pain point.

How to measure customers’ satisfaction without asking them those boring questions

Let’s imagine you want to understand how happy your customers are with your product. According to the marketers there are several methods to do that, like NPS or Temper, but all of them require interaction with the customer.

Let’s be honest, most of the time people don’t want to answer stupid questions like “How do you feel about our new interface” and “Do you like our new red color?” and let’s be honest again and confess that no more than 10% of the users will answer those questions.

Of course you can use the data to create a magnificent dashboard and to convince the  management that your product rocks, but they can ask you some hard questions. “Then why are we losing money?” and “Why the Churn rate is so strange?” are just a couple of examples.

You don’t know.

Let’s take a step back and see what is important in this case. Let’s imagine we have a website where you offer content (video lessons, for example) and you are billing month by month.

 

Define your Groups and their Happiness KPIs

 

Let’s imagine that you have 2 main user groups (2 personas):

First Group – Constant Learners

Group of people interested in constant learning but not sure what they want to learn about (first).  These people will browse your content until they find something interesting and will spend time doing it.

What drives them?

  • They want to discover new topics.
  • They want to know a lot about everything.
  • They are interested in trending topics (no one will browse – How to create a chart in Excel)
  • They are thirsty about new knowledge.

Happiness KPIs (some of them):

  • Number of topics discovered
    • Minutes spent on each topic
  • Questions asked (onsite, outside)
  • Number of logins
  • Number of login patterns (do they log in every week or everyday at noon)
  • Number of points/certificates achieved (if you have such things)
  • Account lifetime

Second Group – Focused Learners

Group of people that are coming to your website to learn something specific – like python, because they need some tricks in their current work. They will find what they need and they will stick to it.

What drives them?

  • They want to learn something on a specific topic
  • They want something meaningful out of the topic fast
  • They want hands-on experience.

Happiness KPIs (some of them):

  • Finished % of  a topic.
  • Exercises completed (if any).
  • Questions asked.
  • Number of Video pauses (try to watch and code at the same time).

 

Ok. What’s next.

It’s obvious –

  • Define your own KPIs – you can use those above as an example.
  • Then try to put a “label” to any a small group of users. Is this user a [focused] learner or a [constant] learner. In the case above, get all users that have browsed more than 3 topics in the past month and assign them into the “constant” bucket and for the “focused” one, get all that have completed only 1 topic within the last month and have asked at least one question.
  • Track them to prove your claim – see if their behavior will remain the same – if it doesn’t – modify it.
  • The create a simple dashboard to visualize the data for the two groups – and create a marketing strategy around that – how to engage both groups and push them gently on the success path.

This is how you can measure customer happiness without asking your visitors boring questions and to give them the opportunity to lie, because most probably at the end of the month you will see most of your “We like this new red button”- type of users leaving your service forever.