I’m not an outpsoken guy. I don’t have any social media, other than YouTube or the occasional visit to LinkedIn. I never comment or post on YouTube, I just watch videos, and on LinkedIn I rarely comment. I guess that is to say that this is my only real outlet when it comes to all the chatter around Agile being dead. Which fine, lets say it was… THEN WHY ARE YOU STILL DOING IT!?

Sorry, I didn’t mean to yell. But come on. I go onto LinkedIn and all I see are posts about it. On YouTube the ever present algorithm knows what I like to watch, so I’m lambasted by videos about it. And so I ask myself… if Agile were dead, then how’s everyone delivering software? Did they all just up and decide to go back to a waterfall approach? LMFAO. I highly doubt that. There’s a reason that waterfall is limited to certain and or specific projects. No… more likely I expect that in it’s place, Agile has taken over.

Yep, you read that right. I’m guessing that what’s happening now is an industry wide recognition that there’s just too much “Agile” overhead in the form of guides and manuals and what nots, and not enough principles based engineering. Some of my first posts on this blog are about using the agile manifesto and ignoring Scrum and or Safe, and or all the other “guides” out there. Just follow the principles. And I think that’s actually what’s happening.

I don’t claim to be some Agile history guru, but if I recollect, the reason the agile manifesto was created in the first place was because some expereinced software people were tired of all the software project management overhead of the 80’s and 90’s and said… “There’s a better way to do this”. They got together and devised a document that, like it or not, has driven software development to where it is today. Yep, you read that right too. Most of the way you work today in software is in some way shape or form linked to that document. DevOps, CI/CD, Pair Programming, Mob Programming, Swarming, these are all related to principles based engineering and those principles are in the manifesto.

I’m not gonna lie, when I first started to learn about Agile, I was into Scrum. I dabbled. But even then I knew it wasn’t going to work. So we didn’t do it fully, we did some combination of it and Kanban. This was in 2013 (ish). I recall an auditor for a potential equity investor telling me that what we were doing then was called “ScrumBan”. I was like, ok, whatever. I called it “Better than Scrum”. I wasn’t some genius, I didn’t know the principles then like I do now (by memory), I just knew that if something isn’t working, don’t keep doing it.

I guess my point to all this is that I don’t think Agile is dead. I think the community of software people are just tired of the overhead. I think we’re coming to an inflection point where all that weight is being shed and what we’ll end up with is a new agile manifesto, or some derivative of it at least. It’ll probably be something like:

• If it doesn’t work, change it. If people don’t like change, change the people. This is a deal breaker. Teams need to be able to change and do new things till you find a path. It’ll work well for a while and then things will change again. Life is change, software making is change. And yes, this does mean you should have retros with your team, and no that doesn’t mean they need to be therapy sessions, make them practical.
• Deliver fast and frequently, do what you can to make sure it’s safe and doesn’t break too much. Keep in mind where you’re company is at in it’s maturity. No one will care if you got to 100% test coverage but you never found product market fit. Remember, you’re not constructing a concrete facility of some kind, you’re working with SOFTware. Concrete is concrete, software is not concrete. You can change it fast and easy.
• People working on less things at the same time, helping each other and collaborating is better than more people working on a lot of different things and then tryign to tie it all together later. Stay focused and limit work in progress.
• Don’t burn people out, people are people, give them space and time to live, but it’s also important that people recognize urgency and put in the extra time when it counts. Build sustainably and you’ll reap the benefits of keeping people and all their domain knowledge, and they’ll produce better results.
• You don’t need only the smartest software people on the planet on your team unless you’re building rockets. There are plenty of smart and talented software people out there that can fit on any team. Do your dilligence but don’t be an ass.
• The best way to know if something works is to put it into the hands of the people using it. Deliver these changes in small increments. Don’t spend time on a vision and then try to deliver on that vision without feedback. Ask people what they like and don’t like, survey them, collect user data. Do anything you can to understand what users do and don’t like about the changes your making. And again… MAKE SMALL CHANGES and deliver them frequently. If you aren’t making changes that make it to production or a production like system every day, you could probably be doing better.
• Stop estimating as a regular practice, it doesn’t work and won’t ever really work well. Of course your team can give some “guesstimates”. Your team can tell you how complex they think something might be. But the moment you make a commitment to that, you’re doomed to failure (at least at some very high percentage of the time). Instead, if you follow the item above this one, you’ll be in a better position to validate changes as you make them. And as your team gets better at making smaller and smaller changes, the future changes will become more predictable (there’s lots of tools for forecasting, learn em, don’t stress your team out with unrealistic deadlines).
• Trust the team you have, even if you don’t think it’s the best there could be. The chances are better than not that they’re are most certainly good enough to build whatever you need them to. And if not, they are what you have for now and not trusting them isn’t helping. If you have to, go ahead and provide some guard rails, but not a prison cell. And if the team needs too much guidance… you’re the problem not them, or at least, that’s your fault not theirs.

