A Public Sector DevOps Story

A few years ago, several of my clients were engaged with “Agile” & “DevOps” projects with public sector Ministries.  Both my clients were 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; they just needed to prove DevOps.  Worse yet, while Development and Operations were lead by a few Managers who did not entirely 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 a citizen (client) facing.

Wow, this was going to be a bit of a challenge, a small 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.  I started the journey with an assessment and created a glossary of terms and definitions because many words like Agile and DevOps are overloaded.  I hosted individual, small team and group interviews, which provided excellent candid feedback.  Fear was apparent, and a few of the consultants were not happy;  resistance was building from some, who would have to likely learn new skills and perhaps were unsure of their future.  SCRUM had made its way into a few projects; however utterly failed, resulting in the only SCRUM Master not involved in these IT projects or engaging with us. . The challenge was that there were no other Scrum Masters involved in the IT projects or a foundation of Agile practice in place.  Regardless we pressed on with getting the Project Teams, Developers and Operations aligned with the Disciplined DevOps’ mindset with specific goals that bring value to IT and their stakeholders.  The team agreed that Agile was complimentary and a great foundation for DevOps.  However, Agile was failing.   This opened up the need for a little Discipline.  Thus I brought Mark Lines, the co-founder of Disciplined Agile, to teach a DA class here in Victoria and help many practitioners or interested teams, struggling with Agile and DevOps.

A Disciplined Mindset is key

Several of the team from IT attended the training class in coordination with the consulting firm I contracted with, my agency was kind enough to provide the location and send some of their consultants as well.  I was very excited and appreciative that my Sponsor, the IT Operations Manager, supported the training.  Several Developers and a Product Owner came along to the workshop. Unfortunately, none of the Managers or Operations decided to go, which was, of course not ideal.  After the training, my colleagues in the Ministry were blown away, they could see 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 an agile team however, we noticed that we had no one representing the Operations Team.  This surely cannot be a DevOps project without operations?

Be Flexible

How ironic is that many “so-called-agile experts” either want rigid processes or disregard any governance or critical processes when applying agility or DevOps?  These so-called experts or “masters” say follow the Agile Manifesto to the letter with the 19-page scrum guide, even if it was written 20 years ago and not pragmatic for your situation?  Following a limited SCRUM process by focusing on building software by developers, excluding Operations, Architecture, and other key Agile Members (stakeholders), always means “scrum-but” or “scrum-fall.”   A project, especially when requirements are developed iteratively with only a Product Owner, Scrum Master, and a Developer role, may build software faster; however, it was not enough value on this client’s site and was not compatible with DevOps. Thus it was tough to help people who wanted to implement DevOps understand that the path is continual learning, not a prescriptive approach or dogma. It’s a blended group of expertise, not just developers.  As the Coach, I also needed to learn flexibility, better conflict resolution and win hearts and minds. The project had limited time to ensure value was realized, and we also were constrained with the realization that most of the team were available part-time and pulled into other work outside of the project, often. Measuring the impact while working with their Managers to avoid these constraints was a key aspect to success. This required flexibility on everyone inside and outside the project to avoid task switching or new work over a six-week commitment (three sprints of two weeks). This approach also meant “starting where we are” by coaching each of the roles such as Scrum Master / Team Lead, Team Members, and supporting casts of Data Architects and SME. Context counted by stepping up as the Product Owner role and coach a new Product Owner.  I also needed to communicate better, be patient with an un-ideal situation and stay focused on value; building in small batches, the team wins and celebrate the successes no matter how little the value may seem at the time.  This resulted in an enthusiastic, supportive and principle of “being awesome” group of team members.  For example, the team wanted to try test-first development and eventually progress to test-driven development, implement automation, create pipelines and other strategic goals while focused on tactical team goals.  None in the team lost sight that one of our primary goals included a potentially consumable product in six weeks. This meant that changes were needed where Operations and those in the data center needed weeks of planning and could be stopped beyond our control anytime.  The stakes were high, the enthusiasm grew. After the project kick-off goals (Inception) and a sprint, we reached a business vision and architecture vision, passing a key milestone and reaching a consensus with the Sponsor and Stakeholders. This team really wanted to key goals, decisions and options and learn new skills. They read books on TDD over a weekend and pushed the midnight oil to practice what they learned.  This formed a tailored approach to how the team would work project work items in our iteration backlog.  Our Sponsor was also flexible, and he played the role of Product Owner in the past, which was great.  Reflectively, with this new backlog, though, our Sponsor realized he was just too busy to continue the Product Owner role for this piece of work, so he handed it over to me. At the same time, I then coached another new  Product Owner for the future work items in the backlogs and sprints (iterations).  Ultimately, many stakeholders inside and outside of this team were flexible, pragmatic and understood that the team adjusted a way of working even after a sprint, based on reflection and retrospectives.  The flexibility and genuine enthusiasm became a foundation for agility and mindset for DevOps in action!

Collaborate and Share

A DevOps mindset was moving from storming to norming; the next step was to progress to a team that was “performing.” This means that developers, operations and data (domain experts) should collaborate during the project and focused on completing each story and work item as a team, as agreed by the group, in our iteration backlog. A  fundamental mind shift appeared, different from the past. On many past occasions, the default way of working meant that the data folk, if included in the agile project, would be included much later and regarded as another team (silo), or just handed over work items thought to have data architecture near the development completion or what was considered the end of the project. Implementation meant rollbacks were regular, and IT accepted occurrence. Of course, the business and citizens were not happpy.  The mindset shift also meant a change to engage early and continually with operations, a progression from (IT ) usually late engagement and siloed collaboration approach in the past.  A mindset change very similar to the data team, the old way of working often resulted in roadblocks and extended go to live wait times, slowing attaining value for BC citizens.

Applying Agile and a DevOps mindset means a Way of Working (WoW) with clear goals, decisions and options tailored and agreed with the Agile and DevOps Teams.   Opposite to a Command and Control Manager style to a servant leader, leader behaviour rather than manager style and approach.  In this project, the team produced a consumable product well before the internal live rollout.  Additionally, 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.  The Management was happy, and most importantly, the Team was more joyful and enthused; I was thrilled with the results and experience; it taught me a lot!  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, I keep in touch with many folks at this Government Ministry.  This was the beginning (in 2017) and added to my understanding of some of the core values in our book Navigating DevOps through Waterfalls.   Tactec calls Agile+DevOps part of our Agile plus approach a proven part of the journey to business agility.   Our DASM and DASSM courses from PMI will teach you the foundation of what made this DevOps project a success.

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.

Notify of
Inline Feedbacks
View all comments

Add to Waitlist

If a course has an ‘add to waitlist’ button then it is likely booked up. Spots often become available so please fill out the form below. We will be in touch within 24hrs


Born 1965, San Antonio, Texas and lives in Dallas, Tx.
Mr. James, Ronald, Maverick holds a Bachelor of Science in Psychology 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!“