Shape up
Stop running in circles and ship work that matters
The case study
Basecamp was started by for people in the year 2003 after fifteen years of collaborative trials and errors. As they developed software, there were challenges of the project, taking too long to be completed, no time to think strategically about the product and, not featuring outdoor. These challenges made them grow from four people to over fifty people. Their first test of the idea came in 2009 by 2015; they had a reliable team that had gained experience and achieved milestone strides. They had to wait for six years to have an established team. No matter what you are doing, develop trust and patience to succeed. For it will take practice to be elevated to another level.
Introduction
This book is a guide to how we do product development at Basecamp. It’s also a toolbox full of techniques that you can apply in your way to your own process.
Whether you’re a founder, CTO, product manager, designer, or developer, you’re probably here because of some common challenges that all software companies have to face.
Six-week cycle
Basecamp developed a six-week cycle to focus on a higher level of the project entirely. To complete a project, you need to set a period that is not too long or too short and be focused toward completion.
Shaping the work
During shaping up of the project, the book explains that the senior team can shape up the better project while working Parallel to the cycling team. Work division depending on experience matters a lot when handling a project.
Making teams responsible
Different people can be given specified works, and this makes seniors have less work of supervision, and they will get time to shape up better projects that will make the team have clear boundaries and work more freely.
Targeting risk
“At every step of the process, we target a specific risk: the risk of not shipping on time. This book isn’t about the risk of building the wrong thing. Other books can help you with that (we recommend Competing against Luck)”. Ryan indicates that this book is about the risk of not shipping on time rather than product development. There is a bit of content on wrong this, but that is not their focus.
“We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default, it doesn’t get an extension.” Meaning that has a fixed time on a project working bearing in mind that no extension.
“We build one meaningful piece of the work end-to-end early on and then repeat.” Instead of working with many loose parts and hoping that they will join in the end, purpose to work with one main project. Start from scratch without skipping processes, and the outcomes shall be an achievement that needs no repetition.
How this book is organized
The author of the shape-up organized the book into three parts. Part one is about shaping up; that is, the work they carry out on the project before they consider it out for schedule. Part two is about betting, i.e., they select among the proposed project and choose what to do in the period of the next six weeks. Part three is about building that is, bringing together all tools of the project and execution to ensure that the deadline is met.
- Principle of shaping
When shaping work, do it to the right level of abstraction. Not too vague and not too concrete. The diagram below explains it simply.
Words are too abstract.
The existence of something that can be looked at depends on the experience of the team. Minimize a word and focus on the next step of coming up with something tangible that everybody can understand. Similar explanations can be made from different artifacts. This is highly dependable on the designing team.
Properties of shaped work
Shaped work has three features; rough work-simply means unfinished work and requires experts to discover real trade-offs that can emerge. Solved work- still rough and unpolished though all the main elements of the solutions are there and can be understood. Bounded wok- shows the team what not to do, to be specific, and work against time. Some things should be left out to meet deadlines. A working team should choose wisely on which of the three properties they should work on.
Who shapes
Shaping is creative and integrative, design work, strategic work, and a closed-door creative process. Shaping requires more keenness to come up with all the needed solutions to arising problems. For effective outcomes, the team may be divided into two shapers and builders. Consider who should shape and who should build to ensure the six-week cycle is working.
Two tracks
Shaping works is risky hence subdivided to shapers and builders. When builders are working on a project, shapers may be working on what the builders may be working in the future.
Steps to shaping
Shaping involves setting boundaries, roughing out the elements, addressing risks and rabbit holes, and finally writing the pitch.
- Setting boundaries
It is setting an appetite that involves the exciting idea that needs time to be invested. A plan should fit on scheduled time.
Fixed time, variable scope
With fixed time and several projects to handle, what is peripheral and unnecessary is omitted, and the team purpose of deciding what core of the project is. The method of the sprint has been highly ignored.
Good is relative
The amount of time taken when finding a solution and the level of importance it is what can determine judgment of it as ‘good.’ Also, new ideas are not rejected or accepted instantly; they are brought. Accepting them may make you be committed to what you don’t understand. Keep the concept as new information may come and may result in the viewing of the presented idea in a different view.
Watch out for grab bag
Unclear ideas may demand redesigning. When such a thing happens, the best option is to split the project into smaller projects rather than kicking off a file that may finally bring mess to the whole project. (page 19)
Boundaries in place
With the defined boundary of the raw idea, an appetite, and a narrow problem solution, moving to define the elements of solutions.
- Find the element
When finding out elements, ideas should be moved from word to elements of software solutions. Need to move with the right speed, i.e., right people and avoiding unnecessary details. Also, borrow helpful ideas from other related sources. “Working at the right “level of abstraction” not only ensures we move at the right speed, but it also leaves this important room for creativity in the later stages.” The means of creativity that you use may determine the challenge that you are going to face at the next level.
- Risks and Rabbit Roles
There are different categories of risk, according to the book. Well shaped risks have high chances of hitting the budget. The diagram below shows up the relation.
Poorly developed risks that have long-tail indicating a project could consume time and original appetite to complete. See the diagram below.
Looking for the rabbit hole
Go through a use case slowly. From the sketched solution, the user should navigate from start to the end. Any gap available notes and anything missing can be designed. The viability of every part that was solved before is questioned if it requires technical work, assuming how the part fits together, any existence of a design solution that we could not come up with, and any hard decision we should settle in advance so as not to trip up the team.
Shapers consider less about the ultimate design and more about fundamental standards and probability.
Cut back.
Solutions that get the team excited aren’t necessarily cutbacks because the feature is still valuable without them.
Technical expert:
Nothing is impossible in software. Where you are not conversant with inputs, a technical expert who understand the codes may be introduced to save time. Limit your talk on that solution being good given the appetite, so they can partner and keep the project at the intended size and emphasize that the risk may blow up the project. Explaining to experts from scratch to the shaping up process, they will understand the concept, and they may have a way out to simplify or a different method to approach. After working with experts, elements of the solution, patches for potential rabbit holes, and fences around areas declared out of bounds are available. Simple language that all people can understand is used in a form to communicate the boundaries and defining solutions to present the idea at the betting table.
- Write the pitch
Campaigning for all resources, getting broad responses, and hijacking ideas when the time is necessary is crucial when writing up the pitch. While presenting an informed bet, the pitch is highly recommended. The ingredients of the pitch contain problems, appetites, solutions, rabbit holes, and boundaries. Problems are always presented together with solutions. Without a problem, no solution that can be confirmed as best to fit. The solution might seem to be perfect, but the problem may be arising to customers who are unfortunate to fit that product. Demand can be captured by offering a solution that favors all people. So the best problem explanation may have one specific story that indicates why the product does not work. This provides a chance to test fitness against. Appetite prevents talks that will bear no fruits in the pitch. There is the availability of a better solution. Much worry is why to spend a fortnight on appetite and the appearance of the solution. Every problem should have a solution, and both should be able to produce a good bet. Rabbit hole should always be addressed in the simplest way possible. Boundaries define things more apparent when their prices are up to than those of appetite.
- Bets not backlogs
More stack may develop a feeling of lagging even though not. Concepts may become no longer fresh. Implementing new ideas and checking delays may cot more time hindering forward movement towards scheduled time. The team should bet on multiple pitches every six weeks. The priority ideas should be pitched first. These may spread prioritization across the organization, and people get more to do with their priorities and their possible solutions. Essential ideas that are heard multiple times should be kept on for the next cycle.
- Bet six weeks
Six weeks are long enough to wok up to the end of a meaningful project to its completion and short enough to see the starting and ending of a project. Some companies split to two weeks cycles that make projects pile up hence making the whole process frustrating. Working in six-week cycles gives a meaningful project ready for shaping and programming. Long cycles make teams to trade-offs, and the fresh project may not subject them to a slog. Planning should not come during the ending time of a project as the teams are pushing to get work done on time. After six week cycle, two weeks cool down for breathing, meeting when needed, and determining what to do next. Designers and programmers may use this cool-down time to fix bugs, explore new ideas, or try new technical possibilities.
Project teams contain programmer, and a designer may be joined by a QA who does integrate testing in a cycle. These teams may carry small batch or large batch projects small-batch projects may take two weeks while large batch projects take a six-week cycle. The betting table is a meeting held during cool down to deciding what project they will tackle next. Everyone should be familiar with background pitches through advanced reading before the meeting. Knowledge of everyone present in the meeting is known, business priorities and work that have been tackled lately, and these lead to the process of making decisions. No approvals needed after the meeting since higher-ranking persons are present.
The meaning of a bet.
Bet simply means planning. Bets may have a payout, commitments, and maximum period one can lose. The pitch indicates a specific payout that makes a bet worth making. Every hour of a programmer is optimized to attain more significant progress. Bet cap simply means no extension of the period set. Pulling out someone to his task for a day may result in loss of momentum and acceleration. These may take time to build up again. Circuit breakers remove the risk of the project running out of control.
A hard deadline set and bigger chances of not shipping inspire to systematically ask how their design and execution decisions are changing the horizon. Three strategies to deal with bugs are the use of cool down, bringing it on the betting table, and holding bug smash cycles over the holiday. A clean criticize is important with every cycle to achieve managing capacity. In betting tables, issues may arise, staring with those that affect the customer, appetite, time, and availability of the people. After the meeting (betting table), one of the team members announces through writing the next project and its executors.
- Hand over the responsibilities
When handing over the responsibilities, projects are assigned, not tasks. The project is not spat into the smaller task because it should stay whole throughout the process so that the bigger picture of the outcomes is not lost. The team is trusted to work within the boundary of the pitch and implement the pitch using their judgment at their best level. Immediately after the work is done, it is submitted, having all processes done. The announcement on a new feature to customers is made in the next cool down.
Kicking off is done by creating a new basecamp project, adding new members to the team, posting the pitch, and members may be allowed to make kick-off calls to have clarification on issues that ate not evident in the write-up. The first few days may have total silence as the team is figuring out the best starting point. Expectations of progress are minimal at this point.
Imagine versus discovered tasks
Before starting the project, there is an existence of task that you think you need to carry out. They are called imagined tasks. Tasks that pops up when work is in progress are called discovered tasks and are rare to be discovered before the work starts because they are unknown
- Get one piece done
The team should be focused on making something physical and doable at the start. The team should get one scope done, integrating front and backs end before proceeding to the next project. The vertical slices refer to the technology, while horizontal slices refer to the end-user experience. Designers are encouraged to establish affordance at the start so they can give room to programmers to integrate with them. Designers should make the design better later styling that is visible are done at the end of the product, not at the start. The same may apply to back end tasks. A controller may be added that provides the device with forged information or make a wire connection to fasten the flow of information—layer in UI, code, and styling the application in turns. The aim is to have the meaningful project completed in a few numbers of days; hence the team is shown the best track. When choosing what to build first, you should consider the core, finish something small but meaningful, and novel to reduce uncertainty.
- Map the Scopes
Organizing should be carried out using structure not by a person to bring out a visual picture of forwarding steps being made in the project. Determination of the scopes is important since the activities involve developing a product that never existed before. As tasks pop up, they may be classified as scopes, which may indicate the important part of the problem that can be sorted unhampered and within a short period. When scope becomes the subject of the project (domain driven design; ubiquitous language), it makes it simple to say of development at an elevated height than the details at the task level.
Scope mapping
Scope mapping must be drawn using free hands because they are not related to planning. The scope is a dependency on each other. The scope is visible when the team is carrying out real work. Determining if the scope is right, the important areas are not hidden in the details, the conversation about the project flows freely, and new tasks can be freely allocated a space. A scope can also be redrawn when the task inside the scope is unrelated, making it difficult to explain how scope is, when it is not project-specific and when the scope is too big to be finished soon.
There are a few ways that one can deal with tasks and scopes that pops up. Layer cake that shares comparable front and backend code. The surface area can judge layer code, and the backend work is small and uniformly distributed. Icebergs Uwhre anew features that may need fork submission, which could require an ambiguous business approach to get back the correct data. Chowder tasks do not fit in the scope. Make nice-to –have-with; tasks that can be used for improvement to existing functionality.
- Show Progress
It is hard to note achievement only with tasks since they pop up during expansion. To do list also becomes big as the team makes achievements. Estimates for work that a team has never tackled before causing inaccuracy. Estimates are inaccurate, especially for work that the team has never done before. “4 hours, or maybe three days,” isn’t meaningful. When working, consider pushing something unknown to a known destination to discover what it is. When discovery is made, you work downhill to do away with the task. When you place each scope uphill to ensure good approximating of the achievement, the edit-draft appears downhill. Managers can look for work scopes that are slowly to solve the stagnant problem. Stagnant scopes may reflect cases of scopes that have the lowest possibility of being tackled soon; they can be refactored to gain separated scope. Things sliding back downhill should be ignored by ensuring enough implementation before claiming to be on top of the hill. Hills can be used to identify the sequence of work. Handle the unknown at first, i.e., something that you have not built before because it may contain more risk. Any task omitted at the end of the cycle and are known can be done faster as the risk of extending some times and getting it done is less.
- Decide When to Stop
Time is limited compared to the work available. After polishing everything, there is the existence of some questions that may make the team feel the product is not good enough to be released. A point of comparison arises. Baseline having to be known as true customer’s reality is brought as a matter of comparison. The team may trade-off through a circuit breaker.cutting slope by the team must be authorized. The cutting slope should not tamper with quality but should add less capability. The feature that is built must have good qualities that will attract customers. Scope hammering is done by repeatedly banging the scope to fit in the time given. Before scope hammering, some factors are considered; the importance of the new feature, effects of adding the feature, impacts of omitting the feature, existing problems on already building features, features private or possible public outcomes when the feature is omitted, and how to repair failed feature. This act of fixing tasks with- may be considered as an act of scope hammering, and they usually end up not done. When getting an extension of a project, all scopes and tasks must be navigating downhill, and all incomplete tasked must be hammered in nice to have.
Let the storm pass
After shipping new features, negative feedback may be experienced or a request for an extra feature. The workflow may also change due to the added feature, but the decision to do away with it should be firm because of your understandings of reasons to make the change and who it is helping.
Stay debt-free
Stay debt-free is refusing to make any other change in the completed project. Any fresh idea should be allowed and placed on a betting table to compete with everything else to confirm that they are highly important.
Conclusion
Explanation to pull out important pieces from the shape up method is tightly hidden. From the book, content learned are; “Shaped versus unshaped work, designing at the right level of abstraction. Setting appetites instead of estimates. Concepting with breadboards and fat marker sketches. Making voluntary commitments—bets— instead of feeding the machine. Choosing the right cycle length (six weeks). A cool-down period between cycles. Breaking projects apart into scope. Downhill versus uphill work and communicating about unknowns. Scope hammering to separate must-haves from nice-to-haves.”
How to Begin to Shape Up
One six-week experiment: Focus on shaped work, deliberate allocation, and variable scope. Shaping first: Practice shaping to give teams’ precise work to highlight allocation problems. Cycles first: Extend cycle time to provide project teams more room to breathe. Build your muscle: Practice scope hammering and shipping on time to get project teams used to it. Focus on the macro: Focus on what gets shipped, not maximizing people’s allocated time.
How to implement shape up in Basecamp
Basecamp was built to implement a shape up the method and converges all project communication, task management, and documentation in one place. A production strategy team is created. People who are active in shaping, giving feedback on pitches, and those who are involved at the betting table are added to the team. The group is kept small, and the announcement of the bet is made widely elsewhere when a cycle is ready to kick off. Pitches are posted on the message board, and a campfire chat room is used to contribute ideas and coordinate the betting meeting between cycles. The actual betting meeting is conducted over video chat.
Basecamp projects for the cycle projects
A basecamp project for every project in the six-week cycle is created with specific names. Designers and programmers who are working on the project are added. A kick-off message is posted with the pitch for the team’s preference.
To-do list for the scope.
When the team gets oriented, they start working, discovering tasks, and mapping them into scope. In the basement project, the team creates a to-do list for every scope with the project’s name. To do items that comprise the work of design and programming to each is added. The process is repeated as the team discovers new scopes and tasks.
Tracking scopes on the hill chart
When tracking scopes on the hill chart, navigation to the to-do list page for every range and clicking the options menu in the upper right is made. Clicking ‘track on the hill chart’ will display a hill chart at the top of the overall to-dos section of the project, with a dot corresponding to the scope. The process is repeated for every range. Hill chart will show development from unknown to known and do on clicking ‘update.’ when it is necessary to add commentary, the annotation feature is used. Any history of updates to the hill chart is seen in the timestamp, where there is a display of the last update. Any other feature at Basecamp can make it harder to know everything about the project in one place. It combines messages, chats, to-dos, and documents in one interface that is powerful to technical people and east to use for everyone else. Managers, programmers, designers, and QA work together tirelessly on the project.
Adjust to your size
Basic truth vs. specific practices
‘Applying shape up in the company helps to separate the basic truth from the specific practices.’ The first truth is shaping because it set clear boundaries and expectations for everybody involved in the work. Without shape, there may be experiences of a rush to meet deadlines, technical limitations, or resource constraints. Another truth is betting. What to bet on should be well understood, and the period is known. Shaping and betting apply regardless of the size of the organization. Specific practices are scale-dependent.
Small enough to wing it
A team can start with a few numbers of people and still have something to deliver. Communication and making changes in a small team is easier because everyone is on the same page. Although a small team can throw out most of the structures, the six-week cycle may not apply here because one person may be involved in many tasks. The phase of work should still hold even if cycles in not followed or having dedicated people to do the shaping and building.
Big enough to specialize
When the organization grows, there is a need for more departments and specialization. Due to more people, communication becomes a problem, and more time is used in coordination, and things may slip through unattended issues. A big organization may make sense to take on the structure of six-week cycles, cool-downs, and betting tables.
How to begin to shape up
New versus existing products
When shaping, betting, and the building will not work.
Consider R&D mode when working on a new product or entirely new technology. In the r&d phase, build incomplete features to gain confidence with the designer. Bet on exploratory work. Dedicate a team to explore a few features in six weeks. The team should combine shaping and building in a blurry mix. When the team identifies the pillars of an element to be built, flipping from r&d mode is necessary. At this point, work can be separated from shaping from the building, and shaped work can be presented for betting.
There are options for what to start with. One can experiment a one six week cycle, begin with shaping or start with cycles.
Fix shipping first
Get the team in the mode of doing things to the end. Once shipping is possible, start improving shaping process input.
Focus on the result
It is good to focus on the outcome rather than thinking whether the team is appropriately managing its time.
How the reading relates to class discussion
In my view, this reading relates to productivity and rethinking in software engineering class discussion. In the rethinking productivity discussion, we learned about the real aspect of productivity. Productivity is not having the ability to write codes at a faster rate but instead is having the tenacity to write quality codes. Other factors that comprise productivity in software engineering include; teamwork, programming languages, time management, and many other factors. The whole discussion im the ‘shape up’ reading is all about increasing productivity for any given project. Shaping is the pre-work done on projects before they are considered ready for a schedule. The next step from shaping is betting, i.e., choosing the right project to carry on from a list of pitched projects. The last step is building, which is about teamwork, i.e., how the team comes together in integrating design and programming. Why the three steps? The three steps have been designed in such a manner to increase project productivity. The main aim of such an arrangement is to increase productivity, which has been accurately laid out in the reading. Also, class 8720 has all along emphasized the necessity of embracing that as software engineers, we cant make it if we don’t work as teams. Collaboration has also been a great emphasis on most of the class discussions and has been observed as a core necessity in creating an all involving software product. Consequently, in the shaping reading, teamwork and collaboration were discussed as vital in ensuring a successful project shaping. A product is as good as the managing team, a lesson well learned in the class readings and which can be seen taking pre-eminence in the assigned reading.
Another way that the reading relates to the class discussions is through the primary focus on the development of products that matters. Shape up is for product development teams who struggle to ship. With eye-opening insights, the Shape Up reading will help developers break off from practices that don’t work, think more in-depth about the right problems and start shipping on the right products. Consequently, we have held various discussions in class that point to focusing on the critical areas in software development. The discussion in software integration tools focused on how it’s challenging to integrate software development tools. One of the main reasons that make software integration difficult is the lack of proper documentation. Choosing the right programming language was also observed to make software better. Finding the right way to make a quality software can be referred to as shipping. In a recent discussion also, the impact of configuration management was observed as a vital tool for detecting improper software systems configurations that may impede quality performance. The central theme in shape up article puts weight in eliminating every hindrance to the development of quality products through what is correctly referred to as “shipping.” These are only some of the ways that the article relates to class discussions. Still, most importantly, I also learned a variety of new knowledge, as discussed in this summary paper.
It’s about time to stop running in circles and start shipping software work that matters!