The Agile Developer’s Survival Guide for 2020
Agile done right is tough, but you can help make things a little bit easier if you follow this advice.
I like to say that Agile is like teen sex, everyone says they’re doing it, but no one really knows exactly what it is.
Actually, some people do, which is why they’re so expensive (who would’ve thought!).
On a more serious note though, our industry (that is, the Software Development industry) is generally going the agile route, which means development teams normally adopt a methodology such as SCRUM where they work on small increments of time towards trying to deliver tiny but concise improvements into a particular project.
Some teams do this by following a certified person’s recommendations and others just take what they think will work from the book and hope that helps. In my opinion, either way, is good, as long as you don’t blindly follow a set of rules without really understanding their purpose, it’s still much better than other alternatives such as waterfall (which by the way, it still has a place in some industries).
As part of this methodology, there are some ceremonies (i.e meetings, that especially now, tend to be virtual ones) to follow, tooling to use and in general, you’re not working alone, which means there is some team-work etiquette to follow that not everyone is really aware of.
So to give you, the agile developer, a healthy chance of surviving this agile jungle, if you will, and especially now with the rise of virtuality thanks to COVID-19, I present to you my (completely not born out of many years of frustration from dealing with people not following these principles) list of recommendations on how to proceed when you’re part of an agile software development team.
Don’t use team stand-up calls to catch up on life
Team stand-up calls are usually meant to last less than 15 minutes, depending on your team, that number may vary, but consider this: they’re called “stand-up” for a reason, they’re meant to be done while standing up so everyone would hurry up and be done with their part as soon as possible.
The usual script for these meetings consists of going one by one (yes, everyone on the team should speak up) saying what you did the day before, what you’re planning on doing today, and if you have any blockers, mention them. There is no catching up with the lives of your coworkers here. There is no telling jokes here, and most importantly, there is no going on in a tangent talking about a particular problem you have, even if it is within your project’s context.
Meetings in this methodology are only meant to exist if they’re essential and even then, they need to be fast and don’t detract the team from what they’re supposed to be doing. So if you see that a daily stand-up is slowly turning into a 30 minutes to 1-hour long meeting every day, it’s is perfectly alright to call whoever is responsible out and ask them to take their problems into another, more focused call with the ones involved.
Be present during sprint planning meetings
Sprints are small chunks of time where you focus the team’s effort into reaching a (usually) small goal. So when you’re planning for that window of time and the type of work you and your team will be doing then, it’s important to make sure the entire team is committed to that delivery.
This is why it is usually encouraged to have the entire team be part of these meetings. By having everyone review the work to be done, some interesting questions may arise, which in turn might completely change the work being reviewed. But this can only be achieved if those involved pay attention, even if you’re not the one who’s going to be implementing it, even if you don’t even have the right role to work on it, questions coming from a different perspective might unlock blockers that not everyone is seeing due to their already existing bias towards that task.
This is the same as arguing whether or not developers should be in charge of testing their own work (spoiler alert, they shouldn’t). Having an outsider’s perspective is key to reviewing and testing a feature, and the same goes for planning future work.
So when you and your team are reviewing the work ahead, please don’t switch your brain off waiting to hear the mention of your name. Don’t start browsing the internet on another tab while others are talking. Be there, be present and make an effort to understand the task being reviewed, maybe 9 out of 10 times, you won’t be able to bring up anything relevant, but that one time you are, it could be the question that changes everything about that user story.
Be mindful of the time left on the sprint
Usually, sprints are 2 weeks long, although some teams may change that number around a bit. The point here is that you should always know exactly how many days are left for you to deliver the work you committed to during the planning ceremony.
And in turn, saying you’re not going to be able to complete your tasks on the very last day of your sprint, is not ideal. And I can hear you saying that that’s not your responsibility, I can even hear you saying your manager should’ve seen it coming and that person should’ve done something to mitigate the problem.
Let me tell you, as a manager myself, that is not entirely correct. Yes, there are some situations where micro-managing a team is required, even in some circumstances, doing it only with a few team members might be beneficial, not only to them but to the entire team. However, teams with enough experience should be able to work without anyone performing micro-management (which takes up a lot of time and effort on both sides) and just deliver the promised work on time.
And if there are difficulties or setbacks (which of course, in a real-world project there always are) you should know better and raise your hand (i.e say something about it) when problems arise. Don’t wait until the end of the sprint to bring these problems up, justifying yourself by saying you thought you’d be able to take care of them. Bring these problems up, let your manager know about them and together decide on how to best proceed.
This is less of an agile-related problem and more of a software development one in general, but considering the small window of time a sprint involves, doing this in this context has a greater impact, since there is very little margin for error.
You’re probably not the only one in your team
Consider the following scenario:
Developer the very last day of the sprint: Ready! I’ve completed all my tasks today, woohoo, I thought I was going to fail the team.
QA team member waiting to test your features: Am I a joke to you?!
Within a single sprint, you’re normally producing work that others will need, whether it’s back-end code that a front-end developer will interact with or a piece of UI that a QA team member needs to verify, you need to think of your work as part of a bigger context.
In other words, delivering your work on the last day of the sprint is already too late, because chances are, you completed your tasks, but the overall user story where you were working on (i.e the feature you were trying to add) requires other people to interact with your code, and now there is no time for that.
So next time you’re working on something, think about who else needs it: is there a QA process that needs to take place? How long will it take? Is my code blocking the development of another task? How long will that other task need to be complete?
You’re not working alone, and you’re certainly not working in a vacuum where any delay or problem you might have will not affect anyone else. There are very big chances that any delay you might incur will, in fact, delay others in your team. So make sure you take that into account both, when planning your work ahead and when problems start piling up.
Stop thinking about your work and start thinking about the team’s goal, that should help you keep the rest of your team in mind.
Everyone hates task tracking, but it’s important
Whether you’re using JIRA, Trello, or any other task tracking tool on the market, odds are, you’re going to hate it. Simply because developers write code, there is very little time to log into those (usually) cumbersome tools and update a status that you’re giving as part of your daily meetings anyway.
So why bother? Right?!
Wrong, actually, and here is why.
Other than making your life miserable, task tracking tools are fantastic to understand, at a glance, the current status of a project as well as make an educated guess on whether or not the team is on track to deliver their promised milestones.
Put yourself in the shoes of your manager for a second, consider their responsibilities, and how they’re usually asked daily by stakeholders whether or not the project is on track. Would you rather they go one by one asking developers, designers, QA, and other team members how their day is going? Or do you think having a birds-eye view of the project might help?
I would assume no one would really go for the first one, ever, so to go for the second option, someone needs to update how every task is going. And that is where you come in, simply by updating the status of your tasks daily you’re providing a lot of value to your manager. Mind you, I’m not asking you to register the number of hours worked on every task, I’m just saying that marking a task as “Pending”, “In Progress”, “Blocked” or “Done” already provides a lot of value. If you want to go that extra mile and leave a comment explaining why it is blocked (for example), then you’re probably amazing and deserve a cookie, so go on, get it and keep reading while you enjoy it.
Story points are not random numbers you attach to a user story
Giving random numbers that really don’t mean anything tangible to a user story makes very little sense, I know. But trust me, that is only at first, once you see the point to them (pun fully intended by the way), they become a must-have.
Let me ask you something: If you were to lead your current project, how would you tell how much work to put inside a sprint when you’re planning the work ahead? I know that as a developer I never really thought about that question for a long time. The tasks I had to work on were given to me, and I was meant to complete them within a 2-week window of time. That was it.
That was my reality until I saw myself sitting in the manager’s chair. How would I know what the magic number was for my team? How many user stories were enough? How many were too many? Would it just be a matter of trial and error? Can I use these story points for anything useful?
But consider the larger plan, if I can’t reliably know how much work can my team deliver in just 2 weeks, how can I know if I’m able to complete the project on time?
That is where story points come into play. If you consistently point stories based on the same scale (oh yes, you need to set up a scale so everyone understands the same thing by a 1 or an 8), then after a few sprints, you start getting an idea of how many points you can complete during a sprint. This is called “velocity” and that is what you’ll use when planning future sprints.
So remember that next time you’re having to point stories, there is a very good reason for it!
To sum it up
Being a good agile developer is not about writing code fast, rather, it’s about adopting the chosen methodology, thinking about the project and your team, instead of just your tasks and yourself. And remember:
- Keep your daily updates to the bare minimum and take everything else to a more focused meeting.
- Planning meetings are very important, be present and contribute to them.
- The sprint is a very well defined window of time, keep that in mind and consider others are waiting for your work.
- Task tracking is important, it helps others understand how the overall team is doing, so do it.
- Story points matter, don’t ignore them or throw random numbers at user stories.
Essentially, play nice with your team and you’ll enjoy the process, only think about yourself and the agile methodology will turn the project into a nightmare.
Have you seen behavior like it in your past projects? Did I miss any tips out that you consider very important? Leave a comment down below and let everyone know your experience!