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.

Introduction

If you’ve bothered to read my other articles, you must be thinking what I always think when I read stuff about Agile on the internet, and that is… “so how do I do it?” No one ever gives a real practical agile guide. And it’s true that reading about Agile doesn’t normally help you understand how to practically implement Agile. And while I don’t think there is any such thing as “implementing agile”, there are certainly practices and patterns of working that are more agile than others. And, in my view at least, if you’re practicing those principles and following those patterns, and most importantly having success in your projects, then well… you’re Agile.

What I intend to do now that the high level stuff is out of the way, in previous posts, is to create a practical guide over the next 5 to 10 blog posts on some common practices and patterns that can help you and your team find success through adherence to the agile manifesto. I don’t plan on beating you down with principles one by one, instead I’m going to piggy back off the earlier posts I made about the categories I’ve personally broken the manifesto down into:

• Communication
• Delivery Speed and Iteration
• People
• Quality
• Workflow Agility

Before jumping in, I want to say the following; the practical examples I’ll be using are examples of work I’ve done myself. They’ll be examples of interactions, or situations I’ve been in. In almost all these circumstances they’ve been with between one to 5 agile teams. That is, I’ve almost exclusively done my work in the startup world. While I am fairly confident that these practical implementation examples and advice would apply in larger team settings, I can’t guarantee anything. In fact, I can’t and don’t guarantee anything no matter your team size, these are my experiences and I’m sharing them to help you understand how being agile helped me and my teams.

Also, it’s important for me to say that this “Guide”, while it has an order, it isn’t something that you should expect to follow and be done with. As you look at the categories above, they are descriptions or parts of everyday work. That is, you can’t just jump in and start working strictly on the “Communication” problems the team is or isn’t having and then when you’ve got that all figured out and working you then move on to the “People” category and then figure that all out. I mean, maybe you could do that, but for me each of these categories is part of a delicate balance. One day you realize that communication isn’t effective, but it had been more effective a few weeks ago, so you need to work on it again, but what changed? Maybe people were added to the team, maybe a change in the workflow had an effect, maybe the quality of the product is making people upset or lazy. Any number of factors can be at play, and so, each of these categories are part of an ongoing process of improvement. You’ll never have them all perfect, and you’ll never be done trying to make them perfect.

This guide will use some or all of the categories above in each part. I’ll be sure to call out what is what and when, as well as maybe what principles we’re looking to for guidance. And without further ado…

Day One – Something Smells Wrong Here

Let’s set the premise for our upcoming adventure. You’re a:

• engineering manager
• agile coach
• team lead
• developer / engineer / programmer
• product owner / manager

The list can go on and on, but the point is you’re on a team and things aren’t going so well. Your team is delivering software but any number of things don’t feel right. Maybe it’s taking much longer to get changes into the hands of your users than you think it should be taking. Or, maybe your moving fast, but the users are really not liking anything that your team is giving them. Maybe there’s a lot of turmoil on the team and every team meeting is full of stress, resentment, and palpable dislike or distrust between the team’s members. Maybe the team is burnt out, unhappy, and you know that certain members are looking elsewhere for a new job.

I want to point out that anyone on a team can recognize a problem, and anyone on a team can start the process of becoming purely agile. It just takes one person on the team to understand that there’s a serious problem and it’s affecting the output of the team negatively.

Another very important thing to point out is that there’s no reason to become agile if you aren’t having any problems. I mean that. If you’re on a team that practices old school waterfall, or even scrum and your users are happy, the team is happy, and the company is making money… then don’t change anything. I mean, you should always be looking to learn and improve, but there’s no reason to undergo a long process of becoming purely agile if some process is already working.

Does Anyone Else Smell that

You’ve identified a problem, but are you the only one whose noticed? Step one is going to be for you to validate your concern with the rest of the team. And, in truth, this first step is actually a part of the process. Being open and honest with your team, and having them be open and honest back is an important part of, you guessed it… Communication.

In your next team meeting, take a risk and present your concerns to your team. See what they have to say. Maybe your thoughts aren’t heard because there’s antagonism on the team from other members. In that case, ask your team lead, or manager, or agile coach or a product manager or anyone that isn’t antagonistic, if they smell the same thing you do. But it’s going to be important to have some level of recognition from the team that there is an issue and you think the team could be doing better. Again, maybe better means, happier work life balance, or happier users, better quality delivery, faster deliveries, less stress in meetings, less fighting, etc.

Let’s move forward under the assumption that you’ve taken the risk, and the team has validated your concerns. What’s more, each of them also has concerns, or more likely, specific complaints. The process is to strict, or Jack doesn’t review any PR’s ever, he leaves them to everyone else, or Susan always picks up the bulky tickets and then takes weeks to deliver them, or we never deliver all the tickets we committed to in the sprint, and then we always have more in the next one… the list of complaints or concerns can go on and on.

