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.

Agile, on the other hand, allows your teams to make decisions quickly. They can make efficient, incremental progress without waiting for a bottleneck decision-making body. Not only does this lessen the burden on top management, but it also allows for more accurate decisions by those who are fully aware of the reality of the situation.

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.

Written by Cathy McGraw

 

Cathy has 25+ years of experience in Application Development as a Software Engineer, Director of Application Development, and Scaled Agile Coach. As her career progressed, Cathy recognized her passion to help people and organizations mature in their careers and Agile journeys, and so for the last 10 years, she has been practicing and coaching Agile. As a SAFe-certified SPC, POPM, and SDP (DevOps) professional, Cathy has helped multiple companies initiate and deploy their Agile and DevOps practices. She has worked in numerous industries, including manufacturing, logistics, insurance, software development, broadcasting, utilities, and retail, where she has provided coaching and training for teams and executives.

 

More…

May 8, 2019

“There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things.”

Niccolo Machiavelli, The Prince (1532)

SAFe^® is all the rage, folks. With over 300,000 trained SAFe practitioners in demand all over the globe, including at over 70% of Fortune 100 companies, The Scaled Agile Framework^® (SAFe^®) is by far the most popular framework for scaling agile. Considering that Scaled Agile, Inc. started in 2010, this growth is no small feat. SAFe has a positive track record as the most viable framework for better solution delivery (just see one of their 50+ case studies), and many businesses may view it as the silver bullet to solve their modern value delivery problems.

As a lifelong learner, student of leadership, and Agile Coach who is a certified SAFe Program Consultant (SPC), I have seen firsthand the value of setting good expectations, realistic goals, and achievable outcomes. The following list is not exhaustive, but it highlights some of the potholes and misthink I’ve encountered that can spiral into real disorder, if left unaddressed.

Expectation #1
SAFe^® will fix our customer & business problems.

Reality
SAFe^® is not a silver bullet.

This may be the biggest misconception when a company starts their Transformation. SAFe will not fix your customer and business problems—it will expose them! You cannot change a process and expect to fix a misaligned organization with an unclear purpose. That requires change of people, process, tools AND culture. “Culture,” as Drucker once said, “eats strategy for breakfast.” Culture is the lagging indicator of the change. If culture is your problem, then SAFe will expose it, and it is up to you to take the time required to change.

Your customer focus will begin to clarify once you have a more collaborative, aligned company culture. Remember that this requires time, patience and leadership! Once everyone is aligned, then you can have a more strategic focus on the business problems that are preventing you from delighting your customers.

Expectation #2
SAFe^® won’t change business & operations.

Reality
They will change and it’ll be hard.

This expectation touches our #1 issue of culture, but also dives into the scary realm of change. Whether you like it or not, SAFe will touch on power structures that are typically immune from organizational change. This is an especially difficult adjustment for those who enjoy wielding their power and authority, as SAFe attempts to decentralize decision making to speed up execution. Significant disruption will occur in organizations with a high command and control culture. Consider nothing sacred!

Areas that will be impacted by the SAFe Transformation that are also high risk spaces for resistance to change include:

• Management derives organizational power from Budgets and Policy. These controls allow them to wield power with authority but not necessarily influence. They often see the loss of personnel or budget as a loss of power or decision authority. They can inhibit adoption by direct or indirect actions, such as withholding assignments, delaying decisions or claiming budgetary restrictions.
• Personnel derive their power from process and tools. They can control the rate of change by simply pointing out that tools or processes would be violated, and the tools and processes were established in order to institutionalize Management Policy. Once again, the change can be mitigated by stalling or avoidance.
• The third rail of a large enterprise includes organizational institutions that provide indirect support to customers but wield extraordinary amounts of power and influence. Departments such as Legal, Risk, and Human Resources could all find various ways to directly or indirectly impact your transformation (or better yet, join it!).

From James Belasco and Ralph Stayer’s Flight of the Buffalo: “Change is hard because people overestimate the value of what they have—and underestimate the value of what they may gain by giving that up.” This statement is completely applicable to SAFe Transformations. As an organizational change leader considering SAFe for competitive advantage, you must have a strategy for dealing with these top 3 risk spaces, especially with the third rail. Human Resources, for example, will need to reevaluate role definitions, compensations and personnel evaluations. Recall Mintzberg’s 5 P’s of strategy—Plan, Pattern, Position, Perspective and Ploy! You may not get it perfect the first time, but moving forward is the natural order of things. Start With Why, rally your people to the real problems, and empower them to unleash real solutions.

Expectation #3
The SAFe^® Transformation will end, we’ll be Agile.

Reality
You are never done.

“We’re done!” or “When will we be done?” are refrains that set you up for failure. Don’t bother establishing a deadline for ‘finding better ways to deliver value faster,’ because that is truly a false deadline.

