Blog

4 Myths About Scaled Agile Framework® (SAFe)

By: Mike Hall | Feb 06, 2020 |  Agile Transformation,  Article

Scaled Agile Framework or SAFe® is the most popular and far-reaching of the Agile scaling frameworks out there. But before you make the decision to go all-in with this popular framework, it’s important to know the facts. Here are 4 busted myths about SAFe.

1. Scaled Agile Framework is prescriptive!

The myth that “SAFe is prescriptive!” is the one I hear the most often. Let’s examine this a bit closer by starting with the meaning of the word “prescriptive”. A common definition for this word is “enforcement of a rule or method”. Even more telling are the listed synonyms: dictatorial, narrow, rigid, authoritarian, repressive, dogmatic. Yikes!

SAFe is a framework. It is not a set of rigid rules. Like any good framework, it requires thoughtful customization to your specific situation. The documentation available at Scaled Agile clearly highlights this dynamic. 

There is one “rigid” aspect to SAFe, and rightfully so. The 10 SAFe Principles are considered immutable. As mentioned above, the principles are considered best practices from the Lean and Agile worlds. These guiding statements are principles, not practices. SAFe clearly allows for customized practices as long as the principles are not encumbered.

2. Scaled Agile Framework is heavyweight

At first glance, SAFe looks overly complicated, thus the cries of “heavyweight”. I would instead call it “complete” or “comprehensive”. But let’s be honest here – typical Agile enterprise transformations are complicated! It stands to reason that most enterprises will need a reasonably comprehensive framework to leverage when pursuing full enterprise agility.

Designed specifically for large enterprise, SAFe addresses the important enterprise-level challenges such as:

  •     How business strategy is translated into executable actions at the development team level
  •     How to ensure seamless collaboration between IT and business
  •     Lean economics
  •     Funding
  •     Pull-based model of bringing the work to persistent teams
  •     Consistent estimation approaches across all teams

3. Scaled Agile Framework is RUP

As a software developer back in the day, I familiarized myself with the Rational Unified Process (RUP) and experienced some reasonable success using it on several projects. RUP has 4 project lifecycle phases – Inception, Elaboration, Construction, and Transition. While it sounds a bit waterfall-ish, these phases do overlap significantly, which allowed for some level of inspection and adaptation between the phases. RUP also points out that iterative development should be used during the Construction phase.

I like to think of RUP as a “bridge” from Waterfall development to Agile development. Personally, at the time I did not think RUP went far enough from an agility perspective. But it was significantly better than standard Waterfall, and for that, we owe the inventors a debt of gratitude.

There is nothing in SAFe that even remotely resembles RUP. SAFe is Agile on steroids, scaled for the enterprise. RUP is a bridge between Waterfall and Agile. In SAFe, there are no old-fashioned phases or gate reviews. Frankly, the only thing in common between SAFe and RUP is that they are both product development frameworks that help teams be successful. And that’s a good thing. 

SAFe represents advanced, evolved, mature Agile thinking – for the whole enterprise.     

4. Scaled Agile Framework is an all-or-nothing approach

Another popular myth is that SAFe must be used in its entirety regardless of the situation. This is false.

As described above, Full SAFe has 3 levels: Portfolio, Large Solution, and Essential. SAFe is configurable. If you don’t need a level, then don’t use it. For example, Essential SAFe consists of only the Team and Program levels. Many enterprise transformations use Essential SAFe only. Others start with Essential SAFe and then add a 3rd layer over time to handle even larger initiative (Large Solution layer) or portfolio management (Portfolio layer) to handle business definition and funding.

Within each layer is a set of roles, constructs, and events. If any of these do not make sense in your specific situation, then don’t use it. But always cross-check your decision against the 9 SAFe principles to make sure that you are still headed in the right direction from a Lean-Agile perspective.

I like to call SAFe a “subtractive framework” in that it covers all or most situations for a full-on enterprise Agile transformation. An Agile leader wanting to apply SAFe can pick and choose which levels to use. You can start with just the 2-level Essential SAFe which provides a straightforward scale up from team-based Agile. You can subtract aspects that do not fit your culture. You can also adjust the specific practices recommended to best fit your company’s culture and needs – as long as you don’t violate SAFe’s nine core principles. 

Conclusion

SAFe is here to stay. It satisfies the need for many organizations to scale Agile within their enterprise. While it does have its detractors, SAFe should be considered carefully by those leading an Agile transformation. Continue your reading on SAFe with Demystifying SAFe® : A beginner’s guide to Scaled Agile Framework.

 

Looking to scale Agile throughout your enterprise? 

Contact Agile Velocity to explore options and find the right solution for you.

 

Blog

Agile Velocity Joins the Scaled Agile® Partner Network

By: Agile Velocity | Jan 29, 2020 |  Agile Transformation,  Article

SAFe- partner-badge-silver (1)We are excited to join Scaled Agile’s Partner program. This worldwide network includes transformation and platform providers who help enterprises facilitate and accelerate business results through the adoption of the Scaled Agile Framework® (SAFe®). As the world’s leading framework for enterprise agility, SAFe helps businesses address the significant challenges of developing and delivering high-quality software and systems in the shortest sustainable lead-time.

Mobilizing large-scale transformations can be daunting. Agile Velocity’s aim is to ensure companies always embark on their SAFe journey with a powerful, simple, and coherent transformation approach anchored to their unique business outcomes. Leveraging Agile Velocity’s Path to Agility® alongside SAFe equips employees at every level to swiftly and accurately diagnose and resolve root causes that derail or stall transformation momentum. Path to Agility produces quicker business results and lasting, durable agile capabilities.

“Our clients are clear. They need meaningful business results, and they don’t want to get stuck in the chaos and resistance phase of a transformation,”  Erik Cottrell, CEO Agile Velocity.  “Agile Velocity’s Path to Agility is designed to accelerate SAFe adoptions with confidence because Path to Agility makes sense of transformations in a simple yet powerful way that’s biased towards results. Having guided dozens of our clients along their path to agility, we’re very proud to be a part of the Scaled Agile network and help more companies deliver lasting change.”