CONGRATULATIONS! You’re agile… OK, not really yet, but damned if I’m not proud of you. You’ve just done something very hard. You’ve communicated in a way that not a lot of teams do. Very few teams are actually open and honest, and you’ve managed to make that happen. Heck, we could even say you’ve had your first real retrospective.

Whoever Smelt It… Now Has to Check Everyone’s Pants

What a great heading, am I right? But seriously, it’s not enough to just smell a problem and then think you can fix it. Nope, you have to identify the problem as best you can and even write it down so that you can look back and gauge the change over time. So, listening to your team, write down all their concerns, and be sure of course to document yours. You can’t say you’ve done good change without knowing what you’ve fixed.

These can be abstract ideas, that is, sometimes it’s hard to pinpoint a problem and be specific about it, in that case just write down what it feels like as best you can. For example, an easy problem to write down is that Jack thinks that Susan’s tickets are taking too long to deliver. It’s a harder to be specific about people issues like the feelign that ego amongst team members is getting in the way of progress. Sure you may have examples of when it has done so, but its not likely everyone on the team will agree, so it’s a subjective issue. But write it down anyways. Or, how about the idea that you think the work is taking so long because there isn’t any clear visibility into work in process. I mean you agree with Jack about Susan but have no way of proving it because there’s only a To Do, Doing and Done state for the work. Just write it all down.

Anyway, You’ve talked to your team and they agree there are problems and that things could be better. You’ve now documented all the things you think are the problem, and you’ve asked your team to do the same. It’s time to get together with the team again. It might be a week later, or two weeks later, but don’t let too much time pass since you had that first meeting confirming there were certainly problems. This time, have your list of concerns and issues that you and the team communicated, and then one by one in a meeting share them, and ask the team for ways they think can fix the different issues.

This is going to be chaotic. Depending on the level of trust that exists on the team this could feel very useless or it could be very scary. What will be important as a facilitator is to share with the team the following. Your going to time box discussions on each concern, and if you don’t have a documented next step on it, that’s OK you’ll move on, and discuss it again in a future “retrospective”.

That’s right, you’re having a retrospective. In more agile manifesto terms, you’re team is “reflecting on how to become more effective, then tuning and adjusting it’s behavior accordingly”. This action encompasses Communication and People from my big five categories. There are a lot of guides on how to conduct a good retrospective, I may write my own someday, but for now, it really is OK to just use a spreadsheet, and a timer to accomplish the goal of trying to get ideas for how to solve each of the concerns / complaints of the team from the team.

I realize I’m not being very specific or practical here, so let’s get simple here. You talked with your team at some point and realized that you weren’t the only one that felt there were problems. So, schedule a meeting. In this first meeting write down your concerns, and any that your team has as well. Don’t worry about trying to solve them yet, given this is maybe your first time talking about these problems with the team, it can take a while. So let them know there will be a second meeting in a week or two. Schedule the second meeting. When the day comes, in the meeting tell the team that you’re going to time discussion about solutions for each problem. If at the end of the timer no solution has been given, move on to the next problem. Let them know you’ll come back to those other ones another day, say in two weeks (same day / time). The point is to make progress where you can, and if discussion on one problem is too long, it likely needs a lot more attention, and it will keep coming up anyway.

The first thing you should do after the meeting is share the notes you have so far with the team. Then, make tasks to implement any of the easy solutions the team was able to agree on. Then, schedule the next meeting (retrospective), to continue discussion on the other points. Lastly, ask them to share anything else between now and the next meeting that they may have thought of.

So, there… put that into practice.

Conclusion

You’ve done a lot so far, and I’ve written more than I planned to for part one. Let’s agree to stop here(ish). You’ve recognized a problem. You’ve shared it with your team and they’ve shared their issues back. Again, big accomplishment. Then you held a retrospective to start getting feedback from the team and understand ways you and they think can solve the problems.

You and the team are being agile in that respect. It’s not however easy to say that just because you used agility to understand, document and propose solutions to several problems that those solutions are agile. In fact, it’s quite likely that many of the solutions proposed by your team are not at all agile. So, that’s what we’ll start exploring in coming additions to this series.

In part two, we’ll discuss what that list of problems your team made likely includes. But we won’t go into specifics on any one of them, for now, because in even more future articles we’re going to dive into each of the issues (at a categorical level) and solutions or practices to help mitigate / rectify them.

