How can Shared Services team members––such as security, infrastructure, and end user training––effectively participate in Program Increment (PI) Planning? I’ve developed the following tips over the past 7 years of helping people adopt the The Scaled Agile Framework® (SAFe). I usually share them online and with colorful handouts.

This is the final installment in a 3-Part Series on applying empiricism in the time of COVID-19 and using hypothesis-driven approaches to adapting to SAFe^® and agile practices in the remote world.

The Process

We planned (Part 1), we executed (Part 2) , and now we learn and adapt!

For the conclusion of this series, I will apply lessons learned and use the proven After-Action Review method. Developed by the military and widely adopted by many industries, an After-Action Review is a structured review process for evaluating:

• What we intended to accomplish
• What happened
• Why it happened and what was learned
• How to improve moving forward

The following is a 3-part series on supporting Scaled Agile Release Trains and Agile Teams in the new 100% remote environment we live in.

Introduction

In my first post, I outlined 4 Enablement Actions that prepared the organization I am supporting to be successful in a 100% remote set of ceremonies associated with the Scaled Agile Framework® (SAFe). I also outlined the decision-making background and provided some details around my Agile Release Train (ART) and my Release Train Engineer (RTE). In Part 2, I provide some additional preparation details, as well as what went well and where there were challenges. Before we begin, I want to remind everyone of our hypothesis:

By having fun and enabling critical tooling so that our teams can conduct themselves as if they were ‘in the room/face to face,’ we can achieve a successful outcome from our Inspect & Adapt ceremony and maintain the 2.5 day cadence. By embracing empiricism, we could run a series of small, fun experiments, reinforce core Agile and Lean Principles, and prepare our teams to excel!

About a year ago, Marty Cagan, founder of svpg.com, posted an article saying that companies using the Scaled Agile Framework® (SAFe) and other scaling frameworks were just utilizing these frameworks as another attempt to command and control. Although Cagan admitted to not knowing much about SAFe, he claimed that it was just a metaphor for doing it wrong.

At the time, I was upset that a leading thinker in the areas of product development and customer focus had called out SAFe. I have used SAFe successfully at multiple Silicon Valley product companies to improve customer focus and connections to teams. However, I also had a deeper, quiet agreement with what he said. A lot of people were doing SAFe wrong, and Cagan had likely seen or heard of one of these “Cargo Cult” implementations.

The following is a 3-part series on supporting Scaled Agile Release Trains and Agile Teams in the new 100% remote environment we live in.

Introduction

Since 2007, I traveled weekly to my clients’ offices, where I trained, coached and supported teams using Agile, Lean and SAFe^®. I embraced the value of face-to-face communication, never supporting teams remotely for longer than a week or two. And then...COVID19!

COVID-19 has been an unwelcome catalyst into fully remote teams, but making optimal use of technology to keep in lockstep with business agility is a powerful illustration of the agile mindset. Recently, a large financial services client pivoted in one week to a fully virtual SAFe^® PI-Planning event with great success. ICON Coach Gillian Evans acted as Solution Train Engineer, and so we asked her some questions about what to consider in a virtual PI Planning.

OKR. OKR. OKR. If you’re like me, you’ve seen this acronym everywhere. OKRs, or Objectives and Key Results, are the latest craze in Enterprise and Strategy management. They sound simple and straightforward enough, but writing an effective OKR can be much more challenging than it seems.

The Agile Manifesto came about as a response to the software industry's need for disruption. Since its inception in 2001, it has helped in the production of higher quality software through more efficient workflow, which in turn has boosted customer satisfaction. The themes behind the Manifesto push for adaptability among organizations in a growingly complex and volatile climate. The four foundational values help not only in the delivery of functional and high-quality software, but also toward achieving an organization’s business goals.

We’ve heard the message of DevOps: Automate Everything.

Automate code testing. Automate workflows. Automate infrastructure. Create the no-touch deploy. Empower the application developer to deploy directly into production. Sounds simple enough, right?

As your organization begins its DevOps transformation, you may become preoccupied with automation, forgetting that there are other DevOps concepts to address in your environment. The Scaled Agile Framework® references CALMR (Culture, Automation, Lean Flow, Metrics, Risk & Recovery) to highlight the importance of more than automation in DevOps. In this article, we’ll address the other concepts to keep in mind while on the DevOps journey.

Every business is a software business.

While that statement may sound extreme, it emphasizes a current reality: digital disruption is changing the landscape of business. As Mik Kersten points out in his book Project to Product: “the tech giants that have mastered software at scale are expanding into traditional business…are mastering traditional businesses more quickly than the world’s established companies are mastering software delivery.”