Continuous feedback during the SAFe PI Planning

PI Planning is a high-priced event. You need to book a room, prepare the materials, order food, plan a social event, flight people over, pay for hotel and transportation and some meals, + even more costs.

The total price can go up to tens of thousands of euros and, in some cases, maybe more.

If you add on top of that the time people spend focusing on the PI Planning process – ~100 people for a few days, you get the whole idea.

That’s why it is very crucial to get feedback on:

  • How to improve the experience on the attendees
  • How to cut some costs
  • How not to repeat mistakes we did already
  • How to make the event more efficient

What SAFe recommends on collecting feedback

SAFe recommends having a retrospective-like event at the end of the Pi Planning, where all the attendees can put some stickies on the wall, and the facilitator will help to combine them in affinity notes, and then the RTE will create follow-up items in the backlog.

I see a bit of a problem in that since we tried it first:

  • The people were super tired and didn’t have the motivation to do yet another exercise.
  • They had feedback on their minds, but they didn’t like the attention to stand in front of everyone and put their stickies on the wall and explain why.
  • Some of the attendees shared verbal feedback with me during the day, but forgot to add it on the boards, thinking that the RTE will do something anyway.
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 difference did I make?

I was reading a great case-study from Eik Thyrsted Brandsgård and Henrik Knibergand and based on something that they did, I decided to go even further and create a Feedback Meter: A scale from +2 (meaning this is super great, and I want this to continue) to -2 (meaning consider changing that in the future).

The board was there for the duration of the whole PI planning event, and the attendees could put their stickies on that scale. Also, I needed to communicate from time to time that the feedback board is there, and it can be used at any time.

Continuous feedback meter.

What I have accomplished with this continuous feedback approach?

  • A mood meter: A quick view on the mood in the room at all time – you can see from that picture that we need some improvements :)
  • Act on time: A see something – do something attitude – if something needs improvement, don’t wait till the end of the Planning, but act now and add a sticky
  • Participation: An excellent way to read the feedback from others and to add your own to theirs.
Agile Monsterd: Continuous feedback

Continuing after the PI Planning

There are 2 groups of attendees that you would miss if you stick to what SAFe recommends as a retrospective practice – those that are attending remotely and those people that love to share anonymous feedback for some reason.

I know you would tell me that this is behavior that I should not encourage, but in my case, I received surpassing feedback from that particular crowd.

To solve that problem, I have created a Podio survey and engaged anyone who could go and add even more feedback online.

What is your opinion on continuous feedback?


I am eager to learn more about how you deal with problems like that in the comments. Remember to start with +2 :)

Read more…

Solving customer pain point through simple prototyping and using my 20/10 rule

Prototyping is part of my work. I don’t trust product owners or analysts that do not prototype ideas and share them with the customer or another stakeholder. I will tell you more now about my strategy and I hope it can be useful for you.

I have grown the ability to listen, remember and prototype nearly live time, but since my buffer size is not so large I ask the customer to do short 30 min iterations, instead of just Q&A for 1 hour.

How does it usually work?

 

First meeting

Let’s have this imaginary situation – a customer approached me to create a very simple (from hers point of view) application to help her to run their business better. The first 20 minutes of our discussion I have been asking questions and in the next 10 I have been able to come up with an idea. After 30 minutes I had this ready – ugly, but useful

Prototype on Paper
Prototype on Paper

The customer was happy with the development, so we moved on to the next screens, again using 20+10-minute approach. At the end of the second working session, I had the full concept on paper together with a lot of notes and small indicators of interaction. (see the arrows and the kpi indicators)

 

Second meeting

I put all of these papers on a wall and I have created the first digital mock-up by using balsamiq (one of my favorite tools). I tried to make it as close to the paper version as possible spending half a day in just making it “clickable”, so I can present it later faster.

 

Digital Mock-up produced after the first meeting.
Digital Mock-up produced after the first meeting.

 

After that I had a presentation session with larger group of stakeholders (from customer’s side). In general they liked what they saw and asked when they could play with it. I told them I would give them a prototype in a week, noting that the prototype would not look like the one they saw today since the appearance would have to come come from our design team (mainly thinking about UX guys first). The agreed principles, however, would remain the same.

 

Third meeting

With all the screens and my notes I contacted our UX guys and Information architects. They gave me some advices on how to incorporate our company style, usability patterns, and UI into the prototype, using the information I have collected. The final result was smashing. I have created a small Js APP using the company framework to make a real looking prototype.

 

Part of the JS solution
Part of the JS solution

Another view of the JS prototype
Another view of the JS prototype

The customer was happy with the job we have done. I gave them the prototype to play with and we tracked their way of learning the new interfaces and their journey inside the app. We have collected useful data and that helped us a lot in developing the product.  By knowing what everyone expects I can write better tasks to the developers and will shorten my communication time with the customer and other stakeholders.

It was a huge success and I am planning to use this approach again.

Voice navigation – bringing your app to the next level?

This morning I was surprised by Google Drive. They offered me to use voice for some basic commands, instead of selecting them or using a shortcut (in my case).

A few months ago I created an experiment by combining the shiny SoHo Interface with a few good working opensource javascript implementations for voice and gesture to control the interface.

I knew that some companies were experimenting with it but maybe because I was too busy with other projects and day-to-day routines I hadn’t realized that the time for it has come. 

I am sure that the experiment by Google (seems useless from user point of view) will evolve into something more usable and can save a lot of time to the end-user.

 

Pros:

  • It’s fun – you can shout commands to your website and it will respond with an action.
  • Sometimes you can do something useful – like control your HTML5  game or even login to your favorite website.
  • Brings apps to people that can’t write (yet), but can talk – this is something huge.
  • Widens the horizon of the developers and companies – think about one more usability and User Experience layer
  • It is super exciting and it evolves well.

 

Cons:

  • There are some technological ones, but I don’t want to be a hater this time :) Yay!
  • The other one is what happens with all of the data collected by the mic? Some of the devices are known for listening all the time for the our precious voice. Should we start ripping batteries off from our laptops and tablets like we do for our mobile phones?

 

How to get started?

See my demo here – there is a video  for voice and gesture controlled UI. This is how a modern app should look like – you can use your voice, but also to listen to the voice answer sent back to you and if you feel like moving things around – use your webcam to do it..

 

More links:

 

  • I am using Annyang for the voice commands 
  • Gest.JS for the gestures
  • and this JS library to interact with the GoogleTTs engine 

What is the future?

Bright – pretty soon we’ll be seeing more and more startups combining the Voice with the millions of the APIs that exists to build even interfaceless applications that will work well at the beginning and then will replace most of those apps we use these days.

 

What do you think?