What we will however do in the next article is discuss some generic agile practices that can help with many of the issues you and your team probably wrote down. These will be practices that you can start right away, and you can easily gauge their success or failure. It’s likely that many of these practices will be reused / discussed when we dive into specific issues in future articles, so this will help setup a good premise for you to understand how they can help now and with specific issues.

Thanks for sticking around, see you soon.

Introduction

In this blog post, we’ll explore Simplifying the Agile Manifesto by breaking it down into high-level categories. These categories will help us better understand the key concepts and principles of agile methodologies, enabling us to apply them more effectively in our daily work. I’ll say the following more then once in this post; these are my categories, I made them to help me. I caution you that you may feel differently, and I don’t want you to get the idea that the Manifesto itself is represented or supposed to be breakdown by categories, it isn’t. I just did this for me, and I’m going to share this with you.

The Agile Manifesto is great. Ok, obviously that’s something I’d say considering I’m writing about it. But, I can also say that it can be a bit long. Or at least, if you wanted to start practicing and adopting it’s ideas practically the fact that there are 16 lines of individual thoughts or concepts makes it a bit daunting. It’s certainly not as daunting as having to memorize how to run a scrum team, or knowing how to implement the SAFE methodology, but even I won’t pretend that by just reading it you’ll know what to do next on your team.

What is true though is that you should do your best to memorize the manifesto. And I’ve always found things easier to remember if I can break them down into categories. So when I started my agile journey, that’s what I did. I broke the manifesto down into 5 high level categories, and placed the principles into them based on the content of the principle. This post will be about those categories, and it’ll help serve as a way for future blogs to cover the specific categories in more detail.

Manifesto Categories

If you take each of the principles on their own, each has a lot to say. In future blog posts I intend on diving deep into each principle, but for now, I have 5 categories that I believe we can divide the principles in to. And that each category on it’s own has a lot to say without having to know or remember anything about the manifesto’s individual principles themselves. That is, the categories themselves can enable us to apply the principles more effectively, even if we don’t know or remember the principles. They like the principles, principles.

Communication

The Agile Manifesto places a strong emphasis on communication, recognizing the importance of individuals and interactions over processes and tools (which itself is one of the principles). This category encompasses principles such as:

• Customer collaboration over contract negotiation
• Business people and developers working together daily throughout the project
• Face-to-face conversation as the most efficient and effective method of conveying information within a development team

While other principles could also fit in here, they fit better in other categories, but what is important to take away from this category is that talking to someone, being available to communicate your team, and not expecting that some document or ticket is ever going to be enough. That is, don’t think that just because you wrote something down, that that will be as effective a communication tool as actually telling someone something.

Delivery Speed and Iteration

Agile methodologies prioritize delivering working software quickly to satisfy customers and provide value. The principles in this category include:

• Working software over comprehensive documentation
• Satisfying customers through early and continuous delivery of valuable software
• Delivering working software frequently, with a preference for shorter timescales

By focusing on rapid delivery, agile teams can better respond to changing customer needs and market conditions, ensuring their products remain relevant and competitive. To achieve this, you need category number one, communication. If you don’t communicate you end up having to document, and documentation is slow. You want to be able to make small changes that you can put in front of someone so they can tell you if it works or not.

People

The Agile Manifesto acknowledges the importance of people in software development, emphasizing the need to create an environment where motivated individuals can thrive. The principles in this category are:

• Building projects around motivated individuals and providing the necessary support and trust
• Promoting sustainable development for sponsors, developers, and users
• Encouraging self-organizing teams to produce the best architectures, requirements, and designs
• Regularly reflecting on team effectiveness and adjusting behaviors accordingly

By empowering people and fostering a culture of trust, agile teams can improve productivity, job satisfaction, and overall project success. This category to me is one of the ones I think isn’t considered as a category in and of itself by most other breakdowns of the manifesto. But to me its very important. People make software, and people are important. As a specialist in startups where it’s considered normal to sprint and burn out team members, I can tell you that losing team members to burn out is the worst loss in productivity possible. People matter.

Quality

Quality is an essential component of the Agile Manifesto, with principles that emphasize the importance of working software as the primary measure of progress and the need for continuous attention to technical excellence and good design. By focusing on quality, agile teams can ensure their products are reliable, efficient, and maintainable, ultimately delivering more value to their customers.

BUT… there’s a catch. Quality is very important, however, in my view, it’s less important if you’re a startup than it is if you’re a company or product that has found the elusive Product Market Fit. Now, that’s not to say that these principles aren’t as important if you’re in a startup, because they are. But I think their interpretation can be different for different products or stages of a product.

It’s sort of weird because quality is important for increasing the speed of delivery. Yes, that’s right, you can have fast and good, and in fact, for it to be good, it has to be fast… you’re gonna have to stay tuned to read me explain that. But suffice it to say, that quality is very important, but what kind of quality, that’s the question. Some teams think quality is a reference to how good their code is, or how well built the architecture is or how future proof and scalable it is. But that’s not what quality here means.