McDonalds has never once thought that their service was ‘fast enough,’ or that their menu had ‘enough value.’ For 70+ years, McDonalds has continued to grow and innovate, offering an abundance of product offerings at all mealtimes in 35,000 locations in over 100 countries. And they’re still growing. While you may not be planning to serve 100 billion cheeseburgers, you can probably understand that the competition is trying to eat your lunch! Only when competitors stop trying can you consider standing still (hint: I still wouldn’t!). Don’t set false deadlines. Instead, use metrics and data to inform continual change plans. Continue to learn, improve, and transform; unless you decide to go out of business.

Expectation # 4
The change happens on a timeline.

Reality
The change must stick and sustain!

Sustainability! Sustainability! Sustainability! Sustainability! Sustainability! Sustainability! Sustainability! It is not enough to implement an Agile Release Train! Focus your efforts on making the changes sustainable! When time passes and change happens, the Agile Release Train (people, processes and tools) will need to be refreshed, retrained, and retooled.

Abraham Lincoln recognized the value of keeping your ‘edge’ in work. He said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” Our technology platforms are constantly changing, updating and realigning; our tools and needs are constantly in churn; and our people are changing, maturing, leaving, joining and learning. Develop a strategy around understanding and leveraging this knowledge for your competitive advantage. You will be glad you did! Don’t make the mistake of declaring victory in the first 6-12 months. No matter how successful you appear to be, the Lean-Agile mindset has not yet stuck and will not sustain without a strategy. Kotter talks about making it stick, I say you must also make it sustain! See Expectation #2.

Expectation #5
SAFe^® is an IT Thing.

Reality
SAFe^® touches the entire enterprise.

