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.

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 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.

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

 

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

 

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?

 

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:
  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!

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.

May 28, 2020

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

I think there is an interesting pattern emerging in agile and SAFe today, seen in part by Marty Cagan but commented more deeply by Oliver Staley in his article, “Whatever Happened to Six Sigma?” published September 3, 2019.

Staley points out that while Six Sigma was a solid model for manufacturing quality excellence, it also caused third-party partners to twist and certify anyone with a check, ending in a lack of results and causing the marketplace to turn away. “The merchants of Six Sigma wanted to keep expanding the market,” and so it was oversold, causing an over-expansion and decline in the use and importance of Six Sigma.

This decline was also rooted in the removal of the quality problem in American manufacturing. Instead, the shift and increase in software problems began to drive the marketplace. Today, companies are rightly turning to software process improvement.

Back to Marty Cagan, who sees companies using scaling frameworks without customer connection and engagement. Are these truly SAFe implementations, or individuals and systems attempting to label and mimic something they don’t understand as Agile, or “Cargo Cult” implementations? In reality, many of these people do not believe or even understand these frameworks or the principles behind them. They are simply driven to implement something that looks like a framework in order to gain conformity or short term rewards for their behavior. To me, this is a symptom of deeper questions about the nature of business cycles:

• Has SAFe begun an over-expansion period, where total assimilation will cause incorrect and destructive systems to label themselves as SAFe?
• Will the strategy of making money overtake the core values of SAFe and create a decline in success, as waterfall systems label themselves SAFe or Agile?

And the biggest question of all:

• Have we as a company taken everything we can from SAFe and removed software issues from driving our marketplace?

I believe we still have work to do and minds to change.

Want to know what the most common anti-pattern in SAFe implementations today?

Aug 1, 2019

…Because the world is moving too fast not to be Agile!

At the XP 2002 Conference, The Standish Group showcased their study of how often features were used in a typical system. According to the results, features were used “often” or “always” only 20% of the time. 15 years later in 2017, after the software development world had largely embraced incremental delivery methods, the Standish Group conducted the same study again. The result? Still only 20% of features were used “often.” There was little to no significant change.

So why didn’t the percentage increase? What inhibited the growth of using features in a system, despite the increase in Agile delivery methods?

The culprit: The Business.

Today, after almost 20 years of demonstrated success using Agile practices and principles, Business is still not a part of most Agile Transformations. Why? Because businesspeople tend to view Agile as an “IT thing” that does not affect them, and so they continue to come up with unproven ideas, still waiting for that “big-bang go-live.” They do not know how to adapt and pivot as soon as something else becomes more valuable.

With technology enabling disruption at breathtaking speeds (that are not slowing down), Business Agility has become mandatory for survival. To stay relevant, the Business needs to realize the importance of learning and adopting Agile behaviors, with executives trailblazing the way.

On, July 16, 2019, ICON Transformation Coach Susan Strain presented this topic as a featured speaker at the Cincy Deliver Conference in Cincinnati, OH. During the presentation, Susan examined disrupted companies and their disruptors, shared how some of the largest enterprises approach Business Agility today, and offered frameworks to help with Business Agility transformations. We are sharing Susan’s slide show presentation with you here, hoping that you can benefit from the value that it has to offer and discover why we all need Business Agility.

Want to download these slides, plus the speaker notes from Susan’s presentation at the 2019 Cincy Deliver Conference? Click below to access detailed background information, relevant links, and more interesting statistics.

Apr 14, 2020

First, let’s set the context. How large was the planning and how was it set up?

Gillian: The big room planning consisted of 2 trains made up of 12 Teams, about 180 people. Both trains planned together because, although there were limited interdependencies, we decided ‘big, virtual room planning’ was the optimal approach. We used Microsoft Teams to run planning, present content, chat and communicate. Multiple channels were used to meet and present core conference content, with specialist channels for Scrum of Scrums, and team breakouts. We obtained a separate tool to visualize PI Objectives, Program Board, dependencies and links for presenting draft and final plan reviews. Subject Matter Experts from the business, architects, and delivery managers were pulled into a channel via chat to facilitate or support teams. All channels were published to all participants so anyone could join a channel at any time to participate. Scrum Masters facilitated planning and played scribes, and product owners worked the story decomposition and PI Objectives definition with the teams. This model worked well for collaboration and content capture.

What is the most important tool for a virtual PI Planning?

Use any tool that can visualize the teams’ written PI Objectives, features, and dependencies. It’s crucial that teams get comfortable with the tool of choice beforehand. It’s also prudent to have a backup tool (resort to spreadsheets, smartsheets) in case collaboration tool access is interrupted. Have a plan, and a backup plan so work can continue if the network goes down or tool access is lost. We asked scrum masters to practice using the tools by pre-loading content before the PI event.

