Category Archives: Agile

Practical Agile Guide Part One: Recognition

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 their 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.

Simplifying the Agile Manifesto: Breaking it Down Into Categories

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.

Being Agile Is Easy

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.