I had an interesting discussion today with someone who has, voluntarily, inherited the challenge of integrating over 50 separate “blobs” of IT capability into one (?) cohesive unit. The organization’s decentralized IT strategy has now, under my friends advocacy, become a centralized IT strategy.
Of course, the “blobs” of IT have very little in common with each other apart from a shared employer. Historic technology choices, current practices and levels of effectiveness are all over the place.
We started a conversation this week which focused on just one part of my friends problem - software development. Now, if you have read a few of my postings on this blog, I would hope you recognize that I try to focus on big and small issues but, generally, they are issues that relate to doing better measurement and process improvement.
In this weeks conversation, as I started to make the usual noises about benchmarks and measurement roadmaps and the value of using CMMI concepts as a template for the immediate issues, my friend (a very experienced individual) stopped me in my tracks. “You’re right,” he said, “All of those things are the right things to be talking about, and I believe in them, but how am I going to get to the point where any of that is meaningful? What choices should I be prioritizing now so that I have a functioning software development group in a couple of years that can be measured?”
Hmm. Good Point! Clearly, there needs to be a transition plan for most of the “blobs” but transition to what? Its almost a green field site. What’s the best software development strategy to choose to day?
There are some key questions to be addressed:
- Leadership: We quickly agreed that leadership is important and my friend knows he will need to find the right person to lead the new software development group.
- People - A new culture needs to be established - that is partly a leadership function but other things are needed too such as processes and training. It will also be important to seek input from the existing people - finding out from the staff in the blobs why change is going to be difficult is the first step in overcoming those difficulties -they are in the best position to know where the ticking time bombs are and the booby traps. The most effective way to get this information is to talk to them - My friend will need to find away to delegate this sensitive but time-consuming task.
- COTS and outsourcing: Software development is not a core business function for the organization so why do ANY software development? COTS and outsourcing will be part of the solution but the organization does some unique things that will always require some development/customization/configuration and, as my friends says, “You should never outsource your problems - it doesn’t work.”
- Integration: How many of the applications needs to be integrated versus remaining as stand-alone point solutions? How urgent is integration - do the legacy applications need to be integrated now or can integration wait until a new technology application is ready to replace the legacy?
- Methodologies: Standardizing around a few methodologies will help develop a common culture and vocabulary but which ones? The need to develop discipline and repeatability suggests using more traditional methodologies and one of these should be included but the organization has a lot of customer-facing applications so there may be a role for agile development in the future. My concern would be that, in some ways, agile requires more discipline - I always think of it as being the job-shop versus the factory approach of, say waterfall - and I’m not sure that the organization is ready for agile yet. Perhaps the new software development group could be seeded with a new agile team focused on innovative projects?
- Technologies: .NET/J2EE, COTS/in-house, client-server/web, etc.
In considering our conversation after we parted, I was forced to come back to first principles and think back to my previous experiences of walking into very immature software development shops.
The first thing I focused on in those cases was repeatability. If you are not capable of doing the same thing the same way twice then there is no point in measuring it and no way to implement process improvements (because there is effectively no process). This repeatability has to be achieved for everything - from coding and testing to architectural decisions.
Given that my friend needs to start with repeatable strategic decisions, I would be inclined to borrow a tool from our IT Governance practice and start by defining what decisions need to be made, who makes them (an individual) and how they are made (i.e. who gets input, when are the decisions made, what metrics are needed to inform the decisions, etc.). This list can be extended and reprioritized indefinitely - the most important decisions will always float to the surface.
Another early step would be to take the patient’s temperature - how many of the blobs have evidence of repeatable processes?
As our conversation continues, I’m sure we will touch a number of strategic decision points in the software development arena. Help me out here - what would you prioritize?
