Incremental Steps
When you’re starting a small business, it’s wild and woolly. You need to be nimble, thrifty, creative, energetic. You don’t have much yet, so you’re making do with what you’ve scraped together. You’re zipping around as fast as you can, striving to woo customers and make them happy.
In IT where I spent so many years, the tools that have sprung up to cater to young software companies are designed for that scenario. The software being developed by young IT companies isn’t big (yet), and the companies aren’t big enough to need or want or afford the methods needed to wrangle large complex software systems (yet).
Low-end tools are usually amenable to Agile project development, which advances by incremental amounts, usually about 4 to 6 weeks worth of development at a time. Until Agile came along, the standard approach to developing serious software was slow and deliberate, partly because it involved thinking far enough ahead to avoid inadvertently backing into an intolerable corner. With huge complicated systems, that’s important. The tools to support that aren’t cheap or easy.
With smaller systems, the incremental approach is feasible. It’s good for producing something of modest size that you can sell quickly, which is vital for a young business. The tools need to be inexpensive and compatible with a fast pace.
I’ve been aware of all that, and I’ve used a few of the low-end tools in groups doing very small projects, technical or more often non-technical. But to someone like me, using low-end tools for more than a very small IT system or project can be disconcerting. In some ways many popular low-end tools even look like they go about the work of managing projects backwards. As an example, there is a vast difference between tracking and making decisions about all the issues (bug reports, change requests, enhancement ideas, etc.) in one place versus dispersing them among all the projects done to the software, which can separate them from other issues that may be related.
As long as the software remains small enough, cheap is necessary and popular is pleasant. It isn’t so great when the software and the company get big enough to need more structure, more depth, more capability in the tools they use the manage their products and projects.
Whenever I’ve needed to think about that transition a growing business eventually has to go through, I’ve tended to focus on how much it changes the way the people in the group have to go about their jobs. Maybe that’s my focus because the first time I went through it, the group was small but it was within a big company. The group took a hard look at what was available, chose what seemed to fit best, and management got it. The tools were not cheap. In that group, changing our tools was nowhere near as hard as changing ourselves. The company was big enough to tolerate the huge adaptation we had to make to go from wild and woolly to full-scale proper issue handling and release management in one enormous push. It took several months.
It was a luxurious position to be in.
A modest-sized business is in a much more constrained position when it reaches that transition. Costly tools? No, although moving up from the bargain basement, the price tag still needs to be frugal. Months of upheaval? Not tolerable at all! Incremental steps, please!
Making that transition incrementally is awkward. The transition is happening precisely because the quickest, easiest, cheapest tools can’t do everything that’s needed now. Tools that do what’s needed now are bigger, more complex, and work differently. At some point you have to grit your teeth, move to the new tools and step up the way you do things to make use of those new capabilities you need.
The trick is getting to a size and shape where you can bear the cost of higher-end tools and the disruption of switching to them. The entire period between small with bottom-end tools and fully grown with hefty tools is peculiar and awkward.
It’s where my main work effort is right now. I want to ease the transition by putting in next-level tools in the background. In theory, integration software should be able to feed the new tools from what everyone is accustomed to using now. For a while only management would have something very new to see through improved dashboards, reports, summaries and so on.
In practice, it isn’t coming together as nicely as I hoped.
There are times when incremental steps are not really the easy way to get to where you want to go. This week I’ve found myself looking at my plan and thinking about alternatives. From longstanding experience, I think farther ahead than Agile methods and do all I can to avoid a dead end. If my original plan isn’t practical, we can still get to where we want to go. It simply might not be as neat, tidy and easy a path as I wanted. A shame, but not a catastrophe.