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.

Apr 5, 2019

Despite these difficulties, most companies feel compelled to hire these Waterfall-oriented vendors because vendors have better expertise in a technology, process, or application. Companies invest in and trust the vendor to build the right things.

Those of you who have survived a SAFe^® Transformation may also be thinking that vendor selection meets all three characteristics of a centralized decision, according to Scaled Agile.

• Infrequent decisions that may require deeper consideration
• Long-lasting decisions that are unlikely to change
• Expensive decisions that involve large amounts of money or time

You don’t hire vendors very often, and you hire them for large initiatives that take a long time and cost a lot of money.

But if your company is going to invest in building the right things at the right time, then even with a centralized selection process, you should consider decentralizing your vendor management processes. Let your vendor worry about the details, while you maintain your product vision and ensure that your future development addresses your business needs.

If your company is operating in an Agile fashion, why would you continue to use a process that is decidedly un-Agile (infrequent, long-lasting, and expensive)? How do you manage agile requirements when you create a fixed-price contract that has clearly defined deliverables and a six-month timeline? The answer is: you don’t. Sure, you can break up the deliverables into Epics, Features, and User Stories; but, at the end of the day, you’re still operating against a fixed-date and won’t be able to respond to the instability in the development process, leading to long hours, missed deadlines, and delivering over-budget. Not only that, but there are many initiatives that will eventually demand significant changes such as changing scope, dates, or even changing the vendor themselves. If you’re on a fixed-price contract, you won’t be able to do anything about it.

Since it doesn’t make sense to deliver a fixed-date fixed-price contract in an Agile environment, we can look to another type of contract for inspiration: Time and Materials. A T&M contract is used when a vendor is paid on the basis of actual labor, cost of materials, and overhead. If you’ve ever had to renovate your home, or even just had a plumbing emergency, you’re probably intimately familiar with a T&M contract. But you might be wondering— how could this possibly apply to a technology vendor? Well, start by thinking about how you could pay a vendor based on actual labor rather than fixed-price. There are three approaches you could take:

• Pay by the hour
• Pay by the story point
• Pay by the sprint

Some immediate gains you would realize with any of the approaches listed above are:

• Increased control over your design – you can change your requirements at any time because the contract doesn’t stop you. As long as the cost is justifiable, fire away.
• Increased control over project cost – By not committing to a price upfront, you can pivot or streamline as needed. You may even be able to funnel your cost into the highest performers for a longer period of time, rather than distributing it across many others.
• Iterative development – The flexibility gained by having your vendor deliver functioning software that can be measured against every sprint is invaluable. Not only do you get working software that is an objective measure of progress towards your goals, but also your vendor has the opportunity to prove their value every two weeks. If they’re not measuring up, you have the flexibility to go to someone else.
• Small commitments – When you sign a contract for X hours/points/sprints rather than a fixed scope, you can manage your work much more efficiently because you have natural points at which you can pivot. Additionally, if your commitments are small enough, you may not need to go through a formal RFP process. Think about how much more quickly you can respond to changing market conditions if you don’t have to go through your own internal legal or purchasing processes.

One thing to note is that for any of these approaches to be truly successful, you need to have a highly collaborative relationship between the hiring organization and the vendor. Any of these metrics can be inflated, “my team does 30 stories a sprint and they’re all 20 points.” As long as no decisions are being made in a silo, and both parties are present and engaged in the agile process, you will be protected from artificial inflation.

Additionally, If you structure your contract so that you pay by the story point or by the sprint, you’ll realize an additional benefit:

• Increased control over quality – Given that in Agile, you only get credit when work has been accepted, you will only pay for the work that has been completed to the quality your Product Owner expected. Otherwise the work has not been accepted and will not be counted.

