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.