I hope you have been following the DevOps series of posts. If not, the following is a quick index of the previous posts on the topic:
You May Be Doing DevOps and Not Even Know It
You may be doing DevOps and not even know it – ‘The First Way’
You may be doing DevOps and not even know it – ‘The Second Way’
Today’s post is the fourth in the series and covers the Third Way practices.
‘The Third Way’ is all about creating a culture that nurtures continual experimentation and an understanding that repetition and practice is the prerequisite to mastery. Experimentation involves risk taking and learning from success as well as failures in order to improve the system of work.
The Third Way necessary practices include:
Let’s face it, creating a culture of innovation and risk taking is not on the radar for most ERP teams. If the current application and database development and change processes are working and the business users are satisfied, why change anything. Besides, many teams are simply too busy to even think about innovation. Moreover, taking on additional risk, well, seems risky.
It has been my experience that the main impediment to innovation is time. ERP teams are generally busy teams. There seem to be an endless cycle of user requests, required patches, issues, and upgrades. Not to mention, even if teams have some time for innovation most are not willing to take on additional risk.
The key to creating a culture of innovation and risk taking is having a stable, well-defined and automated process for safely deploying applications and their changes. Our Stat products provide that capability for our customers and save them time in the process. Time to innovate without adding risk.
I joined an ERP team about a decade ago were there was little trust among team members. The developers did not trust the analysts and users to properly define requirements and test their changes. The DBAs did not trust anyone and the end users had little confidence that the ERP team would deploy their application requests timely and once deployed that they would work as expected.
Trust, once lost, is not easily regained. However, having an automated application change and delivery process that reduces cycle times, improves quality, and improves communication and transparency while reducing risk and risk impacts certainly facilitates building a culture of trust.
I was fortunate enough to be able to implement Stat within the first year of joining the before mentioned team. Stat reduced the human errors associated with manual deployments as well as eliminated the need for developers to have privileged access to deploy code to test and production environments. Communication improved significantly among the team and the business users. The resulting transparency and consistency of on time quality delivery of results continued to build trust over time.
I have two phrases I am fond of saying. The first is ‘to be great delegate’. The second, and more appropriate to our topic, is ‘to be great innovate’. Again, the biggest obstacle to innovation is time. How many times have you said or heard a colleague say ‘when I get some time I have a great idea to improve …’.
Time to allocate twenty percent of development and operation cycles to improve processes or concentrate on non-functional requirements should be a natural progression for DevOps teams. The principles and practices of the first two ways naturally give you back more of your time. That is time to improve application security, implement standards, improve code performance, or even have time to see the next great idea to fruition.
I like high school and NCAA sports. Especially football and basketball. I’m not really a big fan of professional sports. I believe the main reason I appreciate student athletes is they are teachable. I have seen a number of good coaches over the years and one thing they all seem to have in common is they encourage and celebrate improvements. I recall one coach in particular. After each game, win or lose, he would gather the players together and call out all the improvements he had seen in the game from the prior week. He would also identify one or two areas they were going to concentrate improving on in next week’s practice. Each player celebrated the improvements but also clapped as enthusiastically for the areas they were going to work on during the upcoming week’s practice.
DevOps is a team too. You win and lose as a team. There should be no blame game when something goes wrong. Rather, as a team, celebrate the improvements in each cycle and identify what needs to be improved in the next cycle.
I would really like to hear where you are on your DevOps journey. Please post to this blog series and share your story and journey. If you would rather keep it private, please Email me directly at firstname.lastname@example.org.