Dec 1, 2021

Length: 16min. 01sec

In Episode 2 of this video series, ICON Coach, Dan James, cuts to the chase on what Agile actually is, which may come as a surprise to many leaders. If your goal is to scale Business Agility throughout your organization, this video will help you understand exactly what you’re scaling. That understanding is the prerequisite to the adoption of any popular framework. This video series will help you build leadership support and allow leaders to recognize the ROI that follows a transformation.

Take our 3-minute survey to see if your team is ready
for an Agile Transformation

Nov 15, 2021

Mental health is another thing that agile leaders need to support. When your team is happy and mentally well, they can increase productivity and improve project outputs. While you don’t need to play therapist, it will help to provide team members tools that can help them manage anxiety and relieve emotional distress. The online resources listed below can empower employees to take care of their mental wellbeing.

Psycom Quizzes

Psycom.net provides online self-evaluation tools for common mental health disorders such as depression, generalized anxiety disorder, bipolar disorders, and substance abuse. Though the results of these quizzes cannot be used in place of a clinical diagnosis, they can help individuals recognize problem points and determine whether further assessment is necessary. This way, the team gets to detect issues before they get too severe. Additionally, the website provides resources for mental health support, such as fact sheets, articles, and self-help guides.

Radical Acceptance

Self-evaluation and improvement is a key part of agile project management, as stated by the twelfth principle of the agile manifesto. However, self-evaluation can become unproductive when it turns into excessive self-criticism. Agile team members can learn to overcome their self-judgments by studying the concepts taught in Radical Acceptance – Embracing Your Life With The Heart of a Buddha. Here, famous psychologist and spiritual teacher Tara Brach gives readers stories and guided meditations that can help them develop the self-compassion needed to overcome shame. The book is available in both e-book and audiobook form.

Headspace

Meditation helps teams become more mindful and focused, which, in turn, helps them adapt to industry changes quicker. In the e-book The Headspace Guide to Meditation and Mindfulness, former Buddhist monk Andy Puddicombe unravels the science behind meditation. The resource contains a wide variety of meditative exercises readers can use to cope with different emotions, such as stress and anger.

Additionally, readers can try Andy Puddicombe’s Headspace mobile app to gain access to a comprehensive library of meditative exercises. Because most meditations last less than a minute, agile team members can easily work Headspace exercises into their work routines. Doing these exercises consistently can help agile team members improve every aspect of their minds, including work productivity, concentration, and stress relief.

Youper

Chatbot app Youper uses AI technology to put mental health management right at the user’s fingertips. When users open Youper, they’re led to a chatroom, where they’re encouraged to share their thoughts and their current emotional state. Then, Youper analyzes the data the user offers and prescribes appropriate treatments, ranging from cognitive behavioral therapy techniques to breathing exercises.

The app also contains a journal log that users can use to record thoughts and emotions, and additional screening tools that help identify risk factors for depression, anxiety, bipolar disorder, and other mental health issues. These additional tools can help users track their progress when it comes to mental health. According to Dr. Jose Hamilton, the creator of Youper, 80% of Youper users report a decrease in negative moods after talking to the AI.

Agile team members are the backbone of any product development project. By providing them with the resources they need to protect their mental wellbeing, agile team members can reduce stress, improve concentration, and increase efficiency for agile projects.

Sept 23, 2021

Here are some of the most common Agile terms used in the industry. But remember, being Agile requires a lot more than just common terms. It is a shift in culture and mindset for most companies which requires guidance from someone who has made that shift. So, get help from an ICON Coach or mentor who has experience making the Agile transition to ensure success in your own.

Agile Lexicon / Glossary

Acceptance Test

An acceptance test confirms that a story is complete by matching a user action scenario with a desired outcome. In other words, does the delivered solution meet the customer/user expectations? Acceptance testing is also called beta testing, application testing, and end user testing.

Agile Retrospective

In Scrum, the second half of the  Sprint Review Meeting is a retrospective for the Scrum team that is led by the ScrumMaster. The team assesses the way they worked together in the sprint and identifies positive ways of working together that can be encouraged as future practice. The team also identifies the things that could work better and develops strategies for improvement.

Agile Software Development

Agile software development is a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. Agile software development focuses on keeping code simple, testing often, getting frequent customer/user feedback, and delivering functional bits of the application as soon as they are ready.

