Recently, I have shifted from being just a software developer to being more of a software architect, specifically to work on technologies like containers. I have been fortunate to play a key role in driving the adoption of Docker and OpenShift into our organization for running applications inside of containers. There is still a lot of work to be done, mostly in the areas of training materials, videos, and the processes by which developers will transition into the world of containers.
There is more to this job than that, however. As much as some see this as just the adoption of a few new technologies or some new methods of developing software, I see it more as a transformation of everything we do. I was recently reading a book called Leading the Transformation. It was largely about transforming your teams into Agile teams, and how to scale that into large organizations.
Humans by nature are creatures of habit. They learn habits in their early years that will affect how they do things throughout their entire lives, and the earlier something is learned, the harder it is for it to be unlearned. This is as much true for how people do things at home as it is for how they do things at work, and most people don’t like to be told that they are doing it the wrong way.
Once people see its potential for improving software processes, they became more open to changing their organizations, despite their usual resistance to change. Books are bought, consultants are brought in, and the process of the transformation begins. Some companies find great success with Agile and never look back, but other organizations don't quite get the lift that they had expected, and some even go back to more traditional methods like Waterfall.
So what happened? Why did Agile succeed for some and fail for others? There are many factors involved. One is the size of your organization. Agile works extremely well for small companies or where the leaders at the top are close to the teams they manage. It doesn’t work so well when your organization has a deep reporting structure or is geographically split up.
Another issue is generally who has to make changes when adopting Agile. If it is just your development teams (scrum teams, daily standups, etc), it might work for you, but chances are that there is going to be some friction from above as a leadership that was used to giving all of the requirements up front is forced to break those requirements up into pieces that can be delivered over time. There could also be some friction as the teams will require more interaction with the leadership and end-users as features are developed and feedback is required.
The point is that your whole organization (or at least each unit within the organization that is dedicated to a product or service) needs to be a part of the transformation, and everyone needs to change to some degree how they do things to make it work. I have worked in companies in the past that struggled with the adoption of Agile because they were simply unwilling to or unaware of the need to make changes outside of the development teams.
I am fortunate to be in a position where I can help to lead this transformation within my own organization. In addition to my work on software tools like Docker, I am also writing blogs and documentation that cover many topics including Agile and will guide the business as we transition to more Agile ways of doing things. I look forward to seeing the fruits of this labor in the coming years.