A Public Sector DevOps Story

A few years ago several of my clients were engaged with “Agile” & “DevOps” projects with the a public sector Ministry.  Both my clients was consulting firms providing resources.  Both of the Ministries were under the assumption that Agile was working fast at a “special DevOps Lab location outside of their office”, using a technology called Red Hat’s “OpenShift” and was an IT software development project.  My first engagement was to prove that DevOps worked outside of this new lab and could use the systems already in production with the teams already in place in their existing departments and roles.  Needless to say this was challenging, for example many were not happy with their work environment, some were downright hostile.  Their Managers did not believe that their existing way of working needed to change and that their current processes supported Agile, just needed to prove DevOps.  Worse yet, while Development and Operations were lead by Managers who did not collaborate and frequently disagreed; my Sponsor did not want me to work with the business and services teams as he felt this was Development and Operations focused only and would be complicated by including these other teams who were citizen (client) facing. Wow, this was going to be a bit of a challenge, and we had a budget and about six months to educate, pilot and build an application using DevOps.

No Discipline?

The good news was that I had one person assigned to my team who came from development.  He was a Senior Developer with an open mind and willing to give this DevOps project a try.  One of my first initiatives was to create a glossary of terms and definitions as many words like Agile and DevOps are overloaded.  I setup 1:1 and group interviews which went very well.  However some of the consultants were not happy, there was resistance building by suppliers who would have to likely learn new skills and perhaps were unsure of their future.  Additionally, SCRUM had made its way into a few projects however utterly failed, resulting in the only SCRUM Master not showing up a work, engaging with us and later working with other teams.  Would it came down to was this person was actually pretty rude, and they were not interested in communicating however were very interested in forcing SCRUM and bringing LESS into this Ministry while there was no basic foundation of Agile running in practice, not even SCRUM Masters.  Regardless we pressed on with getting the Project Teams, Developers and Operations aligned with what DevOps is and why it could be beneficial.  Additionally, we agreed that Agile was complimentary and a great foundation for DevOps.  However, Agile was not working and in fact very broken in IT.   What it needed was a little Discipline.  Thus I brought Mark Lines the co-founder of Disciplined Agile to instruct a class here in Victoria to help many folks who were struggling with Agile and DevOps.

A Disciplined Mindset is key

Several folks attended the training class from my client’s site, the consulting firm I worked with was kind enough to provide the location and send some of their folks as well.  I was very excited and appreciative that my Sponsor, the IT Operations Manager was very supportive of the training.  Several Developers and a Product Owner came along to the training, unfortunately, none of the Managers or Operations decided to go which was of course was not ideal.  After the training my colleagues in the Ministry were blown away, they could see that how we worked needed to change, but first, we needed to go back to the grassroots of roles, responsibilities and how our Leaders and Managers engaged with the Staff.  I got the green light to begin a DevOps pilot, as Agile Foundational and DevOps Mindset was now in place.  We had begun the Forming of However, where were the Operations Team?

Be Flexible

How ironic that when applying agility or DevOps people want rigid processes or no processes?  So-called “Agilists,” say follow the Agile Manifesto even if it was written 20 years ago? The SCRUM folks for example say, follow the SCRUM processes which are written for a small group of developers, even when the project is not well understood and you will have more than a developer role in any project, period, always and every time. Thus it was very hard to help people who wanted to implement DevOps understand that the path is continual learning, not a dogma and it’s a blended group of expertise, not just developers.  I also needed to learn flexibility, with limited time to ensure value was realized by pulling a group together who were only part-time on the project, convincing their Managers to support the project by not pulling the resources over a six-week commitment (three sprints of two weeks) and myself coaching each of the roles such as Scrum Master / Team Lead, Team Members, and supporting casts of Data Architects and SMEs, plus being the Product Owner was a lot to take on.  I also needed to communicate better, be patient with an un-ideal situation.  The result was that most of the team is not all, got really enthusiastic.  The team wanted to try test-driven development, automation, pipelines which were awesome, however, we also needed to have a consumable product in six weeks, put on a data center where things needed weeks of planning and could be stopped beyond our control anytime.  The staked were high, however, after the project kick-off goals (Inception) we call it in DA and produced the business and architecture vision (a few pages and day or two or work) the Development team made of Government, Union Staff, read books on TDD over the weekend and were pushing the midnight oil to learn and build it into the project work items in our backlog.  Our Sponsor was also flexible, he played the role of Product Owner in the past however realized he was just too busy to really get into the role for this piece of work so handed it over to me while I then coached another current Product Owner for the final sprint.  Everyone was flexible, pragmatic and understood that we adjusted our way of working even after a sprint, based on reflection and the retrospective.  This was agility in action!