“We accelerated through our transition with Agile Velocity’s help. The Path to Agility was crucial to our journey because it focused on outcomes, strengthened our capabilities, and became an integral part of our improvement mindset.” Jeanette Ward, COO, Texas Mutual Insurance Company

“Working with best-in-class partners like Agile Velocity represents our commitment to helping software and systems-dependent enterprises improve time-to-market, quality, and employee engagement,” said Dean Leffingwell, creator of SAFe and cofounder of Scaled Agile, Inc. “By incorporating SAFe into their solution offering, Agile Velocity is enabling the world’s largest organizations to become more agile in the marketplace and more competitive in their industry.”

About Agile Velocity

Agile Velocity serves Fortune 500 companies nationwide. It has grown into an organization filled with people who are passionate about helping companies react quickly to market demands and compete on a global scale through iteration, collaboration, and a shared understanding of both vision and practical execution.  

Change can feel unmanageable–it’s complex and risky in business. That’s when companies bring in AV. We are a trusted, full-service transformation partner, equipping organizations with tools and systems that help achieve tangible business outcomes. We utilize our proven transformation approach, Path to Agility, to teach leaders how to guide their organizations through initial chaos and onto accelerated success.

About Scaled Agile, Inc.

Scaled Agile, Inc. is the provider of SAFe, the world’s leading framework for enterprise agility. Through learning and certification, a global partner network, and a growing community of over 450,000 trained professionals, Scaled Agile helps enterprises build better systems, increase employee engagement, and improve business outcomes. Scaled Agile is a contributing member of the Pledge 1% corporate philanthropy and community service movement. For more information on Scaled Agile and SAFe, visit scaledagile.com.

 

To learn more about how Agile Velocity can help you scale Agile across your organization, visit our SAFe Transformation page.

Blog

Which Agile Scaling Framework is Right For You? SAFe® vs. LeSS

By: Agile Velocity | |  Agile Transformation,  Article

Agile transformations can do wonders for organizations across the board. Agile helps teams to continuously improve while focusing on attainable goals and timely delivery. However, implementing Agile across a large organization comes with its own challenges. Businesses that want to scale Agile across multiple departments have a range of Agile frameworks to consider to help them combat these challenges, and some might work better for their organizations than others.

We’ve highlighted two of the most popular Agile scaling frameworks (SAFe vs LeSS) to help leaders determine which framework best meets their needs.

SAFe vs LeSS: Which is right for you?

SAFe®: Scaled Agile Framework®

SAFe® is the most popular framework for enterprise-wide scaled Agile implementation. Its popularity stems from its roots in proven Lean Systems Thinking and core Agile development principles.

SAFe® works best in organizations with anywhere from five to several hundred teams. Therefore, it’s a great framework for large companies. SAFe® provides these businesses with a highly dependable method for planning, execution, and delivery through Agile Release Trains (ART’s). 

ARTs bring all teams together on a regular cadence of Program Increments lasting eight to 12 weeks. Each Program Increment begins with a multi-team planning session to identify what they’ll deliver, which helps teams identify and address cross-team dependencies and potential obstacles.

Pros of SAFe®

  • Touches upon business aspects other Agile frameworks fail to address
  • Based on Lean Economics – teams deliver the greatest value in the shortest amount of time 
  • Synchronization across multiple teams reduces scaling issues
  • Support via excellent training courses and role-based certifications
  • SAFe® decomposes business strategies into initiatives, then features, then stories of work at the team level–no other scaling framework maps this pathway out as clearly.

Cons of SAFe®

  • The implementation strategy may need to be tweaked to fit the needs of your organization
  • Alignment with economic-driven Lean development may prove challenging from a cultural perspective

SAFe® is a comprehensive and complete solution that addresses not only team agility but also portfolio and business agility. Therefore, SAFe® is an excellent choice for companies that desire full enterprise agility with a highly disciplined approach to deliverables. 

LeSS: Large Scale Scrum

LeSS is the large-scale implementation of key principles and elements of Scrum across multiple teams. A key aspect of LeSS involves redirecting team attention onto the whole organization rather than each team’s individual silo. However, implementing this holistic approach also can be a primary barrier to scaling.

There are two frameworks within LeSS:

  1. LeSS: Up to eight teams
  2. LeSS Huge: Scaled for more than eight teams

While both frameworks rely upon a single Product Owner, LeSS Huge includes additional Area Product Owners that work among their smaller areas. For leaders who are fans of Lean Economics, LeSS can be advantageous due to its emphasis on systems thinking, doing more with less, and queuing theory.

Pros of LeSS:

  • Comfortable and familiar due to its Scrum roots
  • Emphasizes system-wide thinking
  • Focused on a product rather than project
  • Single Product Owner and backlog

Cons of LeSS:

  • Scaling only works for companies with a solid Scrum foundation
  • Since it’s built around Scrum, it’s not a natural extension of other methodologies
  • The single Product Owner may struggle to handle multiple teams

LeSS works best with companies that are successful with Scrum and want to scale it across multiple departments since they will find the concepts of LeSS quite familiar. 

Choosing the Right Agile framework – or Tweaking Them to Fit Your Needs

There are many different Agile frameworks to consider for businesses that have multiple teams working on the same product. But oftentimes, the best solution is one that blends best practices from multiple scaling frameworks. The truth is, organizational leaders have to approach Agile as a method they tailor to fit their needs, rather than a stagnant solution. Hopefully, this SAFe vs LeSS comparison makes your decision-making process a little easier. 

To learn more about how Agile Velocity can help you scale Agile across your organization, visit our Transformation Services page or our SAFe Transformation page.

Blog

Packing for the Yellow Agile Brick Road: 5 Tips for A Successful Transition to Agile

By: Lorena Connolly | Nov 11, 2019 |  Agile Coaching,  Agile Transformation,  Article

