Learnings From School Of PO Conference
On February 13, I went to a new conference in Paris, its very first edition, called “School Of PO”. What is a PO ? The acronym stands for “Product Owner”. The client representative, who knows the requirements, sometimes writes them. In scrum teams, the PO creates and prioritizes stories, and works closely with the development team to build them.
The conference aims to learn more about product ownership, experiment brainstorming techniques that help to innovate, map, and create shared understanding within the team.
It began with a inspirational morning. 4 talks, 4 speakers, 4 steps of a journey :
- Learn : In English, Alberto Brandolini, talked about his “Learner’s Hypothesis”, how learning is never a waste of time in a project. “Learning is always going to happen”, whether we share enough information or not. “Software development is a learning process”, a team, in order to learn, needs to experiment and make mistakes. The more information we share, the better experiments we realize. The PO’s role is not to stands between knowledge and the team. The PO’s role is to share the most possible knowledge so the team can experiment and develop the best solution.
- Invent your limits : the very first Senegalese Olympic skier and his story. Lamine Gueye’s secret to success : the frame we set with our goals, and the dice we choose : easy or complicated way. Are we going to choose the easy way to get to our goal, or the complicated one? Are we framing our life only with what is possible to do, or are trying the impossible, to reach happiness ?
- Play seriously : Laure Chouchan is a TV games producer, and explains how a show is created, beginning with an idea, developing it until we are ready to explain it clearly, the importance of considering all contingencies, and test absolutely every scenario.
- Follow your intuition : Do you often follow your intuition? Livia Cairo has dropped her job, to follow her needs and based all her new career on her intuition. She is now a successful entrepreneur, writer, and helps others listen to their intuition.
The afternoon was organised in two tracks of 4 workshops.
UX thinking for PO
I went to “UX thinking for PO”. We began with an experience mapping, where we set the story of a user, its actions, how we evaluate its experience (with smileys), and the touch points (mobile, web, physical, …). This part could be a full workshop on itself. We then choose one experience that we would like to improve, and we started the design. What a surprise for me, a developer, with a pen and a set of screens to imagine and draw ! The exercise is called 6-to-1. We had, each of us, to draw 6 screens in 10 min. This is really fast, and I only managed to draw 5. Then, in turn, we explain to our team (we were 6) very briefly our ideas. Each of us will then choose one idea, and get 10 min to draw it. The result is quite bluffing, having this small amount of time and ideas to create, gets you very imaginative.
User Story Mapping, for better and worse
The next track was the workshop Alexandre Thibault and I ran, about “User Story Mapping”, and how this technique helped us organize our wedding (true story!). We started with giving our context, with funny slides about how we met at work, and how we decided to get married. At some point of our wedding organisation, 2 months before the “deadline”, we found ourselves with still many things to do, and no real clue on what is important. Alexandre, as an agile coach, taught me about User Story Mapping. It’s an exercice that can be resumed in 6 steps :
- Who, why : for who do we aim our project, and why.
- The big picture : frame your story with the main activities
- Explore : go deeper and define more details for your activities (actions, alternatives)
- Release strategy : now that you have clear view of the story, define slices of achievements. There is always too much work, too many ideas and actions, this step forces you to define a development strategy, what is the necessary to do to achieve your goal.
- Learning strategy : how are you going to measure and validate your hypothesis? You might want to slice into another minimum number of actions, what will help you test sooner your solution.
- Development strategy : you have now your “MVP”, you can organise and plan your development.
All this presentation part last 25 min, we had then 1h to let the participants experiment by themselves in small groups. We asked them first to propose an idea, and volunteer to play the role of Product Owner. It wasn’t as easy as I expected actually, what a long 5 minutes we waited and encouraged people to stand up and talk about their ideas. It finally began with one person, and quickly there were 3 more that stood up. We let the crowd divide in 4 groups, following the leader of each idea. It went surprisingly well, in 45 min, every group had developed pretty good level user story maps, with 3, and some 4 “release” slices.
You can find the slides of our presentation here : https://fr.slideshare.net/AlexandreThibault2/user-story-mappinp-pour-le-meilleur-et-pour-le-pire
Death by estimations
And finally, at 6pm, the conference ended with a great talk, a spectacular manifest against estimations, by Frédéric Languedois. It was astonishingly convincing. He started with stating that “predicting the future, is the job of oracles, fortune-tellers, soothsayers, and project managers”. When did we start to believe that we are able to predict the future ? Why would it be possible in project management ? A project is full with unknown, we don’t really know the constraints, we are not sure about our needs, and in order to gain control over this, some have chosen to plan, set deadlines and budgets, sign contracts, and estimate. Estimation is a great amount of work, spent on predicting the future. All the time we spend on estimation, deadline planning, is a time we don’t spend on developing and actually working on the project. He developed several known “techniques” of estimation, and destroyed them all. I remember this one : “I ask my developers how much time do you think this task will take, and I multiply by 2”. Frédéric’s statement :
“a random number multiplied by 2 is still a random number”.
So how do we coordinate? How do we tell the client when the software is ready? Actually his solution is simple : you first build the solution, then tell the client that it will be ready in 3 weeks. Impossible you might say? How about predicting the future?
This is only common sense, and we are all responsible of doing our work the best way possible. How about we start doing the actual work, and stop trying to control the unpredictable?