Burndown Chart

The burndown chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress.

Customer

In agile software development, a customer is a person with an understanding of both the business needs and operational constraints for a project. The customer provides guidance during development on what priorities should be emphasized. (Called a Product Owner in Scrum.)

Daily Scrum

Each day the ScrumMaster facilitates a fifteen-minute meeting designed to clarify the state of the Scrum. Each team member speaks to three questions: what did I do yesterday, what did I do today, and what impediments got in my way? While anyone can attend this meeting, only team members who have committed to deliver work to the Scrum are allowed to speak. The goal is to share the state of the work, discover any new dependencies, address any personal needs of committed individuals, and adjust the work plan in real time to the needs of the day.

Iteration

An iteration is a single development cycle, usually measured as one week or two weeks. An iteration may also be defined as the elapsed time between iteration planning sessions. (Called a Sprint in Scrum.)

Planning Board

A planning board is used to track the progress of an agile development project. After iteration planning, stories are written on cards and pinned up in priority order on a planning board located in the development area. Development progress is marked on story cards during the week and reviewed daily. (Also called a Team or Kanban Board.)

Planning Game (XP) or Planning Poker (Scrum)

A planning game is a meeting attended by both IT and business teams that is focused on choosing stories for a release or iteration. Story selection is based upon the stories that will provide the most business value and the estimate of development effort provided by the team.

Product Backlog

The product backlog is a high-level document for the entire project. It contains product backlog items: broad descriptions of all required features, wish-list items, etc. It is the “What” that will be built. It contains rough estimates, of both business value and development effort.

Product Owner

The Product Owner is a Scrum role that represents the voice of the customer. They ensure that the Scrum Team works with the right things from a business perspective. The Product Owner writes User Stories, prioritizes them, and then places them in the Product Backlog.

Release

A release is a deployable software package that is culmination of one or more iterations of development.

Release Plan

A release plan is an evolving flowchart that describes which features will be delivered in upcoming releases. Each story in a release plan has a rough size estimate associated with it.

Scrum

An agile method proposed by Ken Schwaber and Jeff Sutherland. Scrum is an agile, lightweight process that can be used to manage and control software and product development. Wrapping existing engineering practices, including XP, Scrum generates the benefits of agile development with the advantages of a simple implementation.

ScrumMaster

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended.

Sprint

“Sprint” is the Scrum term for “iteration,” a time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.

Sprint Backlog

The sprint backlog contains information about how the team is going to implement the requirements for the upcoming sprint. User stories represent what the customer/user wants, and Tasks are used to break stories into actions focused on how to deliver each story.

Sprint Planning Meeting

A Sprint Planning Meeting is used to develop a common understanding of the desired work plan at the beginning of an iteration. The team decides how much work it can successfully take into the sprint based on team size, available hours, and level of team productivity.

Sprint Review Meeting

At the end of a sprint, a Sprint Review Meeting is held. This meeting is time-boxed to a maximum of four hours. The first half of the meeting is set aside to demonstrate to the Product Owner the potentially shippable code that has been developed during the Sprint. The second half of the Sprint Review Meeting is a  retrospective for the Scrum team that is led by the ScrumMaster.

Spike

A spike is a story that cannot be estimated until a development team runs a time-boxed investigation. The goal of a spike is to gain enough knowledge to understand if/how a user story may be delivered. The output of a spike story is an estimate for the original story.

Stand-up

A stand-up is a daily progress meeting, traditionally held within a development area. Business customers may attend for the purpose of gathering information. The term “standup” is derived from the way it is run all attendees must remain standing to keep it short and the team engaged. (Called a  Daily Scrum in Scrum.)

Story / User Story

A story is a particular business need assigned to the software development team. Stories must be broken down into small enough components that they may be delivered in a single development iteration.

Team

The team has the responsibility to deliver the product. A small team of 5-9 people with cross- functional skills (designer, developer, tester, etc.) work together to design, develop, and test user stories in the iteration backlog.

Timebox

A timebox is a defined period of time during which a story or task must be accomplished. Timeboxes are commonly used in agile software development to manage software development risk. Development teams are repeatedly tasked with producing a releasable improvement to software, timeboxed to a specific number of weeks.