What else did you do to prepare?

We ensured the product team handed features to the teams 3 weeks before the PI Planning Event. This is a good practice, whether virtual or not; the teams socialized and familiarized themselves with the content. Pre-populating the content into the tool ahead of time saved time during the PI Planning Event itself for teams to focus on decomposition and dependency mapping.

Two additional readiness Scrum Of Scrums events were added before the PI Planning event. In the first, we discussed the context and content of the virtual planning and what to expect; we also reviewed the agenda which was revised to not only include the topics and times, but also the channels, and backup conference lines in case people lost network connectivity. In the second pre-PI Scrum of Scrums, we made sure all invites had been sent out and went over the checklist of all the technical communication and tool logistics. Everything was set up before the actual event, including teams testing channels for quality and speed. On the day, we launched seamlessly into the channels. Given some overseas groups had challenges with network bandwidth, we abandoned having video as part of the main channel collaboration as mitigation to channels choking on video streaming.

Additional people were added to the event to handle specific issues such as communications or specific tools, and we had 2 or 3 people as a sequential call so if the first person was busy, there were further people who could be called in to help.

Any challenges during the event?

Not really. We had a backup plan, and a backup plan to the backup plan. During the event, some of the teams’ channels dropped or slowed because of network/VPN issues. We had a plan in place for this. If they couldn’t access through the network, then they had a mechanism of sharing a spreadsheet and a phone call bridge and could continue that way until the network came back.

What went well with the virtual event?

Having a full virtual event flattened the playing field. Everyone had a common working agreement of who had the talking stick. There were no problems of people talking over each other and everyone was looking at the same presentation from the same vantage point.

One of the problems with in-person PI Planning is that some people are in the room while others are remote. It’s hard for the remote folks to realize through video the full extent of what the room is doing and experiencing. Remote people often lose context because they can’t hear what some people are saying or see what the people in the room are seeing. A full virtual event yields more value in communication and collaboration than an event that has people both in the room and remote.

What do you prefer—in person PI Planning or virtual PI Planning?

If you can get everyone in a room, you can’t beat that. But how often can you do that these days? There are always some people who are remote. I prefer virtual planning. By everyone doing virtual planning, everyone becomes more accessible. Everyone can hear everyone else and see everything from the same viewpoint. Also, you save money in hotels and travel time.

What are some lessons learned from this virtual PI Planning experience?

SMEs in high demand (e.g. architects, product managers) developed waiting lines for being pulled in to team channels. Having pre-set times when a specialist would come into the team channel (e.g. Product assigning Business Values to PI Objectives) would help with bottlenecks and wait times.

For enterprise organizations with geographically dispersed teams, there is no better, structured framework than SAFe for a seamless pivot to virtual planning.

Need virtual PI Planning or other remote guidance from people who’ve done it before?

Jul 15, 2019

If you’re a newly minted SAFe Program Consultant (SPC), then congratulations! After all your agile/project/program management experience and diligent studying to pass a difficult exam, you deserve a sense of accomplishment. However, as you may already suspect, your journey has only just begun. To be an effective SPC for years to come, more will be required.

Today’s topic is near and dear to my heart. I’ve had the opportunity to work with and observe several great SPCs during the last five years, and I’ve learned nuances and success patterns for the multifaceted endeavor of becoming a great SPC.

Great SPCs are a special breed of people who are comfortable operating at many levels and in various environments. They have to wear many hats and change those hats from day to day; often multiple times within a given day.

As an SPC, you play a critical leadership role in Scaled Agile Framework® (SAFe®) Transformations, driving the culture change that prepares organizations to succeed and sustain on their own. In this post, I will describe seven dimensions that I believe characterize the greatest of SPCs and offer some guidance to help you become a better Lean-Agile change agent.

 

1. Be Agile

Remember The Backwards Brain Bicycle? This video demonstrates just how hard it can be to change your mindset. You might think you and your team(s) have embraced agile principles, but it’s possible that you all have room to grow. Start by reflecting on the Scrum Values: Commitment, Focus, Openness, Respect, and Courage. Also, check out 6 Videos that Reveal the Secrets of Lean-Agile Leadership for deeper understanding of what it means to live by Lean-Agile principles. These videos are easily digestible and even inspiring, giving you further motivation to go out and lead the change!

 

2. Be a Servant Leader

Want a good SPC mantra? Try “serve first.” You’ll find that the greatest SPCs prioritize service over leadership. By serving others, you earn the privilege of leading people that are on transformative journeys.

