On 4-3-19, I’m excited to be brining my talk “What Can Agilists Learn from Super Hero Movies” to Raleigh for Tri-Agile! Here’s a small taste of what I’ll be sharing:
On 4-3-19, I’m excited to be brining my talk “What Can Agilists Learn from Super Hero Movies” to Raleigh for Tri-Agile! Here’s a small taste of what I’ll be sharing:
While this is too much content to clone onto this forum, myself and 2 colleagues put together a nice series on the 12 Principles of Agile. This series tackles common problems that organizations face in achieving each Principle.
This series is near and dear to my heart. I find that working with the 12 Agile Principles can be a great guiding light to fostering better Agility.
Check out the first part of the 12 part blog series here!
I was the featured guest on this week’s episode of the SqlDataPartnters Podcast, talking about technologists and Super Heroes. Feel free to give it a listen at http://sqldatapartners.com/superheroes or find episode 132 on the SqlDataPartnters podcast on your favorite podcast app.
Superhero stories are the parables of our time and that’s why even mere mortal Agilists can learn some lessons from these crusaders. Don’t worry if you don’t have a tiara or a lasso of truth; there are still plenty of things you can learn from Wonder Woman.
Let’s set the stage–Diana Prince, Wonder Woman, lives in Themyscira on the Paradise Islands among the Amazons. The Amazons are warriors who spend most of their time training and consider themselves the most elite fighters in the world. The Paradise Islands are living up to their name until one day, the German army arrives. Which shouldn’t be a problem, right? These are the most elite warriors in the world. But unfortunately, that doesn’t end up being the case.
The Germans have guns and the Amazonian archers aren’t equipped to handle that tech. Eventually the Amazons do win, but it takes a literal heroic effort from an actual superhero to help them make it through this battle.
The first agile lesson we can learn from this scene is to get off the island. As lovely as that island is or maybe your comfort zone is– don’t isolate yourself. As an Agilist, make sure you’re working within your community and going to local meetups. Being involved can help you stay relevant and frankly more Agile.
When the Germans begin firing their weapons, you can see the bewilderment on the faces of the Amazons. Don’t be like the Wonder Woman here; make sure you’re getting out there and seeing what is new. It will keep you from watching the bullet fly right by your face. You don’t want the first time you’re seeing a piece of technology to be when it’s already starting to overtake you.
Were the Amazons really trying to be the best warriors in the world or the just the best archers? It seems if they had aligned their goals they might have been better prepared for this unexpected attack. When you’re working with your teams think about what your end goal truly is. Make sure you align everyone with what you are trying to do and make sure you know what you’re striving for.
Everyone has probably been a part of a project where you witnessed the superhero mentality. This is when someone comes in and pulls all kinds of crazy hours to save a project last a minute. As Agilists, we want to make sure that even if we do get saved by a superhero that it doesn’t stop us from continuously improving. After this battle, do you think the Amazons actually learned about this new technology and leveraged it in their future battles? I’m not sure, but I do know that if you stop learning and improving as you go along it’s easy to be left behind.
SAFe version 4.5 was released on 6/21, and I’ve been excited to dig in and see the changes. Check out the official site for more details on change. Here are some of the changes I’m most excited to see.
The SAFe 4.0 Big Picture can be overwhelming, especially when expanding to 4 levels. SAFe has made 4 different views of the Big Picture that limit the focus of the model, depending on the organization’s need.
Part of this change gives better guidance to organizations on how to adopt subsets of the full Big Picture. With this change, SAFe has adopted some of the lean agile mindset to the process of adopting SAFe – start with an MVP, and build Features on top of that as needed.
SAFe has recognized that there’s more to implementing a successful SAFe environment than simply training all the relevant people involved.
There’s a specific emphasis in the new roadmap on identifying Value Streams and creating ARTs within the Value Streams – a hugely important factor to get right up front. ARTs aren’t particularly helpful if they aren’t properly aligned with a value stream. Either you have multiple value streams within an ART, which weakens the power of an ART, and creates a divide. Or you could have an ART where the value stream actually cuts across multiple portfolios, which creates a huge mess. Getting this right up front saves a huge amount of time and frustration for the teams and programs, so it’s great that SAFe has baked this into the implementation guidelines.
SAFe has explicitely and heavily incorporated the lean startup idea into the model. There is a newly placed emphasis on incorporating the “Build-measure-learn” lean startup cycle (which SAFe has expanded to “Hypothesize-build-measure-learn”) into all levels. This has caused a number of small and larger changes to the model.
This is one of my personal favorite changes to the SAFe model. SAFe has tied the lean startup model directly across the Portfolio and Program layer. This emphasizes one of the underlying principles of Agile – build lean, release, and only build more features if the MVP is worth building upon.
It also clarifies that work continues on the MVP until the tradeoffs suggest working on something else more valuable.
SAFe has recognized that to release lots of MVPs, you need to have the Continuous Delivery Pipeline and Dev Ops to support it. SAFe explicitly calls out both of these on the big picture to emphasize the importance.
SAFe has added an Agile version of Compliance to the Big Picture. Compliance often lives in a Waterfall world, clashing with IT efforts to run Agile.
This is a great first step, and I hope that SAFe will look into other regulations that large enterprises face that often run in Waterfall, such as legal reviews.
The SPC has been added to the Big Picture. SAFe is recognizing the need for additional help beyond the existing roles to help stand up and perpetuate a successful SAFe implementation.
I would encourage organizations to be careful about falling into the “Certification Trap.” While a few of the training activities require an SPC to deliver, the majority of the SPC responsibilities can be executed by an experienced non-SPC coach.
The two major themes in SAFe 4.5 are an emphasis on experimentation through the Lean Startup Mentality and creating new tools that make SAFe itself scalable depending on the size and needs of the organization. SAFe has leaned itself down as small as the Essential SAFe level.
Organizations that are considering SAFe can now combine these two mentalities in their adoption of SAFe. They can start small and lean with an MVP of Essential SAFe, and evaluate the experiment. If it works well, they can add new features to a larger version of SAFe, or abandon the experiment entirely.
With SAFe 4.5, I hope that organizations are now able to take these lean, experimental ideas not just into their software development, but also into their own adoption or expansion of SAFe.
Traditionally, Iterations in a SAFe Program Increment are dedicated to delivering on User Stories and Features. The ideal team is stable and has good, broken down work that allows for consistent delivery Iteration after Iteration. The last thing any Scrum Master wants to see is a Velocity chart that looks more like a seismograph.
When teams get to consistent User Story delivery, the hope is that they can deliver Features consistently over the course of a PI. When talking about nailing the basics, one of the first things mentioned is meeting commitments on a regular basis.
In order to set up teams for consistent delivery, a conservative culture often develops in SAFe environments (and I’m not the only one to observe this). SAFe encourage User Stories and Features that are well-defined, well-understood, and have minimal uncertainty. Teams make sure their User Stories and Features are as refined as possible before committing to them in a PI or Iteration.
This conservative Culture isn’t necessarily a bad thing. Remember, it’s stemming from the lofty goal of consistent delivery. However, it’s important to recognize that this Culture is not conducive to innovation.
The flip-side of encouraging consistent delivery is that risk taking is inherently discouraged. Anything inherently risky or uncertain is encouraged to be better refined. This gives us predictable delivery, but how innovative can our delivery be if we’re not taking any risks?
SAFe explicitly recognizes that innovation may not really be possible during normal delivery Iteration by saying “finding time for free association and innovation in the midst of delivery deadlines can be difficult.” And they put their money where their mouth is by building in time in the PI to dedicate to innovation.
After 10+ weeks of conservative, consistent delivery, what are the odds that people will naturally shift into a mindset of innovation for 2 weeks? As Agile leaders, we need to be deliberate to shift our Culture during the Innovation Iteration; otherwise, there’s a serious risk that the conservative Culture of the normal delivery cycle will bleed into the Innovation sprint.
Hackathons are a common way of leveraging the Innovation Iteration to encourage novel thinking in a fun environment. I recommend any hackathons leverage the SAFe encouragement for them to be free-form – allowing team members to work on whatever they want with whomever they want. This is a clear shift in Culture from the hyper-organized environment during delivery sprints.
There’s evidence that embracing failures helps encourage innovation. If failure is actively discouraged, what incentive is there to stick out with an innovative idea if you’re likely to get hammered back down?
Take time to reflect what is being celebrated in your ART’s hackathon. I worked with a client who celebrated the most successfully executed Hackathon deliverables, which was a great idea and added to the fun of the hackathon. But what incentive is there to risk a truly innovative idea if only the successes are celebrated?
I encouraged the client to not just celebrate the successes, but also the failures. We want to encourage Hackathon teams to dream big and try to build something that may not pan out. We even implemented a “shoot for the moon” award – based on the phrase “shoot for the moon, even if you miss, you’ll land among the stars” – as a way of celebrating a Hackathon team that dreamed big, but didn’t quite hit their mark. What a way to truly shift culture for your Hackathon Iteration by actively rewarding failed ideas. Could you imagine something like that in a traditional SAFe PI?
“A brittle Culture can doom even a great organization.” – Curt Cuffman
It’s said that breakfast is the most important meal of the day. But why is that? Breakfast kick starts your day – you want to embark on your day with a healthy, nutritious meal that sets your day up for success. I know from experience that coffee for breakfast seems like a great idea for about an hour, but when the caffeine boost wears off, the rest of the day becomes a drag.
When thinking about implementing Agile, we want to start by thinking about what we’re having for breakfast – what will start our Agile transformation with the sustaining energy to propel the transformation in the right direction?
The 4 Pillars of Agile
There are 4 major pillars of Agile: Culture, People, Process and Tools. These are the key tenants for an Agile transformation that are so important, I’ll be capitalizing them throughout this blog. When starting an Agile transformation, we should start by thinking about these pillars.
Culture consists of all the intangibles that answer the question: “How do things get done around here?” Culture shapes the environment and ecosystems that will, or already exist, within organizations that drive behavior, feelings, and output.
Agile People are the essence of an organization. People will either thrive or diminish within an organization’s culture. When staffing, whether a team or a whole organization, it’s critical to think through the strengths, attributes, and skills needed for People to be successful.
Processes outline how People will take ideas from discovery through fruition. Processes should assist with the journey from Point A to Point B. It’s important to remember that Agile Processes are meant to be light weight, allowing People the flexibility needed to be successful.
Tools should be implemented to support efficiency and sustainability within a process. Before implementation, tools should be assessed to confirm compatibility with a process. Agile-specific tools incorporate fundamental attributes of Agile processes to ensure synergy.
If we know coffee won’t get us through the day, why would we skip a healthy, nutritious breakfast?
When beginning an Agile transformation, there are serious drawbacks to focusing on other Agile pillars besides Culture.
If we start our Agile transformation by selecting Tools, we run the risk of picking a set of capabilities that are misaligned to our organizations process(es). If we bring a football to a tennis match, we probably won’t have a successful tennis match. Perhaps we shouldn’t have skipped breakfast?
If we start our Agile transformation by establishing Processes, we run the risk of implementing workflows and techniques that render our People useless, preventing our organization from achieving its desired outcomes. If we guarantee 24 hour turnaround, then it would be ill-advised to implement an approval process that takes 72 hours to complete.
If we start our Agile transformation by assessing People, we run the risk of hiring and aligning talent that won’t thrive within our organization’s desired Agile Culture. If we’re building a salt-water fish tank, we probably shouldn’t put fresh-water fish in the tank.
We want to make Culture our Agile breakfast – the first thing we focus on to set the rest of our journey on the right path. Defining what your organization wants to achieve and how you’ll go about achieving it is a critical step that many organizations completely overlook. Yet if an organization is going to have success in their Agile transformation, they should answer this question first: “How do things get done around here?”
It seems like such a simple question to answer, but pause, and try to answer that for yourself. Can you answer that question or these follow-up questions?
Regardless of where you’re at within your Agile transformation, or if you haven’t even started the journey, it’s time to shift the focus to Culture. Culture truly is breakfast – it is the foundation that drives successful Agile transformations. Culture will drive the strategic direction that should align with the desired outcome of the organization.
Having a solid base of Culture will create a solid foundation to support the other 3 Agile pillars. A thriving Culture will promote hiring of People who are aligned to what you’re trying to achieve. A successful Culture promotes better Processes that assist and guide your People toward desired outcomes. Finally, Culture will guide your organization to the correct Tools with the right capabilities needed to support Processes, further setting your People up for success.
Hopefully you’re now convinced that Culture is the bedrock of successful Agile organizations. This post will be updated with links to future blogs written by myself or my co-author Elisabeth White on promoting culture.
This article was also posted on my company’s site.
Elisabeth White is native to Colorado with over 10 years of global experience supporting and guiding organizations through incredible Agile transformations. Her coaching approach is industry and department agnostic – focusing on continuous improvements within Culture, People, Process, and Tools. Elisabeth is an Agile Transformation Lead at CapTech Consulting. She serves as the National Site Lead for CapTech’s Agile Service Offering. She is saving the world, one Agile transformation at a time!
Will Fehringer is a Senior Consultant in our Richmond, VA office and has over 4 years of consulting experience, working with clients in government, banking, and consumer packaged goods industries to deliver Lean, Agile, customer-driven solutions. Will has a passion for working with team and program levels to help bridge the gap between business and technology.