Happy days. Your organization has made the commitment to experiment with Agile or to go whole hog and do a “rip-the-band-aid-off” transformation. Now, you’re learning about stand-ups, backlogs, and self-organizing teams. During this transition to Agile, you may be wondering, “What are we really in for?”

Indeed, you may feel like Dorothy in the Wizard of Oz. You’ve been spun around in a tornado of terminology and change. Now, you’ve landed in an unfamiliar place that bears little resemblance to the place you’ve been working at over the past few years. You really aren’t in Kansas anymore.

It is important that you learn the principles, values, and practices of an Agile way of working. Even after you complete your first training class, keep doing that. That is your Yellow Brick Road. 

This article is about the more elusive, yet essential things, you’ll need to take with you on your Agile journey. The help you need to battle the Wicked Witch of The Way We’ve Always Done Things and the Flying Monkeys of unplanned work, stories that carry over, and big batch work. 

Let’s get back home (though it may look different) and to a place where you feel comfortable and confident again. Here are 5 tips for a successful transition to Agile:

1. The Lion: Courage

The first thing you will need is courage. I just finished an engagement with a client, and as I said my good-byes, I wanted to leave them with a final shot in the arm to sustain them in the days ahead. We sent them medal stickers with the words “Change Takes Courage” emblazoned on them. A reminder that courage is foundational to work in an Agile way. 

You need courage to:

  • Ask the questions that break you away from the way we’ve always done things
  • Not succumb to the “fire of the day”
  • Say “No, that’s not going in the backlog”
  • Tell your boss to take his or her request for work to the Product Owner
  • Have healthy conflict and end with a better solution
  • Speak up and give your opinion, no matter who is in the room
  • Give and receive needed feedback
  • Be self-reflective
  • Let go of long-held management, process, and project control beliefs and work differently
  • Change and transition to Agile

Courage is at the very core of all Agile transformations. I see so many organizations where courage has been all but snuffed out by intentions both well-meaning and not-so-well-meaning. 

Whoa! If I only had some courage! The good news is that you do. It’s there within you. It may only be a little spark, but fan it with small acts of courage and, in no time, you’ll be marching into the Wicked Witch of The Way We’ve Always Done Things castle to vanquish her. 

Agile transformation will require courage from leaders, stakeholders, and teams. Be courageous and celebrate courage when you see it. When you see someone holding back you can use a permission-giving phrase to encourage that person to take the leap. Perhaps by saying “Put ‘em up! Put ‘em up!,” in your best Cowardly Lion’s voice!

2. The Scarecrow: Mindset

In Agile circles, we talk a lot about how Agile is not a process, methodology, or lifecycle. We don’t get the benefits Agile has to offer if we “do Agile.” We get the benefits when we ARE agile. That means shifting the way we think about how to work, how to interact with one another, and how to lead. 

More than memorizing the Agile Manifesto, principles, and values we need to think and act in concert with them. Only then can we transform and realize the business outcomes that Agile helps us achieve.

In practice, this mindset shift looks like this:

  • Turning away from the tyranny of the urgent and moving toward sustainability and predictability
  • Resisting going back to familiar (comfortable) processes and methods to forge new or repair relationships to have productive interactions
  • Moving from managing through status and reports to encouraging and supporting teams to meet their commitments, allowing working software to be the most important measure of progress
  • Enabling our teams by reaching out to our peers to solve long-standing systemic issues that have been a source of slowness all along
  • As a leader, resisting the urge to solve a problem you know how to solve and allowing the team to wrestle with it for a bit and solve it on their own
  • Instead of business and technology working separate from one another, because the other “just doesn’t get it,” both teams are being transparent with themselves and each other
  • Delivering value instead of delivering “deliverables”

Whoa! If I only had an Agile brain! The good news is that you do. It’s in you, it just may need a little rewiring. 

Be intentional in your thinking and decision-making. Ask yourself and others, “Does what we are doing align with Agile principles and values?” Truly explore the worst case scenario of not doing something, rather than responding to the urgent and often inaccurate, “we just have to do it.” 

As a leader, before responding, ask yourself, “Will my response empower my team and encourage ownership?”

3. The Tin Man: Compassion

The transition to Agile is challenging from a tactical perspective. 

It’s even more challenging from an interpersonal perspective. In my opinion, we don’t talk about or equip people sufficiently to deal with what we each experience during an Agile transformation. We teach how to write a user story–relatively easy. But teaching someone how to remain confident when their job, who they work with, and how they interact is significantly changing?  That’s much more difficult. 

As leaders and teammates, we need to have heart and give grace when people and teams:

  • Mess up
  • React emotionally
  • Try and fail
  • Need support in their new roles/jobs
  • Need to adjust

Whoa! If I only had a heart! You know you do. You just need to have the courage to let it show. 

Be willing to have conversations about “humanness” during your Agile transformation. By showing and accepting a little vulnerability, you will be amazed at the trust you can build even in this time of change.

4. Toto: The Friend

Toto was Dorothy’s stalwart companion. He would not abandon her and jumped off a moving bicycle to get back to her. Likewise, Dorothy would not abandon Toto and ran away from home to protect him. 

On this journey, you’ll be tested. You will doubt yourself. Expect it. You are trying new things! Find yourself a Toto to be your sounding board, your cheerleader, your sympathetic ear, and your voice of reason. 

Return the favor for your friend–and don’t let your friend get carried off by a flying monkey!

5. The Wizard: A Coach

The Wizard was ultimately able to help the Lion, the Scarecrow, the Tin Man, and Dorothy realize they already had what they needed within them. They had the power to change their circumstances, they just needed some coaching. The Wizard could see what was inside them, even when they were not yet able to. He didn’t fix their predicaments, he showed them how to fix them on their own. 

As you trek down your Agile Yellow Brick Road, you will need a Wizard. Someone to see what you can not yet see. Someone who has traveled this road many times and will help you solve your predicaments and challenges on your own. Someone to guide you away from the poppy fields and flying monkeys to keep you on course.