Although SAFe Transformations usually begin in IT, SAFe ultimately touches every aspect of the organization (again, revisit Expectation #2). It is not simply a ‘development team’ or an ‘IT thing’ or a ‘non-management thing’. It requires leadership action from everyone—daily, weekly and annually. It requires continuous learning, re-learning, adjustment, planning, and communication. It requires thought, vision, people development, team building, and decision making. In a single word, it requires Leadership.

I have seen a Transformation where the C Suite and the staff bought in, but the middle management layer did not. What resulted was a ‘false transformation’ phenomenon, where the company didn’t get the results they were hoping for, and so they stopped investing in the change activity. This is a real and common problem, and one that applies to all scaling frameworks. This is the C Suite failing to lead. Smokey the Bear used to say, ‘Only YOU can prevent forest fires!’ This could be your forest fire!

Ready to Deal with Reality?
Always return to SAFe^® Values and Principles.

SAFe is certainly attractive. It provides some great ‘out of the box’ starting points for using agile solution delivery teams. There are clearly defined roles, responsibilities, and ceremonies, all of which can be implemented within your current organizational structure. In today’s technology landscape, this means that SAFe is applicable to just about every sized company in every industry.

But SAFe is not revolutionary; it is evolutionary. SAFe is a journey! Rather than looking at SAFe as your cure-all, look at it as an educational starting point toward continuous learning and adjustment. Follow and embrace the SAFe Values and Principles, alongside your own organizational values and principles. No two companies have the same strengths, weaknesses, customers and problems, so it is unlikely to find a perfect, detailed roadmap for your specific journey, but it is possible to use SAFe as a guide and rely on experienced coaches to point out some potholes!

SAFe core values: Alignment | Built-in quality | Transparency | Program execution

SAFe principles: #1 – Take an economic view #2 – Apply systems thinking #3 – Assume variability; preserve options #4 – Build incrementally with fast, integrated learning cycles #5 – Base milestones on objective evaluation of working systems #6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths #7 – Apply cadence, synchronize with cross-domain planning #8 – Unlock the intrinsic motivation of knowledge workers #9 – Decentralize decision-making

By starting with the SAFe values and principles, you can look at your business opportunities, risks, priorities and challenges and get a sense if SAFe is a good fit for addressing the challenges your organization faces. Keep in mind that it will potentially call into question how you do business, what you value and how you present your value proposition to your customers. If you are looking at SAFe, then you already believe there might be problems, or at least potential problems, with the current order of things.

If you are planning to start a SAFe Transformation (or maybe you’ve started but could use some guidance), I encourage you to reach out for help. An experienced outsider, specifically an experienced SPC who has been involved in several transformations, can help you put things into perspective. Whether you want assistance in building your roadmap and strategy or are in deep need of a cultural assessment, contact us! We’re here to help.

Written by Travis Reed

 

Travis is currently on his third career, drawing his passion for helping Organizational Leaders implement ‘Good Change’ in their organizations using Agile, Lean, and other practices. He has led multiple Enterprise-wide Re-engineering efforts within the context of Digital Transformation, Agile Transformation, and efforts in Lean/Lean Six Sigma. His energy and passion are powered by his experience in System and Software Development and Support for over 25 years, as well as the problems he encountered and the learnings he developed. He retains multiple industry certifications including SAFe Program Consultant, Certified Discipline Agilist, Enterprise Business Agility Strategist, and Lego Serious Master Strategist.

 

More…

Oct 25, 2019

Do you find that your teams and Business Owners have a hard time digesting PI Objectives, what they are and their purpose in PI Planning? Their PI Objectives can end up sounding more like features (“Add the green widget feature to the purchase screen”), and sometimes they are ignored entirely.

Neither scenario is okay. If your company wants to create successful business outcomes and meaningful value for its customers, then everyone needs to know what PI Objectives are, why they’re important/useful/cool, and how to pitch them. In other words, the successful application of the Scaled Agile Framework® (SAFe) depends on a clear understanding of PI Objectives.

In this article, I’m going to share my favorite way to explain PI Objectives to teams, which has something to do with a popular TV show involving sharks. But first, a refresher on the what and why.

First, what are PI Objectives?

SAFe PI Objectives are a “summary of the business and technical goals that an Agile Team or train intends to achieve in the upcoming Program Increment (PI).” Simply put, they’re big goals around the real value that teams are delivering. To paraphrase SAFe Fellow Eric Willeke, PI Objectives exist to help the teams and the Business Owners align on the value and scope, focus on outcomes instead of outputs, and give us an easy summary rather than a long list of features. We use them to communicate up, down, and sideways in the organization, so they need to be in clear business language.

Sometimes, teams mistake a PI Objective for a feature. A PI Objective should be based on one or more features, but I’ve rarely seen a feature talk about the value it’s delivering. Of course, if you’ve got a good feature benefit hypothesis, then you’re probably more than halfway there!

Why PI Objectives?

You might read lots of blogs, newsletters, etc. that say agile isn’t giving the intended benefits. This often stems from misalignment between what the Customers/Business want and what the IT teams produce.

SAFe provides PI Objectives to help with the disconnect. During PI Planning, the teams create PI Objectives and pitch them to the Business Owners, who then discuss them with the teams. Next, the Business Owners work with them to express differences, come to a mutual understanding, and score the PI Objectives. If PI Planning is about alignment, then this mutual understanding is one of the best “Alignment Moments” of a PI Planning event.

What About the Sharks?!

OK, I promised you sharks. But first, a story (I’m keeping you on the hook for just a bit longer).

The night before a PI Planning with a former client, I struggled with how to teach the concept of PI Objectives in a way people would understand. Munching on pizza, I flipped through the channels in my hotel room and came across ABC’s reality show Shark Tank…and was amazed how the context of the show held uncanny parallels to pitching PI Objectives.

In Shark Tank, aspiring entrepreneurs get 90 seconds to pitch their product, followed by Q&A and discussion with five titans of industry, aka “the Sharks.” Once the Sharks understand and align on the pitch, they decide to invest—or not.

How nicely this premise transferred to PI Objectives! I started taking notes. Teams would be entrepreneurs. Business Owners (Business and IT) would be the Sharks. Teams would spend about 90 seconds making a business pitch for what they were going to work on for the next 4 iterations. The Business Owners would listen to understand and align on the pitch, and then they would make the investment decision by scoring the PI Objectives.

The next day, I shared the Shark Tank analogy at PI Planning. Most people had seen the show, and it really resonated with the whole train. They loved stepping into Shark Tank; not only did it help them explain their bigger goals and how they related to the larger system, but it also inspired them to have fun. There was only one person who hated the idea, but then even he became a promoter after his first Shark Tank discussion.

At one point, I had a team who presented their PI Objectives and the Sharks (ahem, the Business Owners) didn’t invest. Instead, the Sharks came back to that team and helped them find something they would invest in. While it might sound bad that the Sharks didn’t “invest,” think about the time and money saved by having that conversation before anything got built!

Wrapping Up

I hope that the Shark Tank analogy helps you think of PI Objectives in a new way. If you need additional help coaching PI Objectives and would like some excellent examples of concrete PI Objectives, then please view our free download with more information. Our goal is to help you teach and coach PI objectives in a way that makes sense to people.

Additional Reading

• Charlene Cuenca, ICON Principal Consultant and SPCT, presented “The Synergistic Nature of PI Objectives” at the 2018 SAFe Summit. View her slideshow to learn more about how PI Objectives shift focus from output (Feature/Story completion) to outcomes (value delivery).
• John Cutler wrote a really great article called “12 Signs You’re Working in a Feature Factory”. Read this and think about #9 and #10 as they relate to PI Planning.

Written by Randy Smith , SPCT

 

Randy is a Consultant, Trainer, Agile Transformation Coach, and SPCT. He believes that a transformation is about more than adopting a framework—it’s also about meeting people where they’re at to help them create an optimal human system that can happily and effectively deliver value to customers. Randy has more than 2 decades of experience in the industry and has worked in several sectors, including tech, manufacturing, shipping, financial, and medical firms, and he has served many roles like developer, test management, release management, support, etc. He started using Agile principles and values with a team in 1999, got his SPC in 2014, and completed his SPCT in May 2019.

 

More…

Jul 2, 2019

The first type of meaning is the one most people are familiar with. It’s the denotation meaning and is the specific or primary meaning of a word; its literal meaning. The second type is the connotation meaning and is the subjective meaning of a word based on personal experiences, emotions, or beliefs. If you’re not fully aware of a word’s connotation, it may lead to confusion and/or misunderstanding with the person or people you’re trying to communicate with.

This is where the great agile transformation misunderstanding begins. The word “agile” is a major buzzword in today’s industry. Every organization wants to become an agile organization and every software team wants to call themselves an agile team. As an Enterprise Agile Coach, when I hear a company wants to go through an “agile transformation,” the connotative meaning for me is a positive one. For me, this implies an enterprise-wide agile transformation; and this is where the connotative meaning makes all the difference in the world.

Three different types of agile transformations

Over the past several years, I’ve noticed an agile transformation tends to fall into one of three different connotative meanings:

1. A team-level transformation
2. A scaled-level transformation (program and/or portfolio)
3. An enterprise-level transformation

The first level, a team transformation, is generally focused on software teams in their adoption of agile practices such as Scrum, Kanban, and/or DevOps. An Agile Team Coach, commonly referred to as a Scrum Master, is the main agile role. A good Agile Team Coach coaches the team to continuously improve their performance and the way they work.

The second level is the scaled transformation. This is where a company has many software development teams that need to work together to release a product. There are a variety of scaled agile frameworks such as LeSS, Disciplined Agile, Scrum@Scale, and SAFe. Each of these scaled frameworks has their own connotative meaning with people, so I will not go into the details of them in this article.

Scaling agile is far more challenging than simply teaching Scrum or Kanban at the team-level. If a company cannot do team-level agile well—and they attempt to scale it—then they will scale all of their team problems and challenges, increasing the likelihood of a failed transformation. This is where a program-level coach may help.

A program-level Agile Coach will often be seen at this second level. A good one will be familiar with one or more of the frameworks and can help the company choose the best fit for their organization. This person may also be a “Coach of Coaches,” or someone who helps less experienced Agile Coaches improve through training, coaching, and mentoring.

The third level of a transformation is the enterprise-level. When a business decides they want to become an agile organization or increase their business agility, this is the level they are generally referring to. A successful enterprise agile transformation includes non-IT areas such as Human Resources (HR), Marketing, and Finance. Contrary to popular belief, enterprise agility is not about scaling agile across the enterprise; it’s about de-scaling the enterprise, becoming more lean by reducing redundancies and improving efficiency. It also has nothing to do with technical practices commonly found at the software team level.

An Enterprise Agile Coach is often found at the third level to help the entire enterprise keep up with the speed of the customer. He or she teaches the enterprise how to pivot quickly and shift priorities with minimal disruption. An Enterprise Agile Coach also helps solve systemic problems that exist throughout the company, such as breaking down silos.

All three levels have different areas of focus and require different skill sets. I am not saying one job (Agile Team Coach/Scrum Master, Agile Coach, or Enterprise Agile Coach) is better than the other. I am saying it is extremely important to choose/hire the right skill set for the level of transformation your company wishes to transform. Otherwise, hiring the wrong person will cause your company a significant amount of money, stress, resistance, and frustration.

Clarify your level of agile transformation

Remember the importance of connotation; especially when it comes to an often misunderstood term such as “agile transformation.” What we mean and what people hear are not always the same. To help with any misunderstandings, when you hear someone talking about an agile transformation, ask them to clarify which level they are referring to. Likewise, make sure you clarify the level yourself.

What other ways have you noticed “agile transformation” been misunderstood? Please share your thoughts and feedback with us.

Until next time, continue learning and good luck on your agile journey!

Written by Frank Rios

 

Frank is a highly experienced and sought-after Agile Coach and trainer with strong leadership and organizational skills. He is a frequent contributor to local conferences and has published several articles on LinkedIn with very positive responses. He was first exposed to an Agile framework called eXtreme Programming (XP) back in 1998, where he fell in love with the idea of empowering teams, fast iterations, and coaching. Over the course of 20 years, he has obtained many professional Agile certifications, including a LEGO®️ SERIOUS PLAY®️ Facilitator Certification. As a mentor, trainer, and facilitator, he has taught Agile to well over 1000 people all over the world, individually, in formal classroom settings, and at conferences. He is a certified Enterprise Agile Coach with experience in successfully leading global Enterprise Agile Transformations as well as Team and Scaled Agile Transformations in both IT and non-IT organizations.

 

More…

---

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!

A brave new world!

As with most people who read this, the teams I support and I were disrupted. Suddenly, I had to meet the world from where I was, and meet my teams where they were—online. An agile coach’s number one responsibility: meet people where they are!  It is the only way to be the coach they need. It is a rule I have learned and lived by for many years.

So where were my teams in terms of work, and how could I meet them there?

When quarantine began, the teams on the Agile Release Train (ART) that I coach had just completed their second Program Increment (PI) Planning week. The teams were immature, in that their first PI had been extended by leadership. Only recently had a full-time Release Train Engineer (RTE) been hired to lead the ART. The teams’ agile and engineering practices were just beginning to be enabled. They were not fully engaged at the Program Level. Our Product Management Team needed to do a better job with preparing for PI Planning and working to sequence value into the delivery teams. They were generally working through a backlog that had become stale and bloated. This left them unfocused, working on too much and on outputs, not outcomes. However, I must note that they are highly motivated, exceptional individuals who are genuinely interested in doing the right thing and embracing change. I am lucky to get to work with them!

Since this time, we have worked 100% remotely, and this week is our regularly scheduled PI Planning. This first part in this series will cover the preparation for the 2-day remote PI Planning event, including an Inspect & Adapt (I&A) ceremony. I will discuss how we arranged for the teams to be as prepared as possible. In the following parts, I will discuss how the events unfolded (Part 2), and then a retrospective on how things went and what we learned (Part3). Hopefully, if you are reading this, you will find value in the challenges that you have in front of you or your teams.

 

---

Preparation for PI Planning- Actions Taken

Eisenhower is famously attributed with the statement, “Peace-time plans are of no particular value, but peace-time planning is indispensable.” In other words, the real value is not the output of the planning, but learning from the act of planning. I believe in this paradigm and have often quoted this same saying (usually loosely) in many of my agile trainings.

My ART is currently operating on a 10-week increment. The increment started on March 5, 2020. On March 12, 2020, we went into an ordered lockdown. On March 13, our first Scrum of Scrum and Product Owner Synchronization coordination ceremonies were scheduled.

Previously, our ART had used a physical PI Board, a list of ART Risks and Program Objectives, to evaluate where we were, if we were on track, and where we needed to adjust. In a remote world, this was an example (only one!) of the changes immediately impacting our teams. It was the first symptom of how we needed to start adjusting and adapting.

After the meeting, we began to evaluate how to make Work in Process better and how to enable the teams to complete larger effort ceremonies and get value from them (See SAFe Principle #6). We took four major actions.

 

Action #1 – Enable a Virtual Program Board.

For this action, we needed new software to deliver a virtual program board that teams could collectively read, update, comment and collaborate around. It needed to trace Business Objectives to Milestones, to Features, to Dependencies.

• ‘Decision: After a short evaluation period with several tools for online collaboration, we decided on Miro.
  • ‘Alternative Tools Considered:
    • Mural
    • OneNote
    • Shared Drives/Cloud Storage & Google Drive

• ‘Decision Background: Several drivers formed the basis for the decision…

1. ‘The company had licensing agreements in place
2. ‘Miro had built in template for a PI Board
3. ‘Integration with ALM tooling

Quickly converting the physical board into a virtual board allowed us to begin a 2-fold effort to move forward. First, it allowed us to collaborate and rally around our plans. Second, it allowed us a planning platform to move into the next effort, the larger effort.

 

Action #2 – Enable a collaboration platform.

My client recently migrated from legacy Office Productivity Suite to the modern Office 365 Platform (O365). The primary tooling used for open collaboration was Webex, which left some opportunities on the table, so we considered other options.

• ‘Decision: After a short evaluation and several experiments using gamification, we decided to use Microsoft Teams‘. This platform enabled significant improvements over Webex and other tooling. Chief among them was the ability to create multiple meetings and breakout areas where people could jump quickly into and out of meetings. This made it easy for leadership, who might not be in the daily meetings, etc.
  • ‘Alternative Collaboration Tools Considered:
    • Webex
    • Zoom
    • Skype

 

Action #3 – Enable our people.

Before adopting Miro, we believed that people would quickly embrace and adapt to using this virtual tool. We never considered a learning curve. It was jarring for some people to go from ‘walking to a board and moving a post-it note’ to hand-eye coordination and inherent understanding that when you grab a virtual post-it, you might also move the entire board around!

In my next post, I will review the outcomes from Days 1 & 2 of PI Planning, as well as the Inspect & Adapt ceremony. I will tie the ‘enable people’ part of the outcomes where they succeeded or failed. In the meantime, here is a downloadable reference sheet I produced and shared previously in a blog post.

 

Action #4 – Gamify!

One of my early observations was the ‘confirmation bias‘ in remote teams—they were not challenging each other to try, learn, and change. The disruption pushed people to safe spaces and isolation. Their largest reach was strictly at the team level. When interacting with the RTE, they did not experiment and relied on the RTE to provide any needed change. This was a noticeable change from the office.

We decided to combat the passivity by creating a fun learning environment. In my next post, I will detail some of the specific actions and outcomes around creating a fun online learning environment. I’ll share what we did, how it impacted the teams (short-term and long-term), as well as any observations from the event, things I might change, and how I might adjust our approach.

 

---

What can we gain from preparation?

‘From these four actions, we developed the following 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.

Until my next post, stay safe! I look forward to reporting back soon.

Finally, take care of your people in these trying times. They are still the very best asset you have in your organization!

 

Need virtual PI Planning? Get Guidance from experts

 

In this next section, 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!

---

Inspect & Adapt (I&A) – Observations

Our I&A was a half day that consisted of:

1. System Increment Demo and Business Value Assessment
2. Quantitative Metrics
3. Problem Solving Workshop

All went very well! In this short interactive session with 80+ people on a Miro board, we had limited validation of the hypothesis; however, we learned that the teams could work without interruptions from each other, navigate effectively into breakout sessions, and deliver the desired outcome of each of the ceremonies.

Biggest lesson learned: Create an Agenda, including links to the objects in the Miro Board, lists of participants and links to rejoin/find the meetings.

It helps to post the Agenda in the following places:

1. In Microsoft (MS) Teams, or your collaboration meeting tooling
2. In the email invites
3. On the Miro Board. Just make it easy to find! Here is a sample agenda (all personal and client information has been removed):

 

---

Enabling a Collaboration Tool – Decisions Made

To support our ART before the event, we had to adjust to MS Teams. Initially, it was rolled out as part of Office 365, but there was no plan to align the ARTs in a common way. With the entire organization forced to work remotely, the MS Teams rollout accelerated, resulting in a change and a new tool for many folks.

To support our work, planning, and fun, we decided to make MS Teams our essential daily collaboration tool. We organized and leveraged the MS Teams Architecture to support open collaboration and transparency. The picture below demonstrates how we structured MS Teams.

If MS Teams is your current tool but you are unfamiliar with its underlying architecture, then it will be worth some research. The backend is a SharePoint server that enables file storage, search, communications and integrations with calendars, and other critical tooling that enables many core activities on an Agile Release Train.

When we decided to go all in with MS Teams, a series of additional ‘Centralized Decisions’ paved the way for really unlocking some efficiencies, which easily have delivered more than the Return on Investment in reuse, productivity, and open collaboration.

 

Some Decisions Made around MS Teams:

• Every Team Ceremony is published in the MS Teams Channel Calendar.
• All Ceremonies are in MS Teams, excluding when MS Teams is down (note: we have had no downtime since we started working remotely). Our backup is WebEx.
• All MS Team and System Demos are recorded and published via Stream.
• All Increment Readouts are now recorded in MS Teams. They had previously been recorded on cell phones and uploaded, which often took hours due to restrictions on corporate policy on uploads.

Benefits & Outcomes

• Enabled Communications
  • The Agile Teams are using MS Teams as frequently as they would meet ‘face to face’ in the office for phone calls, video meetings and ad hoc collaboration activities.
• Increased Productivity
  • Due to internal changes, it is not a 1:1 comparison but worst case there was a 22% increase in productivity, in the best case it was as much as 56%
  • I would at least partially credit this to ‘seamless’ communications available on Teams between Chat, Calls, Video Conferencing and general Information sharing.
  • The Increment started before COVID and the ART was forced to work remotely, and still there was a significant productivity increase.
  • The teams realigned after the previous PI, so many teams were new, had new members, or had been realigned.
  • Added a new Scrum Master and new team members during the increment. MS Teams was their primary way of ‘meeting’ their teammates.
• Increased Efficiency
  • The simplification of one tool with transparent access to its information, ease of use, optimized reuse and consolidated information access meant team members did not need to search to find pass codes, meeting updates, etc. They went to their channels and information was consolidated in a single place; ART information was likewise consolidated. If a team member missed a demo, they viewed it in Stream.
  • Product Management could ‘attend’ every Iteration Review & System Demo and give feedback because they could view all the contents in a single day and make adjustments before the next iteration began. Previously, their time had been split between multiple events due to the number of teams on the ART. Prior to the Demo, Product Management culled most of their presentation for Business Value scoring from the video recordings of their Iteration Demos, and where needed extended or performed additional demonstrations. Their presentations were also shared via Miro Boards if someone was interested in viewing them but could not attend the event.

Implementation

• We provided dedicated training and coaching to the Scrum Masters and Product Owners using MS Teams.
• We held ART-wide virtual Happy Hours and had team challenges, games and other activities that required:
  • Moving From one meeting to another and back
  • Interacting in an MS Team environment while simultaneously interacting with other tools
  • Explaining the organization of the MS Teams structure
  • Providing recorded training content for additional features within MS Teams
  • Publishing recordings via MS Teams & Stream, with tagging for search capabilities
  • Exposing barriers to optimized MS Teams experiments (faulty headsets, equipment policy restrictions etc)
• Began utilizing Yammer for amplifying the recorded content throughout the company, engaging the wider Stakeholder group more frequently and visibly.

 

---

Enabling the Virtual Program Board and Our People – Decisions Made

As previously mentioned, we decided on Miro to use as our planning platform. The reasons listed were discussed in my previous post. Much of the learning about how to enable our teams came fromusing Miro early on to migrate our physical board during the PI in execution

The big decisions here were around preparation of our teams. As a coach working with a new RTE, I decided to assist in materials setup and preparation for the actual events. I created/customized templates within Miro and provided training/support, as well as game design for the learning activities used in Miro. I created games, contests and activities to ensure that core capabilities were developed. I ran several workshops, as I prepared my RTE to deliver similar workshops. He excelled and was a fantastic leader!

 

Benefits & Outcomes

• Enabled Core Capabilities – The Agile Teams engaged in several learning sessions that enabled and accelerated their use of Miro, Mural and MS Teams. Games included:
  • Identify your teammates’ baby pictures
  • Trivia
  • Build a picture
  • Complete a process
  • ‘Seek and Find’ on a board
  • Work within a team environment
  • Team Happy Hours
  • Open Sandbox for learning
  • Separate Product Owner and Scrum Master training for advanced skills

• Increased Efficiency – The teams became incredibly effective. Their feedback was that using the virtual tools enabled better productivity, team cohesion and planning due to the ability to quickly see the ‘whole’ picture, as well as their piece of the picture throughout the planning process.
• Increased Team Cohesion – A side effect of these activities was that the teams actually began to know more about each other and learned higher trust and established better relationships. This was especially interesting, as a large number of key roles were new hires, including several people who have never met their teammates face to face.
• Supporting reusable utilities – In addition to the referenced learning, we also looked to optimize the use of the tools by creating reusable utilities that enabled faster content creation in Miro and other planning utilities.
• Team Happiness – The team enjoyed the use of the tools and commented about using the tools going forward. They generally responded very positively to the events and their ability to finish planning in less time than previous events.

To bring the plan together, we decided to create a backup tool for each and every activity. The use of the custom utilities enabled us to quickly adjust if the primary tooling failed. The sample chart below outlines our plan. Additionally, the RTE and I conducted several partial walkthroughs and prepared to have me monitor all ceremonies and provide direct feedback to the RTE about issues, as well as troubleshoot any issues that arose around access, tooling and setup.

 

---

Conclusions

By the final walkthrough of the plan, my RTE was confident and prepared. Each team member completed a checklist, creating specific set-up steps within the planning tools. These steps not only ensured that they knew how to do each task, but also provided them with explicit instructions that left an audit trail, allowing the RTE and I to ensure they could complete the tasks.

We were ready, and we knew it!

In summary: We made a plan based on our hypothesis, putting in place and running specific experiments. We learned from them and used the outcomes to adjust where needed. Because we applied empiricism, we felt that we achieved what we had set out to do.

In the next and final section, I will share some details from the retrospective and observations of the event. Until then, take care of your people in these trying times. They are still the very best asset you have in your organization!

 

Need virtual PI Planning? Get Guidance from experts

 

Contact Us

---

Retrospective: The Process

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

In order to be true to the process and to remind readers what we were attempting to do (our strategy), our original hypothesis is restated here (what did we intend to do?):

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!

 

---

Retrospective: What Happened

So how did we execute relative to our strategy? What did we do? The Release Train Engineer (RTE) and I developed a strategy of using gamification to introduce new tools and methods to the team. Our goals were to:

1. Develop several key skills
2. Introduce new tools
3. Strengthen team cohesion

To achieve these goals, we outlined the skills and built team-based games and competition, then scheduled learning times, including:

1. Team-based Training
2. Team Happy Hours
3. Individual Learning Opportunities

 

---

Retrospective: Why it Happened

When we evaluated our situation, we looked at several things:

1. Time to prepare
2. Things that needed to be accomplished
3. Separating teams learning
4. Target key roles (Scrum Masters (SM) & Product Owners (PO))
5. Setting a good cadence

The table below outlines our plan of action, including objectives (outcomes sought) for each group, and the cadence, as well as our observations from putting the objectives in place. Note: By reviewing the cadence, you can scale this to meet your timeline.

Objective	Target Group	Cadence	Observations
Introduce MS Teams	SM PO Teams	Daily   Weekly Bi-Weekly	Using MS Teams daily enabled the teams to gain comfort with key, basic functionality and enabled better transparency about the teams’ work (see Part II) Using MS Teams weekly, in our Scrum of Scrums and PO Sync, as well as targeted training with these leadership groups. We scheduled biweekly Happy Hours with games to develop the team cohesion, and to expose the teams to using breakout rooms, and other advanced features in MS Teams.
Introduce Miro, Mural Virtual Collaboration Tools	SM PO Teams	Daily/ Every other Day     Weekly     Bi-Weekly	Using MS Teams & Miro (Mural) for collaboration regularly enabled the SMs & POs to gain comfort with key, basic functionality and enabled better visibility & Risk Management (SoS & PO Sync) Transparency about the teams’ work and coordination. Used MS Teams weekly in our training with these leadership groups. It enabled breakout functionality and recording and MS Stream utilization. The scheduled Happy Hours with games required Team to interact with breakout rooms, video content and interactions with Miro, Mural and Mentimeter.  These activities taught key skills in a fun way.
Custom Utilities and Processes	SM PO Teams	As needed	There were a number of additional skills and utilities that we built and designed to make work flow faster and smoother. Our Application Lifecycle Management tool is Rally, and we did not have API Integration in place. We also designed several processes that enabled efficient use of time and made people comfortable and confident.

 

 

---

Retrospective: Other Findings

The main learnings and adjustments made were around optimizations and tailoring the learning to the groups we were working with. We observed positive iterations, and the feedback reaffirmed the purpose for our strategy. We witnessed the teams working better and making their own adjustments, while also seeking out optimizations. They became increasingly interested in challenging our games and demonstrated interest in learning more advanced techniques.

After the PI Planning, we conducted a few retrospectives. The first was an instant retrospective at the conclusion of the 2.5 days of activity in the form of a Word Cloud.

The second was a survey-based retrospective, allowing for more detailed data collection to enhance our feedback loop. There was also an open feedback option after each rating, which is the second Word Cloud.

 

 

---

Adapting the Strategy

How will we refine our execution for a better outcome and repeat our successes?

The feedback (as shown above) was mostly very positive. I believe our biggest learning was that we should’ve enlisted our teams more openly to design their best work environment. For next time: Create the hypothesis around the outcomes we seek, then unleash the teams’ creative talents to find the best way to learn and design in a continuous loop!

Some additional minor adjustments might be made around timing and coordination. Based on our situation, we could have done a better job on aligning in a sequential learning model. We also could have communicated our intentions better and ensured that people understood how to prepare for the sessions. However, I believe that, in large part, gamifying the exercises offset the learning and made it a fun trial-and-error experience.

In the end, I was more than pleased with the outcomes of the exercises. More importantly, I observed an immature Agile Release Train bond, excel, and mature, even exceeding the expectations of the Scaled Agile, Inc approach of extending the PI Planning to more days, not the same or less days.

The teams’ feedback was about keeping the virtual tools, moving away from physical boards and rooms for space—it was all about collaboration optimization.

I expect that moving forward, the key learning of the teams will be that they CAN and SHOULD challenge the status quo. In the end, they became believers of empiricism and embraced the risk-taking of continuous improvement and learning. It was wonderful to watch teams mature quickly and embrace things it often takes other teams years to achieve!

 

---

Final Thoughts

If you can unleash your very best asset, your people, and meet them where they are, the likelihood of achieving your goals is higher than beyond your expectations. It is truly unleashing the power of the agile mindset and developing lifelong learners, masters of the hypothesis-driven method.

I hope you enjoyed the journey with me and my teams. It has been a powerful reminder of the power of the human spirit to not only succeed, but exceed!

Embrace your people, meet them where they are, empower them to drive forward, protect them, and provide for them to embrace manageable risks. Then enjoy their achievements and encourage them to do better next time!

Thanks for coming along on the journey!

Until next time!
 

Need virtual PI Planning? Get Guidance from experts

 

Contact Us

Written by Travis Reed

 

Travis is currently on his third career, drawing his passion for helping Organizational Leaders implement ‘Good Change’ in their organizations using Agile, Lean, and other practices. He has led multiple Enterprise-wide Re-engineering efforts within the context of Digital Transformation, Agile Transformation, and efforts in Lean/Lean Six Sigma. His energy and passion are powered by his experience in System and Software Development and Support for over 25 years, as well as the problems he encountered and the learnings he developed. He retains multiple industry certifications including SAFe Program Consultant, Certified Discipline Agilist, Enterprise Business Agility Strategist, and Lego Serious Master Strategist.