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.

Jun 3, 2019

A colleague suggested I write this article, and I quickly agreed, thinking to myself, “No sweat! There are so many little things that can make a big difference. I can type this out in no time.”

Now pause. Go back and review that last thought. Do you see a flaw in my logic here? “There are so many little things…I can type this out in no time.” Did I really think a long list of things would make this task any easier? That it would make the writing process fly by?

It took me three weeks to write this article. The fact that there are so many small changes that can have a huge impact on a SAFe® Transformation made my heart beat a little faster every time I thought about it. I kept putting my thoughts down and picking them up again, and the list kept growing and growing.

Fortunately, the solution to my problem and the organizational transformation problem above are the same: put on your Product Thinking Cap and prioritize ruthlessly, coming up with a short, doable list of the most important things that can make the greatest impact. Your list doesn’t have to be perfect or comprehensive, but as you focus on small efforts with the biggest impact, you will begin to move forward in the right direction.

Below are my Top 5 suggestions for little changes that will make a big difference in your SAFe Transformation. It’s my belief that these practices go a long way to energize all Agile Transformations at any level, from team adoption to global enterprise transformation. There are nuances, but the principles remain the same.

 

1. Emphasize Mindset over Toolset

There’s a reason why the Scaled Agile Framework^® (SAFe) training classes emphasize Values and Principles at the very beginning. They describe a mindset that is essential to scaling agility within an enterprise environment. Without the right Lean-Agile Mindset, a SAFe Transformation is often ineffective, despite all the great tools included. As I often say, “The mindset fuels the toolset!”

What is the difference between a toolset and a mindset? A toolset is a toolbox of practices that can be used to implement a solution. Scrum, Kanban, XP, and SAFe are all frameworks and/or collections of practices that can be pulled out of an Agile toolbox. A mindset is your understanding; the key to knowing which is the right tool for the job. I can use a screwdriver to beat a nail into a piece of wood, but it takes understanding to know I’d be better off using a hammer.

Just like carpenters who apprentice under a master gain an accelerated understanding of woodworking, SAFe Teams and Senior Leaders who train with a deeply experienced coach gain an accelerated understanding of SAFe. As a SAFe Program Consultant (SPC) and Agile coach, I train people on how to use various toolsets, but more importantly, I help others to develop the Lean-Agile Mindset, which isn’t immediately intuitive and often doesn’t become real until several iterations into the application of a new framework. As teachable moments materialize, I look for opportunities to tie values or principles to the problem being solved, reinforcing Lean-Agile thinking.

So often, people want to do Agile without being Agile. In essence, they want to implement the practices without changing the way they think. Someone will ask how to do something (usually in an email, text, or IM) without context for the problem being solved. Typically, a quick response without a conversation can create more harm than good. Context and understanding are critical when using any of the tools in the Agile toolbox.

If your organization can’t embrace the Lean-Agile Mindset, then you will not have a sustainable SAFe Transformation. Remember—the mindset fuels the toolset! There’s a saying in the martial arts: Learn the way, then make your own way. Once the new way of working transforms how you think and becomes part of you, only then can you truly start to walk down the path of Agility.

 

2. Model Agility – Be Agile as You Do Agile

Try not to fall into Command and Control Management, the traditional “do as I say and not as I do” style of leadership that creates fear, confusion and inhibits transparency. This approach discourages the self-organization necessary for SAFe and other Agile frameworks.

