Last year I read through all of the 37 Signals books on working better. If you’re not familiar, 37 Signals are the creators of the amazing project management software Basecamp and released the Ruby on Rails framework developed for that product.
One of the lessons that really stuck with me from the book Rework was the idea that planning is guessing. The authors emphasize the further out you go, the less accurate your predictions will be. Even going out more than a few weeks you pretty much lose all ability to accurately predict anything, especially in software engineering.
This leads into the engineering process they have spent the last couple decades working out and have kindly shared with the world. It’s known as Shape-Up and breaks your “planning” into six week chunks, where the product folks will scope out a feature and assign it an “appetite”, or how long they would like to spend on the feature.
The biggest thing I love about their idea of scoping? Fat marker diagramming. Basically, this means you define a feature just enough to get the main idea and what the outcome should be without prescribing the manner in which you do it. A quick diagram being drawn with a fat marker gives you just enough information to do the feature without allowing the engineer and designer to get hung up on some idea that wasn’t actually important anyway.
After doing all the scope work and listing out what they want out of the feature, this is picked up by a pair of engineers (usually a designer and software engineer) and they start work on the feature. As they progress, if they encounter issues they can pare down features in order to make the feature within the “appetite.” If the feature is unable to be completed within the six week cycle, the feature is dropped and cannot be picked up again until it is rescoped; no sooner than the cycle after next. This prevents sinking effort into projects that can slowly grow in scope while never being released.
The big feature I like about this is that it removes the need for those “daily standups” and other constant status checking that so many middle managers and project management folks feel is necessary. By clearly stating the outcome desired and trusting the engineers to make good choices on a feature, you free the creativity and increase the satisfaction of those doing the work. Because, at the end of the day, software engineering is more of a creative pursuit than a pure science, especially when it comes to the products we sell.
If you’re looking for more information on what I’ve talked about, there are a couple links below. The first one is to the books site for 37 Signals, list all of the books that they have published over the years. The second is a direct link to the Shape-Up book that describes in much more detail the processes I just mentioned.
37Signals Books: https://37signals.com/books/
Shape-Up: https://basecamp.com/shapeup