You may be thinking that this all sounds good, but how do you actually write an Agile contract? Your primary goal is to structure your contract so that you pay based on the amount of work actually delivered; however, there are other things you want to keep in mind when you are writing your contract as well. The point of an Agile contract is not to list out the requirements and specific deliverables, but rather to help define the working relationship between the client and the vendor. You may recognize this concept as similar to a team creating a working agreement. You want to not only define the relationship, but also ensure that the contract includes adequate protection and risk management strategies for both parties.

If you can embrace these guidelines, ensuring that both you and your vendor understand how you will work together, what metrics and measures you will use to assess project health, and how your monetary relationship will be tied to objective progress, you will be in a strong position to deliver your projects on time, under budget, and with minimal disruptions.

I know I’d like to be running that relationship.

Written by Saahil Panikar , SPCT

 

Saahil has been a leader in transforming organizations and teams by helping them master Agile and Scaled Agile best practices for over 10 years. He is a passionate Agilist whose thirst for continuous improvement led him to his first Agile Transformation in 2013 and has caused him to push the envelope ever since. He has experience working with large-scale Agile initiatives in a variety of contexts. He has worked with start-ups and small businesses, the Federal Government, and Fortune 100 companies.

 

More…

Jan 10, 2020

“Big wheels move slowly” is a saying often used as an excuse for slow delivery, yet the tech giants continue to grow AND move quickly. They look at business differently and don’t embrace all the structures and management practices from the past. They recognize that many of these constructs have now become impediments to remaining competitive in today’s market.

So what is different about these fast-moving behemoths that allows them to enter traditional markets and thrive? A casual observer might assume that tools and infrastructure are giving them the competitive advantage, but these are just byproducts of what really fuels the nimble giants: it’s a new way of working; it’s alignment in delivering solutions at scale; it’s business agility.

While Agile may have originated with small teams of software engineers, it’s grown to encompass teams of teams, delivering solutions that synthesize both digital and traditional. Essentially, Agile has matured and scaled so that the resulting practices and structures require alignment with the entire enterprise and impact other business areas. Traditional businesses need to transform so that they can remain competitive, and different Agile scaling frameworks have emerged to address this need.

Of the various frameworks, I believe that the Scaled Agile Framework® (SAFe) 5.0 is the one that best addresses the most common questions and solves the critical need to transform for today’s business environment. In this article, I’ll tell you what you need to know about SAFe 5.0 and why the Lean-Agile Leadership competency in particular is so crucial to maintaining a competitive advantage in an era of digital disruption.

SAFe® 5.0 and the 7 Core Competencies

SAFe 5.0 is a significant evolution over 2019’s SAFe 4.6 framework, casting a vision for business agility and defining it as: “the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative business solutions.” (© Scaled Agile, Inc.)

SAFe 5.0 is market-driven and centered on the customer. It identifies seven core competencies and the corresponding techniques to measure, prioritize and relentlessly improve. Not every organization is ready to immediately adopt all seven competencies, but understanding how these competencies impact the entire enterprise and having an implementation plan (such as the SAFe Implementation Roadmap) are essential to thriving in the new marketplace.

There are 3 tactical competencies in SAFe 5.0:

1. Team and Technical Agility synchronizes high-performing, cross-functional Agile Teams, where business and technical teams collaborate to deliver quality business solutions that delight customers.
2. Agile Product Delivery is a customer-centric discipline that uses Design Thinking and Lean DevOps practices to continuously explore, integrate, deploy and innovate with a predictable and aligned cadence.
3. Enterprise Solution Delivery applies Lean System Engineering to build and continually evolve large systems that align with the full supply chain.

The next 3 core competencies in SAFe 5.0 are more strategic:

4. Lean Portfolio Management is a nimble and lightweight governance model that aligns strategy, funding and execution to optimize operations across the portfolio.
5. Organizational Agility fosters a Lean-Agile mindset across the enterprise so that business operations can respond quickly to opportunities and threats in a quick and Lean fashion.
6. Continuous Learning Culture drives relentless improvement as everyone takes ownership to explore, innovate and learn while they continue to deliver value.