The Wicked Witch of the Way We’ve Always Done Things is extremely powerful and hard to resist. You need someone who has battled her before and won.

Conclusion

I hope these 5 tips help your Agile transformation go a little smoother, and I wish you a successful journey. 

If you are looking for a Wizard, give Agile Velocity a call. Or you can learn more about our approach to building lasting business agility on our Transformation Services page.

Blog

Zombie Agility & 3 Antidotes to Eradicate Infection In Your Organization – Part 3

By: rachel.abrams@agilevelocity.com Cottrell | Oct 29, 2019 |  Agile Transformation,  Article,  Leadership

In the previous articles of this series, I covered the first and second antidotes to Zombie Agility, the regular and generous application of compelling Business Outcomes and ensuring your change agents aren’t already infected.

Today, we’ll explore the third and final antidote: building strong teams with the capabilities to achieve the organization’s desired business outcomes–and fend off a zombie attack.

Antidote #3: Build healthy teams with strong capabilities to easily repel future Zombie Agility attacks

Zombie Agility is lazy. It avoids hard work. That’s how you can repel it. 

Building teams’ durable capabilities is itself an antidote. Creating team and organization capabilities like measuring results, aligning cross-functionally to deliver value, being action enabled, and building predictable delivery cadences is work. Zombie Agility will get a whiff of teams working hard to develop those capabilities and will move to the next victim.

Let’s say the vision is clear about desired business outcomes. 

Change agents actively reinforce the end goal. This means team attention and energy turns to building their capabilities to make it all happen. Those emerging capabilities become part of the fabric of a sound team and, with continued effort, become extremely durable. 

Teams with sound capabilities can stand up to Zombie Agility threats. Those capabilities help to swiftly address changing business priorities based on new lessons about client needs. Those capabilities help to address obstacles (real and perceived) that naturally show up, like tech debt, production issues, or whatever else is thrown at the team. 

Teams that experience the thrill of growing their capabilities, skills, and results because agility gives them new insights, approaches, and learning? Great. But when the goal is only to “go Agile,” it’s just a matter of time before Zombie Agility is more common than not. 

Conclusion

In conclusion, Zombie Agility is eradicated with crucial sequencing. It goes like this: Desirable business outcomes set the vision. The outcomes are delivered by strong teams with healthy capabilities. All the Agile things (empirically tested practices, meetings, progress reports, etc) are the means to those ends. 

Agility turns into Zombie Agility when the order of events is turned around, no matter why. I don’t really believe zombies are real (much). But I do see Zombie Agility when Agile becomes the end goal, and not simply a means to the end. It doesn’t take much to get it wrong, I’m afraid. 

I hope these antidotes are helpful because delivering better outcomes for customers and creating a better environment for employees is important. Let’s do that. 

Final disclaimer: Anything good above comes from lessons learned using our Path to Agility® Transformation Framework, and by working with our founder and thought leader, David Hawks, who offered me the antidotes like the ones above. 

#nozombies 

 

If you haven’t yet, you can read the previous two articles in this series here:

Blog

Zombie Agility & 3 Antidotes to Eradicate Infection In Your Organization – Part 2

By: rachel.abrams@agilevelocity.com Cottrell | Oct 28, 2019 |  Agile Transformation,  Article,  Leadership

In the previous article in this series, I covered the first antidote to the Zombie Agility contagion, the regular and generous application of compelling Business Outcomes. 

Today, I’ll jump into the second antidote: ensuring your internal Agile change agents aren’t carrying the virus themselves.

Antidote #2: Make sure your Agile change agents aren’t infected themselves

Zombie Agility is transmitted from human to human. Infections can be blatant or subtle. The problem is change agents may not know they are infected. More, you likely aren’t very practiced at knowing how to identify who might be infected and who is not. 

