The folks at Basecamp have written a very interesting book which discuss how they manage projects. “Shape up” is freely available for all to read.

The following is a summary of what is contained there - at least how I understand it.

I will add in my own thoughts concerning this.

Prior to engaging with the content in Shape up, the book presumes the following (or rather, the following is implicit):

Solve a problem

Problems must be solved. If you’re not solving any problems, or are making things more difficult or expensive: then you may as well pack up and go home. You need to constantly assess whether you are on track to solving problems. The problems which most people solve are usually one of the following:

• Making something cheaper,
• Making something faster
• Making something better, or a combination of all of the above.

Here are some places where I have failed in the past:

(1) If you’re adding a new feature: great. Does it require complicated tutorials and explanations? Forget it. This needs to be completely intuitive. If it’s not, then your product doesn’t work. “My users were actually using it incorrectly!” may be your plaintive cry. That might be the case. But your job is to gently guide them down the right path:

(2) Users are not computer experts. They have a set of pre-existing expectations as to how things work. Some may be familiar with “Friend requests” so if you use that concept in your project, and the behaviour is unexpected: then it’s a bug. Use the concepts which they are familiar with to your advantage. “Sending a friend request” should not allow that friend to delete your account (for example).

(3) User Feedback

This is absolutely critical. You need a deep understanding of how users will interact with your product. Here’s something that has helped me immensely.

• You need to SEE for yourselves HOW users interact with your product (via Screenshare or behind their desks). Yes, granted, it’s not a representative data sample, but you will learn A LOT from seeing how they interact with things on the screen. Remember, you will know your product since you made it: But the users will not. It is the user interaction, and expectations, and above all, their problems which must drive the entire process.

Hammer the Scope to fit the resources

• Hammer the scope to fit the time frame. I suppose this is the critical point in the book. Resources are not unlimited. Time and programming ability are all constraints, and wants and desires are gluttonous: people always want more, more and more. Estimate how much an idea is worth, and hammer the time/resources to ensure that it is profitable. It makes no sense spending weeks on adding a feature that doesn’t add anything to the bottom line.

• You can see this in the way people undertake wars. George Mclellan clamoured for more resources, despite having one of the most well equipped and well resourced armies of all time. The Southern generals made do with the resources that they had, and moved swiftly to take the war to the north. Cut your shirt with the cloth that you have.

Hone the scope of a task / project before delegating it

• Make teams full responsible. This seems to be another key tenet of the book. A high level generalist looks into a particular problem, and, as far as practicable, eliminates the key problems and objectives that are standing in the way. Once that is done, and if it all the problem can be feasibly solved: then a very broad task is delegate to a capable team to implement as they see fit. Naturally, the high level manager must have a very good understanding of where projects can fail.

Undertake a full end-to-end test run

• Undertake a full end-to-end test run. In other words, do a full and complete example as early as possible. The hardest part of anything is to get a hello-world up and running. Once that is completed, then you have proven the concept and can add in further complexity to meet your new needs.

Here are where things fail:

• There will be unexpected problems. You will need to have the resilience to solve them in your stride. e.g. I wrote a simple plugin to undertake some material take offs. There were unexpected problems: memory issues. The computer simply could not handle a large number of beams on the project. So I had to go back to the drawing board to solve that problem. Luckily, I had tried to build all the pieces very early on, and had tested it as fully as possible before adding features. Can you imagine if I had spent 2 months building this thing, only to find out that it failed in some critical respect later down the line?

Pull the plug

If a project does not ship at the end of 6 weeks: that’s it. Game over. It does not get an extension. It’s done. Where did it fail? Perhaps it wasn’t scoped or shaped carefully enough? Perhaps there was a rabbit hole that people fell into? That same project is done. If the feature / bug is critical enough, then perhaps it can make its way to the betting table, but reshaped.

The concept of “Shaping”:

Here is a basic question that must be answered before undertaking a project:

