How to actually be Agile
If you’ve read any of my previous articles you’ll know that I am no fan of Agile. This may make you wonder about the title of this article, but to help you better understand where I’m coming from, in this article I want to get into the differences between the Agile philosophy and Agile in practice. Now, I’ve done a whole article about the failings of Agile in practice that you can read here. This article is going to be a little different because I’m going to point out ways to improve your practices rather than point out ways your Agile practices are leading you astray. I’m going to help you guys take these things out of the box and shape it to make your team run more efficiently.
Remove the Rigidity
I have seen far too many Agile implementations impose such strict rigidity, mainly due to the use of Scrum and all the process imposed by Scrum. A good example of this is the standup meeting. For many companies, stand-up must happen at the same time at the same place every day no matter what. Some companies even go so far as to say it must be n number of minutes long and will not accept a minute more or less.
Stand-up is not a unique scrum meeting there are plenty of other ones that are just as rigid. These things can quickly become an anchor weighing your team down and imposing stupid rules that don’t benefit you at all. The key here is not to be so rigid with these processes. One key point of the Agile philosophy is people and interactions over processes and tools, and that cannot be accomplished with Scrum.
If you want to have a stand-up meeting or any other scrum meeting, that’s fine. Personally, I think scrum meetings are a waste of time when you have tools like Slack where this can all be asynchronous and everyone can get on the same page much more easily. My personal feelings aside, I’m not going to say you’re wrong for having scrum meetings, because maybe that works for you. However, if you’re imposing such strict rigidity to these processes and meetings you may find that you’re shooting yourself in the foot. Before you hold a meeting I would ask yourself and your team, “Do we really need to have this meeting?”. There may be some days where the answer is no, and there may be some days where the answer is yes. You should also ask yourself if this process may be better off with a different medium. I’ll go back to the example of stand-up, where you can probably post it all on Slack and have the team catch up at their own pace. You may have several team members who are working on something important that they shouldn’t really come away from until it’s done. I’ve been in this position many times before where I’m trying to hotfix a production bug and the Scrum master has always told me that whatever I was doing was not as important as the stand-up meeting or whatever meeting they were dragging me off to attend. In a situation like that, it would have been more appropriate to let me finish my work and fill me in on the important details over Slack later. If I was critical to the meeting then you can always hold it at a later time.
The key takeaway here is to let your processes be fluid. Don’t rely on a strict schedule for everything. Life does not happen on your schedule and bugs certainly don’t respect your schedule so don’t try to force it to.
Listen to your Subject Matter Experts
Companies hire developers because they have a set of skills and knowledge that the other people in the company do not. We can write the code to make your product work and come to life. For many companies, this is their lifeblood and would be dead in the water if all their developers just stopped working. These same companies hire a Scrum master who attended an overly expensive 2-day Agile seminar to lead their development team. Many times, these people are not developers and are completely non-technical. These are the people who usually fall into the pitfall of imposing rigid processes and they fall into another pitfall of not listening to the developers on their team.
Scrum master is really just a fancy word for “manager who imposes Scrum and Agile”. It can often be a problem when these people, who do not know how to write code or know about the intricacies of creating a software product, try to impose a method that they only spent 2 days learning about. More often than not, these people also ignore their developers who question the practices they’re trying to impose. A good manager will always listen to the advice given by their subject matter experts.
If you’re an Agile manager and you’re also not a developer, then you have one job: keep your developers happy. That is really the key to being a non-technical manager for a software team. Make sure that you’re developers have the tools they need, make sure that they have the ability to perform their duties, unobstructed by process, and make sure you’re listening to them when they bring you a problem. If you’re already doing these things, then by all carry on the good work. However, if you’ve noticed a lot of churn in your team then you should really reconsider how you’re doing things. If you work at a software company then your developers are the engine that makes the company work. Without them, there is no product, no customers, and no company. If they’re unhappy, they will not do their best work, which, at the end of the day, negatively impacts your bottom line.
Evolve over time
From the moment you take your Agile implementation out of the box and don’t change anything, you’re already failing. Teams and projects are vastly different from one another, and so it stands to reason that there cannot be a blanket project management solution for all of them. Unfortunately, Agile is being sold as the silver bullet to tackle all project management woes, which it absolutely is not. There is not, and should not, be a single blanket solution to manage all projects. It’s ok if you start with a simple solution, but you have to change it over time to better fit your team.
Nature is not stagnant, and we shouldn’t be either. We need to change over time and that very much includes project management practices. If something isn’t working, 86 it. If something is working, keep it. A team should always be asking questions to improve themselves and their practices. Too often Scrum masters are hostile to critique and label any who would question them as dissidents. This makes for a toxic work environment which will result in poor performance on the part of your team. This goes hand-in-hand with keeping your developers happy because you also have a responsibility to empower them to make changes to the processes. This leads to developers being more invested in the team and the product. If you are open to critical feedback of your processes you will be able to improve rapidly.
Enforce standards over processes
I have seen Scrum masters push their processes over standards way too many times. This has resulted in poor performance of the team as well as a poorly made product. Enforcing standards is what really makes a huge difference in a product and a team. If your processes aren’t improving the standards or even holding up your standards then you shouldn’t use it.
Too often, the Scrum master will get too caught up in trying to implement Agile and Scrum and enforce those processes that they will completely forget about the standards for the actual product. This will result in a bad product that people don’t like because the team cannot spend any time thinking about the product because they’re spending all their time thinking about Agile and Scrum. The important standard to enforce is the one that makes the product better. Don’t get bogged down with Agile dogma, focus on your product and your customers. You must be careful not to turn this into dogma because then it becomes brittle and resistant to change.
Conclusion
I want to highlight that there are large differences between Agile in practice and the Agile philosophy. Many people will say that the points I make here say that Agile is right because that is what the Agile philosophy is all about. However, that’s not entirely correct. The points I am making in this article are driven specifically to target problems of Agile in practice and happen to align with the Agile philosophy. The Agile philosophy sounds nice, but it has been turned into toxic dogma by companies whose only purpose is to push Agile. So when Agile hits our teams it has been warped into something it was not intended to be.
If you want to succeed then you have to be able to think for yourself and you have to empower your developer to think for themselves as well. You must be able to enforce a set of standards that shape your processes. Taking Agile and Scrum out of the box will not work for you or your team in the long term. It is important that you evolve your practices to better fit your team and product.
Your project management practices should be fluid and ever-changing. If you’ve been chosen to manage a software team, the best advice I can give you is to step out of their way. Try not to become a blocking factor for your team because you want to do Agile and Scrum. Make sure you’re actually empowering your team by listening to them and changing things that don’t work to better suit your team.
If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!
If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!
📝 Read this story later in Journal.
👩💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.