Velocity

Velocity is the number of story points used as a guide for planning the next iteration of a development project. Velocity is based on measurements taken during previous iteration cycles. Velocity is calculated by averaging the original point estimates of the stories that were successfully delivered in the previous 3-5 iterations.

Here are links to some other examples of Agile glossaries:

• https://www.scaledagileframework.com/glossary/
• https://www.agilealliance.org/agile101/agile-glossary/
• https://www.scrum.org/resources/scrum-glossary

---

Looking for guidance in your Agile Transformation? For nearly 3 decades, our experienced coaches have mentored clients in their digital transformations.

Jun 11, 2020

The PI Planning event enables 5-12 teams on an Agile Release Train (ART) to align, plan, manage dependencies, and commit to what will be delivered in an 8 – 12 week time period. This article covers your rights as a Shared Service representative, your responsibilities, and tips to gain the most from your time at the PI Planning event.

 

Your Rights Working with an Agile Release Train

1. Understand the features that the agile teams are working on to achieve outcomes. (Details are available in the agile tool and from discussions with Product Managers and System Architects.)
2. Understand what’s expected from your team (per iteration) to support those features.
3. Understand enough about the methods being used to understand what’s on the physical or online wall and how that data relates to your team’s work.
4. Be honestly informed about progress, wins, risks, and impediments.

 

Your Responsibilities During PI Planning

All references to Day 1 morning, afternoon, etc. assume a classic 2-day PI Planning session. Globally distributed teams and teams working remotely often spread PI Planning over more calendar days to maximize overlap hours. Check with your Release Train Engineer (RTE) or Solution Train Engineer (STE) for their customized agenda.

1. Your participation is optional during Day 1’s opening presentations. These presentations set the business and technical context for the work to be done. Plan to attend if you want to better understand the context and priorities.
2. Your participation is expected during Day 1’s afternoon. The extent of dependencies will influence how much time to spend. Here is your checklist for what to do during this time:
   1. Set up easel sheets or the online equivalent to share your work that affects the Agile Release Train. The amount of info that you need to display and/or collect will influence how you set up your space. See the suggestions in the picture to the right and below this list. Ask the RTE for more guidance, if needed.
   2. Create a sticky note for each piece of work requested by the teams on the train and post it in the correct swim lane and time frame. If it makes more sense to post a list, talk with the RTE.
   3. Create a sticky note for each significant event (e.g., release or decision point) that may affect the work of the agile teams and post it in the correct swim lane and time frame. If it makes more sense to post a list, talk with the RTE.
   4. “Walk the walls” (i.e., visit each team’s wall space) to review and ask questions about what each team is doing and how it relates to your work. Both parties are responsible for ensuring the other knows about upcoming work that will impact them and what is needed to make the whole effort successful. Negotiate time frames and dependencies as necessary and update your wall and program board to reflect the agreements.
   5. Periodically visit the program board, which shows a summarized view of features, milestones, and dependencies. Talk with the RTE about adding a Shared Services swimlane on the program board if one does not already exist. Update the program board accordingly. If you see dependencies posted in the Shared Services swimlane that don’t correspond to work already on your board, then talk with the appropriate team and adjust the board accordingly.
   6. Optional: Stay for the draft plan review (see your agenda for timing) to hear each team’s summarized outcomes. Sometimes the draft plan review reveals additional work for the Shared Services teams.
      Figure 2. Several shared service teams, each with a lot of work, shown by swim lanes across 4 pages (1 per iteration)
3. Your participation is expected during Day 2’s late morning and early afternoon so you can check in with each team and adjust plans and risks as necessary.
   1. Review the program board for changes that affect your work.
   2. Visit each team’s work area to discover if their updated plans will create, change, or remove your planned work. Share any updates that you have on your work that would affect their plans. Consider risks and discuss them with the team, too. They may need to update their risks.
   3. If your work affects other Shared Services teams, discuss dependencies with them and adjust your plans.
   4. Adjust your data on the program board and your wall based on the above.
   5. If you see additional risks, discuss them with the RTE if your area does not have a risk board.
4. Your participation is expected on Day 2’s afternoon so you can hear the final plans, ask remaining questions, and participate in the confidence vote and PI Planning retrospective. Those activites are another opportunity to improve everyone’s success and collaboration.