• What problem are we trying to solve? Answer this question, and this will inform you of how the problem should be solved.
• What is the benefit vs. cost of solving that particular problem (as you’ve scoped it)? If you’re only going to gain $1 a year but it’s going to cost significantly more, then it makes sense not to undertake that project, or to otherwise find a simpler solution.
• What are the different ways can the problem be solved? Think outside the box and choose the most efficient one. Limiting scope:
• You needn’t solve 100% of the problem. 80% is often good enough, especially if the last 20% is very difficult, or is going to cost a lot of time. It is a mistake I learned the hard way. Don’t try to solve it all.

Here are the key points that Basecamp use:

1. Set boundaries
2. Rough out the elements
3. Address risks and rabbit holes
4. Write the pitch

(1) Set Boundaries

I do not understand this chapter to add something that was not discussed before.

The key points elucidated in this chapter:

• a. Understand a problem: what is it? Why is it a problem?
• b. What is the easiest way to fix the problem given our constraints?
• c. Constrain the solution to the alleged problem to fix your budget. NOT the other way around!
• c. If you don’t understand the problem, or cannot constrain it, then put it on the shelf for a moment.

For example, a basecamp customer wanted a complex set of persmissions. Why? Apparently, an archived file went missing? Why? Because someone archived it without understanding the behaviour. Something which would have taken 6 weeks to implement was solved with a simple: warning upon archiving - all because the problem was better understood.

(2) Rough out the elements

The Basecamp folks use a concept called “Bread boarding”.

• The key point: there are many possible solutions to a problem: you want to come up with as many potential solutions that you can - rough solutions, and secondly, you don’t want to be bogged down in too much detail, but once you start writing out the rough solutions, you will see potential problems / issues that were not originally visible.

• When you are roughing things out, you want to keep in mind general concepts: (i) what the user wants to do, and (ii) where the user goes or will have to go to do that, and finally, (iii) choices / options and information that will be presented to the user. You definitely do not want to be doing wire frames.

Rabbit Holes

Unknown technical problems could derail your project timeline. You’d want to identify them up front, or to solve them up front, as far as is practicable.

Here are some tips:

• From a high level point of view, work through the problem, to see if you can uncover any issues.

• If you see problems, then you will have to solve them before handing them off to someone else.

• Set guidelines on what what is out of bounds: i.e. problems that you DO NOT want others to solve, or even get into.

• Present your rough solution to someone else for their feedback, and input - perhaps you might have made a critical assumption, or are solving the problem in a round about way?

Minimise as much risk as you can.

Writing the pitch

• Communicate things to the team: the ideas must be formed, but you must allow them creativity enough to improve on certain ideas. You can also tell them: DO NOT go down this rabbit hole.

Betting: time limits

• Upper management does not keep an extensive list of to-dos. Those are delegated to departments or individuals.

• Projects ipso facto do not get an extension if they do not meet their time lines. If after 6 weeks, you can’t get it done, then the project is finished. It’s over. This prevents you investing many multiples of your original appetite into a project.

• If you dedicate a team to a time line and projects, then you are not allowed to pull them away from those time lines or projects.

What about bugs?

There is nothing worse, or more annoying, then a manager who focuses on the immediate problem-de-jour, and drops everything and all resources to handle that problem: how can deadlines be met if you’re constantly being reallocated to other tasks? Nothing can ever be done: and the worst part is – you will likely be blamed for not meeting the “deadline”, which you could never meet due to re-prioritisation of resources! Nothing could be worse.

Basecamp deal with it in a few ways:

• If something is mission critical, then they’ll stop to fix it: but rarely are software bugs that critical.

Fix it during a small scheduled down time / bug repair sessions

Developers usually maintain a list of things that they would like fixed. Give them an opportunity to go back and scratch that itch. It will usually not take that long, so they can jam back them all together in one session.

Bet on it

