How we Shaped Up our product delivery
From Agile to something else
At UpHill, we are pursuing the mission of building tools that empower people to provide and receive the best care. We want them to be as efficient or smooth as possible, and we think that is only possible if we are also. That being said, we strive for the best way of optimizing our product development process. After some time following the most common agile approaches, we found a different one.
That goes by the name of Shape Up, a guide full of techniques that software development teams can apply in order to ship products faster. Invented by Ryan Singer and the Basecamp team, the guide presents us with ways to start from a user problem, shape a solution, and build it.
Shape Up 101
Shipping a product using Shape Up means going through the following steps:
- Shaping — People who are doing strategic work, and are capable of combining interface ideas with technical possibilities, define the problem and present the solution, at a higher level of abstraction than wireframes but more concrete than words. This work is packaged as a formal write-up called a pitch that summarizes the problem, constraints, solution, rabbit holes, and limitations.
- Betting — People in the highest positions gather around the betting table, a meeting to decide what to do in the next building phase. From the previously produced pitches, the stakeholders bet on those that fill all the requirements and are aligned with the company vision and reject those that do not have an appetizing problem or lack the solution. The selected pitches are assigned to a team of 1 designer and 1 or 2 developers.
- Building — Each team is given six weeks to develop the assigned pitches and takes full ownership of the project scope. The team identifies the needed tasks to do before the end of the cycle. After six weeks, either the project is finished or put away. Extending a project is discouraged, and the conditions to do so are rare.
Some quick background story
UpHill started its development following solid Agile practices. At that time, we were using the Scrum framework to guide our planning and day-to-day activities. We kept a product backlog, estimated the next 2-week sprint, had the daily meetings, and reviewed the work at the end. Our results were good but not great, so I will highlight what went wrong:
- Spending a lot of time and energy on the story estimations (sprint planning);
- Focusing more on the total sprint points rather than the value of the features we were trying to ship, which led us to the state of not shipping anything meaningful because it “did not fit”;
- Not being able to compromise to a 2-week cycle without being interrupted or without realigning the compass;
- Failing to meet our estimations and, as a consequence, invalidating all the purposes of estimations and velocity tracking.
To solve the conflict between the 2-week estimation and not meeting the expectations, we adopted a few principles from Kanban, shifted our minds to a continuous flow, mapped our user stories on a Kanban board, and kept the daily stand up meetings. There were no more cycles, the work was receiving a high-level estimation in the form of a date or deadline. As before, things were going well but not great: the deadlines were underestimated and we were ditching the planning, and failing to understand the problems at hand.
The turnover
Looking for a better way of defining our problems and designing our solutions, we came across Shape Up. We liked their approach, trusted what we saw, and started following the three steps: Shaping, Betting, and Building.
- The Shaping phase
The way we shape our work is very similar to the one proposed by Basecamp. It occurs during a six-week cycle and prepares the work for the next. Our Product Manager takes the wheel and is responsible for presenting a formal pitch that contains the following topics:
- Problem — The idea, user need, or new feature that we are motivated to work on.
- Appetite — How much time we want to spend in terms of energy and enthusiasm, and what constraints we must add to the solution.
- Solution — Elements (instead of words) in the form of fat marker sketches are used to offer a visual idea of the concept we are trying to accomplish. These sketches are drawn at the right level of abstraction, so there will be enough room for designers later on.
- Rabbit holes — The limitations or problems regarding the solution that are worth identifying to prevent future problems.
- No-gos — The things we explicitly decide not to do because they did not fit the appetite.
During this phase, we conduct many user research initiatives to clarify the problem and discuss possible solutions. We interview our users to identify their pain points. Then, we analyze the data collected to have a comprehensive understanding of the problem or the solutions needed.
Before presenting the final formal pitch to the C-level, we try to make the research more transparent by adding its results. We append the following element (not included in the Shape Up guide):
6. Research — The result of users’ interviews and any relevant analytics that we are collecting from users’ current interaction.
Despite being a mostly lonely job, the Product Manager often involves a designer or someone technical during the shaping phase. The designer contributions are useful for user research and sketching tasks, and the software engineer can comment on the solution feasibility or any limitations that have to be taken into account.
In theory, anyone can shape an idea, come up with a pitch, and present it to the team. Multiple pitches can be created and forwarded to the betting table.
- The Betting phase
After having a bundle of pitches, that usually sums up to more than six weeks per team, we held a meeting — the betting table — where we select which of the shaped work is in better condition and makes us more enthusiastic. Therefore, there are no other circumstances to validate the plan or get approval, and nobody else can jump in afterward to interfere or interrupt the scheduled work.
Our betting table consists of the CEO, the COO, the Product Manager, and the Head of Engineering. Each one must read the pitches and get ready for the meeting in advance. During the meeting, we bet on the pitch content, deciding which ones should advance or not. Pitches are discarded when presenting a lack of research, or if its solutions do not show signs of delivering something valuable.
- The pre-Building phase (not included in the Shape Up guide)
After the betting table and before handing over the responsibility, we felt the need to add a set of requirements that clarify the solution. Even if this step is not included in the original guide, we found it was an easy way to convert the pitch result into a common language, that everyone — from business to technical positions — can understand.
To do this, we take the principles of behavior-driven development (BDD), a software engineering process that suggests the specification of how an application should behave, in a simple user-focused language. Someone from the Engineering team starts by creating the User Stories and specify the behavior using the gherkin Given-When-Then syntax. Each scenario serves as a guideline for the proposed solution and can be altered, to some degree, by the building team.
An example of a scenario, using the BDD approach, taken from our requirements:
Feature: As a User, I want to see a list of stages and events (steps) so that I can have an overview of the main steps of an algorithm
Scenario: Access the list of stages
Given I am seeing an algorithm on the pathway viewer
And I have a menu with a list of stages
When I expand the menu
Then the list must expand horizontally
And I must be able to see the description of the steps in full
Scenario: Expand a stage in the list
Given I am seeing an algorithm on the pathway viewer
And I have a menu with a list of stages
When I select a specific stage in the list
Then that item on the list must expand
And the related content must be revealed
Scenario: Assess already visited steps
Given I am seeing an algorithm on the pathway viewer
And I have a menu with a list of phases
When I navigate to the next action
Then I must see the previous phase marked as completed on the list of steps- The Building phase
Teams of 1 designer and 1 or 2 developers are assigned a project and take full responsibility for building it during the following six weeks. The set of requirements gives each team the first push but its inherently high level requires more exploration to be done. The first days of the cycle tend to be more exploratory and each team breaks down each feature into multiple tasks and assigns an owner for each one. As the team gets oriented, and the scope is detailed enough to proceed, the team starts working on the same requirement.
The idea of working in parallel was the first mental barrier we had to break down. The proposal was to stop the misconception that programmers have to wait until having the finished designs or the finished API. Whether we like it or not, waiting for the final polished mock-ups before starting to implement is more likely a waterfall method than an agile one. In contrast, the frontend developer does not need to wait for pixel-perfect screens to implement something, nor the backend needs to wait before thinking about the data model or creating the API endpoints.
According to our vision, each team can start by defining basic affordances and come up with a simple screen. For instance, using the scenario described and the solution sketched above, it is clear that the app must present the user with a list of steps inside the left panel. Implementing a functional <ul></ul> list is possible without knowing the font size or color of each item. This helps our team to make some decisions, show progress, and present a functional prototype to someone from outside.
The Shape Up guide suggests we track our progress using a hill chart. As with the requirement definition, our usage of agile frameworks made us stick to a project management board. We find it easier and faster to get a snapshot of who is doing what, what dependencies are there, and what is being blocked.
The product board breaks down as the following:
- Ready for development — Contains every identified feature and reported bug. Each feature/user story contains its related BDD scenarios, while every bug contains the steps to reproduce.
- In Development— Represents the work in progress. When someone starts developing a feature or fixing a bug, the corresponding card is moved here.
- Ready for Review — The feature is ready to be tested after being developed. Tests are written, went through code review, and merged into the staging environment.
- Done — Everything worked out just fine in the staging environment and is ready to go live.
- Deployed — Actually, done means deployed, which makes me think that the previous column needs to change its name. This is the final intent. Contains the features that are live in production and changing users’ lives.
Our team goal during this six week period is to keep pushing all these cards forward, or as many as possible. After this, the team may take a break.
- The cool-down.
When the cycle is over we dedicate some time to cool down and let the storm pass. It is not supposed to use this time to finish some features. Instead, the team dedicates this time to complete any unfinished documentation, refactor code, and fixing already known bugs.
What we love
It is an impossible job to develop a high-quality product if you do not know what your users are looking for. The process of researching a problem and shaping its solution helps us to be confident that we are following the right direction. We also increased the sense of individual ownership by making the team responsible for the project and setting an environment where we work close to each other.
Working in parallel helps us to move faster. After having something that works, the designer can have a closer look at it and understand how to make it pixel-perfect, and discuss with the frontend if a specific solution is worth the effort. This approach reduces the number of final designs that were being produced but not implemented due to lack of programming time and freed up more user research time.
What we are still learning
Our main difficulties are related to maintaining the focus during the six weeks and not extending that period. We are still learning how to say no to interruptions and how to protect the building cycle from outside events.
Final Thoughts
Don’t get me wrong: I’m not trying to prove that one framework is better than another. Each team has its own culture and the process is highly influenced by people. In the end, being agile is a mindset and we must strive to find our own way to maximize our tools and people, aiming to ship the most valuable products.
