Shape Up, When not to follow the book
It is one of the articles in the Shape Up series.
For Table of Contents go to: How to make Shape Up successful?
How do we learn and obtain mastery?
A widely shared example says that when you do not know how to cook and need to prepare spaghetti, you look for the recipe on the Internet and follow it.
After a few times, you start experimenting with other ingredients. You become better and better. After many years, you cook it in your way and get a Michelin Star.
All frameworks like Scrum or Shape Up are such recipes. It is a basic knowledge set, which will most likely make your team more performant than when working without any idea how to organise.
In applying all of these, you may fall into two extremes.
Extreme of By-The-Book
You may blindly apply all of the rules from the guide without considering your company, teams, current state and constraints. If a single rule is not used, then there is a person to say, “It is not real <methodology/framework> because we do not do X”.
Such an approach will not solve all the problems that you have. Of course, it may solve some of these, but it also will create new ones.
Extreme of Skip-The-Book
On the other hand, you may find yourself over-confident or over-complaining. If you are in a group of people saying, “this is not going to work for our company” or “I know better and this book is stupid” then it is worth finding some counterpart for your discussions. You might be burnt out, tired or biased.
Even if some methodology is stupid, you may likely find some learnings that you might apply in your context.
Common Sense is the right way to go
Your experiences, past failures and successes, feelings, thinking abilities, and colleagues are your common sense. For successful and smooth implementation, you need to:
Imagine how you may work in X weeks/months/years. Call it a vision.
Plan how you and your colleagues can go through this journey to get there. Call it a strategy.
Find your way for experimentation to make it safe to fail.
Success lies in between the two extremes mentioned above. Usually, if you are less experienced, you should follow most of the rules. If you are more experienced, you need to balance your over-confidence and biases, but most likely, you will be able to find a much better path for your company than when blindly following a single guide.
Apply your knowledge from the other areas
If you are getting into a new topic, using your other skills and knowledge within the new methods is natural. That’s fine to fill Shape Up’s framework with different techniques that you find helpful.
Inspiration from Software Developers
A long time ago, there was a joke in the PHP community about Symfony Docs showing how to put all the business and persistence logic inside Controllers.
However, this is not how you use the programming language/framework after you get some experience. You use the documentation but do not apply 100% of the available statements to make your project work. You use your common sense to use only the parts of the language which will help you achieve the desired result. Experienced PHP engineers knew that.
Let’s learn from them and not make management a 0-1 game.
Inspiration from PMBOK book
In 2015, I spent five days learning the theory of Scrum from scratch to pass my PSM exam. I thought Agile rocks and Project Management did not.
Then a few years later, I took a training on PMBOK. The trainer said that PMBOK is not a strict set of rules you must follow. You use it as an encyclopedia. You face a specific challenge, choose tools and then use the book to ensure that you do not forget something that has already been tested thousands of times. Once you read it, it is up to you how you will use it.
Experiences from the Project Management Body of Knowledge might help you in the Shape Up journey.
First steps with Shape Up
We went through the theory of thinking about what we are doing. But where to start?
Basecamp recommends their set of Basic truths for Shape You, and I think they got it right.
My recommendation for 6-20 people big teams would be to start by focusing on:
Explicitly separating Shaping and Building.
Setting the Appetite for the Pitches / Projects.
Using shorter Cycles than 6+2. Like 3+1 or 4+1.
Doing your best in terms of vertical slicing of the scope, planning, early testing and early deployments.
Writing the project plan down and using it.
Doing dailies at least in the first days of the new project.
Respecting the Cooldown.
Once you set this up, you may start filling its frames and improve iteration by iteration.
Do not apply 100% of the book on the very first day.
In a big organisation, you may start with 1 or 2 teams working this way.
In the next article, we will look at Shaping vs Building.