Is your development process about to be eroded?
The following quote from The Economist (Jan 3rd-9th) provides a reasonable analogy for what some development teams are experiencing as once free-flowing technology investment starts to dry up:
For the more curmudgeonly sort of older manager, the current recession is the joyful equivalent of hiding an alarm clock in a sleeping teenager's bedroom. Once again, the touchy-feely management fads that always spring up in times of plenty are being ditched in favour of more brutal command-and-control methods.
The article refers to how the relationship between old-school management and the net generation is shifting back in favour of the former's approach. While it wouldn't be correct to equate "touchy-feely" with "agile", some relationship is apparent.
I think this may ultimately be for our own good: a chance to experience how things might otherwise be done and to see whether our processes are really as perfect as we preach. Even Toyota, often cited by agile evangelists, is (understandably!) struggling, albeit far less than their american counterparts. Similarly, our software development processes will not make us immune from a downturn in business, however responsive they are to change.
As part of the interface between the business and the technology teams, architects may find themselves in an increasingly divisive position. On the one hand they may need to defend the progress (and investment) that has been made in coaching and process change. On the other, they may have to concede that lower-quality, shorter-term thinking may be required in difficult times. In either case, it would seem prudent to be proactively ensuring that your assumptions, requirements and, ultimately, the resultant process and architecture remain appropriate now that the business drivers may be shifting, if they haven't done so already.
Re: Is your development process about to be eroded?
I'm certainly seeing a strong motivation to cut costs, and one approach I'm closely involved with is replacing costly on-shore, on-site developers with managed service equivalents, with a medium term view of paying near / off-shore prices for a similar service.
The first part of this strategy is defining how the existing development team works, formalising the interactions with the stakeholders, and agreeing the desired processes behind those interactions. From this information you can estimate the required effort to provide a particular level of service, and hence price the service.
This end result of this approach is a set of working practices which goes against at least three of the four tenets of the agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
This is not necessarily lower-quality or shorter term, but is perhaps an example of a "more brutal command-and-control" method being introduced with the bank balance in mind.
Re: Is your development process about to be eroded?
Re: Is your development process about to be eroded?
Re: Is your development process about to be eroded?









Kevin has been working with Java for 10 years, in defence research through dot com to investment banking. Currently he works at 