You want software that doesn’t break for the customer, and there are dozens of ways of making sure that your customer doesn’t get broken software, that don’t include creating 100% test coverage or making sure your architecture can scale for a future number of users you don’t have now. So, with all that said, remember that Quality is important, but what matters most is your customers experience… and they don’t experience the code.

Workflow Agility

The Agile Manifesto encourages teams to embrace change and adapt their workflows to accommodate new requirements, even late in development. The principles in this category include:

• Responding to change over following a plan
• Welcoming changing requirements for the customer’s competitive advantage
• Pursuing simplicity by maximizing the amount of work not done

By fostering workflow agility, agile teams can quickly adapt to changing circumstances, reducing the risk of wasted effort and ensuring their products remain aligned with customer needs. And I know this is more easily said than done. People don’t like change, and managing change is hard. To put this into practice, you have to be able to create fast feedback loops so that you are prepared to show the team how changes are affecting your product.

Conclusion

• Communication
• Delivery Speed and Iteration
• People
• Quality
• Workflow Agility

These are my categories, I’ve seen others and they may work just as well. I encourage you to create your own as well after you have a good understanding of the manifesto. Ultimately you’re the one who has to adopt, implement, and then adapt them to help your teams work better, so if you can break them down into meaningful categories that are like your own, principles principles, you’ll have an easier time of making them a part of your normal decision making process.

By examining the Agile Manifesto through the lens of these high-level categories, we gain a deeper understanding of the core principles that guide agile methodologies. By focusing on communication, delivery speed, people, quality, and workflow agility, we can better apply these principles in our own teams and projects, ultimately improving our ability to deliver value to our customers.

Introduction

The idea of changing from your current “agile” process might seem daunting at first, but adopting a pure, or what I call, true agile mindset doesn’t have to be complicated. Now, if what you’re currently doing is working fine for your and your team, DON’T CHANGE. I mean, you should reflect and update, but there’s no reason to change whole hog. However, I expect that if you’re here reading this right now, things probably aren’t going as well as you’d like. Don’t worry, being agile is easy.

You don’t need an advanced degree or years of experience to understand and practice the Agile Manifesto and its principles. In fact, the whole team, including software engineers, product owners, designers, QA members, DevOps professionals, and business stakeholders, can easily embrace these principles and enjoy the benefits of agile development. And yes, all those roles, are part of your team. An agile team isn’t just developers and a manager, the whole team is everyone involved in delivering value, and then learning from that delivery.

So, if you’re still reading, I’m gonna do my best to make a case for why you should drop your current methodology, especially if it’s some prescribed one like Scrum, or SAFE, and become an agile purist.

Simplicity at Its Core: The Agile Manifesto

The Agile Manifesto is built on four straightforward values that emphasize collaboration, adaptability, and customer-centricity:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

These values are easy to understand and can be quickly adopted by teams of any size or experience level.

Implementing Agile Principles: A Team Effort for Everyone

Agile development is a team effort that encourages open communication, trust, and shared responsibility among all members, including software engineers, product owners, designers, QA members, DevOps professionals, and business stakeholders. By working together, teams can easily put the Agile Manifesto’s principles into practice:

1. Remain adaptable and open to change based on customer feedback and evolving requirements, even late in development.
2. Emphasize face-to-face communication to build trust and foster collaboration across all roles.
3. Focus on delivering working software that provides value to customers.
4. Encourage continuous learning, improvement, and innovation.

By following these basic principles, teams can create an agile environment that promotes efficiency, creativity, and adaptability.

Being Agile Is Easy for Everyone

You don’t need to be an agile expert to put the Agile Manifesto and its principles into practice. By fostering a culture of collaboration, open communication, and adaptability among all team members, teams can easily embrace an agile mindset and enjoy the benefits of agile development.

To help your team become more agile, consider these simple steps:

1. Review the Agile Manifesto and its principles together as a team, involving all roles.
2. Identify areas where your team can improve communication, collaboration, and adaptability.
3. Implement small, incremental changes that align with the Agile Manifesto’s values and principles.
4. Regularly review progress and adjust your approach as needed.

Remember, being agile is about embracing simplicity, collaboration, and adaptability. By focusing on the Agile Manifesto’s core values and putting its principles into practice, your entire team can easily adopt an agile mindset and excel in delivering value to customers.

Over the coming weeks, I’m going to be posting more specifics on the topics above, like, what does it mean to be collaborative and adaptable, or how does a team move to small incremental delivery’s. So, hang in there, I’ve got a lot more to come.