“Go big or go home” was first used as an advertising slogan in the 1990s to sell oversized Harley Davidson exhaust pipes. I can imagine the words said with a Texan drawl, bragging about having the biggest, meanest, noisiest Harley ever!
It’s since come to mean that one should do a thing to its fullest, or not at all. In the case of IT systems, we have many examples of Go Big. Many bad examples.
Big, ambitious implementations, involving lots of people, lots of money, and estimated in years, that exceed budgets by orders of magnitude in terms of cost and time.
Over and over, I hear of implementations planned around one final big go-live at the end of the project. There’s usually a nod to some prioritising – most teams have a phased approach, where phase one is most of the system, and then phase two and three are the few items that the team convinced the users they could do without upfront. Phase two and three seldom get done.
Go Big, when applied to IT projects, has a pretty dismal record.
There are a number of explanations for our lemming-like dash to destruction with over-ambitious projects. The one I’d like to focus on is the very real difficulty of breaking big problems down into little, more manageable ones.
But first, a word from our sponsor: Agile. If you follow Agile principles, you’d release often, in small iterations, prioritising by the value of a specific piece of software to the users.
A simple concept, that’s surprisingly difficult in practice. The millions of words written on the subject of Agile, beyond the original Manifesto from 2001, prove that the development community is still very much battling with the implementation of these straightforward principles.
Smaller, smaller, smaller
In these millions of words and the many, many treatises on Agile, I detect a faint, plaintiff murmur underlying them all. The common thread, almost drowned out by the robust ceremonies and practices of Agile, is to please go smaller, smaller, smaller…
Big implementations are too difficult, says Agile, so release more often. Break stories down into scenarios that can be tested, says TDD. Keep your code check-ins small and frequent, says development best practice. Each aspect of Agile is really about working in the small.
What is blocking software developers from achieving the holy grail of smaller everything?
1. Knowledge
All sorts of questions need to be answered to create small pieces of work. When we work in the large, we can leave the details for later. When we work in the small, later is now. We can’t make good decisions around what work can go together unless we have resolved all, or at least most of, the details of the task at hand.
This is tiresome, and often feels like we are slowing down productivity. It’s an old truth that developers like to develop. Deep planning feels like wasted time that could be spent on writing code. The real truth is that the exercise of planning to a lower level of detail is precisely what will save our bacon in the long run.
People often compare building software to building houses. It’s a terrible comparison, because software does not work with such tangible things as bricks and mortar. Software is an exercise in thinking, mainly. However, there is one area where software could do well to learn from the building trade. They have a saying, measure twice, cut once. That’s what detail planning is in software – measure twice. Cut the code only once.
2. Prioritising
All teams need to understand where their piece of work fits. We cannot put our heads down and focus on one tiny item while losing track of the bigger picture. Ideally, teams are guided by a Product Owner, who helps to keep the vision visible, and makes decisions around aligning development to business value.
At this stage, it is worth pausing to consider what we mean by “small”? It is clearly a relative term, and my small will differ from yours. The point is that whatever we pick, we must always strive for even smaller.
If an obvious feature of value can be identified as priority one, we should look at how we can break that feature down into sub-features. Then ask if we can break it down into tasks of a single day each? Do we know enough to break it down to such a fine grain? That is a trick question – to work in the small, the answer must be yes.
3.Dependencies
Tendrils of dependencies are the biggest challenge in breaking work down into small, discrete pieces. We need to tease our piece out of the overall requirements until it stands pure and free!
This will involve compromises. We can alleviate some of the compromises by carefully picking our way through the requirements in the sequence that best allows us to build upon what has already been delivered.
Consider a hypothetical website for customer orders. It has product pages, a registration form for customers, a buy mechanism and a pay mechanism. The business agrees that making our products visible on our new web site has value, with a ‘Call us to Order’ option that simply shows our call centre number. That’s a compromise from business, but it’s also a winning strategy because a sub-feature (view products) can go live, without waiting for a full eCommerce implementation.
What would the outcome look like if the business had decided that registering users was the first step in the buying process, and we should build the customer registration first? I’d say that it’s pretty unlikely that clients will register when there is nothing to buy. I see teams arguing for this kind of approach all too often because they can only see the final big solution, and want to get there in a logical straight line.
Finding pieces of value before you get to the final destination, is more like meandering along a small path, with turns and twists. You may even end up in a different place than you first thought. That’s great, because in system terms it means we have learnt some lessons en route, and were able to adjust accordingly.
Enterprises are consumed with concerns of Scale. How to scale up. Really, we need to scale down. If we can get each task to be as discrete and small as possible, we can easily do many, many such tasks, creating overall productivity at Scale.
To really go big, we need to go a lot smaller.