Shape Up, Planning the execution - How?
It is one of the articles in the Shape Up series.
For Table of Contents, go to: How to make Shape Up successful?
Shape Up, Planning the execution. How to do it?
We spoke about how planning aims to build collaboration towards the goal. Now, we are going to talk about techniques that you can apply. I will try not to repeat what’s written down in original’s Shape Up book, I want to show different perspectives.
After getting a lot of experience in planning, the techniques do not matter anymore. Very experienced people see the current state and the goal, and they magically devise the plan using all these techniques mixed together. They rarely use them by their names.
However, when learning something new, it is a good idea to follow the process described in a tutorial on a specific technique. Recently, Gynveal Coldwind, who has around 20 years of experience in security, has started learning Rust publicly. In the first episode, he began by manually rewriting some open source project's code to his IDE. That shows even such an experienced person, when learning something new, follows a simple learning technique.
I encourage you to do something similar around planning. Take the project or epic you recently delivered and try to re-create the plan for its execution by using all the techniques mentioned below.
After you experiment with all of these, it will become much easier for you to jump between them in the real-life projects you will be working on. Thanks to trying all of them, when using one technique, you will also apply learnings from other ones.
Start with Persona
No matter what we want to deliver. We do it for someone to use. Before we start the planning, it is worth consciously recognising this persona. On the Internet, you can find many tutorials on shaping personas (research-driven ones) or proto-personas (described by us relying on the assumptions).
Below is the simple template I used 5 years ago — you can put name, picture, demographic, needs, opportunities, and pain points. Whatever makes sense to you.
Additionally, you can also map real-life process the persona is going through at work. It can make you realize that your product or feature will cover only a little part of their daily work.
Outcomes over Outputs
When doing the planning, many people often get irritated. The main reason for this is that in the past, they worked in teams that have been building outputs-driven plans, which described the next very detailed activities as a series of technical tasks they had to do.
To overcome it, that’s essential to start planning on the outcomes level. This level of planning will adequately manage your focus and leave us enough space for autonomy and decision-making along the execution of the project.
Starting from outputs is okay if you haven’t done too much planning in the past. But aim to increase the presence of outcomes in your plans.
The outcome is a meaningful change for the persona, stakeholders, or team. It might be a new capability or behaviour unlocked, some risk addressed, some decision made, some problem addressed. Not the technical activity that you do, but the effect of this activity.
Planning techniques
This article is to give you some inspiration. You can ask Google, ChatGPT, or YouTube or check linked materials for more detailed explanations of a specific technique. For each method, I will give you a short visual showing what it looks like, more or less.
Week-by-week checkboxes
Shape Up projects are just a few weeks long. This planning technique assumes that we can split it into smaller pieces and think about how its execution may look week-by-week.
You can do it in Google Docs, Notion, Issue Tracking System or Visual White Board such as Miro or FigJam.
When you use Notion, you could create a database with the list of these checkboxes and use additional columns to add Weeks and Scopes (from the original Shape Up’s) to jump between By Scopes and By Weeks grouping views freely.
Gantt Charts / Timeline
This one is coming from more formal project management techniques. I still often use it to visualise the timelines. Once you do them in an outcomes-based approach, these become useful. However, when planning a new project, it is challenging to build an outcome-based timeline and not get the tendency to build that in an outputs-based way.
Try to draw a timeline for a project you delivered recently. Do not overthink it.
User Story Mapping
There is no better technique than User Story Mapping to help us move from task-based waterfall planning to proper iterative or incremental approach for software delivery.
This technique builds the bridge in discussions between engineers, designers and product managers perfectly well.
It tells you a user journey from left-to-right, and implementation priorities from top-to-bottom.
To read more about it: https://jpattonassociates.com/story-mapping/, but I strongly encourage you to read a book by Jeff Patton, which is linked on this website.
This is my Number 1 pick for most projects.
Event Storming
In my opinion, Event Storming is a little bit over-hyped, but still it is useful in many contexts. It is not really a planning technique but a process mapping or software design technique. It is also perfect technique for analysing how the existing software product works.
Sometimes you may want to create a few event storming boards. Like one to map the solution's current state (as-is) and another one for desired state (to-be). Or a big picture level one at the beginning of the project, and a few little more detailed event storming boards to discuss just a few more complex areas of the final solution.
After building an event storming board, you may use it to create an execution plan on top of it. Just look at the effects of event storming and discuss with team members how you want to make it happen.
To read more, check: https://github.com/mariuszgil/awesome-eventstorming
Free Form White Boarding
This way of planning was more common in the old times when we didn’t know the techniques by their name. And the Internet was not that resourceful.
The team starts drawing on the whiteboard, and they keep discussing the project.
Magically, this process ends up with better understanding what they want to do.
Written Narrative
I do not know if this technique is described anywhere on the Internet, but to me, it makes sense.
Try to write a story about the team going through the project. Describe what they do, how they react to surprises, what they implement, and what they test.
Make your last project a novel.
Architecture Driven Planning
Software engineers like to draw diagrams and write RFCs.
So we may also use diagramming for planning.
After we draw the diagrams of current architecture and the desired architecture of a solution, we may describe the journey from one state to of the architecture to another.
Just keep discussing while looking at the diagram.
Impact Mapping or Mind Mapping
Impact Mapping is a simple visualisation that you can apply to almost everything. There is a book by Gojko Adzic on that topic.
After seeing the visualisation, you can more easily devise a project plan. Sometimes, I like to use font background colours to describe the priorities or statuses of elements on an impact map.
In the original technique, the layers for Actors, Outcomes and Deliverables are specified. You may experiment with the format of an Impact Map as it is described on the Internet, or play around with just a Mind Map.
Event Modeling
This technique comes from the areas of Domain Driven Design, Event Sourcing, Command-Query Responsibility Segregation and Event Storming.
It mixes UI Screens with Triggers, Domain Events, Commands, Read Models, and provides the ability to slice the work.
Its patterns are also influenced by Brandolini’s Picture That Explains Everything.
To learn more go to Adam’s Dmytruk’s website: https://eventmodeling.org/
Value Stream alike
Value Stream Mapping is a technique from lean management and probably the manufacturing industry. I heard years ago about business and software products that most of them lead to the transfer of information or money. Once we spot the information and money flows, we can better understand the reality.
For me, this is an easy-going painting that visualises the actors, systems and flows on the whiteboard. It is a visualisation that helps quickly describe the business to others.
Looking at this diagram, you can start discussing what you will do.
Below, you can see an example that I created 7 years ago. It explains the part of the supply chain in the manufacturing industry.
Backward Planning
It is not actually a planning technique but more like an approach that you can use in all techniques mentioned above.
Set a deadline (date at the end of the appetite) and describe what you want on that day. Then try going backwards from the deadline to the present moment.
It changes the mindset from forward planning, which is: “in a result of Thing A what happens next”?
To backward planning mindset, which is: “Thing C happened, what could cause it to happen?”.
You can experiment with Backward Planning and Forward Planning in most of the abovementioned techniques.
No plan, YOLO (You Only Live Once)
Not everything must be planned. Sometimes, things are simple. However, that’s important not to underestimate the problems that we are about to solve.
Also, not everything in our lives must be well planned. Sometimes we want to go with the flow and have fun. If we and our company can cover its costs, it might be worth going yolo for more open creativity or just for fun.
Basecamp’s approach
The original Shape Up book has chapters on Getting oriented, Get One Piece Done and Map the Scopes. That’s worth reading these articles because they are connected with the planning topic. Sometimes, using Scopes described by them might be the most effective.
However, feel comfortable using your judgment to decide how you want to plan your project because sometimes it is worth not following the book.
Nobody will deliver the project for your team, so it is your job to make a call.
Which technique shall I use?
Sometimes you will pick some technique described above. Or find another one on the Internet, or invent your own one. Sometimes you will mix many of them together.
For example, do Big Picture Event Storming to understand the overall process. Then User Story Mapping to scope the project and plan increments. And then two Event Storming sessions just to understand a few post-its from the User Story Map better. Finish it with drawing Architecture Diagrams and based on them revisit the plan visible on the User Story Map.
On the other hand, do not over-engineer the planning.
There is no golden recipe for it. Because “it all depends”. In the end, having the perfect plan is less important than having a habit of discussing a plan on the team level.
In the next article, we will focus on the most significant change the team can make to make the project successful - early testing and early feedback.