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!