Most people working in software or tech have some fundamental understanding of Agile. That understanding is layered on top of a host of assumptions about how software development operates and what expectations we should hold each other to. That doesn’t mean that those assumptions are correct. As an organization that both trains people to work in an agile way, and hires developers who already embrace an agile mindset, we know that our first day with a company is usually spent debunking a whole lot of Agile urban legend, and resetting a lot of assumptions.
The confusion is understandable. Agile isn’t a system, and it’s hard to define.
Understanding that conceptually is one thing. Ensuring that it is embraced the same way across the organization usually requires some level setting. If you’re not all playing from the same playbook, you’re never going to get the full benefits of an approach that frees up human intervention, encourages automation and innovation, and enables faster delivery of functional software. What’s not to love?
We work with a vendor who told me this story, which illustrates the point well. Early in her career, she was doing sales and marketing for a large Fortune 500 in their call center selling small business products that were all priced between $100 and $200 (listen, it was the ’90s).
While she was pitching one of those products, a senior VP from the home office happened to be visiting and heard her pitch in real time. What on earth, that senior executive said, was she even talking about? She showed this VP the training materials she’d been given, by her boss, that were created locally to train the local employees on her sales team. The VP was livid.
The answer was “No.” What our colleague came to find out was that the company had changed the product post launch and, because they didn’t inform everyone downstream, the people tasked with selling this stuff never got the updated information.
They had absolutely all been trained, they were just trained with wrong information and inconsistently at different times, with different resources, by different leaders, and in different places. What the VP unearthed from overhearing one phone call was that this was an issue in all of their major call centers.
They fixed the issue, but not before customers, and quite a few of them, refused to pay for these products, because, after all, it’s not what they were sold. Sort of the worst-case scenario, right? Training doesn’t just provide information. It ensures consistency, and that’s critical when your staff is changing the way not only that it works, but how it thinks.
What we see time and time again is that even though someone thinks they’re “doing Agile,” it’s not exactly what someone else means, and before too long, people blame the mindset and not the way it’s been implemented. Whenever we run a boot camp, we’re amazed by how many people introduce themselves just like this: “We are an agile company, but in name only. No one really seems to know how it should work. So I’m here to really learn it.”
It’s easy for Agile to get misinterpreted because there are several ways of implementing an agile process (Scrum, Kanban, etc.), and there are also several ways of implementing it inappropriately. Mindsets are tough to define when you don’t understand what that means, let alone if everyone is using a different playbook.
People typically discuss Agile as a polar opposite to waterfall development, when really they’re two different categories. An agile mindset is a creative way to solve big business problems in a contemporary, continuous development world. Waterfall isn’t a mindset, it’s a project management methodology.
In the past, most software had a hard-drop deliverable date with a checklist of requirements. The tech world was assumed to be far more linear and devices far less complex. Today, we know that software is never really done. We’re not asserting that deadlines don’t exist (they do, and they’re important!), but we’re saying that a “fixed” mindset that defined engineering, particularly for software, isn’t always applicable two decades into the 21st century.
Managers and leaders with an agile mindset know how to evolve products over time to get to market faster in a changing, volatile world. The agile mind isn’t driven by a fixed idea of what specific features are needed, but rather by what problems need to get solved. When you work backward from a problem, you often discover creative, and underutilized, innovations. In short: Agile isn’t a system. It’s a way to describe a mindset or approach.
That said, there is a lot of confusion as to what, exactly, that mindset is. This is one of the main reasons why there are Agile certifications: They ensure that there is a common, universal understanding of what Agile principles and practices are. But even with certification, there is a lot of variation and diversity.
There are quite a few Agile certifications available (250 and counting) and several different bodies that do the actual certifying. For example, we provide training for certifications from Scrum Alliance that cover several tracks, like Scrum master or product owner.
Each of those tracks then has different levels of certification and training, depending on how far you want or need to take your training.
There are also senior Agile leadership trainings available for people who are interested in becoming certified Agile coaches, trainers, or leaders. Scrum Alliance has three different coaching certifications that are available only for experienced coaches and leaders.
Most certification programs have an exam at the end, and the training can be both time-consuming and costly. Before you do any training, it’s a good idea to do your homework and make sure, among other things, that:
So we posed this question here because we get it a lot…but I’m not going to answer it because there isn’t really a clear-cut answer.
Let’s approach this question from an agile perspective and tweak it so we’re not approaching the problem in such a binary way. Ask this instead:
What insights will a deep understanding of the Agile mindset do for you as a professional or a leader to solve the most critical business problems in your industry?
How an Agile transformation takes shape at a single organization is never quite the same, because no two orgs or departments are, either. That’s why an agile mindset is so important. It’s an umbrella for several flexible methodologies that you can import into nearly any business situation to leverage the feedback from your customers to deliver value faster and with greater innovation.
Let’s go back up to our friend at the call center. What if she’d been sent to a single source that taught her a consistent tool set and then she brought that tool set back to work? What if one person traveled to each office training every sales team instead of just assuming that the right information would magically get into the right hands even as that information changed regularly?
Is the entire team or organization going to evolve overnight or with a two-day training? No more than you could expect to learn to read and speak French or Spanish fluently during a weekend crash course. Short trainings are introductory, they impart knowledge. But all journeys to understanding have to begin somewhere – they all start with knowledge.
Check out these posts below to give you some necessary Agile fluency as you continue your personal and organizational adventure, or join us at one of our upcoming ICAgile Fundamentals training and certification classes.
The Importance of Proper Tools at Work
Agile transition stalling? Maybe it’s not the team. Maybe it’s the tools. In this piece we analyze how the tools you give your team are a foundational aspect of a team-led company.
How to Master the Retrospective Meeting While Working Remotely
Remote work is likely here to stay, and running your retrospectives remotely will crush your team’s collective spirit and productivity if they’re not going well. This article on best practices will help get you out of your retro rut.
The Case for Simplicity at Work
What does maximizing “the work not done” mean in a real-world context when you rip it off the page and apply it? It’s not nearly as complex as you think. Instead, master how to identify what is “simple.”
How an Agile Transformation Might Go Off the Rails (and How Leadership Should Respond)
One of the things we say here all the time is, “If it’s hard, you’re doing it right.” Even though an agile transition can be difficult, that doesn’t mean it should be a struggle. This piece will help you get back on course.