If a bug / feature is that critical, perhaps they can allocate significant resources to it (i.e. a 6 week cycle).

Questions to ask:

(a) Does the problem matter?

• What is the problem we are trying to solve? There are many ways we can skin a cat: is that the best way to skin a cat? Is that the easiest way?

• How will this solution impact other issues? i.e. you might make a fix that affects a small proportion of customers, but perhaps that will put a huge burden on your support team: in that case, is this a problem that is worth solving? Or can it be solved in a different way.

• You needn’t solve the full problem. 50% of the problem is still ok. And usually good enough.

Example: Early on, I used to treat my customers as king, and did whatever they asked of me. After all, I’m solving their problems, right? It’s a good attitude to have, but the customer does not know or care: (i) the time it takes to get a job done vs the benefits that will accrue, and (ii) the impact of that particular solution on the problem to be solved, and on other parts and functions of a system.

My detailer (and boss) wanted a particular solution. It was a very complicated solution, requiring a lot of complex logic, which computers are not apt to solve. I tried to program a computer to solve it, but it was too complicated given the time available. Rather, what I should have done, was to simplify the problem: the computer need not solve all of it. We could still have a person manually input things as required, while still having some significant productivity gains. The pareto rule applies: solving just 20% of a problem may realise 80% of the efficiency gains.

(b) Is the appetite right?

What if someone doesn’t want to spend 6 weeks on a given problem.

The key is to find out exactly WHY that is the case. And then asking: is it worth spending x amount of time to solve it.

(c) Is the solution attractive?

A solution might solve the problem, but it could incur some costs: e.g. buttons on a screen. Real estate is valuable, and once a button goes there, it will be very difficult to remove it without incurring huge costs in support.

(d) People availability

I like the idea of letting your team members choose a project: that way they are a little more committed than a manager ordering someone to do some work.

Handing over responsibility

I agree with the points made here:

• Don’t act like a task master: because you can’t see unforeseen problems. The best person/people to take care of this would be the teams who are implementing the project themselves.

• Done: means testing and deployment within the time alloted. This means your team will have to make some hard scoping decisions.

• There will be hidden problems, lurking, which will need to be solved - these problems are likely not able to be disocvered by an initial scoping.

Get one piece done

(a) ** Build end-to-end** as early as possible: I have long held to the opinion that something - in it’s most simple form: needs to be done from end to end - and ideally tested and deployed. You build something, by first making a very simple (and empty) but working implementation, and then, once it is working, should you then add on layers of complexity. Why?

• You don’t want to build an entire plane, only to find out that you do not have the right fuel to make it fly. You don’t want to find that out on the last day. Ideally, you want to build a very small plane (to minimise your investment costs) and get that plane to fly. And before that, you will want to build and test and most importantly integrate components as early as possible.

• Because things change. When you have something working, you may realise: oops, that’s not what I want. The less you invest in something that is gonna be lost, the better.

Case Study: What do I mean by get something done?

I mean get a mock up done. i.e. For an integration that I was writing, recently: I wanted to get a basic thing started. Of course, it has to be end to end. So I created a test. That forced me to determine an API design in my mind. That forced me to create a class. And to make sure that the test worked: I simply returned true from the method. It all worked, but nothing was done. Now, the time to integrate it in the code base had come. The next step was to add a button, and simply respond with a puts.

What had I actually accomplished? The feature had no functionality, but it had a shape. I did discover a small problem though: I had to require a file in order to get Zeitwerk working.

Once that was done, I proceeded to add some functionality (the very basic functionality). In my case: I wanted to create a bucket. That was done. And it worked well. But not I need to check for validity, and after that got done, I need to add CORS on that bucket.

Bascamp gave the example of confidential data. This means you will have to add in authentication. Did they do that right away? No! They simply hardcoded the password and got things working from end to end, early on. You want to get a dialog working between all the different composite parts.

Starting in the middle: Where should you start?

