Introduction

In our first installment, we acknowledged the elephant in the room: recognizing that your team’s current processes might be hindering rather than helping. We opened up lines of communication and began a journey towards true agility by facing these issues head-on. Now, it’s time to start laying down the practical steps towards improvement, setting the stage for specific strategies in later discussions.

I won’t lie, there’s gonna be a lot in this one. I want to cover for you in one article as best I can, a myriad of problems I expect your team communicated to you or you identified, and then I want to give you some practical advice / tools on how to resolve them.

Agile in Action: Applying Theory to Practice

Step 1: Prioritizing the Problem List

Before diving into solutions, let’s categorize the concerns your team voiced. This will help us tackle the most impactful issues first.

Categories of Concerns:

• Process Bottlenecks
• Team Dynamics
• Quality Assurance
• Delivery Pace

Process Bottlenecks:

Lengthy PR reviews, unclear workflow visibility, too many sign offs. How does this probably look, or how can you identify these from the myriad of complaints you’ve received or the problems you yourself have noticed and documented.

Let’s start with lengthy PR reviews… if you have a PR that’s been in review for more than a day, that’s too long, period. So, start there, now, if you’re team is complaining that people on the team aren’t reviewing PR’s regularly enough, that’s a sign.

Unclear workflow visibility is pretty common. So how do you know if it’s an issue people are complaing about? Let’s start with this first, your team won’t tell you this. There’s something important to know about engineering teams and people in general (in my experience), the less clear a workflow is, the more work or moreover no work can be hidden. So what do complaints here look like? Usually it’s management or product team people complaining about not knowing when something was completed, or how much longer something might take. It’s an even worse problem when the engineers (devops, developers, testers) are complaining of not knowing when to start their work or their piece of a work item.

If you have more than 1 sign off, in the form of a PR you have too many. So that’s an easy one to identify. Sure, there may be some super high security reason in some places to have more than one, but there are some great techniques even in those cases to mitigate slow downs based on those sign offs.

Team Dynamics:

Interpersonal issues, trust deficits, lack of collaboration, overly nitpicky comments on Pull Requests. These are the worst kinds of problems, and they manifest in so many different ways.

Trust deficits are team killers and truthfully can manifest in ways that look like complaints in other areas. For example, lengthy PR reviews are usually caused by trust deficits amongst the team. So, if you’re having PR reviews that are too lengthy, like mentioned above, it’s also probably a team dynamics issue. Another trust issue is when you have one or two engineers on a team always looking at other peoples code, before, during or after they’re pushing up their changes. Cross specialization trust issues are pretty easy to identify, for example the engineering team complaining that product isn’t writing enough details into the tickets, or the product team complaining that the engineering team isn’t doing what they’re asking.

Lack of collaboration is really hard to determine, but know this. If your team isn’t regularly meeting to discuss their work, they’re lacking collaboration. A good sign is that team members spend a lot of time breaking work items down into very specific and tiny tasks up front. Yeah that’s right, this is not a good sign. Sure it might make estimating seem like it’s easier or more effective, but really what’s happening is your team wants to just have their tasks and not be bothered till their done with it. Moreoever, down below, I’m gonna tell you something about estimating and how to do it better (hint: don’t do it).

Quality Assurance:

Flaws in the product, unsatisfied users, lengthy test cycles, finding unimportant bugs and holding up releases. All these are problems in quality that are pretty easy to identify. But what’s more likley the case, especially early on in your agile team building process is that these are side effects of poor collaboration and poor trust. After you’ve got a team that is doing those things better, you’ll have less quality issues and then the ones you do have will be about something in your workflow or possibly some legitimate non team specific thing related to your code or infrastructure.

Delivery Pace:

Inconsistent speed, missed deadlines, overcommitment, missing sprint goals. As a category of problems this one is easy to identify, or at least it’ll seem easy. Why do I say that, well because let’s get real, who’s to say what’s slow or fast. There’s a good chance that your team is building something that either hasn’t been built before, or if it has, only a few people on the team have built it before or something like it, and then what bar do you have to measure speed against.

