Published by Ray Barrera on May 8, 2024
"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan."
It was a simple mantra, and easy for teams to understand, at least in principle. There is no mention of sticky notes, no rules about what meetings to have when and with whom, and no talk about mob or pair programming–just four simple values.
As the industry around software engineering has matured, so too have the processes that drive software development from the ideation phase to delivering a product or service to an end user. This process of maturation has invited many to look at every step of the software development life cycle to eke out every possible optimization. Not just in terms of throughput, but in the increasingly important areas of professional development, developer satisfaction, etc.
The combination of simple values teams could rally around and a love of systems, naturally lead to an attempt to build frameworks that teams could implement. Not just vague idealistic principles, but actionable plans and roles that teams could wrap their heads around.
I’m not just referring to [insert JavaScript framework of the week here]. Along with this agile awakening, we have seen the proliferation of agile frameworks to help teams of any scale implement “agile principles” into their process. No two tech companies are the same–they range from a few individuals to several thousand. Some are public, others are private. Some specialize in highly regulated industries like finance and healthcare. It is against this background that we’ve seen a variety of agile frameworks proliferate. The number of acronyms describing these frameworks will make your head spin–SAFe, XP, LSD, DA, etc.
All that said, you’ve likely heard of at least two frameworks that dominate the landscape: Scrum and Kanban. If you’re in tech, there’s a good chance you’ve at least one of them….
Or at least something you heard referred to by the same name.
To satisfy the demand for process sanity in growing organizations, an entire industry has sprung up–legions of agile trainers, promising to make your process woes a thing of the past. There are mountains of books on the topic, and no shortage of gurus willing to help teach your organization the agile way… for a handsome fee. In the VC-powered land of tech and software, there is no shortage of opportunity for building an entire career out of training and coaching teams on agile.
The demand for these coaching services has grown, but the supply of true experts in the field software engineering that actually know how to grow organizations and help build teams that work efficiently has not kept up with the demand. True expertise takes time, dedication, and effort to develop. In order to bridge the gap, the industry has tried to fill in the gaps, and build shortcuts. Training programs and certifications that you can complete in days or weeks are readily available… for a handsome fee. And just like that, you can become a bonafide agile expert without ever having led a team successfully.
The shrewdest of the bunch, have found ways not just to fill the gaps in demand, but to invent all-new niches within the industry. And with each “invention”, or layer of training on top of the core concepts, we get farther and farther from what Agile was meant to be.
For those lucky enough to find the pockets of true expertise in the industry, and to match them with leaders within organizations that effect true, radical change, the benefits of agile are immediate, obvious, and profound.
All too often, unfortunately, engineering teams are left with a sour taste in their mouths after failed transformations, or ineffective implementations of agile frameworks that miss the mark. If I had a penny for every time I’ve interviewed an engineer whose understanding of agile was “I have stand ups, and use JIRA to manage tasks”, I might be able to afford one of these fancy scrum training programs. This ambivalence towards scrum is, of course, the best-case scenario.
Worse yet, are teams or engineers that are completely allergic to even the mention of scrum or agile because they’ve been stuck in hours and hours of planning meetings where no one understands why they are there, why they are playing poker games with funny numbers, and why the designer in the room is falling asleep in the back of the room.
The lack of deep, shared understanding of why the team is doing the things they are doing, inevitably leads to a lack of caring for any of the things they are doing. They’ll do them to get them done, not because they add any value.
This is the part where I pitch you on my podcast, newsletter, training program, book, or consulting company that will solve all of these problems. It’s the part where I say something like “I can help you avoid these pitfalls… for a handsome fee.” But the reality is that there are no shortcuts. Leaders in organizations that want to improve and grow must recognize that there is no substitute for the hard work. This is what separates successful teams from those that are destined to fail.
Becoming an Agile team that understands the fundamental purpose of the methodology requires deep understanding of what success looks like, a willingness to learn, the application of expertise and a desire to implement a culture of craftsmanship in your organization. Yes, there is a place for trainers, training programs, books, and all of it, but none of these can be a cure-all for your team. Be very skeptical of any individual trying to sell you on a magic remedy. Your engineering team will be.
Published by Ray Barrera on April 22, 2024
Hey, look at that! The new blog works :)