October 5, 2018
TABLE OF CONTENTS
Without a doubt, Agile has taken over the development space, and in many regards has moved beyond traditional software development shops. The majority of North American organizations are using some type of Agile methodology in their technology development process.
Over the last two decades, an increasing number of organizations have been going through what has now been coined an “Agile transformation.” However, if you talk to some organizations on the front lines, you will find that the reasoning behind these transformations are often misguided. Many organizations believe that process changes will fix all of their problems, but that couldn’t be further from the truth.
So, you are “going Agile.” You have your favorite methodology all picked out, you’ve chosen which scaled approach you are going to use, and you’ve put timelines with key performance indicators (KPIs) in place. You know exactly how long your transformation will take, and what work will still need to be conducted under the traditional Waterfall approach until the Agile transformation spreads to your entire organization.
Here’s the problem—it won’t work.
Have you stopped to ask yourself why you decided to go Agile? Is it because you’ve been told you can deliver more at a faster pace? Or because some innovative organizations—such as Spotify—are Agile, and their delivery model has been put on a pedestal by other companies? If any of that sounds like your organization, then you are falling into the same trap many others fall into: you are subscribing to a process instead of focusing on delivering value.
At this point you might be thinking, “Okay, these folks are just a bunch of value zealots that don’t understand that our people need structure.” On the contrary, Levvel believes structure is very necessary (we love it!). However, the type of structure that leads to successful Agile transformations—or disciplined Agile more generally—is one that creates a space where experimentation and failure expose what does and doesn’t work in the context of your organization’s landscape (from the industry all the way down to the people and culture). The type of structure that doesn’t work is dogmatic allegiance to any one methodology or set of tools. The ideal structure is one that leads to adaptability and flexibility, not rigidity.
Rigidity is exactly what you get when you say any variation of this sentence: “Upon the conclusion of our Proof of Concept (POC), we will adopt the Spotify model and we will have full implementation by the end of the year.” If you or anyone else in your organization believe that you can “adopt model X”, you automatically lock yourself into a process. This can lead to blind adherence, which prevents the organization from discovering (or crafting) a well-suited used pattern for delivering value. Discovering and then expanding on a pattern that fits your landscape unleashes value delivery in your organization.
The ideal structure is one that leads to adaptability and flexibility, not rigidity.
Maybe it’s a pattern found in a popular process, but maybe it’s not—and that’s the point. Any Agile organization must structure itself to allow its people to quickly and safely run through all the patterns that don’t work so that they can find the ones that do. It’s also important to note that any one pattern may not work for you forever, so experimentation and refinement are an ongoing effort.
Are you blindly following the hot trend and expecting it to solve your problems, or are you structured in a way that will allow you to discover the right ways to fulfill your needs?
Value over process—that’s the name of the game, and it’s the mindset shift that has helped many organizations mature beyond the point of just following a process.
To be clear, starting with a process is fine, and it’s actually encouraged. Following that process at all costs is the anti-pattern to avoid. Just like with the Agile Values in the Agile Manifesto, the use of the word “over” implies the other is still important, but the first thing is more important.
For example, do you want to implement SAFe? Go right ahead; however, be cautious. As you identify what does or doesn’t work for you, be willing to ask yourself why and tinker with the process, even if the end result isn’t SAFe by the book. The idea isn’t to “implement the Spotify model”— the way forward is to discover your model. Sticking with the SAFe example, this tinkering could be as simple as switching around the Epic > Feature > Story relationship, or changing the Scrum of Scrums to function like something out of Scrum@Scale.
You have to go on a journey to discover what your model looks like. Beg, borrow, and steal from all of the different Agile processes/methodologies/frameworks. Those terms are used interchangeably by most people—and rightfully so—as they are all just a dressed-up way to do the same thing: deliver value.
In all, find what works for you, gravitate towards it, and ruthlessly throw out what doesn’t meet your needs.
Delivering value should be at the forefront of everything you do—after all, if you aren’t delivering value, why are you in business? If something simply isn’t working for your organization, you need to look into why it isn’t working instead of blindly following a process and expecting it to solve the issue. Don’t make changes for the sake of shaking things up—the people who are impacted the most will see that right away, and the outcome won’t be pretty. Instead, dig deeper and find out why some things just aren’t clicking. It could be a lack of training, a lack of direction, or even a misunderstanding from training or direction.
Here are a few actions typically taken by those with a value-centric mindset:
Go through an exercise to help you find the pain points in your process. Once you’ve identified the parts of your process that result in inefficiencies and pain points, ask yourself, “Why is that action even a part of the process? What value does it bring? Can we do things differently?” Experiment with different patterns. It could be as subtle as changing up the style of your stand-up, or it could be a monumental change in how you do long-term planning.
If you’re having issues with your existing teams, consider how you can rearrange the team composition in a positive manner. Let creatives flex their muscles by taking an outside-the-box approach to innovating on your product, or by creating a whole new offering you never thought your customers would want from you.
There isn’t a right or wrong way to do this. Start anywhere, as long as you quickly turn your focus towards putting value at the forefront of everything you do.
Not sure what to do next? Need some guidance or coaching? Levvel knows how to structure organizations to focus on value and find the patterns that work. We have experience coaching development teams of various sizes and locations, ranging from co-located teams at startups to 40+ teams spread around the world at Fortune 50 organizations. Give us a shout at firstname.lastname@example.org.
Founder, Chief Executive Officer
Chris has more than 15 years of technology leadership experience with a specialized focus on financial technology solutions in the consumer, commercial and wealth management space. He has led software development, infrastructure, and QA organizations at multiple Fortune 100 companies and also helped grow and launch a number of early-stage technology companies. Chris’s technical expertise, startup experience, and global program management background enables our ability to support a wide range of clients at all stages of transformation.
Throughout this series we'll provide answers to frequently asked questions surrounding product management for RTP, such as managing the product(s) long term, dealing with cannibalizing current products, and more.
Inspect and adapt. These are words every agile practitioner will hear non-stop in their career—and rightly so. What does it take to inspect and adapt? The answer is both simple and extremely complex. It all comes down to experiments.
Product development failure is real. According to Harvard Business School professor Clayton Christensen, 95 percent of new products fail.
The customer is at the heart of any decision to change a product, and therefore should be considered throughout the entire process, from ideation to release.