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!