The 7th and foundational core competency of SAFe 5.0 is Lean-Agile Leadership. The tendency for many digital transformations is to start changing the teams, which is certainly important. However, transformations quickly hit a ceiling and often fizzle when the other competencies are ignored. There’s a proverb that says: “Without a vision, the people perish.” Leaders are the vision-casters, and it’s their active participation that connects vision with outcome. They help people see what the future reality looks like.

Why Lean-Agile Leadership is Your Priority

Leaders need to lead

A Lean-Agile Leader is not a finish-line critic, nor a side-line cheerleader. They lead by example, embracing and exemplifying the Mindset & Principles because the new way of working requires a new way of thinking. Lean-Agile Leaders actually lead change and proactively seek to help their people reach the vision. For example: a cheerleader may applaud a team’s results, but a Lean-Agile Leader will exemplify servant-leadership and ask, “Is there anything I can do to help?”

Leaders need to understand

As a young naval officer, I learned that I was ultimately accountable for everything in my area of responsibility. If something didn’t make sense to me, then either I needed to ramp up quickly or work with others to quickly fix a flawed system. My experience as a consultant working with many different businesses has only solidified my belief that leaders must seek to understand. While they can delegate responsibility, they can’t delegate accountability.

As the Backwards Bicycle video by Destin Sandlin at Smarter Every Day illustrates, knowledge is not understanding. There’s a martial arts proverb: “Learn the way, then make your own way.” Taking a class or reading a book can give you knowledge, but having a mentor will take you farther faster. Having an experienced Agile Coach walk with you and your people will streamline your transformation.

The Cost of Transformation

Be aware that there is a personal cost to transformation: your active participation as an executive. You are the foundation of Lean-Agile Leadership. People need your vision, your commitment to understanding, your supportive leadership. You can be a good leader or you can be a bad leader, but either way you’re a leader. Be a good leader.

Looking for an experienced partner to assist in your SAFe 5.0 Transformation? Drop us a note and we’ll set you up with a free phone consultation with one of our SAFe Program Consultants.

Written by Mitch Malloy

 

Mitchell “Mitch” Malloy has 25+ years in the software industry. As a Coach and Mentor for 10+ years, he keeps a focus on value, an eye for excellence, and a passion for people. Since the 1990s, Mitch practiced Agile techniques while growing in his own Agile journey. He has led and participated in numerous Agile Transformations for companies of all sizes, where he has mentored others in Agile values, principles, and techniques.

 

More…

May 30, 2019

You’re a new SPC gearing up to teach your first class in the Scaled Agile Framework^® (SAFe^®), i.e., formal training with lots of slides. You’re probably a bit nervous, maybe unsure about how to present all this information in an engaging, relevant way.

So how can you go in prepared? To help you out, we developed a list of tips for new SAFe instructors, a list that we would’ve wanted at the beginning of our teaching careers. These suggestions are all tried and true, and we hope that they will help you motivate the newest crop of Lean-Agile change agents.

1. Learn About Your Students before the Class

To be the most effective communicator, you have to know your audience. What are their mindsets and where are they coming from? Research their organizations. Find out what their Value Streams are. Ask them about their businesses and the features they’re working on. If you can’t research ahead of time, then greet your students as they walk in and ask some questions. Just a few minutes of learning about your students can help you create a much more meaningful context for them.

2. Get Familiar with the Trainer Guide

The Trainer Guide comes with each SAFe course when you purchase the course license. You can find it in the “Getting Started” folder. One of the best ways to learn the materials is through this Guide, which contains all the slides and speaker notes. We recommend that you study it twice over before teaching your first class.

3. Research the Hard Concepts

When you’re new to the material, there will be things you don’t understand. For me (Randy), it was U-Curve optimization. I had to study it and phone a friend or two before it made sense. If you’re unsure about a concept, reach out to your network, maybe even a previous instructor.

4. Pre-load the Videos