Yes, this is basically a derivative of the original manifesto, and to some degree a derivative of the DevOps principles which themselves were deratives of the agile manifesto. I don’t expect my off the cuff list above will become the next manifesto. Actually I don’t even think we really need one. I’m a purist when it comes to agile.

On my teams, I try to instill the agile manifesto and its principles in our environment and in the team so that those principles are how we operate. Yes, we have Kanban boards and tickets and process. These are just necessary elements of delivering software for some teams. We have flow metrics, and ticket counts and we sometimes provide guesses as to how long something might take. But as a manager, I manage leadership’s expectations more than I “manage” the team in some cases. I work to free the team up, give them space and time. In return they work with me to learn the principles and implement them, and that looks like the team making smaller and smaller changes, building tests and delivery pipelines, not overengineering things when less work is better. It’s a collaboration between all the members of the team, of which I’m just one. I see it as my job on the team to instill the right principles and then guide the team to find the practices that work best for that team and that follow those principles; I try not to impose any practice, though sometimes I have been known to impose, it’s a balance 🙂

Let’s be real. There’s no such thing as having no process. If you had no process, your process is having no process. And if you had no process, you’re probably a lone developer building your own projects. And even then, I bet you still have a process. No, I think when people say they hate agile or its dead or its dying, or that they are tired of all the “agile” overhead, what they mean is they’re tired of having systems imposed on them, and then having to try and work in that system, instead of having principles, and letting the system and processes form around those principles. And for each team those systems and processes might be a little different, but what won’t be are the principles.

Oh, but Andre, you’re not thinking about teams that need to scale. Is what everyone always says. Scale is just more people, your processes will have to change, but the principles don’t. If you stick to the agile principles and just let the teams form a system and process that include them, you’re going to find that all the so called rules set out in any number of different methodologies are all stupid. 2 pizza teams, 2 week sprints, scrum of scrums… who cares. Do you have a large team, so what if your delivering. Can you delivery daily, good, so why wait two weeks. Let all that shit go, focus on the principles and then see what comes out of it.

Is Agile dead, no. Maybe Scrum and Safe and whatever else is out there is, or will be. But no one’s going back to waterfall. I’d wager that if anyone did, we wouldn’t even know because they’d be out of business. They’d lose out to any competitors who are still agile. No, I think our industry is coming full circle back to the original principles, little by little, whether they know it or not. So, go on, keep writing catchy click baity articles about the death of agile… I expect I’ll still see those same article titles in 10 years.

In a regular weekly poker game among familiar faces, there emerged an intriguing dynamic between two players, Al and Steve. Despite their long history and shared experiences, whenever they faced off in a hand, Al seemed to come out on top consistently. This pattern sparked a realization that transcends the poker table and offers a valuable life lesson.

Observing Al’s consistent victories over Steve led to a simple yet profound insight: there’s no magic or luck involved; Al’s success stems from understanding and adapting to how Steve plays. It’s a testament to the power of strategy, observation, and adaptation in achieving success.

This anecdote resonates far beyond the realm of poker. It underscores the importance of recognizing patterns, learning from experiences, and being open to change. Steve’s realization that to overcome Al’s advantage, he needed to alter his approach serves as a reminder of the necessity of adaptability and flexibility in facing challenges and pursuing goals.

In life, as in poker, we encounter situations where our usual strategies may not yield the desired outcomes. It’s during these moments that the ability to step back, reassess, and adjust becomes invaluable. Whether it’s in personal relationships, career endeavors, or everyday decisions, the willingness to learn, evolve, and try new approaches can make all the difference.

The poker parable teaches us that success is not merely about luck or innate talent; it’s about strategy, resilience, and the willingness to adapt. Just as Steve realized that to beat Al, he had to change his game, we too can navigate life’s challenges and opportunities by embracing a mindset of continuous learning, growth, and adaptation.

In essence, the poker table becomes a metaphor for life’s journey—a reminder that success often follows those who are not only skilled but also willing to evolve and adapt their strategies along the way.

So, this isn’t new, of course, we’ve all heard, that if life gives you lemons, you make lemonade. Which basically means, adapt. But, no one makes lemonade anymore, so I like mine better.

If you want to beat Al, you gotta change your game.

As a little league head coach, I recently encountered a situation that resonated deeply with my role as a manager of a software engineering team. One of the star players on my team of 7 and 8 year olds approached me after our championship victory, expressing disappointment about not receiving more recognition in the form of stars on his hat. This interactio led me to a realization about the dynamics of teamwork and individual contributions.

