Over the last 5 years, Agile approaches have seen widespread adoption across the US Federal Government. Where real commitment is given to proven Agile frameworks and techniques, programs do see significant improvement in value delivery and speed. But unfortunately often, ‘Agile’ nomenclature is used while perpetuating behaviors that make real improvement impossible, and may actually make the lived experience worse for participants or stakeholders. And where Agile approaches fail, they add to a narrative that real methods won’t work in this environment. Many of the anti-patterns I’ve seen working as a Coach in the Public Sector are rooted in decision-makers clinging to 5 myths about Agile in Government. This talk will explore these 5 myths, where they come from, and some ways out of them.

 
9 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/Structure of the Talk

  1. Start Up (5 mins)
  2. Walk Though of 5 Myths, with Questions (30 mins
  3. Final Questions and Wrap Up (10 mins)

(an older version of this talk is provided as a link)

Spoilers

The 5 Myths to be discussed are:

1) Story Points Have Absolute Meaning

2) Product Owner is a Title (as opposed to a job)

3) More Awareness = More Control

4) We can say, "Teams!" but actually stay just Individuals

5) SAFe saves

Learning Outcome

Participants will leave with the awareness of several institutional anti-patterns that derail Agile teams, and some approaches for overcoming them.

Target Audience

Government-sector Agile pracitioners, Government Executives interested in Agile frameworks, Government Personnel overseeing Agile-based programs

Prerequisites for Attendees

  • Passing familiarity with Agile team frameworks (Scrum, Kanban, etc.)
  • Awareness of some Agile scaling approaches (SAFe, LeSS, etc.)
  • Passing familiarity with how US Government buys IT work
