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.

Feb 1, 2021

If you want to create a valuable product that the customer adores, then consider Lean Budgeting (LB). LB is an approach to fund initiatives without the traditional restrictions of pre-defined rigid scope and timelines. It provides strategies to eliminate the overhead of traditional project-based funding and cost accounting. It maintains appropriate oversight by providing guardrails and value-stream budgets. With LB, enterprises can have the best of both worlds – a development process that’s responsive to the market and accountable management of spending.

In my experience, I’ve seen four areas where the LB is far superior to Project Cost Accounting. Below I’ve highlighted these areas and provided context for the difference between the two approaches.

 

1. Continuous Customer Engagement

In Project Cost Accounting, the customer is not involved in determining if the solution is successful. Instead, success is measured by meeting arbitrary dates and a predetermined scope. Even if the teams have met the dates and scope, they might not have created a product that is valuable for the customer. That is not success.

In Agile, a consistent and transparent relationship is built with the customer. The customer assures your teams that business value is being enhanced throughout development. Based on customer feedback, your teams only build what is valuable regardless of whether they are IT teams or Business teams.

Prior to using LB Guardrails, I’ve seen many teams build a product to the initial requirements written many months (or even years!) prior to the completion of the project, only to have the customer completely disappointed with the end result because it didn’t meet their expectations or it no longer met the market needs. Customer engagement throughout the duration of the planning horizon assures that your time (and money) is not wasted on an outdated product.

 

2. Decentralized Decision Making

The rigidity of Project Cost Accounting discourages autonomy and decentralized decision making. Decisions are made up front and can’t be altered. Project Cost Accounting doesn’t allow for variance from the original approved plan without a scope change and approvals up the chain.

I’ve seen teams wait weeks or even months for executive management to make a decision on something that impacted one team. That team could have easily resolved the issue on their own. The impact to both morale and the product can’t be undersold.

 

3. Flexibility

As I mentioned earlier, in a traditional planning model, a pre-defined scope with specific timelines is funded annually; neither scope nor timelines are evaluated or modified throughout the year.

LB Guardrails allow your product to evolve throughout the planning horizon. When the funding is released at the beginning of the horizon, there isn’t a formal static list of requirements that teams must follow. As the product evolves and customer feedback collects, teams have the flexibility to create what will provide business value that meets the customers’ evolving needs.

I’ve witnessed a customer identifying a feature that didn’t meet their needs and then their delight when that feature was quickly descoped so something else could be prioritized. I’ve seen entire products de-funded because the initial proof-of-concept didn’t bring the anticipated return on investment.

Instead of throwing more money after an approach that doesn’t answer your business need, reallocate the funding to another initiative! The flexibility to quickly evaluate and pivot assures that your company is spending money on initiatives that meet the needs now, instead of waiting until the end of the planning horizon to determine success. An even worse scenario is continuing to work on a product when you know it won’t meet anyone’s needs.

 

4. Product Lifecycle Visibility

In a typical traditional planning approach, the funding for a project is assigned for a year without looking at the life of the product. But the product is ever-evolving! Prior to creating a new product, when a concept is being explored, the funding model will be different versus when a product is being retired or decommissioned.

It’s critical that funding is available for the life of your product. LB Guardrails provide guidance on identifying and funding a product throughout its lifecycle. In my experience, without these guardrails, companies have a tendency to spend heavily on a new product, without evaluating the viability of the new product in the market. Additionally, they spend very little on products that are “stable” and the backbone of their enterprise. By evaluating all initiatives in the horizon model, you can be assured that funding is spent on the correct initiatives and keeping the foundational applications stable, secure, and continually providing business value.

 

What Does the Transition Look Like?

Moving from Project Cost Accounting to Lean Budgeting can be daunting. It requires commitment and collaboration from many parts of the organization. First, you’ll need to link strategic themes to products in preparation for the funding discussions. This will allow you to eliminate waste by not funding work that doesn’t tie to a strategic theme. You’ll want to have the key decision makers part of the Participatory Budgeting process to determine where the funding will be spent and assure buy-in across the organization. Plus, you’ll need to look at Governance to make sure the requirements for your industry are incorporated. And of course, for successful LB, the customer must be involved and committed to the product throughout the lifecycle. It requires giving the power of defining the product to the customer and letting it evolve through the planning horizon. That being said, once the LB foundation is in place, your organization will reap the benefits without the Project Cost Accounting headaches I mention above.

 

Are you ready to transition from Project Cost Accounting to Lean Budgeting? ICON coaches have experience enabling customers with sustainable, evolving improvements, including streamlining approval, funding and governance.