But you, the business outcomes leader, have decided to eradicate Zombie Agility by keeping Agile as the means to the real goal. Therefore, you cannot leave room for the zombie contagion to spread. Your goals and outcomes are too important. Besides, you’re working too hard to communicate compelling outcomes to your teams (See Antidote #1). 

How can you certify your Agile change agents aren’t infected? No surprise, it’s going to take work on your part to make sure all is well. 

Proactive Approaches: 

  • Invest time with your change agents to ensure they really grasp the business outcomes that are in focus and how those credible and compelling results are critical to the company
  • Explicitly enlist their help to spread the word about these outcomes among all the teams. They should know they are expected to reinforce the outcomes story
  • Ask for their help to make sure everyone on your teams knows how they each contribute to the business outcomes focus

Reactive Approaches:

  • Be especially wary when you hear change agents say things which indicate Zombie Agility. The key here is identifying when “going Agile” becomes more important than the outcomes that agility helps deliver. Watch for comments like:
    • “We aren’t agile enough!”
    • “Leaders need to be more agile.”
    • “Jargon, jargon, jargon…” (Think “Brains…Brains…Brains” when you hear Agile jargon)
  • Be on the lookout for misplaced excitement about Agile compliance or adherence. What you want to hear is:
    • How teams are celebrating wins
    • What results they’re delivering
    • Lessons they are learning
    • How they are collaborating better internally and across the organization
    • Etc. 

Conclusion

It’s a real possibility that some of your Agile experts may need inoculation and that’s OK. Unlike real zombies (I cannot believe I’m taking this analogy this far), Zombie Agility is completely reversible. To reverse it, they need to understand why they mistook Agile as the goal, and how they can ensure they won’t regress. 

Spoiler: It’s well worth the effort. 

 

Don’t forget to check out the third and final installment of the Zombie Agility series, we’ll cover the last antidote: building healthy teams with strong capabilities. 

 

Blog

Zombie Agility and 3 Antidotes to Eradicate It In Your Organization – Part 1

By: Agile Velocity | Oct 24, 2019 |  Agile Coaching,  Agile Transformation,  Article,  Leadership

Preface: The author assumes the reader has a working understanding of zombies and is open to the possibility they are real. (Hint: They are.)

Disclaimer: “Every analogy breaks down eventually.” – Marc Escobosa,1998.

“Zombie Agility is here. I seen it.” – Erik Cottrell, 2019.

Zombie Agility takes over when the goal of an organization is simply to “go Agile.” Whenever Agile becomes the goal, expect a zombie epidemic. Surprise! It doesn’t just happen at the start of an Agile transformation. 

You know your organization has Zombie Agility when…

  • Your Agile teams are half-animated, joyless, and listless
  • You’re Agile! But you still aren’t seeing desired business results
  • Your colleagues observe lackluster results and disengaged people

Thriving Agility is good. You achieve this when the business goal is to deliver more value, with more predictably, and better learning. In other words, the goal is continuous improvement for customers and employees.

I’ve been a part of Zombie Agility. In fact, I have since learned I contributed to it. It was soul-crushing. It was physically taxing for many of my teams. It nearly broke us. We were not vibrant, growing, or thriving. We often felt like we were sleepwalking through the motions. 

Good news? Zombie Agility has proven antidotes. I hope these antidotes will spark conversations among your teams about how to eradicate the Zombie Agility threat inside your organization.

In today’s article, we’ll start with the first of 3 antidotes–Stay tuned for my articles on the other 2.

Antidote #1: Inoculate your teams against Zombie Agility’s mindlessness by the regular and generous application of compelling Business Outcomes

Mindlessness incubates Zombie Agility. With no clarity of purpose, no compelling results in sight, and no clear objectives, teams start to wander aimlessly. The zombie contagion starts when “doing agile things” becomes the focus, without a clear business result as a goal. Beware of Agile transformations that lack a crisp, mind-sharpening focus on business results. 

The goal of a transformation is not to “go Agile.” You can start to inoculate your organization by banishing that term forever. Instead, the goal for adopting Agile is obtaining better outcomes you can’t get with the way you work now. 

Here are some examples of better Business Outcomes:

  • Market Responsiveness
  • Customer Satisfaction
  • Employee Engagement

Business Outcomes are the goalposts for high-performance teams that use Agile to deliver those valuable outcomes.

Maybe you can see how teams that aren’t inoculated can be infected. As soon as the company decides to “go Agile” without clear Business Outcomes, the minds of team members turn into zombie mush. Like real zombies focusing on “Brains…Brains…Brains,” they’re focusing on “Scrum… Stand ups… Burn downs…Retrospectives…Mmmmmm. ” Their valuable brainpower turns to mindless process compliance. As a result, energy is not invested in better customer experiences or Business Outcomes. 

To treat this, regularly track and communicate progress towards the organization’s desired Business Outcomes.  

These Business Outcomes, delivered with agility, provide:

  • Crucial direction for the organization
  • Clarity to inform better decision making 
  • Collaboration towards shared goals that make work more engaging

Progressing together towards these Business Outcomes instills pride and reinforces teamwork as people strive together for improvement. No room for mindlessness there.

Conclusion

So, to inoculate against mindless Zombie Agility, make the Business Outcomes you seek credible and inspirational. Talk about why they matter as often as you can. You literally cannot under-communicate compelling outcomes. 

“When you’re tired of saying it, people are starting to hear it to hear it.” – Jeff Weiner, Measure What Matters by John Doerr

 

In the next article of this series, I’ll share Antidote #2: Making sure your Agile change agents aren’t infected. 

 

Blog

“Overcome Transformation Impediments with Outcome-Driven Agility” Presented at Southern Fried Agile 2019

By: David Hawks | Oct 22, 2019 |  Agile Coaching,  Agile Transformation,  Leadership,  Slides

As the rate of market disruption increases, it’s now more important than ever that organizations gain the ability to respond, adapt, and thrive. This is why many companies are embarking on Agile transformations. However, few of them ever realize that level of agility and many struggle to realize the benefits Agile promises (speed, quality, engaged employees). For that reason, many organizations give up before they see results. 

In this workshop at Southern Fried Agile 2019, Agile Velocity Founder and Chief Agilist David Hawks explained common impediments to agility and how implementing Agile develops new capabilities across the organization.

Key Takeaways From “Overcome Transformation Impediments with Outcome-Driven Agility”:

  • The impacts of four key impediments slowing or preventing significant gains
  • An understanding of how an organization develops new abilities by implementing Agile practices and how those abilities result in organizational agility 
  • The ability to assess their current state of agility and where to focus near term
Blog

Live Stream Recording “The Biggest Missed Opportunity: Focusing On Agile Things Instead Of Business Outcomes”

By: Agile Velocity | Oct 18, 2019 |  Agile Transformation,  Webinar

Did you know Amazon doesn’t even use standard Agile practices and vocabulary? Yet, they are arguably the most agile and successful organizations in the world. 

It’s not about doing Agile. It’s about gaining capabilities that drive results from Agile like happy customers, market responsiveness, engaged employees, etc. 

On November 7th, we hosted an event all about achieving these results from Agile. If you didn’t make the event, we recorded David’s talk so you wouldn’t miss a thing.

Key Takeaways:

– In a survey performed in David’s conference presentations on organizations’ current state of agility, over 50% reported that they were still improving their agility while 29% reported they still only had “Superficial Agility” in their organizations. Why does this happen? David explains. 

– There are 9 different Business Outcomes we’ve identified as important goals for a transformation: 

  1. Speed
  2. Predictability
  3. Market Responsiveness
  4. Customer Satisfaction
  5. Innovation
  6. Employee Engagement
  7. Quality 
  8. Productivity
  9. Continuous Improvement

– Once you determine what Business Outcomes your organization is after, then you can determine which Agile Outcomes and Practices you need to achieve those outcomes. For example, there are a total of 8 Agile Outcomes that go into improving an organization’s Speed, including the Ability to Focus and Decision Agility. 

 

We hope you found this live stream beneficial. If you have questions or if you’d like to learn more about how we successfully guide organizations as they work to become more agile through coaching, training, or a simple tune-up, you can reach out here.

Blog

“Behind the Agile Curtain: Why Leaders Choose Agility” Panel Presented at Keep Austin Agile 2019

By: Agile Velocity | Oct 09, 2019 |  Agile Transformation,  Leadership

In this panel at Keep Austin Agile, Erik Cottrell (CEO, Agile Velocity), Nicole Tanzillo (CO-Founder & COO, Ceresa), Ron Dovich (Assistant VP of Technology, AT&T Cybersecurity), and Amy Green-Hinojosa (VP, Project Management Office, Texas Mutual Insurance) shared an inside look into what it takes to convince leaders of Agile, the challenges and rewards of leading change, and the benefits they realized once they began to embrace agility. Read the full transcription below.

My name is Erik Cottrell, and I’m with Agile Velocity. It is an honor to be here with you today.

What we intended to do with this panel was to give folks a glimpse into what it’s like for leaders who are on an agility journey. We have the great fortune of working with some really great companies, and for me personally, I’ve worked with three of the finest people I know. They are on stage today, so we are going to allow them to tell their stories.

 

 

My name is Nicole Tanzillo. I am the co-founder and COO of a company called Ceresa. We are based here in Austin, and we are focused on democratizing access to the best of the best in terms of leadership development through a technology platform. I’ll also be commenting from my past role. Most recently I spent eight years at Spiceworks, moving through a number of roles there, including pioneering our product operations function. That ultimately lead into business operations, where I was the VP on our executive team, leading some of our broader strategic functions and specifically our Agile transformation.

 

 

I’m Ron Dovich, AVP of Technology at AT&T Cybersecurity. We were AlienVault and got acquired about a year ago into AT&T. They formed a new cybersecurity unit as part of the acquisition, and I run the engineering team of about a hundred people. We focus on threat detection for businesses.

 

 

My name is Amy Green-Hinojosa I work at Texas Mutual Insurance Company. We are the leading provider of workers comp insurance for the state of Texas. I am Vice President of Enterprise Program Management for the organization. We oversee all of the core initiatives of the company, and I had the pleasure of being the executive sponsor for our Agile transformation.

 

 

Erik: What led to your decision to pursue agility?

Ron: We were in an Agile process, but we had really plateaued. Coming into the organization, we didn’t have much Agile experience at all. We got to a certain point and really struggled to get the team to move any further. We had a lot of problems with carry-over of stories from sprint to sprint, so we were not predictable at all. We had challenges in the organization even though the leaders were saying, “Hey, go do these things,” the team didn’t really know how to do them. We needed to help the teams so we said, “Hey, we need outside help.”

Nicole: Very similarly, what we were doing wasn’t working anymore. Our organization had gotten to the size of about a 100+ folks in the technical organization across engineering, product, design, IT, and devops. 

We had recently rolled out product management, which was new for the organization, and we didn’t really change things with that new team so we were experiencing a lot of struggles. From a business perspective, [we, the leadership team,] felt like we were spending a lot of money on our technical organization but didn’t really know what we were getting. It didn’t feel like we were aligned on what we were supposed to be building. 

On the flip side, the engineering organization was super frustrated. They felt like they were getting different direction and changing priorities from leadership constantly. They felt like they were having mounting technical debt, and felt like leadership wasn’t listening. There was a bunch of miscommunication and misalignment. We knew it wasn’t working, and we knew of this Agile thing that people say is great. So we decided to go see if it would work for us. It really it came down to the fact that we knew we had to do something because nobody was particularly happy with where we were at the time.

Amy: Our story is very similar. We were in the midst of some major legacy replacement, so we had projects that went on for 5 to 7 years. We tried to use some Agile techniques in those big projects, and when we came to the end of those, we looked at ourselves and said, “Well, that was fun.” 

So, we thought we knew what were doing…but we really didn’t know what we were doing. We were just throwing around terms and ideas! But, we had a really neat group of people who did research and started a grassroots effort to push the company to embrace Agile. Some of those people are now moving into leadership positions in the organization…they became evangelists for Agile, and that’s what helped us decide to start our journey.

Erik: I think there’s a thread: things were broken, they weren’t working. Was there anything in particular that convinced you to say, “Yep, we know we need to go do something”?

Nicole: We knew we needed to change, but without an external inflection point, it can be hard to pull the trigger. For us, we had a change in leadership in the engineering organization and an opening to new ideas. That was the tipping point that helped us say “OK, it’s time to make some changes.” It’s not that anything fundamentally changed, we didn’t have any more information than we had the day before, but we had momentum in the organization to do it.

Ron: For me, it was that nobody was happy. Management wasn’t happy, the teams weren’t happy. We needed to change something. 

Erik: One of the things I think is interesting is that leaders have to work in teams as well. So Ron, this question is for you. How did you convince your colleagues and leadership at AlienVault (AT&T Cybersecurity) to get on board?

Ron: We thought a lot about it, and we were trying to figure out how to get past the plateau that we were at. We were batting around different ideas, and I had heard of Agile Velocity here a couple years ago so I said “Let’s bring in David.”

David [Hawks] came in for a 2-hour workshop with my team and drove home a lot of points and pushed on us really hard in those two hours. Walking in, everyone had different ideas about what we should do but walking out, we all knew what we needed to go do.

Erik: Question in terms of that same convincing thing… Amy, what did your boss think?

Amy: I had a unique situation. I had two bosses that the time. I had our CIO who was really happy with the way things were going and didn’t really see that there was a need for change. But we had a new COO, Jeanette Ward, who really embraced this and was very excited for the things that she was hearing out in the industry and in journals. She was 150% supportive of this–so, we had to walk the line of pleasing her but also helping bring that CIO along. 

We had to work through some of the processes and get a few little wins under our belt, and eventually, before he retired, he was supportive of our Agile journey and understood the need for it. But, it wasn’t easy to convince somebody who’d been in the IT industry for 40 years that the way we were doing it before wasn’t going to work in this new world. 

Erik: I’m going to dig a little deeper on that one… so, were there specific things that gave that person comfort or confidence that it was okay to keep going down that path? Is there anything that comes to mind that helped them see a different way? 

Amy: Their peers. The other C-suite people in the organization started seeing positive change. He also saw his direct reports really embrace this and come together as a strong team–and that had not necessarily been the case before. But through the transformation, he saw a really good team come together and be able to execute good things.

Erik: Change is almost always disruptive, in some way shape or form. Nicole, looking back now that you’ve changed roles and companies, you have very different hindsight. So, how was this transformation different than yours? 

Nicole: I think if I separate my expectations from the organization’s expectations that will help too. 

It was pretty clear upfront that we had a road to walk down in terms of change. We had 100+ people who were going to be doing this day-to-day. I think the biggest challenge for us was that we had “buy-in” from executive leadership to make [the transformation] happen, but not necessarily real understanding as to what that really meant. So, for us, if I had to go back and think about what I would do differently, it would have been spending more time with them, and really having them walk down the path with us and push it. It’s really easy to let schedules dictate them being involved or not, which makes a lot of sense. But I think we would have ended up where we wanted to be a little faster had we done that. 

As I look back, I’m really glad we did it the way we did it. For us, the decision wasn’t whether we are going to do it or not. It was, “Are we going to do it ourselves or are we going to bring in somebody from the outside?” Because we like to do things ourselves–and that was a really big challenge for us. 

Those of you considering it, there are two things that made me really glad we did. It helped to have somebody that could see the blind spots that we couldn’t see. We were so in it, we didn’t know what we didn’t know–both at a day-to-day implementation and at a leadership level. The other thing is something that I learned in this process that is applied at a lot of different areas: it matters who the message is coming from. I can read a book and figure stuff out–I’m a pretty smart person. I’ve got these skills but the entire engineering organization was not going to listen to me tell them how to do this because I’m not the right person to give this message. I don’t have all the expertise. And for me, finding those experts–whether they were internal or external–to help me champion it was a really big deal. It couldn’t just be about me championing. I had to bring in folks who could champion it for me, in the right ways. 

Amy: We, historically, as an organization, are about doing it ourselves. Bringing in outside expertise has not been a part of our culture. This was one of the first times that we brought someone in to really help us see the blind spots. We’re really good at what we do both on the insurance and the technology side, so we have a level of arrogance–that we earned! But to have someone come in and tell us, “You’re good, but you’re not as good as you think, and here’s where you need to focus,” was so powerful. We would have missed the mark completely if we had not had someone there to help us through those things. 

Ron: For me the biggest thing was, I thought they would help us with processes, but that’s such a small piece of it. It’s the people, the soft skills, the communication problems, the collaboration, relinquishing the command and control that we were doing as leaders–telling people what to do and not letting the people come with their best ideas–that was the biggest unexpected part for me.

Amy: It’s painful in the middle of your transformation when your teams say, “You are the impediment. You need to change this.” You cannot lead in the same way.

Nicole: That’s one of the things we also saw. As the teams were rising up and having more initiative, they had to wait on us. They were looking to us for context to make localized decisions that would make sense in the context of the broader organization. And we weren’t doing our jobs–we wouldn’t tell them. They’d make decisions, and we would have to go back to correct stuff–everyone was mad. It put a lot more ownership on us to put in the work up front and set up those frameworks so they could just go. We didn’t understand that right out the gate, that this would really impact how leadership behaves. 

Audience member: When you give up control, you’re giving up power. You guys seem to have handled it pretty well. What advice do you have for other leaders? In enterprises, it’s all about control. Span and scope means power–how do you manage giving up power?

Ron: Leaders also need coaching. We need help. We get to a certain point in our careers where we think we got this, but we really don’t and our people see through it. So, you have to get somebody to help you drill into an issue and really figure out why you’re having that issue and what the root of the problem is–most of us are pretty poor at that. You don’t just bring in people and have them fix your teams, you have to help yourself along the way. 

Nicole: One of the things I read in Turn The Ship Around is that relinquishing control is so fear-based. Anyone else type A? I suffer from that disease, and it’s really hard. We don’t scale as leaders if we keep holding on to things, and Erik is still teaching me that lesson everyday. One of the great things they talk about in that book is how are you pushing that down in a way that you can be confident it’s going to work–a leaders job is about creating and testing competency in your people. It is on us to not just give it to them but to think about the mechanisms in place to certify that competency so they are able to make decisions. So for me it’s about starting to develop those frameworks and processes so that I can release control.

Amy: Baby steps. Small wins that begin to tell the story that it’s okay to let power go.

Erik: One of the things that often happens, is we forget the fact that you have to give before you can get. Leaders have a tough job. A lot of people come to them asking and taking, no one is coming to them giving. As people seeking to drive change, we have to remember their goals are not our goals and we need to get our goals aligned to their goals and treat them with the same kind of respect we’re asking for.

Nicole: What the transformation has been about for us is much more about how people work together, how we communicate, how we prioritize, how to make decisions, and far less about how everything is set up mechanically.  

Erik: Let’s talk about the benefits. What was the best part about your transformation?

Ron: For me, it is when the team started to come back and ask for things from us. Before, leadership was telling everybody what to go do. Suddenly the teams started coming to us saying what they need and why they need it. Which meant we were finally working together towards the same goals. 

Amy: The first time the teams started coming back with the most amazing solutions that nobody thought was possible and started asking the why’s: “How come we can’t do that?” and “Can we do that?” was amazing to see. We’re only 19 months into our transformation but our teams are already developing things that no engineer was thinking about a year or two years ago.

Nicole: Pretty quickly, I saw that once we got out of the bottom of the change curve, the energy fundamentally changed. There’s something about having things on the wall, having standups, and operating differently that they were able to take ownership in a way they never had the context to do well before. It was exciting and felt good to be around.

Erik: One of the things that we often run up against is culture. How has your culture been impacted?

Amy: Our culture has changed significantly. We are a good place to work. We were voted one of the best places to work in Texas. But within IT, we were very siloed. Teams didn’t interact with each other, and we didn’t interact as much with our onsite business customers. 

But, now what you see is that buzz and energy. Everybody is really focused on collaboration and tackling things together. People that never spoke to each other before or interact with each other are working together. Once people got empowered and were given freedom in their abilities to work, it changed from a happy, positive place to this energetic, exciting place to be. 

It hasn’t been all rainbows and unicorns because while people ask for empowerment and freedom, there is responsibility that comes with that. Transitioning and helping teams understand that they are responsible and accountable for things they didn’t have to worry about before caused some stress. But, I think they’re coming around to that. Now that they understand that we’ve put frameworks and guardrails in place, the technology group at Texas Mutual is a better, more energetic environment.

Ron: We’re till pretty early in our transformation, only about 8 or 9 months in. It hasn’t changed our culture yet, but we are in transition.

Nicole: It helped uncover issues in our culture. It is hard to hide stuff in this model. Right away when we were first doing some workshops, we identified some divas who were used to working in a very isolated way and perhaps not treating their colleagues super well because they were so amazing at what they did. That doesn’t fly so well in this model. 

So, it created some really hard choices for the leadership team right away, because we had to decide if we allow this one person to continue to do their own thing or if we say this person is not a fit for the organization that we’re building. In some cases, they figured it out and others don’t work there anymore because it just wasn’t aligned with where we were going. You gotta engage. 

Amy: It’s a drastic change going from individual contributors, getting kudos to focusing on the team where everybody is scored the same and it is a team success. There are no more superheroes and the playing field becomes level. 

Erik: One of the things that I noticed at Texas Mutual: There is a team that had an area [in the office] and outside of it there was a sign that said “Success on delivering on our last commitment”. Beneath this sign, they had a picture of a thumb that you can turn up or down. For the next sprint the thumb was turned down. They were broadcasting to the entire company that they did not meet their commitment. 

I told the CIO that they don’t have to manage that team anymore. They are self-managing, holding themselves accountable.

Audience member: We’ve talked about teams and individuals, but how did this process change you? How did it impact you as a leader? 

Amy: It made us hold a mirror up to ourselves as a leader and say, “What does this new world mean to me?” and, “Do I even want to be a leader in this new world?” or, “Am I willing to make that kind of change?” 

You have to look at yourself and make a real, deliberate choice to lead differently.

Nicole: I grew as much or more than the organization did in this process. There were a lot of moments where I was freaking out. We were asking really big questions that I didn’t have the answers to, and wasn’t sure how we are going to get there with our leadership team. It’s that battle of, “How do I do the work that puts the team first and offers what they need out of me?”

That’s exhausting: slowing down and being thoughtful before I go into a conversation,  thinking about what they need from me. Because it’s not about what I have, it’s about what they need.

Ron: It’s re-energized me. You can do these jobs for years and get good at it, but am I really being strategic. This will make you question what you are getting done and what your priorities are. Now you have to spend more time being thoughtful instead of just blowing through things.

Erik: How do you work with your partners on the business side to get them to see what you’re about to do? 

Amy: One of the things that we did when we decided to go on the journey, was put together an Agile Leadership Team of people to help guide the journey. We went and asked our executive leadership if we could have some people from our business unit be a part of that. 

We didn’t get a whole lot of people, but we got enough and converted some to evangelize Agile to the business. It was really important to have the voice of our business counterparts be a part of the transformation. IT can stand up all day long and talk about benefits, but if the business side it not part of that journey, it’s really hard for them to understand. We also checked in a lot with our business leadership people, and gave them Agile updates every week. We forced them along with our journey.

Nicole: We got away from talking about the features and stuff we were doing to what we were trying to do for the business. We were able to connect by shifting our goals and communication to be around the outcomes we were trying to achieve. We were speaking their language and that was a big shift for us. It moved us from being an activity-based organization to an outcome-based organization. 

Ron: We’re not there. We’re siloed from the rest of the business–and by business, I don’t mean AT&T, I mean the threat detection and response piece of the Cybersecurity unit–the rest of the business unit around us thinks Agile is an engineering thing. 

Erik’s Advice: Banish every bit of jargon. Don’t use the word Agile–Agility doesn’t count [as jargon]. Try and have a conversation. It’s all about working together. Are we clear about what we are trying to do, do we communicate well, do we fight well? Banishing the jargon is a good exercise because it helps us think about what are we trying to do together.

Audience member: How did you work through the need to be there at all times and fully informed of all details?

Ron: I’m still working on it. As our organization continues to grow, you just can’t. You have to be comfortable relying on other people. It’s a struggle because when someone asks a question you want to know the answer, but I often don’t.

Audience member: How do you handle it when someone wants to be the answer person?

Nicole: If we democratize access to the data, then everyone can validate, verify, and provide that data as well. So, the more we can get away from only one person being able to access the data, the better.

Amy: That is the journey we are on right now, getting that visibility so anybody can self service the information they need about the work that is getting done. 

Erik: I challenge you to step back, because this person is doing this for a reason–it gives them a sense of value. When you take a step back, you realize this person just needs love and validation. [Sometimes, a little sympathy and conversation can work wonders.]Final words of wisdom:

Ron: Get yourself a coach. Could be a mentor–just someone who is willing to ask you tough questions. It has been life changing for me. 

Nicole: It’s not just about us. Lebron has a coach. The US Women’s Soccer Team has a coach. These are world class people doing world class things, and they still have coaches because none of us can see the blind spots. Having someone who is objective both for us as leadership and for your team is important. 

One of the biggest mistakes we almost made was not having Agile team coaches. Everyone thought that they were going to be a Scrum Master who would take notes and schedule meetings. But that is so far from the truth.  This idea of having a coaching mindset in an organization is transformative but you have to have enough of them and support for them for it to take hold.

Amy: Build internal coaches. Because when the external coaches leave, you still have that coaching capability in your organization–and you will need it.