Just about five years ago, I wrote a blog post describing a conversation I had with a friend who had taken on the challenge of integrating 50 separate pieces of IT capability into one cohesive unit. Our conversation touched on the best software development strategy for his circumstance – a circumstance surely shared by others.
I never imagined that this simple post would become one of our most visited pages on the website. Five years on, it seemed appropriate to revisit the original post to see if I would change anything today.
Several of the themes outlined in the previous post readily stand the test of time and would still be my recommendations today:
- Leadership: Finding the right leader for the group is key in successful integration.
- People: Establishing a new culture – aside from just new leadership – including new processes and training.
- IT Governance: Defining what decisions need to be made, who should make them and how they will be made.
However, a number of my recommendations have changed over time.
Five years ago, for an ill-disciplined group such as my friend had assembled, I hesitated to recommend more than an Agile trial. If we had the original conversation today, I would expect over half of the 50 teams to be using or to have had exposure to Agile. From this more substantial knowledge base, I would push harder for him to deploy lean-Agile across the board. I would, perhaps, recommend a greater focus on the use of Kanban to manage task flow than some of the team might have experienced from basic scrum implementations, which would be an adjustment. Overall, the scale of the operation would lead me to recommend SAFe™ for implementing Agile across the enterprise.
In the previous post, I also talked about the importance of integration in the context of the applications being managed and extended by the 50 teams. The rise of lean-Agile has made continuous integration a necessity, and I would expect the volume of interaction between the various groups to have grown from occasional design meetings to frequent, if not daily, discussions about integrations and dependencies.
I also discussed COTS and outsourcing. While most large organizations continue to use COTS systems, in the past five years the line has probably blurred between installed systems and cloud-based systems, which have significant advantages if an organization can reconcile its security needs on such systems. For example, most companies have become accustomed to using salesforce.com or something similar for CRM but not all are ready to put, say, their HR system in the cloud.
Of course, “the cloud” was not mentioned at all in the article five years ago, while now even DCG uses cloud tools internally! Thus today, my recommendation would probably integrate more of a cloud-based approach.
Software development is an ever-changing industry. I’m sure if I revisit these posts again in five years, I will have new recommendations. This exercise outlines the importance of continuously reviewing a software strategy to ensure that it’s still the right choice for today’s environment – successful strategies are ones that easily adapt and change over time.
There have been many changes in the past five years. What important ones should I have included?