So, I’ve been trying to get my head around how best to deal with our heterogeneous development environment in an agile way. It’s easy to say a process is agile, much like we used to say software was user friendly. We just slapped a label on it that said User Friendly. Now I think we’re sometimes doing the same with Agile.
So, how do we distil agile down to its core elements. Well, we don’t have to, it’s been done already. I think for where I am, competing priorities are the greatest concern. We’ve always got client jobs going on, in different stages of development. However, we usually try to make sure the developers have one block of work on a day, but one day might be a different job to the next. And we need to consider how we invest our time in planning for the future with new technologies.
Almost every good feature in computer operating systems today, including most features in DOS, Windows, and Windows NT, came from the mind of one hacker or another. Typically the work was not commissioned by a company. It was done as a research project then productized. Without these people, we make no forward progress. – Larry McVoy, The Sourceware Operating System Proposal, 1993.
Our struggle at the moment is finding the right balance between letting the developers have their time to freely investigate a new technology, and doing paid client work. We can’t spend all the time doing study and training, and developers aren’t robots that can churn out code 100% of the time.
One point of view is that research can be done as part of clients’ work. That is, when a client’s job is being quoted or designed we can throw in project time then and there to do the research required to get the job done. I call this the Brave New World way of doing things. The advantage of this is that it’s fully funded research and has a clear end goal and time allocated to the work.
The flip side is having dedicated time not allocated to a particular job where the developers can try out new things that don’t directly lead to a paying client’s job. The advantage here, as in the quote above, is that it tends to lead towards more innovation and discovering unique things that may not have been discovered if the goal had already been chosen. The down side of this, of course, is the cost. It doesn’t directly bring in revenue. Research is a cost, not a profit generator in the short term.
The business person prefers the first way, and the technical the second.
Planning for the long term is expensive, but the investment pays off much later. But how much later? And is it really the domain of a small business to be doing research?
I’m sure if we position research as training, then it would be fine. It might be easier to justify the expense if we had found a training course, the money to send the developer off on it, and off they went for a day or two. We’re not talking about pure research, but about investigating new technology without the pressure of delivering to a client.
So how does this all fit into a agile way of doing things? Well, it doesn’t directly. Agile is about delivering to the customer the best product within the constraints provided. And, although the principles mention
Continuous attention to technical excellence and good design enhances agility.
and
The best architectures, requirements, and designs emerge from self-organizing teams.
We need to think about how we can make those an input to the system rather than as an end product. How can we keep both the business and technical people happy?