Coined by Robert K. Greenleaf, “Servant Leadership” advocates that the main goal of a leader is to serve. To be a valuable Servant Leader and SPC in a SAFe Transformation, you want to support people in producing measurable outcomes. Start by listening to teams, trains and stakeholders and focusing on their needs. Help ARTs to develop so that they constantly improve and perform at the highest sustainable level.

If you want to be a great SPC, then serve others in your words and actions. Roll up your sleeves and model behaviors for specific roles like Release Train Engineer, Product Owner or Scrum Master. Modeling these roles builds credibility with members of the Train and also allows you to walk in the shoes of those you are trying to serve.

 

3. Be a Value Deliverer

Value is in the eye of the stakeholders. In order to deliver the right kind of value, desired outcomes must be agreed upon as the Agile Release Train (ART) is launched and progresses from Program Increment to Program Increment (PI). Product Management and key stakeholders should see a track record of results produced by each ART that aligns to their priorities.

Through coaching, training and mentorship, you can help facilitate true value delivery. Gently guide your ARTs to the realization that the SAFe principles and practices are designed to support more efficient and predictable value delivery with higher built-in quality.

 

4. Be a Teacher/Trainer

Some SPCs specialize in teaching or training other Agilists. Some SPCs alternate between delivery and teaching, depending on the needs of the ARTs. Regardless of who, how much, or how often you teach, prepare yourself to be the most versatile teacher you can be.

The greatest SPCs can instruct and inspire Lean-Agile leaders, RTEs, SMs, PM/POs, development team members, executives, stakeholders, and novices. Stay ahead by keeping current on the latest release of the Framework and enable yourself to teach the courses that are needed by the ARTs that your serve.

Part of the privilege of being an SPC is that you have an abundance of learning resources from Scaled Agile. You can complete Course Delivery Enablement (CDE) online and pass an exam that allows you to teach the course. However, if you’re feeling some uncertainty about the subject matter, I suggest taking a public course and getting certified that way. Watching another deeply experienced SPC or SPCT teach can be an amazing learning experience—you can hear real world examples, gather stories, network, and pick up a teaching trick or two.

Want some immediate pointers on how to be a better SAFe teacher? Check out 10 Teaching Tips for Your First SAFe Classes by Randy Smith and Scott Green. These suggestions are like a checklist to help you prepare for any of your upcoming SAFe classes.

Teaching Agile practices is important for SPCs, but remember that the greatest SPCs ensure that the principles supporting the practices are valued more. This should be emphasized directly and indirectly as you teach and coach.

 

5. Be a Coach

To be a great SPC and coach, you must model the behavior that you expect teams to adopt. Sure, coaching is about motivating and guiding your teams, but the coaching role expands far beyond that. According to Lyssa Adkins, “Agile coaching is more about who you are and what behaviors you model than it is about any specific technique or idea you bring to the team.” She provides the following rough estimate: “…agile coaching is 40% doing and 60% being.”

 

6. Be a Public Speaker

Being a great SPC calls for a great deal of public speaking! You will likely be called on to lead group discussions, facilitate PI Planning events, educate senior leaders, and present at meet-ups or gatherings. If you haven’t already, then it’s a good idea to sharpen those communication skills.

If public speaking does not come naturally to you (and it doesn’t with most), then seize opportunities to practice by participating in a public speaking group or your local Toastmasters club. Toastmasters has helped many great SPCs build confidence. As you practice in front of a supportive group and gather constructive feedback, you will develop influential public speaking and leadership skills.

Also remember that public speaking is about more than sounding convincing and smart. It’s also about bringing social awareness to the table—can you read a room? Are you empathetic towards those you are interacting with? You are trying to build trust and connection with those you work with, so constant communication, transparency, and openness are required.

 

7. Be a Lifelong Learner

The Scaled Agile Framework is constantly evolving. As a practitioner, you must also evolve, not just learning about the latest SAFe updates, but also taking on challenges and sharing resolutions with others who may be on similar journeys.

As Agile organizations mature, previously advanced topics like Lean Portfolio Management, DevOps and Business Agility have become the water-cooler talk of today. You will need to know these concepts as you continue to embrace a Lean-Agile mindset and as you teach, train, and coach others.

 

Conclusion

As you may have gathered while reading this article, the seven dimensions are not mutually exclusive—each overlaps and builds on the others. As you improve your skills in one dimension, you are likely to improve your skills in another. While this makes it easier to become a great SPC, keep in mind that very few SPCs have arrived at the pinnacle of all of these dimensions. In true SAFe fashion, we must all practice continuous reflection and relentless improvement.

Are you an SPC with proven experience leading and transforming large groups of people? You may have what it takes to be an ICON Coach.