This is a key point that is being made here: start on the problem that is absolutely critical: start on the thing you’ve never ever done before, that could derail the project; start on the riskiest proposition with the smallest scope.

Once you’ve solved that portion, then the problem is effectively solved:

The way Basecamp tend to do it is:

• it must be small
• it must be core
• it must be novel

Why is this thing important?

Adding user logs in is important, but it’s a solved problem: you know that you can do it. But interacting with a foreign API: that’s something you’ve never done before. Which one should you attempt?

Ideally, you would make a “hello world” attempt at interacting with that API. In doing so you would solve a lot of problems, and address a lot of issues:

(i) credentials (ii) and also: what happens if the request fails? (iii) you will have proven the concept.

But if you did all the work of building a user logins, and after that, then you attempted to do the thing which you’ve never done before: if you fail there, then the entire project will be a failure.

Mapping the scopes

Break off and categorise tasks into mini-projects that can all be completed independently. When they are self-contained, you can take a broad over-all look at the project and see how it is coming along.

Showing progress

Basecamp handles this using the “hill-concept”. Basically, solving problems means that new problems will be discovered along the way - which will need to be fixed. A start of a project might involve: (i) baking a cake - which is easy enough. But once you start looking for recipes, one might realise - oops - they don’t have any icing in the pantry. Now, a decision has to be made: should we allocate more time to run to the shop to get the icing? Or should we change the design of the cake, so that we can make one without icing? The point being is that when you start a task, new tasks will pop up out of nowhere. Most of the problem solving will be handled in understanding it, and confining it to certain areas.

Do the hard tasks first

Work expands to fill the time available for it. There is no point working on a sleek user interface, when the risky stuff - that which you’re not sure of - has not been solved. Solve that first. Eliminate the risk as early as possible. Prove the concept first. You don’t want to struggle with that at the end of your programming cycle.

Once that is discovered, the actual implementation will usually be swift. But how is one to communicate and demonstrate that is not easy. Basecamp draws these milestones on a hill. And shifts those milestones up and down the hill as they progress.

Decide When to Stop

There is a always stuff that you would like to have. Basecamp suggests you consider things from the customer’s point of view. What are they currently having to deal with: and will your problem solve their CURRENT problem? And how well will it solve that problem?

Scope grows like grass

I agree. You gotta allow the people best placed to make those decisions to make those decisions.

• Does it need to be prominent?
• Does the feature need to be flash?
• Is this feature critical?
• Does it cater to your market?
• How many users will face this problem?

Basecamp suggests that you should give your team the autonomy in which to make those decisions and trade offs.

I like to think of the Pareto rule. The 80-20 rule. If with 20 hours of work, you solve 80% of the client’s problem, you are winning. It might not be worth spending 80 hours of work, to fix the remaining 20 hours of your customers’ pain.

Case Studies

Here’s a little project that I am working on. I want to calculate the SHA1 values of files that are dragged and dropped. I want users to see the progress of calculation taking place. Finally, I want to the SHA1 values inputted into an Elm plugin that I am working on.

• Why Elm?

Because I am familiar with it. And secondly, because it affords zero run time errors, which is extremely attractive. You need to write very little tests for it.

• The risks

I am not writing the code myself. I need to get someone else to write the code, and I need to make sure that they understand the task and can deliver. You don’t want someone to spend 100 hours only to realise that the code doesn’t work, or that they are going to deliver something you didn’t want, nor ask for. So I staged it the entire design and prosecution of the project. If you cannot deliver on step 1, then one cannot progress to step 2.

• A huge focus was on end-to-end implementation. I must take a hello-world concept of their code, and make sure it works effectively on my Rails app. Step 1: ensure that the code can deploy. If that is successful, then the biggest pain point/risk is taken care of

&* Secondly, ensure that data can be passed into my elm app. Stub the data. There is no need to even consider Crypto libraries at this stage. If you can stub the data, then you are winning.

…. to be continued.