The young player, undoubtedly talented and a key asset to our team’s success, believed that he had carried a significant load throughout the season. In response, I gently reminded him of the essence of team sports. While his skills were commendable and his efforts invaluable, no player can single-handedly win games in a team sport like baseball. I pointed out that even the best player couldn’t field against an entire opposing team or hit, run the bases, and score alone. It takes a collective effort, with each player contributing their unique strengths, to achieve victory.

What’s more, I reminded him that he does have the most stars on his hat. He most certainly has gotten plenty of recognition for his contributions to the team, but that doesn’t mean we should only give him recogniton and not anyone else.

This scenario mirrors the challenges often faced in software engineering teams. Just as in sports, there are individuals with exceptional skills and capabilities—superheroes, if you will. These individuals may consistently deliver outstanding results and play a crucial role in the team’s success. However, it’s essential to recognize that no single person can carry the entire workload or solve all problems alone.

In the world of software development, projects are complex and multifaceted. They require collaboration, communication, and the combined expertise of a diverse team. Each team member, like a player on a sports team, brings their expertise, experience, and perspective to the table. Just as a baseball team needs pitchers, catchers, infielders, and outfielders working together, an engineering team thrives when everyone contributes their unique skills—whether it’s coding, testing, design, or product management.

The superhero analogy in engineering teams can be misleading if it leads to the misconception that one person can or should do it all. Instead, it’s about fostering a culture of collaboration, recognizing and appreciating each team member’s contributions, and leveraging collective strengths to tackle challenges and achieve success.

As a manager, I strive to cultivate an environment where every team member feels valued, supported, and empowered to excel in their roles. Just as in little league, where every player receives stars on their hat not just for individual achievements but for their contributions to the team’s victories, in software engineering, recognition and appreciation should be inclusive and reflective of collective efforts.

The journey from the baseball field to the software development arena unveils timeless lessons about teamwork, collaboration, and the power of collective contributions. Whether coaching young players or leading seasoned engineers, the essence remains the same: success is a team effort, and every player—every team member—plays a vital part in achieving it.

Quick Note

So, I’m not writing as often as I want to here. I guess it’s because I painted myself into a corner early on last year about wanting to give some specific advice that is practical and useful, but honestly, that’s just not as fun as some of the other stuff I want to write about. So, today I’m gonna write what will be my last blog in this series. I guess I’m saying that I’m not gonna finish the series I meant to finish in the way I imagined I’d finish it.

This article today will be a brief way of closing out what I started, in the best way I think I can.

Retro-duction

Let’s take a moment to recap the key themes from my previous posts on agile development. We’ve discussed:

• The beauty and simplicity of the Agile Manifesto
• How agility derives from values that emphasize individuals, collaboration, and adaptability
• And why we should focus on the manifesto rather than prescriptive methodologies like Scrum or SAFe.

Then, we categorized the principles into

• communication
• delivery speed and iteration
• people
• quality
• and workflow agility

We did that to provide a framework for analysis and action. We began outlining a practical guide, featuring the recognition of issues and matching them with agile practices, which led us to understand the critical building blocks for agile solutions.

Now, it’s time to briefly build on these insights and then to quickly conclude them. I’m going to be hoping that if you can’t put what I’m saying here into practice, because well, I didn’t do what I said I was going to do by being really practical about how to do that, that you’ll except what i’m saying at face value given my experience.

Lets Wrap This Up In A Tiny Little Bow

As we dig deeper into the world of agile software development, it’s essential to remember that the final destination is not to blindly follow a set of rules but to create a culture where continuous improvement is the norm, collaboration is key, and delivery of value is rapid and consistent.

Embrace the Manifesto as Your Compass: Whether you’re managing a team, coding, or strategizing as a product owner, the Agile Manifesto is more than a document it’s your North Star. Keep its values close to your heart, and its principles at the forefront of every decision.

Lean into Kanban: I’m not saying Kanban is the only thing you can use to be agile, but it’s by far the closest any documented or regimented process is to the principles in the manifesto. I’m gonna throw this out there; stop sprinting. If you remember what we’ve gone over in previous articles, see principle number 8 of the manifesto, and someone please tell me how you can be consistent and sustainable if you’re sprinting. You can’t sprint forever. Lean into Kanban for an easy interface towards true agility.

Visualize Your Work and Workflow: This one is actually much harder than it seems. Guess what, people are resistant to others knowing the state of their work. Also, I’ve found that most teams really hate the idea of having 15 columns in JIRA or whatever tool you use. But I can’t stress this enough. Until you consistently know the state of of your teams work items, you won’t get your stuff together as a team. You need to visualize the entire workflow from when a change request comes from a customer request, all the way to when that change is put into production. Same with bugs. You can make distinct worktypes if you have the team and manpower for it, but just know that you need to visualize the work. The good news is that I promise after you’ve broken down the work into steps represented by dozens of columns if needed, over time it will change and you will eliminate many if not all the extra ones.