May 17, 2019

The point of an I&A is to inspect both the product and process so you can make them better for the coming PI. The I&A breaks down into three parts:

1) PI System Demo – Inspect and Adapt the product

2) Quantitative Measurement – Inspect the process using metrics

3) Problem-Solving Workshop – Adapt the process

You might be asking, “Why all this rigor vs a regular retro?” Because…the bigger the groups of technology and people, the bigger and harder the problems. Imagine using a Start/Stop/Continue Retrospective to solve a complicated Delivery Pipeline issue affecting multiple teams. Your likely result would a hodgepodge of small ideas that don’t fix the harder problems.

In the spirit of Relentless Improvement, you need to take the plunge. How about a few I&A tips to put your mind at ease?

 

Watch On-Demand Webinar “Inspect & Adapt: A Coach’s Secrets For Optimizing Your Investment” Now

 

---

Tip #1: Make your PI System Demo exciting with a real-time simulation.

SAFe suggests a brief 45-60 minute timebox for a PI System Demo. In this time, it’s common for each development team to quickly demonstrate their portion of features, sit down, and allow for the next team’s presentation. While this style of demo allows each team to get direct credit for their work, I often find the overall presentation clunky and disjointed (not to mention…boring). So what does a better PI System Demo look like?

A few things to note:

• This simulation was planned in only a few hours (not days).
• It was presented with working software, not PowerPoint.
• Because the demo focused on the solution and not the development teams, some of the component and data teams also felt appreciated.

 

---

Tip #2: Focus on the Big Picture.

You’re following SAFe Principle #4 – Build Incrementally with Fast, Integrated Learning Cycles. Every couple of weeks, you’re giving a System Demo of an integrated working solution to Product Management and Business Owners, who see and approve the individual features and explore the corner cases and error handling. They are aware of the details. So what value can you bring them in the PI System Demo? What don’t they already know?

How everything fits together! For the first part of the demo, focus on giving people the big picture and try not to get lost in specifics. Remember, you’re in a timebox! Big picture thinking allows you to solve problems quickly without dwelling on small potatoes. Thinking big will drive your success.

A few things to note:

 

---

Tip #3: Use your metrics to tell the PI’s story.

Let’s move into the Quantitative Measurement section (Part 2) of the event, which is also suggested to be a 45-60 minute affair. The PI System Demo has given us a Product perspective. Now it’s time to take a Process perspective.

Typical questions after a PI include: “How did we do?” “Did we make our predictability?” “Is test automation on the rise?” Hint: the numbers alone don’t say anything meaningful. The key is to know the story that the metrics are telling and then using that story to provide context.

Saying “We only made 50% predictability” doesn’t mean much. Often, leaders avoid accountability and blame the teams for falling short of expectations instead of digging deeper for the real problem. If you want to find solutions that work, then you have to find the real story, or why you only made 50% predictability.

Being able to say: “We only made 50% predictability because we were working on too many things at once” is a powerful moment and gives you serious food for thought for the Problem-Solving Workshop (Part 3 of I&A). RTEs, this is a great place to serve and stand up for the train!

A few things to note:

• Sometimes people worry that Quantitative Measurement will be a big reveal of bad news. If you’ve been doing your SAFe events well and there is transparency, then this isn’t news. It’s just data.
• There is more power when the RTE, Product Management, and Architect “troika” present this section together.
• If you’re looking for what metrics to show, start with the Program Performance Metrics section of Scaled Agile, Inc’s Metrics article, or try ICON’s free ART Maturity Assessment tool.

 

---

Tip #4: Train Problem Solving Workshop facilitators ahead of time.

 
A few things to note:

• Problem statements can be hard. Give the teams a few examples of good problem statements to model and bad problems statements to avoid.
• Problem statements shouldn’t suggest a solution.
• Focus on problems they can control or influence.
• Show the economic impact of a problem— this really inspires people to want to fix it. Most problems result in time wasted, so you can quantify that by asking management for the cost of a development team for a day, a sprint, etc.

For detailed suggestions and examples of how to have a better Problem Solving Workshop and examples of good/bad problem statements, download this helpful PDF.

 

Download 5 Additional Tips for Better I&A Problem Solving

 

---

