I was first introduced to devops a year and a half ago when I joined the Digital Academy, and I’ve been intrigued with it ever since. I am not a technologist by trade, but the guiding principles of devops are so compelling that I argue anyone with the desire to do government better needs to take a page out of this book. Here are my reflections on what I’ve been learning through developing curriculum for devops, getting to know practitioners in the field, following leaders and reading a ton of IT Revolution books (my favourites being the Unicorn Project , War and Peace and IT, and A Seat at the Table). Building a culture of continuous learning, psychological safety and real business value are the three values and priorities I am intentionally taking with me into 2020.
At the heart, devops is the culture, processes and tools for continuous improvement and delivery. Developers and development teams use this approach to plan, coordinate, test and execute their work in sprints, typically lasting a few weeks from end to end. This contrasts the traditional cycle of code, test and deploy which can take anywhere from weeks to months, an individual developer can code, push that code for testing and QA and production immediate and continuously — hundreds of times a day even — so that any errors are identified immediately and fixed.
It’s akin to the agile way of working and the original agile manifesto, made by and for developers. It has its roots in the textbook Toyota assembly line and the andon cord where every worker had the right (and were indeed expected) to pull the cord when they spot a defect, even stopping the entire assembly line, so that the error can be fixed immediately. It seems counter cultural and counter productive, but this was the key to Toyota’s success for high quality, as they were able to prevent that error for any other car being made. The andon cord was also an example of how shorter “feedback loops” resulted in higher quality work. Overall, this instilled a culture for excellence. In modern day terms, this means no large IT project would be deployed without continuous testing and refinement throughout the process, and not just at the end when so much investment and time has gone that little can be shifted meaningfully. I’ve picked three main components of the devops culture that I am actively trying to live out and I would love to hear your stories.
- Promoting a culture of learning through cross functional teams, T-shaped people
Any DevOps team has developers from across the spectrum, from those who write the code to those who provide QA and everywhere in between. Likewise, for any digitally enabled service to be built, a host of expertise is required from UX to back end systems to data warehouse to marketing to policy and everything in between. There is no reasonable way that any one component can exist without the others, and that one team could contain all or even a few of the expertise required. Having now been on a few truly cross functional teams for specific products, I am now 100% sold on its utility and the amazing way that working in a cross functional team helps create and promote a culture of learning. In the traditional method of project management, or waterfall, where one component hands off the work to another discrete unit, in a linear, logical manner, it would take a long time to see the impact of one change in the system, much less the collective impact of all changes to the system. We’ve all experienced this — in my policy world, this meant passing an enormous batch of program or policy changes to operations, and maybe having done a little testing, but nothing significant enough to truly understand its impacts. By working in cross functional teams with in-house expertise essential to the product, and designing work so that it is chunked out in small incremental at a time (e.g. two week sprints or so), small changes can be made and tested incrementally. Instead of pushing out a huge release, it is pushing out small releases all the time. By working in a cross functional team, shorter feedback loops are created since the required expertise is readily available on the team, resulting in learning and work being done faster.
Moreover, as a team, this means learning about each others’ expertise well enough so you at least understand their function, and the impacts of your work on theirs. It helps to develop ‘T-shaped’ people, who have a deep expertise in one area, but general enough know how in many areas in order to be effective. More and more, this is the model we need to develop. Not having this awareness, and on a deeper level, empathy for others’ constraints and frustrations in their work, including how you can help or hinder, is one of the biggest reasons why teams don’t work well together. I’ve been so thankful to have worked with amazing people who seem to get whatever my frustration is and who actively help to solve my problem. These folks are golden in an organization, and we can help create a culture that enables that since by working together day in and day out, empathy or at least understanding, happens almost organically. It’s when we dehumanize interactions — when we create endless ticketing systems and there is no ownership of each part of our development — that we lose this, to all of our detriment.
2.Creating psychological safety to fail fast and course correct even faster
In the Unicorn Project, the strong culture of physical safety was often highlighted as the reason behind the success of Parts Unlimited. That is, in the plant environment, having a zero tolerance for harm meant that workers felt safe and secure in their jobs, and as a result, performed better. In DevOps, this same culture permeates as work is visible, using tools to track and where code is shared in open repos, and importantly, the immediate impact of code is seen when it is deployed multiple times a day. For most of us today, it is also this same psychological rather than physical safety, that is the challenge. Psychological safety, having the atmosphere of trust and high risk tolerance — allows us to challenge everything without fear of reprimand. This environment is what breeds innovation, but it is important here to distinguish that the goal of failing fast, or better yet, course correct fast, is to learn. It’s not an excuse for poor planning or on the other hand, blindly following processes and rules.
Specifically, staff are able to call out without fear of reprimand, ideas, processes and structures within the organization that are faulty. This is not intended to be a carte blanche for staff but this could vary from raising hesitations or concerns about a specific hiring decision to questioning the priorities and resource allocations set for the year. How many of us have debated whether or not to raise an issue at work, sometimes agonizing for weeks at whether or not by putting up our hand we would risk losing part of our respect or reputation, and even more importantly, if we would even be heard. As a youngish looking woman in the digital space, I struggle with this equation of whether raising a flag (and any changes that may or may not occur) is worth risking the social and political capital that I have painstakingly built over the years. If you are in a similar situation, I encourage you to find allies and a company of wise counsel to support you; if you are in any leadership position, men or women, watch, listen and create space for others to speak up.
3.Doing things only of business value
For too long we have divided IT and business, and structured our interactions as that of client and customer at best, and master and servant at worst. I love the way Mark Schwartz calls this out in War and Peace and IT, and the call to action that all business people need to be ‘IT savvy’ as much as all IT people need to be ‘business savvy’. This is also a note against doing shiny and cool things for their own sake. There is always a time for play and for learning — but the magic happens when IT and business work together on solving problems of real business value, that is, without which the business would fail (and yes government is a type of business too). Again this is where DevOps wins — as an organization and a team, the overarching objectives are set and then small teams using DevOps as the approach seek to meet the challenge.
If we take a hard look at how we spend our time and efforts — for example, do a time study on the percentage of time spent with staff 1:1 versus external engagements versus administrative work, do our efforts reflect our business priorities? Without a clear mission and a ruthless dedication to the cause, too often we can let our schedules fill up with goodness as my colleague Tom often says. Furthermore, do we have the right mix of watchers and doers? More often than not, we in the government have more watches, those who verify check boxes and make sure the dashboards are submitted, than we have people actually making the things. Related, have we simplified our business processes and governance structures so much so that they provide the right approval at the right level (aka in the hierarchy) at the right time?
It is also important to note that if we are really honest, we can let our ego get in the way and seek only to do the things that we like, instead of those activities that the business desperately requires. I equate this to doing housework — just like running your own household there are those activities that are needed, this changes depending on the context, but in any event there are the tasks that are often not given the respect and time of day. Being a servant leader means stepping into those places when necessary.
In summary, I’ve been finding that devops — the mindset, tools and structure in which we work, helps us to provide the kind of world class digital services our citizens expect of us and we of ourselves. I’m excited to continue this journey and also to hear from you: If you are a devops practitioner, what are your greatest challenges and opportunities? If you are intrigued by this approach, would love to hear from you and see how you take your first steps.