Champion DevOps Culture: The DevOps “movement” or whatever you want to call it is a direct result of following the agile principles. Continuous Integration and Delivery are not mere buzzwords for trendy engineers, they’re actually incredible tools for delivering software fast, getting feedback and iterating. I can’t spend too much time on this one, but read Continuous Delivery by Dave Farley or Continuous Delivery Pipelines also by Dave Farley, or watch his YouTube channel (Continuous Delivery), to get a real sense for what Continuous Delivery and Continuous Integration really are. I find that most teams think they’re doing CI or CD because they have a CI/CD tool like Jenkins or Github actions in place helping them deploy. That doesn’t make a CI / CD process. Find out if you really are or are not, because true CI will change your team’s ability to deliver fast with quality.

Quality Comes With Quantity: Writing software is a scientific pursuit that thrives on experimentation. Invest in tools that allow your team to quickly analyze the changes being made and determining if they work. I know I’ve moved on from talking about CI / CD since I mentioned it already but I can’t stress enough how important a pipeline that has tests is to the quality of your application. And, the more your team delivers, the faster the tests will get, and the better the quality of results will be. There’s a lot as to why this is the case, but suffice it to say, that the old addage of quality or speed, isn’t true anymore, or at least it doesn’t have to be.

Communication Reigns Supreme: In Agile, clear communication is key. Shatter the silos, dispense with needless documentation, and channel the power of face-to-face meetings and calls. I’ve seen tickets written by some of the best ticket writers I’ve ever met, and man how I’ve wished they would have spent even just 90% of the time they wasted writing their super amazing gherkin for the acceptance criteria on just pairing with the developer doing the code. There has never been a ticket with enough acceptance criteria to ever save more time than had the product owner, business analyst, or whoever, just prioritized the work being coded, at that time, and sat with the dev to answer all their questions in the moment. This applies for developers on a team as well. Stop commenting on tickets or pull requests just to wait 2 or more hours for another developer to respond. You have a problem with a PR? Call your teammate and tell them, and fix it with them IN THE MOMENT.

Metrics That Matter: Stop using velocity and story points, start using DevOps Research and Assessment (DORA) metrics to tell the tale of true progress. Measure deployment frequency, lead time for changes, change failure rate, and time to restore; let data that data tell you what you need to work on as a team. Use additional metrics such as cycle time or PR wait times, etc. only if and when the DORA metrics are telling you there’s something wrong.

Trust Your Team: If you have the great fortune of working with a team that isn’t contracted or outsourced, take full advantage of this. Now I’m not saying that you can’t be agile in the way I’m describing it with a contracted team, but I will say there is a different dynamic there. In so far as you can, you should try and include a contract team in the same way you would a team of non contractors. With that out of the way, trust your team. By and large, if you have a team of smart people on a team, they’ll get the job done if you give them the tools and support they need. And, by team, I mean you too. Managers, or coaches, or leads, or whatever you want to call youself, you’re a part of the team, just the same. That means that stuff that they might thing isn’t important, like building a workflow, understanding cycle times, etc. all that is actually pretty important to making a team efficient and effective. I’ll add one thing here as well; don’t worry about the size of your team, it’s only too small or too big if you see that there are problems. Don’t get hung up on cool catch phrases like “two pizza teams” or whatever the “Scrum Guide” says. If you’re team is able to deliver, who cares.

Retrospectives: Conduct these often but keep them light, make them a conversation, not a soul-crushing reiteration of a performance appraisal. And yes, these can be hard to do, as different team members engage in different ways. But it’s important that you hear everyone’s perspective. Don’t let retro’s become fluff fests where no one actually says what’s bothering them, what’s hurting the team’s performance, and then discussing how they can try fixing it. Do be careful however, as you don’t want retro’s to become open areas for picking on or attacking individuals, you’re facilitation of these in a fair and just way is important. You should know before going into a retro, what’s likely to come up in it. If anything gets too intense, just pull it out of the meeting when it’s happening. By and large though, most engineers are pretty down to earth and can manage their emotions and social interactions well. But make sure you are doing these frequently. Every other week, or maybe even at the end of any big feature completion.

Conclusion

And there it is, I’m done. While it didn’t turn out exactly how I’d imagined it at the beginning of last year, and it’s taken way longer than I had as well, I’m happy about how I’m concluding it.

In the future, I’m going to be posting agile related blog posts, about my experiences as a software engineering leader. I hope you enjoy these. See you soon!