Collaborate and Share

Now that the Pilot using DevOps was in full swing, we needed to ensure that our Developers, Operations and Data experts were engaged from the beginning and throughout the completion of each story.  This was a fundamental mind shift from the past where the Data folks would not be told about project work until (usually) near the end.  Rollbacks were the norm, and the poor Operations folks were struggling many times with business as usual that late engagement with them meant roadblocks to deploy the new software or service.  Using Agile and DevOps mindset, processes with clear goals, decisions and options agreed with the Team and not a task-oriented Manager meant the team was in complete control.  The Team made it happen well before the internal live rollout and Development was given some of the keys to the “Operational” Kingdom as trusting and sharing the workload was part of … you guessed it, “our way of working”.  The Team was happy and wanted to share, so we formed a Community of Practice to continue developing Agile and DevOps skills.  I was happy, the Management was happy and most importantly the Team was more joyful and enthused.  My six and bit month project was completed and we had successfully met the key goals my Sponsor and the CIO planned, measured and agreed on.  On to the next challenge and I do keep in touch with many of the folks I worked with at this Government Ministry.  This was the beginning (in 2017) of my understanding of what I call Agile+.

We Can Help!

We can not force change; however, we can not stop change either. If Business agility is still elusive, needs refinement or is stalling, we at Tactec can help. The true innovation comes from the Art+Science tailored to your organization’s DNA, and your innovation becomes part of your transformation.

Leave a Reply

Your email address will not be published. Required fields are marked *

CIO

Born 1965, San Antonio, Texas and lives in Dallas, Tx.
Mr. James, Ronald, Maverick holds a Bachelor of Science in Phycology at The University of Texas, San Antonio.

Mr. Maverick or JR as many call him is a “slick” but warm and friendly character in our upcoming book on the DevOps Mindset. Mr. Maverick cares about his IT team very much and could charm the socks off a Texas Longhorn. JR is liked by many in his organization; however, he is not as well trusted by the Overlords as he used to be. Mr. Maverick has a group of loyal staff, including Mr. Barker a bit of an opposite to JR. Of course, Mr. Barker would never call him JR; he would only call him Mr. Maverick because well, Mr. Maverick is his boss. Mr. Maverick has held many IT positions in the past, including starting as a Sales Professional for HP and IBM mini and mainframe computers. Over the years he has risen through the ranks to hold this senior position by delivering using high-paid consultants and Big name firms. He also received his promotion from outsourcing to a foreign country where he was able to reduce his IT spend significantly. Recently he has discovered (actually this was made painfully aware to him by the Overlords) that both the Offshore roadmap and use of external consultants was not giving him the value and velocity for his IT department, and he was probably paying more than he bargained for

So, after hearing a talk at a DevOps event by the Agents of Chaos, JR decided to enlist them to help with their digital transformation roadmap and help improve the value, focus and velocity of his department. However, MR. Maverick has a few ideas about agile and DevOps, something he has heard about for a while and read in various CIO magazines; he thinks of these as Marketing terms and something that can be bought. While Mr. Maverick has held on for many years to traditional IT ways of working he has come to the end of his tenure if he doesn’t do something fast and get DevOps working quickly as he has promised to the Overlords providing him with a little more rope to get the transformation completed more quickly as they view his IT department ageing, procrastinators who are not able to keep up with business demands. JR says in his mind, “I will get it done, they don’t call me Maverick for nothing!“