Tip #5: The Inspect and Adapt Event Template is your friend!

You may not know it, but if you’re an SPC, then you have access to something called the SAFe Program Increment Toolkit from the Toolkits and Templates section of the Community site. The PI Toolkit has the Inspect and Adapt Event Template, which is a PowerPoint with all the steps needed to walk people through the entire I&A event. This is really, really useful!

The I&A Workshop is a complex event and there is a lot more to say, but these five tips should help you get started. Now go forth and make your train better!

View the Scaled Agile, Inc. partner profile for ICON Agility Services

 

---

 

Nov 13, 2019

 

1. Refine the Backlog with the Teams

We know it’s important to have the top 10 or so features determined before PI Planning, but you know what’s even more important? For those features to be refined prior to the event. If the teams don’t see the features until PI Planning, then they won’t have time to ask all their questions and create necessary stories for each feature. Teams need time to digest the features and have their questions answered.

To refine the backlog effectively, the Product Manager (PM) must spend time with the team prior to PI Planning to explain what is needed from each feature and what business value will be achieved. The PM might have to go back to the business for clarification. The PM and the team should have a “definition of ready” for features, so each will be “ready” for PI Planning.

It’s common for teams to encounter features for the first time in PI Planning. I’ve seen unprepared teams get frustrated quickly as they try to create stories and size the effort without truly understanding the product that they need to build. The Product Managers get frustrated too, because they believe the features they wrote included everything the teams needed.

Remember that the communication between the PMs and teams is bidirectional. Each is learning from the other so that the product created for the customer is the right one with the highest business value. When the features are refined and the PMs and teams are in sync, then the iteration planning is effective with few unknowns identified.

 

2. Logistics, Logistics, Logistics

SAFe encourages that everyone be together for a face-to-face PI Planning, which requires a lot of thoughtful logistics. One challenge is that many companies don’t have regular access to a room that can hold 150 people working closely together. Having the planning event offsite helps reduce the interruptions from non-Planning work; however, if a non-attendee is unexpectedly needed, then it can be difficult to pull them in.

I worked with one ART who didn’t have all Train members onsite for their first PI Planning. They knew it wasn’t ideal, but thought video conferencing would be good enough. Unfortunately, with a 6-hour time difference and the general chaos of the event, the experience was very discouraging for the offsite team members. For their second PI Planning, everyone was in the same room and the results were much better.

In addition to the physical location, here is a checklist of seemingly small things that actually play a huge role in creating a smooth and successful PI Planning:

 

3. Business Leaders in Place

Leadership support is paramount to Agile and SAFe—it is the foundation of the SAFe House of Lean. The popular Leading SAFe course instills the “how-to’s” for all leaders on the SAFe journey. During PI Planning, business leaders have an opportunity to share their vision for the product, as well as offer their support and appreciation of what the teams are doing. Demonstrated leadership is absolutely crucial to the entire PI Planning event. The ART needs to hear the commitment from the business leaders to be assured that their work matters.

The greatest leaders I’ve encountered share their SAFe journey with the teams, learning right along with the ART and instilling confidence that they will be there along the way. Make sure your business leaders commit to being visible and available during the PI Planning event. Their encouragement and business context is critical to getting the ART off the ground successfully. The train wants and needs to hear from them directly.

 

4. Teams know the Business Value (why they are here)

 

5. The Systems Team Knows their Value

A Systems Team doesn’t typically receive all their work from one ART. Some work comes from one ART, and the rest may come from other ARTs or parts of the organization. Because these various work sources do not attend one PI Planning session, a Systems Team won’t plan their next 10-12 weeks of work during this event. They are, however, included in PI Planning for a host of reasons. It’s important for them to understand those reasons so that their attendance is beneficial to both them and the ART.

The Systems Team is there to provide information to the ART on upcoming systems work and the general direction of the enterprise. Additionally, the Systems Team gains understanding of what the ART is doing and how they are going to do it. They also gather work requests from the ART teams. This two-way communication is critical for success. The Systems Team needs to proactively engage the individual teams to understand the needs and direction of the ART.

In my experience, I’ve seen the Systems Teams sitting off in the corner wondering why they are there and feeling unnecessary. Spend the time upfront to make sure everyone knows why the Systems Team is attending PI Planning.

 

