As a software engineer, you know that writing code is only a part of the job. In a more complex development structure, you must define and regularly maintain guidelines for communicating with people in order to make your work more efficient. These sets of directives are referred to as working methodologies. There are a few most popular ones, like Scrum and Kanban, but here I will focus on Shape Up — a methodology framework I have been exposed to recently.
What is Shape Up?
It is a methodology framework introduced by Basecamp. It is advertised as a software development management process that works out of the box, contrary to existing scrum and lean. In its claim, it is designed to increase productivity significantly compared to its counterparts.
How does it work?
The concept is to work in a cross-functional setup in fixed-term build phase cycles of 6 weeks, within which you are given a task to deliver a product. During this time, the developers have the authority to determine the best way to reach the goal. The team members can trim the workload as they wish, but no matter what, they need to deliver something to the market. After 6 weeks, usually, the team enters the cooldown phase, where the developers are supposed to turn away attention from the build phase.
The Shape Up environment consists mainly of Shapers and Builders. The former are senior management and product owners, who decide what needs to be done and on what priority. The latter are developers taking care of execution. What needs to be worked on is agreed upon during the Betting process.
First impression
In my situation, Shape Up was integrated on a company level; honestly, I am not precisely sure why. I can only guess that it was due to the implications regarding the cross-functional nature of the approach or other reasons that I am unaware of.
I immediately noticed that this framework requires central coordination to impose standard behaviour. The methodology rules are laid down in a book/manifesto called Shape Up. Although the principles in the book seem logical at first, they create many unexpected results in practice. Freedom of interpretation in some aspects can only be resolved by imposing rules from top to bottom. Ultimately, the system requires developers to adopt its strict conventions and does not allow participants to seek the solutions that suit them, which is more natural.
How agile is Shape Up?
Let’s first understand what agile means. It is the concept of responding to changes. For the environment to be flexible, it needs to provide an ability to observe, measure and react in unrestrained scope.
It’s challenging to call Shape Up agile. In my opinion, it violates its principles by introducing unnecessary constraints to the decision-making process. Let me elaborate because this so-called freedom of decision is one of Basecamp’s most vital selling points.
Once the project has been planned and the building phase begins, the developers can choose how to complete the project. The team can decide what to cut from the project and how to move forward. However, they do not have control over resource allocation and are limited in resolving many dependencies. This can be a problem because resources and dependencies often hinder the development process.
Instead of relying on reactive measures to address this issue, I noticed that this problem was addressed differently by attempting to identify as many dependencies as possible and anticipating resource needs in the planning phase. This is when the project planners try to anticipate any potential problems, determine the necessary personnel and their availability, and visualise the workflow.
The team also starts its development process by trying to devise a plan to define the unknowns, remove the dependencies and do precise time management based on resources. It is necessary to understand that when the Build phase starts, the environment becomes very rigid with limited options for manoeuvre. On many occasions, we found ourselves being stuck with something that we had no influence on, making the build phase failable at the start. For example, wrong allocation of resources by shapers, dependencies with other simultaneously running projects or different stakeholders, and many more problems that were hard to foresee.
According to Shape Up, detailed planning, including time management, is the answer to successful development (at least, you can make this conclusion from the principles laid down in the book, and I can make it out from my observation). This system completely violates the foundation of an agile environment because it lacks the ability to adapt to changing circumstances and instead focuses excessively on trying to find a one-size-fits-all solution for the planning development process — in my case, across the company.
Lack of empirical approach
Empirical is a process of providing solutions based on observation or experience that disregards theory and stands opposite to logic.
Basecamp relies on the assumption and belief that its out-of-the-box framework will improve working productivity and deliveries — a theoretical system built on logic, which is entirely at odds with the empirical approach. The idea of 6 weekly work cycle has no foundation and is defined out of nowhere. What is the base of the timeframe? How was it measured? I am also unclear on the 2 week cooldown time. I would like to understand more about how the creators of Shape Up arrived at these rules. There are many questions about this methodology that remain unanswered.
Shape Up doesn’t have a built-in empirical mechanism. Unlike scrum, which has frequent in-loop feedback or kanban with statistical process control, it doesn’t have any revision guidelines which tell you how to observe and adjust the process based on findings, but rather its principles prompt forecasting working flow. Shape up is a ready-to-go methodology framework with minimal improvement guidelines — it assumes it works out of the box. The current revision process mentioned is minuscule, and on a high level, so you are very limited in adjusting your setup based on your observations or needs.
I feel that the Shape Up architects have never understood the principles of the agile working environment. The simple yet common knowledge is that most of the problems you get to know only when you face them. I recommend diving into some literature regarding the human decision process and why excessive planning never realises as we expect. This phenomenon is very well described in the book “Undoing Project” by Michael Lewis. If you want to go even deeper, I would recommend looking at the great work of 2 famous Israeli statistical psychologists, Amos Tversky and Daniel Kahneman.
Quality
The strict 6-week cycle puts a lot of pressure on the quality of the final result, which can be damaging.
Typically, there will always be more to do than time allows to complete, so this is addressed by introducing the “Scope hammering” concept, which allows the builders to trim the work to deliver something on time.
Developing software requires time; the 6-week deadline takes away the necessary comfort to pay attention to details. Lack of refinement in the build phase (due to the concept of scope hammering/change) is later not addressed adequately by Shapers and during the betting process, resulting in half-baked features. Shape Up doesn’t address this problem transparently. One way is to polish all the edges in the support cycle or, alternatively, in the cooldown phase. This is a theory, but the reality is usually different. There will never be time to take care of finishing up and polishing the product. One reason is that the technical debt during the feature development grows disproportionally. I strongly feel that Shape Up focuses too much on delivering at any cost and not addressing quality enough. In fact, I couldn’t see it covers the concept of product refinement. In the end, the supposed frequent delivery is less frequent, and the product comes out in not the best shape.
The Product team
You could claim that this is the product’s responsibility to make sure all the edges are refined, but I would strongly argue that the problem lies elsewhere. The Shape up removed “storytelling-like” product development. There is a deep sense of exclusion and detachment in making decisions and a lack of transparency in product planning and execution that should be more consistent and cohesive. The maintenance and refinement in Shape Up are repeatedly pushed to triviality.
However, the biggest splinter in my eye is limiting the POs’ responsibilities. In the end, the PO was one of the main guarantors of the quality of the outcome. With Shape Up, sadly, it is not anymore, and their importance is significantly undermined and pushed into the margin.
The scope hammering/changes
The concept is also very theoretical, and I can’t understand its origin. The idea, as mentioned, is to regularly revise the work with a team and adjust during the build phase to deliver the feature/product on time. More than likely, you will either not be able to change anything because the project scope provided by Shapers cannot be adjusted (I have noticed this a lot) or simply because your team will not adapt quickly enough.
I have witnessed that the revision and adjustment hardly functioned for me, and as I was frequently in a cross-functional setup with different team members, I observed it also barely worked for the rest of us.
Naturally, we were more optimistic about our work than we could process, and when we realised we could fail, it was likely too late to change the scope — if it was possible in the first place.
Cross functional teams
While the idea may be appealing, a lack of understanding of its benefits and disadvantages can quickly backfire.
The semantics of cross-functional teams are deeper than common understanding. If you think more profound about the meaning, you will find that the term is relatively abstract. I would see more sense in organising work around multi-skilled cross-functional developers who can operate on different technologies within the project. Or to consider whether or not the project is cross-functional capable — for example, members within a team can work and deliver independently to each other yet complement one another.
It’s also important to note that the cross-functional approach does not necessarily mean that work should be completed in a non-linear fashion. However, I’ve noticed that many people seem to understand this way. And the Shape Up book doesn’t help in this case, either.
Consecutive vs cross-functional
Integrating the Shape Up approach with a bold line is thoughtless. The idea laid down by Basecamp methodology is to remove unnecessary dependencies and the burden of waste. Needless to say, you will likely have strong dependencies within “cross-functional teams”; and often outside due to the rigid build phase setup.
Should QA be part of the team? In the end, the QA rely on the completed feature to progress. How do you remove the dependency between the back-end providing API and the front-end using it? Because working simultaneously almost doesn’t exist specifically in complex projects, and even minor changes to API could have massive implications for the front end. What do you do with other members who experience a deficit of tasks due to dependencies? The Shape Up book is very theoretical about it.
Software development is usually based on consecutive procedures. And often they are not easy to manage, there is no doubt about it. Unfortunately, there is no simple way to change it. A cross-functional approach can be one way to challenge it, but it is not a guarantee for success.
I tried pretty successful cross-functional software development in one of my previous companies. Firstly, the project was assessed whether or not it could be handled this way, and then the stream work was created with all necessary resources. This way, we made sure to use a cross-functional approach sensibly in the first place, and it was only created on demand with flexible resources.
Side effects
One of the most damaging in Shape Up is the notion of success and failure constantly formulated due to the methodology’s concept. When I worked with Kanban or Scram, we never discussed the idea of failing. Basecamp introduced this absurd concept, and no matter how much you try to prove otherwise, this is how it will mostly work.
Because Shape Up idea is to work in 6-week cycles, it creates an utterly undesired deadline setup. You know how uncomfortable it is and what consequences it has on your state of mind when you continuously challenge the time.
At least in my company, at the end of the build phase, there is always a revision meeting where everyone presents their work and the senior management highlights successful projects and failures.
The book
It wouldn’t be fair if I didn’t mention the book.
Many detailed explanations and proposed approaches (in the form of a case study) are provided. Still, they come across as overly simplistic, very naive, infantile and lacking in logical depth, completely neglecting the fact that most of the time, the working environments are more complex than presented.
To be honest, I am not particularly sure of some of the examples other than to think that the content is deliberately deceiving to make Shape Up look legit.
I will not focus on the details of this book in this article. It would take much more time to describe individual points than I am willing to commit. I may, however, continue writing articles in future, particularly with attention to the content of the Shape Up manifesto.
The bottom line
The art of developing software varies from environment to environment, and its characteristics are defined by underlying technologies, skills and many other factors. Web development is usually more straightforward than developing standalone desktop or mobile projects. Working on an SDK requires a different approach than on consumer applications. That’s why integrating methodologies should be a team-oriented process of research based on observation, not copying and pasting book content on a high level.
I have experienced enormous waste of time, slow delivery, and low-quality outcomes. Shape Up provides a false sense of freedom of decision that, at least in my working environment, is difficult to deal with, and it is all opposite to what was promised.
On the one hand, the problem with Shape Up is that the principles are over-complicated and very unclear, with many open questions that make them easy to interpret in their own way. For example, how you treat issues, maintenance or refinements is unclear. The concept of user stories is removed, so how do you create transparent stories for QA to know what to test? On the other hand, you have a very detailed explanation on the macro level of how you should analyse and organise your project tasks and how to group them sensibly and process them. This is perhaps the most micromanaged guideline I have ever experienced in my professional career.
Ultimately, you are confused about whether you should take Shape Up principles literally or be free to interpret them your way. The latter can easily backfire and open a pandora’s box that all will start crumbling down with an attempt to over-regulate the process, limiting already almost non-existent agility. The moment you start working on a more complex project than the examples in the Shape Up book, all shortcomings come to the surface, doing your work very hard.
If you have a more analytical mind, it shouldn’t take long to know that Shape Up is unsustainable process. All these problems are the outcomes of the methodology principles built based on hypothesis instead of observation. Many, if not most, theoretical concepts are assumed to work, but in reality, they fail miserably.
But can the concept work?
Can you master it? I believe you can improve it, but I doubt you can ever utilise it to become an enjoyable, fruitful solution.
However, if you decide to go ahead with Shape Up, make sure to understand its benefits and disadvantages. I recommend picking up what would interest you and trying to integrate it within your existing methodology. The recommended cross-functional setup should only consider projects that suit them and accept that treating all tasks with a bold line is simply wrong. And remember, the methodology should always fit the developers’ needs, and senior leadership should never force solutions against their will.
I really feel uncomfortable with this framework. In my humble opinion, the methodology is a spinoff project to boost the sale of Basecamp’s flagship product, “Campfire”, — a project management tool that costs $99 a month. Looking at the Shape Up book, you will find Campfire examples on many pages. It is often advertised on its discussion forum as the perfect working tool utilising this methodology. I naturally don’t trust solutions spun off for business purposes — the priorities are just not right.
And, of course, there is nothing wrong with trying to boost sales by promoting products, but it would be more admirable if Basecamp made it transparent because, let’s be honest, Shape Up is hardly up to its shape.
