The technology and solution providers has been in this quest and journey of helping or making enterprises become agile. Most of the conversations I have had with management teams will always bring up a topic to a certain degree that refers to being agile or become more agile. Just like the words innovation and DevOps, the word agility is a loaded terminology. Every organization will look at this differently based on its organizational or enterprise context. Speed of delivery has always been something that management or the executive team wants to have due to market and economic conditions. The challenge is how does one implement agility in an enterprise and not just the I.T. organization.
The usual approach is to start with I.T. particularly when building a technology solution; software and/or infrastructure. However, starting with I.T. does not always mean that agile adoption or agile transformation will work and add value to the organization. It is all about the adoption and transformation context. Most of the time the agile transformation or adoption is challenged if not completely failing. There was even an article written here in LinkedIn titled “Agile does NOT work!“. I agree with some of the frustrations written in the article. However, this tells me that the people particularly the management/leadership did not really support the initiative to make sure it works and adds value to the enterprise. I always say this to anyone I speak with. When you choose to take the path into enterprise agility, you don’t just do cowboy coding. You don’t forget the practices that makes a product fit for use and fit for purpose. The trouble most of the time is that the people almost always fall into the trap of “just doing it”. Product release (software or otherwise) should always be based on the principles of fit for use and fit for purpose that is delivered faster to meet business and market demand. Adrian Wible wrote some sample considerations when working towards enterprise agility. Below is his sample list :
- Legacy system dependencies
- Vendor dependencies
- Disparate technologies requiring different skill sets, resulting in divided teams—e.g., mainframe versus Java, mobile versus web
- Geographical separation of talent (different time zones, or even just different floors)
- Coordination among software, firmware, and hardware teams
- Lack of automated tests (I think this is one important key constraint in achieving agility).
Adrian further talked about potential agile maturity performance indicators to consider when transforming into an agile enterprise or at the minimum an agile I.T. They are as follows:
- Agile requirements maturity. What to build.
- Engineering practice maturity. How to build.
- Testing practice maturity. How and what to validate.
- Deployment maturity. How to release.
I thought some of the contents in his article would help the reader take a step back and re-consider the approach they are taking towards enterprise agility.
What’s your thought?
Software is becoming the main business lever to growth and innovation. This trend speaks not only of the application but also of infrastructure deployment. This created an appetite for enterprises to adopt Agile and DevOps practices to build and deploy software faster and potentially with the desired quality of the project to ensure that the software product is not only fit for use but also fit for purpose. The goal is to enable the enterprise to meet market demands. However, despite all the success stories in the use and adoption of agile practices, larger organizations are finding it challenging to compete in the market place. I have encountered organizations looking for scrum masters to add to their team to help move agility in IT. However, if you would look at these larger organizations, they still are having problems with their software deployment velocity and quality.
I think that the enterprise’s adoption of Agile or DevOps should not only be a grassroot effort but also an executive level commitment. The executives and management need to understand that this practice is an organizational change and this requires a clear understanding that the adoption is driven by the business objectives. I have always presented to my potential employers that I am a business-driven leader because that is what I do. I first try to understand the business goals to understand why a PMO for example is needed by the organization or why DevOps adoption would be a valuable investment for the enterprise. Since this is an organizational change, I would tend to say that this leads to understanding the longer term goals from a transformation perspective. The executives should practice the ITIL continuous service improvement mindset to effectively engage the organization in this journey. The executives and management should support the new delivery model of thinly slicing work and delivering business value based on that slice of work compared to a plan-driven model where you try to forecast when the project will be completed. This is a known mindset change.
Once this is in place, the enterprise would obviously try to invest in automation represented by the DevOps practice we have been hearing recently. This model of integrating working codes into the main software pipeline is a big challenge. I would caution you on this because as IT professionals we have the tendency to just look at “tools” or technology and skip the process and practice part of the venture. This will require cultural shifts in the IT functional groups. Adopting DevOps and Agile practices cannot be done in a short time. Like the old saying goes, “we did not get to this mess in a day”. It was a journey and therefore it requires patience to get through this agile journey as well.
Scaling Agile and DevOps within the IT team would not be easy specially when they have been operating in a functional model and does not look at the IT value from an end-to-end service model. We need to have a good understanding of the Agile and DevOps principles and accept that this is a solution to the shortcoming of the traditional work practices we have in our environment. Change management is one of the areas that will be impacted by this new work new model. When doing Agile, I would encourage that you look at the business results you are hoping to achieve and not focus on just the “team”. The other area that will seriously be affected by this is the project portfolio management domain. It has to shift from looking at projects to looking at enterprise business backlogs that is aiming to give business value or increase revenue through the incremental and iterative delivery of these backlog items. I am not saying that you will have a panacea but at least you will have better alternatives to the impediments you currently have at hand.
What do you think?