Most course modules have a video or two. What happens if you don’t have network access? Switching back and forth between the course PowerPoint and a web browser is awkward and not a good option. For a smoother approach, embed the videos in the PowerPoint slides before you start class. Duplicate the PowerPoint slides with the links, download the videos, and then insert the videos onto the duplicated slides with AutoPlay set.

5. Master Stories and Analogies

There are concepts your students just aren’t going to understand without some connection or context. Think about real stories or analogies from your own work to help students make the connections. If you can’t find your own stories, then borrow someone else’s.

6. Pair Teach or Watch Someone Else Teach First

If you can, pair with someone who has taught the class before. We recommend creating a system that allows for pairing, if you don’t have one already. Can’t pair? Then watch someone else teach the class and take notes. Even though we’ve taught more than a thousand students, we still watch others teach to learn valuable tricks and stories from them.

7. Get the Room Ready Early

Get the room set with supplies, posters, etc. the day or night before. By strategically placing furniture and materials to optimize learning and reduce distractions, you are setting your students up for better outcomes.

8. Manage Student Interest Levels

Being able to deliver and manage your training is critical. Let’s face it—our attention can wander after about 10-20 minutes. So how can you engage (or reengage) your students?

• Move around the room.
• Change the tone and tempo of your delivery.
• Whiteboard out a concept.
• Don’t read every bullet point on the slides. Instead, focus on a particular bullet point or two and relate it to your audience (see Tip #5).
• Don’t do all the teaching. If you can, ask powerful questions that lead to deeper thoughts. A great question might be: “What will it take to make this happen in your organization?”

9. Manage the Timebox

If you’re lucky, your students will be highly engaged and have lots of questions. That’s a blessing and a curse. What are some ways to stay on track?

• Study the Timings section of your Trainer Guide and stick to it as best you can.
• Give students short, two-sentence answers to their questions, then encourage them to write their questions on the classroom Parking Lot or offer to talk more over the break.
• To shave off a few minutes, you can shorten the exercises. Don’t eliminate them entirely, because they’re there for a reason.
• Many exercises involve solo thought, then some discussion. You can cut some time by skipping right to the discussion. While it’s not always ideal, students get more time to hear others’ perspectives.

10. Manage the Energy

Every class has a lull where the students start to get groggy. Prepare a few activities to get them up and moving.

• One of our favorite activities is “Share One Thing You Learned.” The class stands, and each student shares one thing that he or she has learned with someone else in the room. It gets students moving and adds energy and positivity to the class. Just be aware that you may have to work a little bit to get them back on track.
• Snacks help (sometimes a lot). Balance healthy options with junk food. You don’t have to buy much; offer a little of each and see what disappears the fastest. Then buy more of that.
• Everyone loves fun and interesting videos that demonstrate a point. Some of our favorites are:

• One of our favorite activities is “Share One Thing You Learned.” The class stands, and each student shares one thing that he or she has learned with someone else in the room. It gets students moving and adds energy and positivity to the class. Just be aware that you may have to work a little bit to get them back on track.
• Snacks help (sometimes a lot). Balance healthy options with junk food. You don’t have to buy much; offer a little of each and see what disappears the fastest. Then buy more of that.
• Everyone loves fun and interesting videos that demonstrate a point. Some of our favorites are:
  1. Sh*t Bad Scrum Masters Say (“That’s not an impediment!”)
  2. A Funny Scrum Master Movie with Jeff Sutherland
  3. The Resource Utilization Trap
  4. ICON’s Transformation Coach Susan Strain curated 6 Videos that Reveal the Secrets of Lean-Agile Leadership, some of which you may recognize. Our personal favorite is “Location, Location, Location”.

If you’re interested in learning more, invite us to train with you or come to one of our public classes. Some ICON coaches have been teaching SAFe courses as early as 2013…that’s a lot of teaching experience!

Written by Scott Green

 

Scott has over 20 years of experience in implementing process improvement within Software Development companies. His foundations in Agile, eXtreme Programming (XP), and Scrum have enabled him to deliver products and solutions for enterprises around the globe.

He began the exploration of the Scaled Agile Framework (SAFe®) and became an SPC in 2014. Scott specializes in integrating Scrum Teams into larger Agile Release Trains that are focused on Value Delivery, organizational OKRs, and KPIs. Scott has led many SAFe Transformations and enjoys helping large-scale enterprises appreciate transformational benefits including; increased speed to market, improved quality products, and higher employee engagement.

 

More…

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…

Mar 15, 2019

Agile is disciplined; not reckless.

To put it another way, IT is simply a function (one of many) of a Product Organization. But how do we get there? In order to build and organize around Product, we need to look to another concept: Enterprise Business Agility (EBA). Agile has been around for nearly two decades, and what we have seen consistently is that Agile Transformations start and end in IT organizations; nearly everybody forgets about the Business.

Some organizations have IT groups decide to go Agile without letting anyone else know. Others have involved everybody in the decision but decided to just train IT; and some have even “gone Agile” without creating Product Owners and Scrum Masters while saying, “the teams are smart. They can do all that.”

None of these common implementations will achieve the value you’re looking for. You can implement all the practices without ever realizing any of the benefits if you don’t understand where the benefits are supposed to come from. You may have heard the phrase, “Agile done poorly is worse than Agile not done at all.”

Let’s take it one step further and assume you had a successful Agile Transformation in your IT space. That’s worth celebrating! You’ll see a lot of benefits already. However, in order to create a Product Organization that is Agile, the Enterprise around it also needs to be Agile, so we need to extend that Agility beyond IT to the Business, and to functions like HR, Legal/Compliance, Finance, etc.

At its core, EBA is the idea that you can gain alignment across all your different business functions through a transparent set of processes that are executed consistently with a focus on built-in quality (you may recognize that the core values of SAFe® enable true EBA). Today, the best EBA model has come from Agile Transformation, Inc (ATI), and they have created a strong transformation journey with 7 pillars of Enterprise Business Agility that lead to 5 core transformation centers.

With these 5 major areas of focus on your transformation journey, you have the blueprint of a successful EBA implementation. It’s important to note that EBA is not meant to replace or supplant your Agile or SAFe® implementation; EBA is designed to support and enhance it. The whole point is to extend your Agility to the Enterprise with Agile, SAFe®, and EBA all working in concert together. Another key takeaway of the journey pictured above is that it is not meant to be read left to right. You do not create team agility, then team of teams agility, then organizational agility, etc. You will need to focus your transformation on all 5 areas at once, as each area of focus contributes to the success of the other areas. This may seem intimidating, but you’ll see that once the dominoes start falling, the momentum of transformation is really easy to maintain.

Once you’ve created an environment where all your different business functions are aligned, and operating on the same cadence, you will start to realize the benefits by delivering high quality products to your customers frequently and with the shortest possible sustainable lead-time.

Remember, when we started, our goal was to create a Product Organization. It’s only at this point, with aligned and collaborative IT and Business functions, that you will have the ability to create a true Product Organization. It may not seem necessary, but eventually you must break down the walls and streamline your organization. (Another reason that HR needs to be made Agile through EBA). You will need a Product Organization that exists on paper to ensure everybody is aligned to the same goals and driven by the same future vision.

Product and EBA are two sides of the same coin. When IT is considered a function of a business unit, and everybody has a shared understanding of the future vision, then you’ll have created a sense of collective ownership and given life to a change in the way we work that will leave you wondering how we ever did it any other way.

Written by Saahil Panikar , SPCT

 

Saahil has been a leader in transforming organizations and teams by helping them master Agile and Scaled Agile best practices for over 10 years. He is a passionate Agilist whose thirst for continuous improvement led him to his first Agile Transformation in 2013 and has caused him to push the envelope ever since. He has experience working with large-scale Agile initiatives in a variety of contexts. He has worked with start-ups and small businesses, the Federal Government, and Fortune 100 companies.

 

More…