In Conclusion

Need additional help?

PI Planning can get messy! If you find yourself in a bind, then drop us a line. We’d love to help you with your first PI Planning, or wherever you are on your SAFe journey. Let us know your concerns, and we’ll set up with a consultation with an experienced SPC in your industry.

 

Sep 20, 2019

I initially thought that DevOps could contribute nothing new—after all, I grew up coding using XP and dark launching. But as I dug deeper past the hype, I was able to find truly great ideas and patterns that added value to the way we build robust, secure and risk-free systems. My first “A-ha!” came when I learned that DevOps systems were proven to recover almost 150x faster than normal.

In this article, we will explore some of the important things that we can and need to do to implement DevSecOps (DevOps + Security), which enhances security and enforces compliance at the same time.

 

Quick Refresher: DevOps and It’s Challenges

Before we get into the need and details of DevSecOps, let’s quickly refresh ourselves on the advantages of DevOps, along with a few corresponding challenges.

1. Speed of Delivery – Most companies adopt DevOps to bring their products to market faster. However, with great speed comes great responsibility. How do we address responsibility for quality and security?
2. Design and principle of YAGNI – DevOps is built on the principles of agile, lean and YAGNI (“You Aren’t Gonna Need It”). This means eliminating large upfront design and constantly cutting down on design and features to meet only the most important goal(s). When and how will the security teams’ threat models stay in sync with such frequent and continuous changes?
3. Microservices & Containers – DevOps introduced the design of small, isolated functions that can be changed, tested, deployed, and managed completely independently. Unfortunately, microservices and containers also come with downsides, including operational complexity, polyglot programming, logging strategy, and attack surface. Containers (especially the famous Docker) used with microservices can actually provide micro-segmentation. Adrian Mouat, author of Using Docker, has expressed serious security concerns, such as Kernel exploit, Denial of Service attacks, Container breakouts, Poisoned images and compromising secrets. How can security cater to all of these concerns?
4. Compliance & Change Control – Adopting DevOps brings in the need to change old compliance and change control processes. There needs to be SoD (Separation of duties), as well as clear handoffs and wait times to ensure that requirements for data confidentiality and integrity are satisfied; the data and configuration cannot be altered by unauthorized individuals. How do we address this while moving fast?

By wiring compliance and security into DevOps, otherwise known as “DevSecOps,” there are ways to tackle the aforementioned challenges. Below are three solutions to help you get started on your DevSecOps Journey.

 

Shift Security Left

Etsy is a great example of a company that has successfully shifted security left. Etsy built their security culture on top of their engineering culture, which has resulted in an overall thriving company culture. Their driving principles are:

1. Trust people to do the right thing, but still verify – Rely on reviews to prevent or catch mistakes. The production mistakes go through a process of blameless postmortems to examine and understand the source of the problem, so they can fix problems at their source.
2. “If it Moves, Graph it” – Make data visible to everyone in the company so that everyone can understand and act on it, including information about security risks, threats and attacks.
3. “Just Ship it” – Every engineer can push code to production at any time, including security engineers. If something is broken, then fix and ship it right away. Send it through the CI/CD pipeline so all the tests are done again to the fixed code.
4. Security cannot be a blocker – The word “No” is a finite resource, so use it only when you must.

 

Follow OWASP Proactive Controls

At Twitter, for example, security checks are run automatically every time a developer makes a change. They use tools like Brakeman to check the code for security vulnerabilities and to provide the developer with direct feedback when something is found. Developers also have a “bullshit” button to reject false positive findings.

 

Infrastructure as Code

Another key to DevSecOps is Infrastructure as Code, or managing infrastructure configuration in code using tools like Ansible, Chef, Puppet, and Salt. This speeds up and simplifies provisioning and configuring systems, especially at scale. It also helps to ensure consistency between systems and test and production, standardizes configurations and minimizes configuration drift, and reduces the chance of an attacker finding and exploiting a one-off mistake.

Security teams can also use Infrastructure as Code to program security policies directly into configuration, to continuously audit and enforce policies at runtime, and to patch vulnerabilities quickly and safely. A good example of this is a service called UpGuard.

 

The Bottom Line

Need help getting started with DevSecOps? ICON offers testing, quality, and strategic DevOps Solutions.