Last month we got a new project underway with our client and partner Grupo Ubesol.
Just like in every project, as a technical team, the first thing we do is to understand the user´s needs and expectations, as they are the ones who will use our product. For these purposes, we pool ideas based on what has worked before, experience working on other projects, etc.
We decided to break away from our past experience in order to apply a model widely adopted by agile methodologies: the lean inception (with some adjustments). Why lean inception and not a traditional meeting between the different heads of department (or not only with them)? Because it puts the user´s knowledge, his/her expectations, needs, skills, at the heart of the decision-making process. Because it allows the product user to choose how he/she wants to prioritise and organise deliveries. Because it gives us the peace of mind inherent to following a transparent process, where communication is ongoing and where deliveries are agreed with specific results.
For us, the project´s success lies in the end user being pleased with our product, and being able to provide him/her with as much information as possible, while intruding into his/her day-to-day life as little as possible. And without having extensive knowledge about who is who in the project, and what everyone does, we believe that this result is difficult to achieve.
How does this lean inception work?
Through some practical exercises or workshops, the aim is for as much knowledge as possible to be shared between the technical team and end user about the needs that the project needs to solve.
We kicked-off the project with a quadrant in which the technical team and users established what the product we are going to work on is, what it does, what it is not and what it does not do. In this way, we lay a clear foundation that enables us to understand the scope of the project. Furthermore, we defined the project objectives and looked into issues such as what they expect to achieve with the implementation of the new product, making it clear to both parties what needs are to be met.
Our next activity was to define the profiles of the users who were going to be involved in the project, their expectations, their objectives, their skills and a very important point: their responsibilities. This allowed us to understand who was going to use our system and to think about how they would use it.
Once we had clear objectives in mind and knew who was going to use the system, we started to build the castle according to the functionalities we wanted our system to have. Carte blanche to ask for anything… with only one condition; the functionalities had to be defined by applying the pattern:
“Given a context…
When an event occurs…
Then a result will be obtained…
To meet the target…”
It is a system inherited from Behaviour-Driven Design that forces us all to think and define acceptance criteria along with functionality.
Implementation of the functionalities
The next thing we did was to “draw” how we wanted these features to be implemented, the sketching. Using a whiteboard and marker, we outlined the user experience (UX) together with the user: which fields, which hyperlinks… everything necessary to make it as useful as possible.
The last stage of the process was one of the most interesting and I think one of the toughest for the client. We had to order and prioritise all the functionalities that were to be included. We used the MoSCoW pattern for prioritisation (Must, Should, Could, Wouldn’t). We forced each profile to mark at least one functionality with each category, which forced them to think whether or not what they had asked for was really necessary.
Based on the data collected, we have drawn up a functional document and will organise blocks of deliveries in iterations. Right from the first delivery, we will be providing functionalities ready for the productive environment, providing value to the client from the get-go.
We were left with many of the activities proposed by the model in the inkwell (sizing, user travel, MPV canvas, …), but despite this, it was a session in which both the Ubesol Group and Sothis provided a lot of knowledge, and set consistent objectives, without false expectations, with absolute transparency…deepl