The Oxford English Dictionary defines “evolution” as “the gradual development of plants, animals etc. over many years as they adapt to changes in their environment”.
Interestingly, “transformation” is defined as “a marked change in form, nature or appearance”. It doesn’t mention what triggers a transformation or whether or not the transformation can be sustained.
Evolution is a series of steps necessary for a species to survive in an ever-changing environment. Each step might not be huge but its purpose is far from trivial – survival.
Perhaps it seems a bit extreme to use “survival” in the same sentence as software delivery but successful organisations are those that are capable of reacting quickly to change and that means releasing software to market often and efficiently, without increasing risk exposure – not just as a once-off but in a sustainable manner. Bottom line – organisations that fail to react to change don’t survive. I’ve worked for some of them.
The “evolution” metaphor is well worth considering within delivery teams. While “transformation” seeks to force change on teams, “evolution” recognizes the challenges and impediments that are unique to the organisation and looks to the delivery team for solutions. The evolutionary approach starts with a problem, a tangible business problem, whether it be a drop in revenue, a production outage or new market-driven demands, and it looks to the team to change what they do or how they do it, in order to resolve the problem. These changes might be “minor tweaks” but they’re fuelled by a desire to fix a real business-impacting problem.
With evolution, we look for low-effort but powerful changes – ones that we can implement quickly and cheaply, we go for several small “tweaks” rather than “big bang” and we re-evaluate after each one. One small step for the team, one giant leap for the organization.
What does this look like in reality? It may mean deciding to automate as little as possible rather than “everything”; it may mean tweaking a manual process rather than implementing automation at all; it may mean prioritizing deployment automation over feature development. The quality of the solution depends on the common understanding of the problem by the entire delivery team and open-mindedness in considering solutions.
We at 3WestStreet don’t drive change on our own or enforce “best practice” but we engage with team members so that all stakeholders are working towards a tangible common outcome, one that benefits both the team and the business.
That understanding gives teams an unprecedented level of clarity and enables them to achieve outcomes that are clearly aligned with business drivers.
And, it only gets easier. As we continue to use this approach, the business and technical delivery teams move forward together towards a shared common goal.
We believe so much in the power of evolution that we are re-building our entire company around it. If you’d like to read more about the results our approach has achieved, drop an email to email@example.com.
We’d be happy to talk you through our approach and share a recent client case study with you.