devopsy.kinsta.cloud

Author: Dave West

  • Can Agile and DevOps Get Along?

    Can Agile and DevOps Get Along?

    There is a common misconception that Agile and DevOps cannot work together, which does a disservice to everyone in the software development and delivery field. In fact, both approaches can significantly add to the Scrum pillars of transparency, inspection and adaption to better enable product teams to develop, deliver and sustain complex products. Both Agile and DevOps embody great ideas and enthusiasm that can add value to how teams work, ensuring the success of their organization in a world where business is both driven and disrupted by software.

    For businesses to take full advantage of the opportunities presented by Agile and DevOps, both communities—the Agilists and DevOps professionals—need to rectify the misunderstandings between the two approaches that amplify the differences between them. They must understand why these myths permeate and learn how to overcome these barriers so Agile and DevOps can finally play nice in the sandbox.

    Agile and DevOps: The Misunderstandings

    Both Agile and DevOps pursue the desire to deliver value to customers in a more effective way, but from different starting points—Agile with the developer, and DevOps from operations. Their emphasis also varies, leading people to believe that they are different things: Agile emphasizes team interactions, culture and values, while DevOps emphasizes delivery pipelines and flow.

    These apparent differences are further amplified by misunderstandings that do nothing but to pit the two approaches against each other:

    • Some Agilists think all process is bad, while DevOps is steeped in a history of stability through process.
    • DevOps uses tools and automation to increase speed, while some Agilists view tools as unavoidable at best and a distraction at worst.
    • DevOps uses holistic systems to solve problems, while Agile uses people to drive change and discover it through work.

    It is disheartening that these misunderstandings exist because Agile and DevOps share more in common than most realize. For instance, both include faster delivery cycles, smaller increments or releases and use feedback to improve and remove waste and impediments. Both approaches can also influence a cultural shift in an organization that promotes small changes that are easily manageable so they lead to bigger and better business outcomes over time.

    If they are more alike than dissimilar, then what exactly is holding these two methodologies back from getting along?

    Politics, Organizational Silos Widen the Gap

    Organizational changes, such as new hires and managerial moves, etc., attract strong personalities who get recognized for driving change and who get rewarded when those changes produce results. When their success is tied to the success of either their Agile or DevOps program, competing political goals are deemed a threat and lead to confusion:

    • Different tool strategies: How many times do you hear, “The Agile teams use JIRA, but the DevOps teams use Service Now”? These tools and the vendors selling them focus on a change initiative to drive purchases. This makes it even more difficult to integrate Agile and DevOps, as their data and processes are hidden within different tools.
    • Politics rather than value to make decisions: The saying, “It is not what you know, it is who you know,” is not just true in national capitals, but in any organization. Politics is the reality of most organizations and that means that the associated initiatives not only come with baggage of the work, but also with the politics of who is driving them.
    • Increased division and organizational conflict: Ironically, the DevOps and Agile movements call for unification and collaboration between different groups. However, when practiced, they can sometimes lead to even deeper gaps within traditional groups due to their different terminology and ideas.

    Different Cultures

    Agilists consider process to be “emergent” in response to the needs of the situation. This means teams are empowered to make decisions about how they work via a light framework (such as Scrum) and then add any other process they think are needed to achieve more value and faster feedback.

    DevOps traditionally takes a different tack, with a focus on systems thinking with flow models and value streams.

    Despite the culture differences, Agile and DevOps need consistent language and concepts to work together, or else communication breaks down and collaboration suffers. This leads to alienated stakeholders, increased fear and defensive behavior, poor product and service quality, lack of transparency and visibility and, more painstakingly, never getting anything done.

    Scrum Breaks Down the Barriers to Agile and DevOps

    Delivering value to customers through software requires elements from both Agile and DevOps coming together in a comprehensive process that is fluid and enables the teams to work in a dynamic manner. Through Scrum that empowers cross-functional, business-oriented teams to deliver software continuously, work flows seamlessly between all the right stakeholders, in real time.

    However, simply having cross-functional teams in your organization isn’t enough to make sure all involved are working in a holistic way to deliver customer value. Organizations need to make the right decisions about who should be in or out of a team, since different technologies require specialist skills and infrastructure to support it.

    A cross-functional team must have all the competencies needed to accomplish the work without depending on others who are not part of the team, as described in the Scrum Guide, to deliver a working product.

    As technology, market and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily—Scrum teams are highly flexible and adaptive so that they can deliver products of the highest possible value. When misunderstandings are put aside, and people learn to communicate with each other, cross-functional teams comprised of Agilists and DevOps with all the right skills can deliver done software, faster for your organization.

    — Dave West

  • Demystifying Scrum for the Ops Crowd

    Demystifying Scrum for the Ops Crowd

    Scrum is, by far, the most popular way development teams are organized and work. In fact, well over 70 percent of Agile teams around the world use Scrum. But for those unfamiliar with the structure, Scrum may look like a strange collection of rituals and oddly named designations, such as the “Scrum Master.”

    However, behind that collection of ceremonies, roles and rituals, Scrum is a huge opportunity for Operations teams to streamline development and delivery, improve productivity and create a strong sense of team within the group. Not only does Scrum encourage DevOps, but because it is empirical, risk and visibility are first-class citizens.

    Scrum Basics, and More

    For those wondering how to get started, here are eight things that every operations professional needs to know about Scrum:

    1. Scrum is not focused solely on developing software; it’s about delivering software. The Agile Manifesto describes it as “working software” and Scrum describes it as being “Done,” but ultimately, Agile encourages teams to deliver working software to production frequently. With that in mind, it becomes clear that Scrum is not just about software development, but includes everyone involved in delivering working software to customers.
    2. Definition of “Done” is a DevOps artifact. “Done” describes what it means to be finished with a product backlog item (PBI). Ideally, it describes all the steps necessary to release the PBI to production, or highlights the gap between what the Scrum team thinks Done is and Operations’ idea of what it means to be complete with a piece of work. Operations professionals need to get involved in the formation of the definition of Done (DoD) and work with the team to both improve its reach and validate its use.
    3. The increment should be integrated and deployable. In Scum-speak, the increment is the working software the team produces during a Sprint (a set time frame, from start to Done). If multiple Scrum teams are working on the same product, then it is crucial that the increment be integrated across those Scrum teams. And, when I say integrated, I really mean integrated—as in, tested with processes and practices that are consistent with delivery to production. Thus, the increment is “ready to go.” By regularly integrating the increment, many of the problems that historically have plagued Operations are removed, as teams are, by design, forced into falling in sync much earlier in the life cycle.
    4. The Sprint Review is not a phase gate to production. When moving from waterfall to Scrum, many organizations confuse the Sprint Review with a phase gate to move to production. Rather than being a phase gate for production—or the next phase of the process—the Sprint Review is a mechanism for the team and stakeholders to inspect and adapt at the boundary of the sprint. Ideally, the Sprint Review is executed on software that is being used by real users, in production. This increases the value of the review, as the team and stakeholders get to inspect how real people are using the software.
    5. Continuous integration and continuous delivery automate Done. At the heart of Scrum is the idea that teams deliver working software in small batches to better understand the risks, requirements and solution. Adding delivery to continuous integration (CI) ensures they not only are integrating the software, but also formalizing the deployment processes to ensure there are no surprises. This is a great place for Operations to get involved and help ensure that aspect of Done is consistent with how it views delivering software. This might mean additional steps—or at the very least—a better understanding of operational versus development systems.
    6. Scrum is an empirical process which helps reduce risk. The idea of delivering small chunks of functionality to support learning is at the heart of Scrum. Ultimately, Operations cares about risk. By delivering software in small batches, it is possible to surface risks early and mitigate them. By frequently delivering software, Scrum teams demonstrate they understand the processes necessary to deliver software, thus removing friction from traditional release processes. However, all of these benefits are undermined if the team does not use “production ready” deployment processes or include risk as part of their prioritization of what to work on next.
    7. The Scrum Masters are Operations’ friends. The role of the Scrum Master is to both protect the team from outside distractions and help them to identify and remove impediments. To deliver Done, the team needs to work effectively with Operations and thus, the Scrum Master often will be the person who helps build those relationships. By working closely with the Scrum Master, Operations professionals will gain better insight into what the Scrum team will need from them and how they can deliver Done software.
    8. Helping the Product Owner understand risk. The Product Owner (PO) manages the backlog, which is the place where all work exists. This means the PO is prioritizing the backlog and deciding on what should be done next. Normally, this is accomplished by looking at business value and negotiating with the Development team to determine what can be most effectively completed next. Operations has a great understanding of risk and, by working with the product owner, can add that context to the backlog, allowing the PO to make informed decisions and about value and risk.

    Ultimately, Scrum provides a great framework to build bridges between Operations and Development and can act as a catalyst to drive fundamental improvements to the way teams collaborate and deliver business value. However, both sides need to stop hiding behind the “mystery of agile” to avoid each other and embrace the desire to break down things into small chunks, incrementally manage risk and get to repeatable Done software as fast as possible.

    About the Author / Dave West

    west-daveDave West is the product owner at scrum.org. He is a frequent keynote speaker and is a widely published author of articles, along with his acclaimed book, “Head First Object-Oriented Analysis and Design.” He led the development of the Rational Unified Process (RUP) and then worked with Ivar Jacobson running the North American business for IJI. Then managed the software delivery practice at Forrester research where he was VP and research director. Prior to joining Scrum.org he was Chief Product Officer at Tasktop where he was responsible for product management, engineering and architecture. Follow him on Twitter.

    — Dave West