There are times in a transformation where it is appropriate to take a prescriptive approach (see SAFe Principle #9), but the goal is to move toward a facilitator role and become a Servant-Leader. Maximize the capabilities of your team by empowering them. Ask thought-provoking questions and provide goals without giving directions. By allowing your teams to think and act for themselves, they will develop their own leadership skills.

An impactful SAFe transformation leader understands that Agility is a journey and not a destination. You and your team may find yourself slipping into the comfortable old ways of Command and Control and order-taking. Rather than becoming discouraged, reinvigorate your Lean-Agile Mindset by acknowledging what happened, and then demonstrate relentless self-improvement by retrospecting how you will act in the future. As you do, you will be able to respectfully pull others back onto the path of Agility. Doesn’t this sound like a healthier approach than the fruitless criticism of a person’s inability to transform?

 

3. Define the Minimum Viable Transformation (MVT)

In some cases, launching a train and walking through a Program Increment (PI) might be enough. In other instances, mentoring over a longer period may be necessary to achieve the desired goal. First you have to ask yourself, “What are the goals or desired outcomes of this transformation?” Doing without understanding is NOT the behavior of a Lean-Agilist, so defining an MVP and hypothesizing benefits should be part of your transformation. The decision to persevere or pivot should be evaluated throughout the transformation and as understanding grows, a new MVT may be established.

 

4. Engage Leadership; Don’t Just Inform Them

As you move the down path of transformation, having described an MVT and hypothesized benefits, who can validate that you are going down the right path? And if the MVT changes or your hypotheses produce unexpected results, then who can make the decision to either persevere or pivot?

Business leaders often expect they can step out of the way once they’ve engaged someone to lead an organizational change, but expectations for their role need to be made early and repeatedly in a SAFe Transformation. They can’t simply be informed of the progress; they need to understand how their role plays a critical part in the organizational change.

Leadership requests and behaviors can either reinforce or weaken transformation efforts. For example, holding individuals accountable rather than teams will lead to command and control behaviors and other anti-patterns. This is especially true when holding individuals accountable for metrics.

Metrics are neither goals, nor accomplishments. As the Agile Manifesto eloquently states, working software is our primary measure of success. Metrics can be gamed and used to cloud the real issues, or they can shed light on how to help and improve teams. Encourage your leaders to find the context for those metrics. If leadership places an emphasis on metrics themselves, their well-intentioned workers will put in the effort to have the best possible metrics. But if leaders emphasize delivery of quality software in their participation at System Demos and PI Planning events, then guess where people will focus their efforts?

The importance of good leadership in a SAFe Transformation can’t be emphasized enough. If leaders model Agility by participating and collaborating across functional areas, then their behavior will be a powerful force for the change they want to see. If they fail to model Agility and don’t motivate their teams, then the Transformation is likely to stagnate.

 

5. Organize for Success

• To what extent can teams be collocated?
• Do you have the right people in the right roles?
• As the team and program ceremonies are implemented, can other redundant meetings be removed?
• Do the budgeting and portfolio management support the new way of working, or are they set up to create tension?
• Are Agile Release Trains (ARTs) aligned along Value Streams or are they siloed along technology stacks?
• Do teams and Trains know how they will respond to unplanned work requests?
• Have expectations been set with Business Partners so they know how to interact with the new working model?

An external coach (or two) can help you find answers to these questions and navigate the change. And while external coaches are certainly an enabling factor to any successful SAFe transformation, at some point, they need to remove themselves from the client’s site. The goal of any good coach is not to become a permanent fixture, but to make necessary adjustments and get out of the way. An experienced consultant energizes both internal coaches and senior leaders to renew the Lean-Agile Mindset and model agility, thereby creating a sustainable transformation that lasts long after that coach leaves the client site. In other words, they help with these 5 little activities that make a big difference in your SAFe Transformation.

How well are you doing the little things that make a big difference in your SAFe Transformation? Check in with this 10 Question Survey, which shows you how well you’re doing and offers solutions based on how you score.

Nov 3, 2020

In this short, interactive Lean Coffee with Dean Leffingwell, the creator and co-founder of the Scaled Agile Framework^® (SAFe), Dean presents his excellent musings and chalk-talk answers on the following topics:

• Critical Success Factors for a Lean-Agile Center of Excellence and Roadmap for Organizational Agility
• Roadmap for SAFe 6.0
• The Do’s and Don’ts when implementing Lean Portfolio Management

This conversation was facilitated by Kathy Marshak, Principal Transformation Consultant, SAFe Fellow and SPCT for ICON.