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!