But that aside, as a team, if you’re missing deadlines or the team is overcommitting it’s easy to see this becasue well you missed deadlines or probably didn’t deliver all the tickets within a sprint.

Step 2: The Agile Toolbox

Agile isn’t about blindly applying practices; it’s about understanding the why behind each action. We’ll introduce some universal agile tools that can address a wide array of problems.

Before hopping in, I’m gonna tell you something and you may not want to hear it. More over it’s gonna freak you out some too. The tools and techniques I’m going to suggest below are likely going to be wholesale changes in the way you work. The reason is simple, it’s what I know, first, and second, it’s not a boxed off the shelf solution like SCRUM or SAFE, or anything. Lastly, as a so called Certified Scrum Master I’ve seen Scrum fail miserably to meet the needs of a great development team and workflow. My approaches, techniques and tools are much more agile manifesto principles based now and they’ve worked wonders.

Let me give you some info to help you understand where I’m coming from. I’m an evangelist for the manifesto because I’ve seen it in it’s purest form work. What’s more is that I’ve seen the offshoots of the manifesto really work well. For example, DevOps, Continuous Delivery, Value Stream Management, etc. these are all methodologies, concepts, practices that have their foundations in the agile manifesto.

If you want to understand these concepts better check out my Resources page on the best books, podcasts, videos and creators to follow on these topics. With that information, here goes nothing:

• Stop sprinting, it’s not sustainable
• Stop giving work to frontend people and backend people and devops people and QA people separately, instead work as a team on one or two items
• Start a continuous delivery workflow immediately
• Stop measuring velocity and more importantly
• Stop estimating
• Delivery smaller chunks of work that have value
• Lastly, break up your workflows visibly so that you and the entire team can see all the true steps and details that are happening.

Now that you have a base, let’s get into the tools and techniques a bit more that can help you do what I just described.

Agile Tools and Techniques:

Here’s the tools we’ll be discussing

• Make Work Visible: Understanding and laying out the real state of a change and it’s flow through your team on its way to production is important.
• Kanban Boards: Visualizing work in progress to increase transparency and identify process inefficiencies.
• WIP Limits: Limits on the amount of work in progress help teams stay focused.
• Metrics are important but some are proven to be much more effective and useful than others. DORA metrics are way you should start.
• Stand-ups: Daily check-ins to synchronize team efforts and identify roadblocks early.
• Pair Programming and Team swarming: Enhancing collaboration and code quality while reducing knowledge silos.
• Less Documentation More Communication: Documentation is great for a lot of things, but not communication of needs and details.
• Continuous Integration/Continuous Deployment (CI/CD): This buzzword isn’t just that, it’s actually an integral part of delivering high quality software.
• Retrospectives: Regular reflection and adaptation sessions to incrementally improve team practices.
• Iterative Development: Don’t eat the pig, eat the frog. Disgusting I know, but understand that delivering small valuable chunks is way more effective.
• Teams Solve Probelms They Don’t Implement Features: Don’t build features, solve problems that features fix, and do it AS A TEAM.

Step 3: Implementing Agile Tools

Now, let’s explore how these tools can specifically address the concerns you’ve identified.

For Process Bottlenecks:

• Make Work Visible: That’s right, taking your boards from “To Do”, “Doing”, and “Done” to “To Do”, “Doing”, “PR Rejected”, “Pending QA”, “In QA”, “In PR”, “Release Ready” and “Done” will change your life and understanding of your workflow (btw these were some generic states of code I put together, you’ll need to determine what states matter to you and your team). What’s important is that you and the entire team has a clear understanding of the state of a requested change, from when it’s requested to when it’s in production.
• Kanban Boards: Adopting a Kanban approach could illuminate the current state of work, showing where tasks get stuck and why Susan’s tickets take so long. So if you add states to your workflow, the Kanban Board is the best method to see them. This is much bigger a thing than I’m doing it justice in this section. Kanban is fantastic because it seems to me the most natural exentions of the agile manifesto, in terms of a methodology. This one’s gonna take a bit of research to understand more about pulling not pushing work, and how that works and why. Do the research… this will pay itself off in spades.
• WIP Limits: Implementing work-in-progress limits can prevent overcommitment and ensure focus on task completion. Also, WIP limits help with understanding how a Kanban workflow operates. So, what does this look like in practice? It’s simple, decide as a team on the number of items the whole team can have in the in progress states of a feature (so that might be a group of states such as in progress, QA, release ready), and then say when that number is met, no new work can be started. Ok, but Andre, then what does frontend do when there are no in progress tickets for the front end. Well, front end in that case, does everything in their power to help out whatever is in progress, maybe it’s reviewing tickets in PR, or doing some QA work, or maybe it’s simply sitting in and learning and getting more application domain knowledge from the backend folks until there’s space for more work. And this applies to everyone on the team. I told you, this is a big topic, maybe I’ll cover it in more detail at some point down the line.

For Team Dynamics:

• Stand-ups: These can foster better understanding and collaboration within the team, as well as early detection of interpersonal issues, but drop the… “what did you do yesterday, what are you gonna do today part”, who cares. Just ask and determine what’s blocking them from moving their work, today. If you’re implementing Kanban, you’ll learn that the most important thing isn’t what’s been done, it’s how to get a work item from where it is now to where it should be as fast and effectively as possible. One more quick thing, because we’ll touch on it a little more down below, but stand-ups are not a replacement for team meetings and collaboration.
• Retrospectives: Offer a safe space for discussing non-technical issues that affect team morale and collaboration. My favorte approach to a retro is to use the lean coffee style. Look it up, it works a treat. Something to note is that you should do these every other week or so, and probably once after every major feature / function / project release.

For Quality Assurance:

• Pair Programming and Swarming: This practice can help improve the quality of the codebase and share ownership of the product’s quality. You don’t have to do this in that very specific pair programming way. A great technique I’ve found here is to have a few hours or sessions a day where the team just works together on their own thing. So, maybe pop open a zoom or huddle or whatever and everyone does their own thing. After some time, this magical shift in how they work and what they’re working on happens. Soon you’ll see they are all working on the same item and completing it faster and with more quality.
• Less Documentation More Communication: If youre product and development team members are at odds over the details of a ticket, then stop making detailed tickets, and instead communicate more about a ticket while a developer is actually working on it. Let’s get this out of the way right now… there is NO AMOUNT of documentation that can ever convery what you need something to do, in enough detail that there won’t be misunderstandings, period. So why do we pretend that there is. Why do we constantly go back and forth on the details of a ticket and fight over whether or not the intent of a delivered feature was met or not. Instead of writing down every last detail, make the product team work on the same tickets that the engineers are on. They should be in those team discussions while engineers are working on a ticket so they can answer any of the hundreds of questions that arise during the development of a functionality.
• Continuous Integration/Continuous Deployment (CI/CD): Introduce automated testing and deployment to receive faster feedback and ensure a quality product. If you did nothing else, you had better get on this train and fast. The entire industry is moving or has moved to this and if you don’t your company will be left behind. And let me state that I don’t make fake CI / CD. I mean real CI / CD. See my blog on books and videos for some more insight on this, it’s big topic. But suffice it to say, you need more tests than you think you do, and you need less sign offs.

For Delivery Pace:

• Iterative Development: By working in smaller increments, the team can adjust more quickly to changes and deliver value more consistently. This one is a hard practice to really solve. The practice of doing smaller increments requires your WHOLE TEAM, including product people and even mangement / leadershipt to think differently. You should be in the habit of making small valuable improvements and collecting feedback from your users, regularly, and quickly with every, very reqular, release you do. Feedback can be in the form of pure data, and in other instances it can be in the form of just asking them. So, if you are looking down the barrel of a huge problem, work as a team to break it up into smaller deliverable chunks of value that your team can deliver. There’s techniques to help with this as well, such as feature flagging or canary releases, etc. Just strive as a team deliver less more often and this will come together.
• Teams Solve Probelms They Don’t Implement Features: Yup, you heard that right. If you want faster delivery of quality software, then don’t think about your team as contractors, your team is there to solve engineering problems. Your team is probably made up of a product person or two, a designer, a frontend person or more, some backend folks a devops skilled person and maybe some QA and a manager of some kind. Everyone I just mentioned is a part of the team. They all have different specializations but they should all be involved in understanding the problem and helping solve it. Product collects feedback from user and outlines the problem, they involve the team to find a solution, together that meets the business and user needs, designers create some nice visuals that meet the needs of the solution, QA helps devise early tests to implement throughout the dev cycle, the engineers do the implementation a manager helps ensure a collaborative and functioning workflow, and devops creates or adapts infrastructure to deploy the changes into. Then the cycle starts again with product understanding how the change impacted users, and then identifying new problems to solve.

Step 4: Measuring Success

As you start implementing these practices, establish clear metrics to measure their impact.

Potential Metrics:

• DORA Metrics: If you do nothing else, implement these. Again see my post on the different books, videos, etc that I love, in order for you to understand more aout the why. But suffice it to say, that these metrics are proven to be the most important ones in the industry, and here they are:
  • Lead Time for Change
    • Depending on the maturity of your continuous delivery workflow this can be a measure of how long it takes from when a PR us approved to when it’s in production OR if you have a really mature CI workflow, I’ve found it helpfule to expand the scope of this metric to include the entire process from feature or change inception to productition deployemtn.
  • Mean Time to Restore
    • How long does it take from when you identify a production bug or issue to when you’ve deployed that fix into production.
  • Change Failure Rate
    • How many changes result in a failure over the number of deployments your team has delivered in a given time span. Some might use generally any bug that is in production, but this will depend on your team’s maturity and your app’s maturity level.
  • Deployments / Releases
    • This is an important one. Keep a count of the number releases / deployments your team is making in a time period. The more you make, the better your team will be and the more quality your app will have. Now, I know you’re like, WHAT? But yes, the data is clear on this, if you make this metric important within your team, the team and more likely the organization will reorient itself around it, and the results of that lead to more quality (because you aren’t releasing changes without issues if they have bugs), faster feedback loops (because your team is gathering information after every change), and doing less useless work (because your focused on just those important piece of feedback and making small changes rather than frivolous changes).
• Cycle Time: This is an important metric but you have to determine what cycle to measure. Focus on lowring the cycle time between steps in the workflow that smell like they are taking long. And since you’ve implemented a very visible workflow this shouldn’t be too hard.
• Work Items Completed: So, if you followed my advice above, you aren’t sprinting and you don’t have any velocity. There’s a great way to still have a good sense for how the teams doing and that’s just simply counting the number of work items completed in a given time period and then tracking that. This number will fluctuate and change overtime, but it should remain within some standard deviation. Why? Well becasue the more a team works together, the more it sizes solutions similarly to other items, and the more they solve them in similar ways. Teams will find a natural equilibrium. But what is still true is that different problems will always have different solutions so don’t use this as a bar, just follow the trend and if it is trending downward, use it as a red flag to determine what could be, if any, the issue.

Conclusion

In this chapter, we’ve set the foundation for applying agile principles to our recognized problems. These building blocks are designed to be versatile, forming the basis for the customized solutions we’ll develop in subsequent parts of this guide.

As we look forward to the next installment, remember that agility is as much about mindset as it is about methodology. Embracing change, seeking continuous improvement, and fostering a collaborative environment are the true markers of an Agile team.

Stay tuned for part three, where we’ll take a deeper dive into tailoring these agile practices to our unique challenges, ensuring each solution is not just a band-aid, but a step towards sustainable agility.

Thank you for following along, and remember, the journey to agility is ongoing, but every step counts.