schedule Submitted 11 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • Dr. Patrick McConnell
    By Dr. Patrick McConnell  ~  10 months ago
    reply Reply

    Updated with a link to a prior version of this talk.

  • George Dinwiddie
    By George Dinwiddie  ~  10 months ago
    reply Reply

    I like these aspects of the submission, and they should be retained:

    • I like the premise.

    I think the submission could be improved by:

    • Letting the reviewers know what 5 myths you plan to address. As is, the submission is basically blank.
    • Dr. Patrick McConnell
      By Dr. Patrick McConnell  ~  10 months ago
      reply Reply

      Thanks, George, and good point!

      I've added the Myths to the Session Outline.


  • Richard Cheng
    Richard Cheng
    Principal
    Excella Consulting
    schedule 9 months ago
    Sold Out!
    10 Mins
    Lightning Talk
    Intermediate

    In this lightning talk, we explore the 5 attributes to look for in a ScrumMaster:

    • Knowledge - Deep knowledge in Agile and Scrum
    • Experience - Deep experience with Scrum teams and in Agile environments
    • Coaching - Deep understanding of Coaching concepts and techniques
    • Facilitation - Deep understanding of Facilitation concepts and techniques
    • Servant Leadership - Deep understanding and desire to enable success for the teams and the organization

    From there we look at the ScrumMaster's progression for removing impediments and addressing issues:

    • Did we talk about it in the Retrospective?
    • Did we discuss the impact?
    • Did we identify root causes?
    • Did we come up with solutions?
    • Have we tried the solutions?
    • What were the initial results?
    • What are next steps from here?

    We use the steps above to ensure:

    • Our teams are not making the same mistakes time time after time
    • Our teams are not having the same issues arise time and time again
    • Our teams are not stagnating but rather are getting better over time

    This session will arm session attendees with what to look for in a ScrumMaster and discuss how the SM uses the impediment progression to ensure we have a continuously improving team.

  • Liked Richard Cheng
    keyboard_arrow_down

    Richard Cheng - The Perfect Product Owner!!

    Richard Cheng
    Richard Cheng
    Principal
    Excella Consulting
    schedule 9 months ago
    Sold Out!
    45 Mins
    Tutorial
    Intermediate

    Want to find the perfect Product Owner? It's easy, all you have to do is find one with the time to do the job, the power to make decisions, the knowledge to make smart decisions, the interest in doing the job, and the Vision to build the right product. Easy, right?

    Via a story, the session will start by exploring 5 key attributes of being a Product Owner:

    1. Bandwidth
    2. Power
    3. Knowledge
    4. Interest
    5. Vision

    After that discussion, we do an exercise to identify what a Product Owner does day to day. The debrief will identify the balance a Product Owner must have in working with stakeholders, end users, customers AND working with the Scrum team AND product backlog refinement. We will also touch on client/vendor relationships and identify if the PO should come from the client or the vendor (and how technical should the PO be).

    The session concludes the attendees being given a Product Owner persona scoring template. The attendees can use this template to score their Product Owners and we will discuss how to identify their Product Owners areas of strength and gaps areas.

  • Liked Gene Gotimer
    keyboard_arrow_down

    Gene Gotimer - Building the Pipeline of My Dreams

    Gene Gotimer
    Gene Gotimer
    Technical Manager
    Coveros, Inc.
    schedule 10 months ago
    Sold Out!
    45 Mins
    Case Study
    Beginner

    I often suggest to teams that they should be using all sorts of tools in their pipelines- from simple static analysis checks and automated builds to security scans and performance testing. I've done presentations and talks at conferences. I've lobbied to clients. I've commiserated with my colleagues. But I've never put together my dream pipeline in one of my own projects.

    There are always reasons that some tests and tools get left out- our policies won't allow them, they will take too long to get approved, we don't have time, we have bigger problems to deal with, it just isn't what the client is looking for right now. And I usually think, if only I were in charge, I'd make sure we were using those...

    In late 2017 I took over maintenance on an open-source project. Now I have no restrictions. The sky's the limit. No one is around to tell me what I can't do. So why don't I have my dream pipeline in place yet?

    I'll talk about the trade-offs and compromises I made when building out the pipeline. Why I decided to focus on some tools and tests but skipped others, and what I need to do or change to make this delivery process the pipeline I've always dreamed about, now that I have no one else to blame.

  • 45 Mins
    Workshop
    Intermediate

    In our follow-up session to last year’s Kanban in Action: Thoughtfully Observing Flow, we are excited to bring our newest installment of the series: Kanban in Action: Thoughtfully Creating and Discussing Flow.

    This session puts the attendee in the driver’s seat to create their own Kanban board configurations. We provide seven business scenario exercises and ask the attendees how they would go about configuring their Kanban board given the unique constraints of each scenario. Each team/table in the room will spend a few minutes discussing how they would configure their board using the provided flip charts, markers, and stickies. A debrief with the entire room follows as each team shares its concepts. The instructors will also share their own board configurations and ideas.

    These exercises will increase your understanding of Kanban systems, give you practice interpreting and creating board configurations, present multiple implementable ideas for any given scenario, and provide you with approaches for meaningful engagement. They are great for aspiring coaches, managers, and leaders who want to have more valuable conversations with their teams and improve Kanban implementations.

  • Liked Richard Mills
    keyboard_arrow_down

    Richard Mills - DevOpsing Your Greenfield: Cultivating New Growth

    Richard Mills
    Richard Mills
    DevOps Solution Lead
    Coveros, Inc.
    schedule 9 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    You have a golden gem of an activity. There's a brand new project and your project sponsor says "I want to do some DevOps on our new Agile project!" Sigh. You respond with "Well, how about this? Let's BE Agile and adopt a DevOps approach to structuring our teams, designing our architecture, and leveraging automation to rapidly deliver value to our customers." There. At least we've set the mood.


    Regardless, greenfield projects provide a unique opportunity for us as DevOps professionals. You don't have the established baggage of a legacy project. The project is probably open to modern tools and architectures. The project is trying to set up team structure that will have the right skill sets.


    The problem is: where you do you actually start with greenfield projects? When we introduce DevOps to an existing project (brownfield) we have a unique set of challenges and we can prioritize where to start based on our biggest problems. What do you do when you have a blank page? "Do everything!" Well, what actually makes up "everything" and where do we start?


    Putting a solid DevOps solution in place involves some key things. You can follow the religion of the "Three Ways of DevOps" (fast delivery, fast feedback, constant learning) made popular by Gene Kim, but you still have to start somewhere. In this talk, I'll provide a pragmatic formula to setting up well-integrated teams, establishing a DevOps platform, organically growing an initial DevOps pipeline with continuous integration and continuous delivery, establishing some (useful) standards, and guiding the system architecture to support rapid build, deployment, and testing.

  • Liked Thomas Stiehm
    keyboard_arrow_down

    Thomas Stiehm - Failure is Inevitable But it Isn’t Permanent

    Thomas Stiehm
    Thomas Stiehm
    CTO
    Coveros, Inc.
    schedule 10 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Elevator Pitch:

    Agile Transformation is harder than it needs to be because we often find ways to consciously or subconsciously sabotage our efforts if we can recognize this behavior it is possible to intervene and make a change for the positive.

    Abstract:

    Have you ever been on a project where it seems like team members are preventing the team from getting better? Why do they do that? I don’t know either- a psychologist might have to answer that. What I can tell you about is my experiences in seeing teams become their own worst enemies and unwittingly sabotaging the projects they are trying to make successful. My goal is to help you realize when you or those around you are behaving in a way that is going to lead the team plateauing or even failing. I have often found that many teams can get stuck, or plateau, at a certain point along the continuum of agile maturity. These teams can meander around without getting better or even changing anything for long stretches of time. I have also worked with teams that put so many hurdles in their own way that they had no option but to fail. They often fell back into old patterns and gave up hope that things can get better. As an Agile Coach, I have often felt that one of the most valuable things I can share with the people I coach are my failures. I have worked on Agile projects for a long time, and I have failed in many different ways. Having been through failure, I have learned that to keep getting better you have to recognize the things that you do that lead to plateaus and failures to overcome them. This talk is for coaches and team leads who want to make sure their team isn't getting stuck in a rut, or who are trying to get out of a rut with their health and sanity intact.

    Failure signs and examples

    No process is defined and followed

    • ex. Projects that claim to be agile without any experience or training, or doesn’t have basic agile practices such as retrospectives, I.e. we are agile because we have hour long daily standup meetings.

    Process practices are ignored or removed with no compensating practices

    • ex. Agile practices hold each other together, supporting each other by the value they bring to the project, some teams decide to not do some practices without doing something else to get that value, for instance pair programming provides code review and knowledge transfer, many teams don’t pair program and don’t do code reviews and or knowledge transfer.

    Automation is not valued or planned into work

    • ex. We will automate tests later. Often that later never comes and the team is left with a code base that is hard to maintain and change because you don’t know what your changes break.

    No stakeholder expectations management

    • ex. The only way a project can negotiate scope and or schedule is to actively manage stakeholder expectations. An example of unmanaged expectations is the PO that never says no to a feature request or the executive that decides what must to delivered and when it must be delivered.

    Quality and testing practices are an after thought or short changed on schedule

    • ex. Teams that don’t complete sprint commitments because the testers get coded stories too late in a sprint to do all the required testing and the rest of the team isn’t held responsible to help test.

    No negotiation allowed in deliverables and or schedule

    • ex. Executives that dictate all of the terms of a project before a team is even selected.

    The team doing the work didn’t estimate the work but are held to an estimate

    • Many government projects have such a long procurement cycle that no one from the proposal team is put on the project.

    Part time team members are in the critical path

    • ex. Sometimes people with special skills are needed for a part of a project. If the person is part time but their work is in the critical path the project is in trouble.

    Heavy team turn over

    • ex. Heavy turn over is a sign of a project that isn’t on track, even if it hits its deadlines the quality and output will suffer.

    Political motivations more important than team’s ability to do work

    • ex. If the team is setup to fail for reasons outside the team, they will most likely fail.

    Distraction from issues outside the work that needs to be done

    • ex. Scrum Masters that don’t shield the team from issues outside the work that needs to be done during a sprint will end up with a team that doesn’t hit the mark.

    Examples of what can be done to avoid failed projects:

    Focus on shielding the team from outside influence

    • Have the team focus on the things they can control and prevent outside issues from distracting the team.

    Negotiate delivery with the team

    • The team can develop an understanding of what it can deliver. Trying to make the team do more is going to lower quality and potentially make the project take longer.

    Management of stakeholder expectations

    • Stakeholders always want more, that is their job. Let them ask for anything but set their expectations on what is really going to happen.

    Focus on technical excellence, quality, and automation

    • If you want your teams to get better, have them focus internally on things they can control like technical aspects of the project including quality and automation.

    Hire motivated team members and make it possible for them to work

    • People who care about what they are doing will always be better than the cheapest people that don’t care. Hire people who care.

    Maintain a progressive planning pace for getting requirements ready

    • Agile requires planning at different levels, skipping a level for any reason means there are going to be disconnects between your stakeholders and the people doing the work. Disconnects means the project will not product the results you want.
  • Liked Julie Wyman
    keyboard_arrow_down

    Julie Wyman / Wm. Hunter Tammaro - Breaking Up is Hard to Do: How to Split a Team (Without Breaking It)

    45 Mins
    Experience Report
    Beginner

    Struggling to fit your Agile team into one room for ceremonies? Daily stand-up meetings dragging on? Finding it harder to keep the whole team informed? It might be time to split into the three- to nine-person teams the Scrum Guide recommends for better communication, collaboration and decision making. But abruptly changing the team structure can disrupt the larger group's dynamic and culture, and by breaking existing lines of collaboration, hurt the sense of team and organizational unity that already exists. By sharing our experience working with a large team at a non-profit client, we will illustrate the challenges that can face an Agile transformation when a team already has a culture of collaboration worth preserving. The lessons learned from our story will highlight not just the principles for nurturing Agility in a team's culture, but also specific strategies we used to overcome challenges and ensure the journey was one all our teams could embark on together.

  • Liked Julie Wyman
    keyboard_arrow_down

    Julie Wyman - Responding to Change over Following a Plan: Agile Lessons from Antarctica

    Julie Wyman
    Julie Wyman
    Agile Coach
    Excella Consulting
    schedule 11 months ago
    Sold Out!
    10 Mins
    Lightning Talk
    Beginner

    I spent January in Antarctica hanging out with penguins, whales, and seals. It was about as different from my day-to-day work as can be. And yet, on my long flight home, I couldn’t help but reflect on how well my trip aligned with one specific value of the Agile Manifesto: “Responding to change over following a plan.”

    Antarctica is a place that truly drives home why we need both planning AND, even more importantly, the ability to respond to change. This trip helped me fully appreciate how true this value is - and not just in software development. And after being stuck in Antarctica six days longer than planned, it also built up my empathy for team members struggling with dynamic situations!

  • Liked Hina Popal
    keyboard_arrow_down

    Hina Popal - Reviving Retrospectives: How to make them more than just an end sprint of calendar invite

    Hina Popal
    Hina Popal
    Sr. Agile Practitioner
    Red hat
    schedule 10 months ago
    Sold Out!
    45 Mins
    Workshop
    Beginner

    Retrospectives are not just about making you feel bad for missing your commitments, pointing fingers at your colleagues, and hearing your talkative team members go on and on. They are supposed to help your team become great. This workshop is for anyone that participates in retrospectives, doesn’t always feel they are useful and wants to learn a better way to accomplish the intended goal.

    We will explore several different topics to help revive retros such as:

    • Understanding people's perspectives to retros
    • The psychology of blame
    • Looking for what is working in the team
    • Problem solving strategies
    • Getting the team's feelings out on the table
    • Understand team perceptions
    • Using data to determine the way forward
    • Improving team interactions in a remote environment

  • Liked Lisa Cooney
    keyboard_arrow_down

    Lisa Cooney - Brain Agility: Overcoming Cognitive Bias

    Lisa Cooney
    Lisa Cooney
    Agile Consultant
    Independent
    schedule 11 months ago
    Sold Out!
    45 Mins
    Workshop
    Intermediate

    Did you know that your brain tells you stories all day long, and that if they are good stories, you believe them? Come to this entertaining interactive session to experience some "cognitive illusions" for yourself, and learn what they demonstrate about how our brains' work. Cognitive science and behavioral psychology offer important insights for agilists, insights that can help us work more effectively with our co-workers and clients. You will learn how awareness of our brains' tendencies is a powerful tool to overcome our own innate cognitive bias, and the cognitive bias of others. This newfound awareness can open you to more varied perspectives in order to tell yourself a story that is both richer and more nuanced -- and closer to being "a true story."

  • 45 Mins
    Workshop
    Beginner

    Ever struggled to define what is minimally necessary? Whether it is defining a Minimally Viable Product or what is minimally necessary for a project or team, you need a way to not only brainstorm ideas, but also a way to cut the unnecessary waste out.

    Pass to Perfection is a game for getting a solution, product, or project started with what is minimally necessary; in development terms, this is your Minimal Viable Product (MVP). It mashes up ‘Yes and’ thinking for co-creation, and the essence of The Perfection Game (from the Core Protocols) for negotiation and prioritization in a collaborative round-robin game format. Create ideas until you can’t think of anything else and you pass, remove ideas until you have what is essential and you pass. This workshop will have you try out the game and learn how easy it is to get people started.

  • Liked Chris Li
    keyboard_arrow_down

    Chris Li - Power Windows and Prioritization - a different approach to ordering your Product Backlog

    Chris Li
    Chris Li
    Founder
    SparkPlug Agility
    schedule 10 months ago
    Sold Out!
    45 Mins
    Workshop
    Intermediate

    Product Owners have the challenging task of choosing which items their teams should focus on next. By combining their experience, conversations, and intuition, they often have to make decisions based on a set of imperfect data, which is hard to do. Adding to this, that they may have to justify their reasoning, making the task of prioritizing even more difficult.

    In this workshop, participants will explore the Kano Model, an approach that takes into account satisfaction, functionality, and categorization to best identify the most important things based on customer response. This model gives Product Owners real data and insights to aid their decision making process, vastly improving on "this is important because I said so!"

  • Liked Joshua Seckel
    keyboard_arrow_down

    Joshua Seckel - Modern Agile 101 for Government

    45 Mins
    Talk
    Beginner

    In 2001, a group of software developers got together in Snowbird, UT, and created the Agile Manifesto. The Manifesto was a statement of core value and principles. The core values are:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    These four values are supplemented by 12 principles of agile software. The original 17 signatories were joined by thousands of additional people with the ability to sign cut off in 2016.

    These principles are the foundation of much of the work in agile that has occurred in agile development, but have been mostly frozen as practices and agile has evolved.

    Modern Agile has been created recently to update the underlying foundational values and to provide a focus beyond software delivery. Those four values are:

    • Make People Awesome
    • Deliver Value Continuously
    • Make Safety a Prerequisite
    • Experience and Learn Rapidly

    This talk will walk through this reimagining of the agile values and what they mean for delivery within a government context. We will take each value and look at government cultural and technical challenges and opportunities to advance modern development practices.

  • Liked Clare Stankwitz
    keyboard_arrow_down

    Clare Stankwitz / Mathias Eifert - Making Agile Work for Data Teams: Writing Effective PBIs for Data Products

    45 Mins
    Talk
    Intermediate

    Want to help your data and analytics teams embrace Agile but don’t know where to start? Wondering why your data team seems to struggle with creating manageable yet valuable stories? Curious why we think Agile for data teams is a distinct challenge?

    Data work is often structured more like a pyramid than the familiar “layer cake” metaphor due to the state of data infrastructure technology, common industry practices, and the heavy lift to integrate data before it can be analyzed and visualized. Prevailing Agile wisdom of cutting work into “vertical slices” thus presents significant challenges for Agilists working on data teams! Typical full-stack vertical stories in this environment can easily become too complex, interdependent, and unwieldy to fit into fixed-length sprints. Technical stories can encapsulate smaller work increments but risk becoming too abstracted from the customer’s core problems and trap the team in infrastructure work for too long. An additional impediment to traditional user stories is the highly exploratory nature of advanced analytics and data science projects where in many cases end users lack awareness of what kind of problems can even be solved and technical experts can’t initially predict which solutions will actually be possible.


    This session presents successes and lessons learned from applying alternative story decomposition and writing techniques on several data products across multiple teams. Returning to one of the fundamentals of what makes Agile valuable, namely to obtain feedback on feasibility and end user value as quickly and systematically as possible, our approaches strive to ensure teams have small, independent stories while still maintaining a value focus. We discuss ways to decouple the technical stack through stubbing and gradual tightening of the Definition of Done. This technique accommodates the necessary foundational work in the background while also obtaining early feedback about the value of the eventual product delivery options. A second approach incorporates Lean Startup concepts and centers on replacing traditional user stories with testable hypothesis statements that allow for explicit experimentation and risk trade-offs towards relevant milestones such as model quality, performance, predictive reliability, etc. in the context of extreme uncertainty.


    Join us as we discuss some of the friction Agilists can encounter on data teams, as well as some validated ideas for meaningful solutions.

  • Liked Dane Weber
    keyboard_arrow_down

    Dane Weber - Please Stop Modernizing!

    Dane Weber
    Dane Weber
    Sr. Consultant
    Excella
    schedule 11 months ago
    Sold Out!
    10 Mins
    Lightning Talk
    Executive

    The federal government loves modernizing software systems and it isn't wrong: stale, decaying software leads to major headaches and eventual catastrophe. Modernization efforts, however, have big risks and big failures.

    There is an alternative: software renovation. That is improving, updating, and upgrading the software system one piece at a time while it continues to operate.

    Dane has participated deeply in three US government modernization projects. Each project followed a pattern of pitfalls, scary "go-live" transitions, and unpleasant trade-offs.

    Renovating legacy software is frequently a better option. The software system continues to gain functionality at the same time that its design and performance are improved.

  • Liked Adrienne Rinaldi
    keyboard_arrow_down

    Adrienne Rinaldi - Coach the Coach | The Coaching Backlog

    Adrienne Rinaldi
    Adrienne Rinaldi
    Agile Coach
    CapTech Consulting
    schedule 11 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    You’re a new coach. Now what? This session will help you get started on an agile transformation assignment with a coaching backlog. This session will inform new coaches on “where to start” as an Agile Coach. The session will begin agile transformation challenges followed by common agile impediments, conditions for success, an agile readiness checklist and a coaching backlog including Epics, Features and Stories.

  • Trent Hone
    Trent Hone
    Managing Consultant
    Excella Consulting
    schedule 11 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Agile at the team level fosters self-organization by leveraging constraints. Timeboxes, Work in Progress (WIP) Limits, and clear operational definitions are excellent examples of the kinds of constraints teams regularly employ to deliver reliably. Are you familiar and comfortable with these ideas, but uncertain how to apply them at larger scales? Are you looking for techniques that will allow you to harness the creativity of your teams to enable self-organization at scale? If so, this session is for you.

    I’m passionate about applying concepts from Complex Systems Theory (as developed by Dave Snowden, Alicia Juarrero, Bob Artigiani, etc.) to the work of software teams. My colleagues and I at Excella have been exploiting these ideas by using a variety of patterns borrowed from different theories and frameworks to allow our teams to grow like healthy plants in a garden. From Large-Scale Scrum (LeSS) we leverage the concepts of a single product backlog and a shared cadence. Kanban principles of visualizing the work and limiting WIP help align the teams and foster greater collaboration. Dave Snowden’s emphasis on Homo Narrans—the human as storyteller—has provided a framework for clarifying and promulgating common values, which are essential for decentralized decision-making. Collectively, these mental models created an environment that helped us scale one of our engagements from three teams to eight over the course of a single year.

  • Liked Gene Gotimer
    keyboard_arrow_down

    Gene Gotimer - Build a Better, Faster Pipeline for Software Delivery

    Gene Gotimer
    Gene Gotimer
    Technical Manager
    Coveros, Inc.
    schedule 10 months ago
    Sold Out!
    45 Mins
    Workshop
    Beginner

    The software delivery pipeline is the process of taking features from developers and getting them delivered to customers. The earliest tests should be the quickest and easiest to run, giving developers the fastest feedback. Successive rounds of testing should increase confidence that the code is a viable candidate for production and that more expensive tests—be it time, effort, cost—are justified. Manual testing should be performed toward the end of the pipeline, leaving computers to do as much work as possible before people get involved. Although it is tempting to arrange the delivery pipeline in phases (e.g., functional tests, then acceptance tests, then load and performance tests, then security tests), this can lead to problems progressing down the pipeline.

    In this interactive workshop, we will discuss how to arrange your pipeline, automated or not, and so each round of tests provides just enough testing to give you confidence that the next set of tests is worth the investment. We'll explore how to get the right types of testing into your pipeline at the right points so that you can determine which builds are viable candidates for production.

  • Liked Gene Gotimer
    keyboard_arrow_down

    Gene Gotimer - A Definition of Done for DevSecOps

    Gene Gotimer
    Gene Gotimer
    Technical Manager
    Coveros, Inc.
    schedule 10 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    DevOps needs to consider many different aspects of software quality, including security. The term DevSecOps was developed to highlight that security is a focus of the pipeline, not a second-class citizen.

    Fortunately, we can define done for our pipeline so that it includes security. Continuous integration can invoke static analysis tools to test for security errors and check if we are using components with known vulnerabilities. Automated deployments and virtualization make dynamic environments available for testing in a production-like setting. Regression tests can drive traffic through proxies for security analysis. From the code to the systems where we deploy the software, the process can be designed to make sure that we follow security best practices, and not produce insecure software.

    Participants will learn how to construct a definition of done that focuses on security in a DevOps pipeline. They will see how to define security practices that build confidence that they are doing DevSecOps, and how those practices and criteria might mature over time.

  • Liked Glenn Buckholz
    keyboard_arrow_down

    Glenn Buckholz - Failing Faster with Kubernetes and then Recovering

    Glenn Buckholz
    Glenn Buckholz
    Technical Manager
    Coveros
    schedule 10 months ago
    Sold Out!
    45 Mins
    Case Study
    Intermediate

    Kubernetes is quickly gaining popularity, but does the technology deserve so many accolades. In this talk we learn what exactly kubernetes has to offer in the DevOps world. We see that as a service it can provide resources for your DevOps pipeline, automated tests, and the application you are trying to build. We visit an example implementation of such a pipeline and discuss some lessons learned about how to balance these three needs. Additionally, we look at what design considerations your application needs to make, you should consider for your automated testing infrastructure, and how all of this can be leveraged to keep consistent CM while deploying rapidly. Lastly, we explore how threading it all together can help you fail fast and recover quickly as well.