devopsy.kinsta.cloud

Tag: agile methodology

  • Best of 2020: Don’t Do Agile and DevOps by the Book

    Best of 2020: Don’t Do Agile and DevOps by the Book

    As we close out 2020, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the fifth in our series of the Best of 2020.

    In software development, we talk a lot about the importance of Agile and DevOps. Agile aims for rapid releases, positively encourages involvement from customers and other stakeholders and splits work into smaller iterations, releasing as soon as possible. DevOps extends it by introducing cross-functional team collaboration and automation, enabling teams to always have a stable build ready to deploy.

    That’s the short version and there’s a huge range of books and frameworks out there to read so that anyone, anywhere–apparently–can just start doing it. The danger is that if you follow them too closely, processes can actually become too rigid, so you end up losing the agility you’re striving for. I always get suspicious when theories in books are read and regurgitated completely without thinking about the actual situation on the ground. I’d much rather have a conversation, write up our notes, try it out and see how it can be improved.

    Clearly, I’m not saying that you shouldn’t have boundaries and rules. I worked for a company that moved from no processes at all to adopting Agile methodologies. It needed to put in place a framework to guide people in the right direction, particularly initially.

    As companies mature though, they need to look at what works best for their particular situation–otherwise the danger is that common practice masks commonsense. You end up following processes, such as two-weekly reviews, that don’t necessarily match your needs–why wait two weeks for a review, for example, if something obviously needs fixing today? Where did Agile go?

    What Does Agile Mean for You?

    The best place to start is to define Agile for your organization. On the positive side, definitions of Agile are very broad–but the flip side of that is people get confused about what terms actually mean and whether they should be using them.

    For me, Agile is about being able to change the way you work, reflect on things and continuously improve. The biggest goal is to bring in very short feedback loops and be in a position where you can do something when you get that feedback. After all, there’s no point having a quick feedback loop if you can’t adapt or react equally quickly. 

    I’ve deliberately kept this definition high level–it’s important not to mandate exactly how you deliver Agile. For example, we use a variation of Kanban in our team, based on the original methods adopted by Toyota, having switched from a flavor of Scrum. I’ve had people come up to me and say we’re not really doing Kanban properly, as we’re not following every step of it rigorously. That’s not an issue–we’re using it in a way that matches our needs and goals.

    The Components of an Agile Philosophy

    One of the reasons that people follow Agile books and processes is that it’s easier than looking at your culture and mindset. In software, I believe we’re more interested in the output of our minds, rather than the output of our hands. We have bodies, but they’re primarily there to move our minds to meetings. What becomes difficult is if we try and measure productivity by looking at the wrong metrics–essentially focusing on the output of our hands instead of our minds (how many lines of code have you written, for example).

    You need to move away from this and create a culture with four pillars:

     

    • Everyone is committed to constant improvement: Even the best bit of code or greatest process can be improved, so teams need to be open to always try to get better at what they do and how they work (focusing on where improvement will have an impact). It isn’t a negative or an admission that you’re not up to the job. In fact, it’s the exact opposite–wanting to learn and improve is fundamental to Agile, and generally being a good developer. 

     

     

    • Everyone is free to share their ideas: I talked about the need for fast feedback loops, and that extends to everyone being able to give their opinions, without fear or worries about ridicule. There really is no such thing as a bad idea, as it can spur further thoughts that get you to a solution. For sharing to actually work, you need psychological safety in your team–people have to be confident that whatever they say, it won’t be held against them come review time. Forget the “I know best because I’ve been doing it for longer” approach as well. I’ve often seen young inexperienced developers come up with great ideas–because they’re young and inexperienced.

     

     

    • Everyone is encouraged to question everything: Building on the first point, people have to be prepared to constantly review the way they, and the wider organization, works. Why do we do it this way? Is there a better solution? This shouldn’t be a recipe for constantly changing working practices and not getting anything done though. Go back to your original objectives of what you’re trying to achieve and then question whether current methods are the best way of getting you there.

     

     

    • Teams don’t have to follow rigid methods: No one should be forced to work a certain way (that’s the antithesis of Agile). Instead, teams should be encouraged to find the way that works for them. There’s a whole range of Agile methods out there, and the combination you adopt should be focused on your particular needs. That’s where my suspicion of Agile books comes from–for me the perfect read would be one that just fills your brain with thousands of ideas.

     

    Agile is at the heart of efficient, high-quality software development–just don’t risk losing its agility by following processes too slavishly and making everything you do too rigid and inflexible.

    — Dave Rook

  • Transforming the Security Team Into a DevOps Partner

    Transforming the Security Team Into a DevOps Partner

    Securing DevOps environments is an increasingly important concern for chief information security officers (CISOs) and security teams. While developers often recognize security is important, it is not their top priority. More typically, the DevOps team prioritizes delivering new capabilities and features to the business and customers, often as part of a larger digital transformation initiative. And, developers often view security as something that will slow down deployments.

    Security teams usually have limited DevOps knowledge or expertise. Too often the result is that DevOps adoption begins and even takes hold inside an organization before the security team gets involved. Consequently, security vulnerabilities are not always adequately addressed in DevOps environments and can drive unnecessary risk.

    Integrating Security in DevOps

    The priority is for the security team to take the lead in integrating security into the DevOps processes before poor practices become entrenched. But as both teams are often siloed and don’t tend to work collaboratively, how can security teams better engage, energize and collaborate with their DevOps counterparts to strike the right balance? In a nutshell, how can organizations bring their DevOps and security teams into alignment and establish collaboration for stronger overall security?

    There are a few crucial steps to take to achieve true integration of security and DevOps.

    1. Establish the Requisite Skills to Get in the Driver’s Seat. Effective collaboration requires effective communication. While developers write the actual code, it’s important for security teams to gain knowledge about programming languages along with how applications are built, tested and deployed automatically. This will help them have more meaningful discussions and credible conversations. Security professionals can start by learning some of the fundamentals: PowerShell, Python and Rust, as well as how DevOps tools use REST calls and containerization technologies–particularly Docker and Kubernetes.
    2. Make it Easy for Developers to Do the Right Thing. You can’t be the manual cog in their completely automated process. Make it easy for developers to do the right thing by training them in secure coding practices and implementing a self-service model for security capabilities. For example, you could provide security policy as code that can be integrated into the developers’ automated processes.
    3. Establish Effective Ways to Collaborate. Set up formal systems to ensure DevOps practitioners understand security risks and implement good security practices across the organization. Consider how best to deploy security resources into existing or new organizational models and structures. This includes establishing centers of excellence, community leaders, security champions and embedding security team members inside development teams.
    4. Get Developers to Think Like Attackers. Educate DevOps teams on specific attacker tactics, show how sample code modules could expose secrets and provide examples as user stories. For example, “As an attacker, I would scan the organization’s code repositories looking for secrets.” Take the team through a penetration testing exercise or engage a red team to demonstrate how an attacker would compromise a CI/CD pipeline.
    5. Adopt Agile and DevOps Methods. Security should begin utilizing agile and DevOps methods within their own teams, not only to gain a deeper understanding of DevOps methodologies but also to achieve greater efficiency by automating tasks or delivering capabilities in smaller increments more frequently.

    The bottom line is, it is crucial to understand how other enterprises approach secrets management challenges across DevOps and cloud environments. This can help encourage collaboration and help fast-track the security team’s own efforts. Ultimately, this will ensure agility is not just implemented for the sake of innovation, but companies reflect on their processes and prioritize security to make the most of their transformation.

    — Josh Kirkwood

  • Sounding the Death Knell for Agile: Not so Fast!

    Sounding the Death Knell for Agile: Not so Fast!

    Some say DevOps is the next step in Agile’s evolution.

    Software development is changing rapidly; if you don’t change with it, modern development may leave you behind. DevOps connects information technology operations with development and vice versa; this is a big change for the art of software creation. Agile was not designed with this new level of focus on information technology operations in mind, and must change to include this focus to thrive.

    According to Tony Higgins, CTO of Blueprint, the hot new trends that are supposed to replace the methodology actually are extensions of it. DevOps, for example, aims to extend the collaboration happening between development and QA teams to the operations people who are running the production infrastructure. “It’s the next step in the Agile process,” he says.

    Survey data correlates with assertions it is growing in large enterprises even as DevOps is expanding. According to VersionOne’s 2016 State of Agile Report, more than 24 percent of respondents who use the methodology work for organizations with more than 20,000 employees, compared to 21 percent last year.

    Addressing the State of Agile

    Some enterprise software development stakeholders are shifting their sentiments by moving into enterprise Agile from software project-based/development side-only Agile.

    To some, the original creed should be unwavering, even though it addresses only software development and not information technology operations. “In an ISV context, which is where Agile ‘grew up,’ this understanding did really well. But now with [it] making rapid inroads into information technology, the context is very different and, in a nutshell, the manifesto is insufficient,” says Higgins. The needs of information technology operations such as those that DevOps is meeting are driving new frameworks so it also can morph to include a Dev and Ops methodology.

    “Rather than dying, Agile is transitioning from a competitive differentiator to a core competency,” says Higgins. Whether as part of Agile, what the industry calls DevOps or some new methodology, development is accelerating by building new features and innovations in small, rapid, incremental trips through the pipeline; that approach is originally a core concept of Agile. “Industry folks declaring it’s dead don’t realize that businesses have not given up on it; they’re just looking for better ways to do it,” he adds.

    Agile is Growing

    According to Higgins, the methodology isn’t something that just “happened” in 2001 when its manifesto came to into existence. “Software development organizations were practicing and evolving the various principles of Agile all along and the manifesto was really a culminating event that codified it,” Higgins explains.

    The methodology is spreading much like DevOps, appearing in executive groups such as marketing, sales and information technology. “In marketing, they’re time-boxing their work into iterations with tangible outputs/deliverables. You’re seeing regular ‘stand-ups’ happening with the inside sales group. Agile is making fast and strong inroads into information technology, driving tighter collaboration with operations, and enabling faster delivery,” says Higgins. It is proving to be a repeatable business model that applies to every part of the organization that cares to use it.

    Proof it is a core competency lies in the fact that technology must now be able to support it. “Analysis tools that help determine requirements must be able to do so in an Agile environment,” says Higgins.

    Enterprises are approaching the methodology in better ways as organizations are seeing that requirements are keys to its effectiveness. “Requirements often have been overlooked in Agile processes, but recently we have seen research firms (Gartner, Forrester) and the market shift their focus to requirements to improve their deployments,” says Higgins.

    Both Agile and DevOps are useful in extending the collaboration of development and QA not only to operations people but ultimately also to other departments. “Instituting DevOps, continuous integration tools or any type of automated deployments will inherently require collaboration between departments; this must actually extend well beyond just Dev, QA and Ops and to the rest of the business to ensure that end-to-end visibility is achieved and decisions are not made in isolation,” says Higgins.

  • Our Sprint to Agile Success

    Our Sprint to Agile Success

    Adoption of the agile methodology is essential to the success of a DevOps culture. This is not revolutionary, but is an important foundation.

    We view agile as the tool for developers to achieve DevOps. Our team, which is developer-centric, is focusing on the agile piece of the equation moving forward.

    But what happens when you think you have a grasp on the agile methodology but it turns out you were completely wrong?

    A change is needed.

    Getting back to the Agile Manifesto is a great starting point. This is our story of DevOps failure to success by implementing the correct agile methodology.

    Our Perception Was Wrong

    When thinking about the agile methodology, and, to a greater extent, DevOps, open communication is at the core. However, it is not the only thing agile and DevOps is.

    At the beginning, we thought as long as there was open communication we were agile. Seeing as we sat in the same room, this was pretty simple. But we quickly learned that this was not agile, and the revelation was painful.

    As we experienced development bottlenecks and difficulty in defining responsibilities, we knew there needed to be an adjustment in how we viewed the agile process. Also, we had begun adopting projects in areas where we did not have a high level of expertise.

    This is what brought us back to the drawing board.

    Getting back to the basics meant looking at the reason for implementing agile in the first place. For us, it was releasing better software, more often, with fewer updates. In detail, it was looking at how long it took the team to identify and define the need. Then, it was looking at how long it took from problem definition to software release. We consider this one software cycle.

    The reason for implementing agile is to decrease the time it takes to move through one of these cycles, as well as to decrease the number of cycles on any one project. Defining this process to the team is how we brought our software development back to the basics.

    Renewed Focus

    Once there was a renewed focus, it was time to implement a set of tools and processes. The concepts we focused on incorporating are the following:

    • Adoption of sprints
    • Open communication
    • Version tracking
    • Environment of continuous testing
    • Responsibility definition

    None of these are particularly revolutionary, but when implemented effectively, it made a world of difference. Once we defined these five areas of focus, we adopted the daily sprint meeting. This implementation was the core of our transformation into a truly agile environment.

    The Daily Sprint Meeting

    In the developer environment, meetings can be against the team culture, especially in a startup. This is why a meeting needs to be strategic. The daily sprint meeting should have both a question constraint and a time constraint. The result is no dragging meetings.

    The two metrics for the daily sprint meeting are: 1) each team member gets two minutes to speak, and 2) four questions need to be answered. Those are:

    1. What did I accomplish yesterday?
    2. What will I achieve today?
    3. What obstacles do I face to accomplish my projects?
    4. How am I feeling today?

    With a team of five people, this meeting should take 10 minutes at the beginning of each day. The adoption of the daily sprint has helped us achieve a level of focus not possible without it. This focus has produced increased productivity, as well as adopting an effective agile environment.

    The daily sprint meeting is how we successfully implemented a DevOps culture. This has made all the difference within our team.

    About the Author/Logan Rivenes

    LRivenes PictureLogan Rivenes is a Marketing Manager with Datapath.io, specializing in decreasing latency through network traffic optimization for DevOps.
    Twitter: @loganrivenes

    LinkedIn: https://www.linkedin.com/in/logan-rivenes-01a8964a

  • Being Agile is all about controlling the flow

    Being Agile is all about controlling the flow

    For businesses, Agile is the new fashionable initiative as was E-business was in the 2000’s, Six Sigma was in the 90’s and Total Quality Management (TQM) was in the 80’s. If we look back across the spectrum of these initiatives, we need to examine how many of these initiatives met the goals the business was looking for and, more importantly, if they were fully adopted, remembering that many were derailed, did they deliver the value the business was seeking?

    Of course we cannot answer this question with generalities—it’s a spectrum. For some businesses, these initiatives were red herrings, some did not follow through to completion, but certain changes adopted as part of these initiatives had a very positive impact, while others succeeded wildly. It’s a Harvard Business Review case study as to why a business ended up at the point on the spectrum that they did.

    Clearly, one fundamental aspect that is consistent across all these initiatives is the ability for a business to embrace change. In a previous blog, “Cloud Computing, DevOps and Business Velocity,” I addressed the issue of business velocity—the rate at which an organization can embrace a particular disruptive technology change. Underestimating your business’ ability to adopt a new technology or process will most likely have a strong negative impact on the outcome. In a recent conversation with a client, the non-IT business areas has been very successful at adopting lean practices, but IT short-circuited shortly after starting. It didn’t outright fail, but after a strong start, they took a break from which they never started back up. Without a post-mortem, we don’t know why this specific initiative fell flat, but we can intimate that if something is difficult and feels unnatural, we’re more easily able to focus our attention elsewhere—think dieting and exercise programs in your own life.

    This seems to be the decade of Agility. Businesses want to be more dynamic and fluid. They want the organization to be prepared to respond to market changes more quickly, introduce new products faster, and respond to problems that occur more rapidly. To accomplish this goal, the business will have to let go of some of the ways that they do things today. They will have to re-engineer processes to be more compose-able and componentized so that they are less static. For example, a manufacturer goes through a lot of planning to deliver a new product to market. They go through steps for design, prototype, test, source, manufacture and distribute. The entire cycle may take upwards of a year and is highly automated once it reaches the manufacture stage. Tweaking the product between batches would cause  significant delays and pain because the process is static. It effectively amounts to restarting the entire cycle. So, what if they discovered that by simply elongating the body by 2 cm the product was far more useful their intended audience? In this case, agility might equate to being able to complete the design-to-manufacture process faster.

    In the previous example, this latter step of being able to tweak the product is called continuous improvement and is a key element of fostering agility. If a product isn’t selling well in the market, many companies will just abandon the product completely due to the costs associated with making the product viable. The reason being that most manufacturers consider that each product is a project and when it reaches the manufacturing stage it moves under the control of operations. That is, the creative team that includes marketing, finance, and other stakeholders view their position as “completed” with regard to getting that product to market and they then move onto other projects. With this mindset, there’s no room for the group to review the process, think about how it could have been done better and then iterate with the improvements incorporated. Hence, they just keep taking their “this is the way we do it” to the next project.

    Being agile means being able to control the flow. There’s no way to change how products come to market if there’s a culture of accepting finality once a product has reached a certain point in the cycle.

    The other aspect of controlling the flow is managing how products and services enter and exit the development pipeline.  I spend a lot of my time helping IT organizations unlock their potential to deliver by helping them to understand that there’s only so much that can be done to improve managing the work-in-progress (WIP). The only way to make gains beyond a certain point is to enable transparency with those that are responsible for inserting work into the pipeline or who are demanding that work completes and exits the pipeline at a certain time.

    The following two figures express well the reason transparency is a requirement. I believe most people would agree that managing production is a far easier task in Figure 1 than Figure 2. In Figure 1, there is one input and one expected output. Managing WIP for this pipeline is a matter of optimizing just the process for completing that one deliverable. In Figure 2, there are many more variables at work. There could be contention for resources within the pipeline to support the multiple inputs.

    wip

     

     

     

    wip2

     

    Likewise, there may be a request to reprioritize what gets completed when to meet certain business goals. Perhaps a particular report is required urgently to support a key business decision. I personally dealt with this very scenario when the business I was working for years ago was suddenly engaging in acquiring another company. All focus was transferred to producing the needed financial statements and everything else was put on the backlog. In that particular case, the CEO and CFO were the customer, so no one questioned the delays to their projects, but for many IT organizations reprioritization requests are never that clear making it very difficult to manage the control of the flow. Hence, transparency and communication between those consuming the services of the pipeline and those who own the control of the flow of the pipeline is an imperative for agility.

    Like TQM, Six Sigma, and E-Business, Agility will require changes to the fundamental way that a business operates. An analogy of this process can be as benign as a person recovering from knee surgery or as complex as recovering from a stroke depending upon what the business wants to accomplish and how they are organized currently. Along the way, people will most likely be the biggest hurdles to success.

    When change of this magnitude occurs, employees tend to become very myopic of their own situation. To mitigate this risk, it is critical that changes are reviewed with employees prior to change, during implementation and after the change is enacted. Management must gauge if employees are struggling because the complexity of the change or because they personally don’t agree with the change. The former can be overcome with education and support while the latter should be dealt with quickly through removal.

    Businesses can succeed with their Agility initiatives given they identify and mitigate key risk factors prior to starting and are willing to commit to looking critically at the way they have been operating the business. In agile software development, developers are trained to think about ways their code can break and then write unit tests to ensure that the software is sustainable in light of these possibilities. Creating an agile business means looking at ways to ensure sustainability in light of market changes, new competitors, supplier changes, and changing customer demands.

  • Mixed Martial DevOps vs.The Scrum Master

    Mixed Martial DevOps vs.The Scrum Master

    Royce Grace won the most tournaments in UFC history before he retired. With a record of 14 wins, 2 losses, and 2 draws, it’s understandable why he’s considered by some to be the most influential figure in the history of modern MMA. With 100% of his finishes from submissions, he’s undeniably Brazilian Jujitsu royalty. You’d be hard pressed to find anyone familiar with the fighting world that would argue against building a strong base in BJJ while learning to fight. Royce proved that BJJ was the single most effective form of fighting in the early nineties by submitting opponents much larger than him, like Dan Severn, in UFC 4. Severn had just shy of a 100 pound weight advantage on Gracie but ended up getting caught in a triangle choke. I can remember watching the video and trying to figure out how he made him tap like that. All the sudden fighting wasn’t just about kicking and punching anymore, the game had changed forever.

     

    Fast Forward 12 years to UFC when the Master Royce Gracie is to make his return to the octagon. Matt Hughes crumpled him up like a paper napkin. Royce had continued to practice BJJ since his fight with Dan Severn as it was a successful strategy. The mistake he made was investing in a monoculture. Royce kept a razor point on his BJJ, but fighters like Matt Hughes were smart enough to put an edge on all the dull perspectives of their game. Hughes was a well decorated submission wrestler that knew he needed to work on his striking and maintaining his strength and endurance. Ronda Rousey made it clear after her last victory that she’d been working more on her striking too, which makes sense considering she’s already an Olympic medalist in judo.

    At the end of the day it’s a fighter that wins a fight, not the discipline they practice. A well rounded fighter is going to be able to adapt to adversity better than someone that only has nth level experience in a particular area. The same is true for software methodology. A scrum master’s team will consistently be outperformed by a team taking a mixed approach. Not because something is inherently wrong with scrum, but that people get the work done, not the process. A team embracing a diverse approach is more likely to do what works. They will be open to more experimentation to figure out what is successful and to confirm when the current model isn’t working. Sometimes it’s the people not cooperating, but telling them there’s a problem because they’re not fully embracing the methodology is usually wrong. Often enough the methodology is being taken as gospel and is embraced too tightly.

    I both like and understand kanban, but feel scrum has too much convention to adhere to specifically. I checked Google and it seems to agree with me:

    scrumBlur

    scrumis2

    Just to be fair, I checked to see how Google felt about kanban.

    kanbanis

    But Google didn’t seem to treat kanban as harshly.

    kanbanis2

    If you can’t take my word for this maybe you’ll listen to someone else?

    Just the other day Andrew Clay Shafer posted this on Twitter:

    littleidea

    I did ask Andrew to offer an alternative approach if scrum wasn’t going to work, and he directed me to slide 46 of a presentation he did in Pittsburgh for a Ruby User Group (shown below). This slide advocates a mixed approach as well. I agree with everything Andrew encourages there, and can honestly admit I need to dig into XP technical practices a little deeper myself. This will not be an abandonment of current methodology and a complete shift in another direction, but an evaluation to see if I can fill some holes in my game.

    peopleWork

     littleidea46

  • A Critical First Step in Bringing Dev and Ops Together

    A Critical First Step in Bringing Dev and Ops Together

    We all want to deliver excellent software to our customers. We now have a greater awareness than ever before of the interconnectedness of all the activities required to do so. The agile movement started this but it was not until the advent of DevOps that Ops was considered part of the full picture. In this article I will explain an effective first step that agile organizations can take to complete the picture and bring ops more completely into the product development process.

    Delivering excellent software starts with product definition and flows from those initial stories and designs, into dev, verification and testing, into production and then back again in the form of customer feedback and bugs. In reality the feedback paths represent a transitive closure of all activities just mentioned as you can see in the diagram below. Agile recognized the importance of feedback loops in good product development. Agile also realized that for the right information to flow, walls had to be broken down. The motto “Done means tested” arose and indicated that product owners were not done with a story, could not consider it closed, until it had been tested and they had verified it. This represented the integration of PM, development and QA functions. A huge step, but one step too short. Operations was still not viewed as a key part of building excellent software and there was not much insight into the fact that the feedback loop did not stop at testing. DevOps has recognized this shortfall and taken it to its logical conclusion – “Done means in production.”

    Operational Excellence Feedback Loop

    Product development is a cycle, a cycle that operations is a critical part of. In describing how all parts of the cycle can be integrated lets start at the most natural beginning; product definition. Product definition activities produce stories, designs, functional acceptance criteria (A.C.) and prioritization. In this phase we don’t produce all we need for the finished product but just enough to get us going. With popular agile methodologies like Scrum this is ideally not done solely by a product owner but instead in conjunction with dev and test at story grooming meetings, design reviews and sprint planning. In these meetings dev, QA and product communicate and negotiate stories, comment on designs, and flesh out acceptance criteria. In this way the stories, designs and acceptance criteria are improved and everyone gains an understanding of what is being built; they also become invested in it. A story may look something like this (abbreviated):

    Story: Blog administrator can change user roles SO THAT users can be managed effectively

    A.C: Given blog administrator is logged in
    And on a user profile
    When he selects a permission scheme from a permissions drop-down menu
    Then the users permissions are updated and stored in the DB

    This is a great start but it is not enough. If we are to be excellent we must modernize this just a bit and add in some DevOps spice.

    A first step towards bringing ops effectively into the cycle is to include someone responsible for actually operating the software in the story and acceptance criteria grooming sessions, design reviews, and sprint planning meetings. The critical aspect is that when the team negotiates the acceptance criteria associated with a story it will be ops responsibility to ensure we for each story or feature the team adds success and failure metrics, initial alarm values and any operational functionality such as a kill switch that will be needed in order to operate the functionality effectively. So a story will now contain things like the following in the A.C. (acceptance criteria).

    Given operation X fails
    Then the metric operation-x:failed will be sent through the metrics feed

    We will also alter our definition of done to make sure that a story will not be closed until we meet the ops driven acceptance criteria. For example: we can see the metrics we have defined in our A.C. show up on an ops dashboard. There are so many benefits to this such as folks that are unlucky enough to be on on-call will have participated in this story grooming and will know exactly what these metrics mean when they encounter an issue with them for the first time in production. Furthermore, they will know what operational levers they can pull or request to be pulled.

    This first step represents a connection from product definition to dev, to QA, to operations. This connection is perfectly natural and intuitive when you think about it. Being a true DevOps organization and developing operationally excellent products requires more but having connected product definition to operations as we have provides a nice toe hold from which to flesh things out further. Best of luck. If you have any questions leave them as comments and I will respond as best I can.