A methodology for everyone: how I learned to stop worrying and love Agile — Part II
While preparing this series of articles, I came across multiple opinion posts criticising Agile applied to certain industries or types of projects. For example, this one regarding data science projects that deal with open-ended and hard-to-estimate problems.
While some of the claims are fully justified, I feel like they shouldn’t be blocking you from trying out the methodology and deciding for yourself if it’s going to be your go-to way of working. So, to reiterate the goal of this series, I want to show you that there are things you can safely try out regardless of your job title and give some tips to make it run smooth.
Getting started
Alright, you decided to take the leap of faith I described in the first part of my blog post and try out Agile methodologies in your team. Where do you start?
#1. The standup
In her opinion piece for Forbes, Tracy Brower says the following (and I can’t agree more!):
…when agile teams work effectively they tend to share a lot of information. This contributes to shared mental models and helping behaviors. Essentially, fast information flow (information density) contributes to people who have shared thinking and common ways of understanding. This shared experience contributes toward team members who stay aware of each other’s needs and provide support, assistance and guidance on tasks, making for better outcomes overall.
I feel that a good starting point for creating an open culture and supporting atmosphere is a daily standup that gives a floor to everyone not only to update others on their work but to ask help questions and share successes. This way, as an Agile methodologies enthusiast, you can learn about the nature of tasks your colleagues are carrying out, the typical timelines of their work, and the size of projects/tasks. And the best thing — you only need 15 minutes for that.
#2. The board
Your main instrument to visualise the progress of your work. I believe most of the people you work with use task trackers in one way or another (think anything from todo lists on your phone or blocks in the agenda), but boards provide a great helicopter view of the overall status of the work done by the whole team. Especially when you work in sprints.
Like any visual instrument, if used smartly, boards help notice patterns and raise important questions to discuss with the team. For example, you can spot too many tasks stuck in “blocked” or “review” columns: this will be a clear signal to discuss collaboration within a team or with external members. Does the amount of work on an individual level prevent you from reviewing other teammates' work or conflicts within a team?
Do you notice more incoming bugs than usual, and you’re working on them instead of new features? Too many tasks on “todo” and the team lack focus? You’re in the middle of the sprint, everyone looks busy, but the “todo’s” are much longer than done? These are the things I’d have never proposed to discuss if we didn’t use boards to visualise our progress.
#3. The retro
Again, I believe this happens in some way in non-agile teams, but mostly in 1-on-1s. However, it’s the reflections on the way of working that are made public within a team that contributes to an open culture where people listen to and help each other naturally.
Thus, find a format that gets your teammates talking and listen to what they say. I personally like Metroretro’s retrospective templates: why waste time on the technicalities of hosting a retro, if everything has already been done for you? Instead, focus on the meeting itself.
Also, what worked well for the teams I was part of, is looking back at previous retros and noticing the steps we made (or didn’t make) to tackle the negative points. This brings continuity to the process and makes the reflections more tangible.
Do’s and Dont’s
Now that we’ve discussed which practices are the easiest to adapt to, I wanted to give some tips on how to actually adopt them. So, let me introduce you to my learned-the-hard-way Do’s and Dont’s of Agile methodologies.
Do’s
# 1. Personalise your experience
Normally, Scrum or a Kanban board will look like something like the title picture of this blog post. The columns on the board are no doubt self-descriptive and make sense but could be too much tailored to the process of software development. Be creative and mindful about your use-cases: perhaps, “Published” will be more relatable for your team of analysts building visualisations for a report than “Done” or an extra column “Documented” will become that much-needed reminder to update the docs for your team of developers.
My other advice relates to the so-called open-ended nature of data science projects. I find it helpful to reduce the uncertainty by separating the implementation of the prototype from research into the possible approaches/features/architecture. So I do a Spike to choose an approach for the part that I’m not yet sure about and once it’s done build a prototype which now has fewer loose ends. The important thing here is to time-box your spikes so that you don’t go down the rabbit hole and iterate fast.
#2. Plan ahead
I think that oftentimes people see creating and organising tickets as a time-consuming chore bringing little to zero value. To me, it’s a misconception coming from two major causes. Either overly demanding management blocking developers' creativity (why write a story when they think they know exactly how to solve a problem?) or alternatively, extremely individualistic developers (why write a story for someone to understand if it’s them who is most likely to pick it up?).
I believe, if prepared properly, a ticket on the board can be a tool advocating for developers, not against them. For example, it visualises the development process so that when priorities shift, the person can show that switching to a new task will delay other things on the board, rework the priorities together with a manager and swap the tickets.
In addition, a properly written user story can prevent the team from doing double work and trigger the discussion on achieving the value more simply. This is much harder to achieve when the task starts with what needs to be done rather than why. In the end, it’s not about doing a task but solving a problem.
# 3. Take ownership
I believe taking ownership is something that needs to happen on multiple levels of Agile development: starting with having a person responsible for the methodology adoption to each team member who takes the initiative in picking up the relevant tickets and shares their thoughts on the retrospective.
For me, it works well when tickets are assigned to me before the sprint starts so that I can oversee my plan for the upcoming weeks and exercise ownership. Of course, we work as a team but it’s the individual responsibility that keeps it working smooth. Even if later you find out that the task needs someone else’s input and transfer the ticket, there’s a higher chance that it will succeed when more than one person is involved.
Also, it seems harder to estimate the load for the team than for a particular individual and prevent overpromising on team level. However, everyone has unique insights into their productivity and availability during the sprint.
Dont’s
#1. Don’t rush and over-complicate
Switching to another way of working could be a handful: in addition to carrying out your everyday work you’re refactoring the way you do it. Thus, my advice would be not to rush with all the changes and roll them out gradually. That’s a bit of recursion: Agile advocates for iterative development, so what could be more natural than to trying out the methodology itself iteratively too?
I would advise starting with Kanban rather than Scrum to figure out your regular timelines, learn to write user stories, and develop a habit of sharing your progress. Having the refinement sessions and estimating the sprint velocity right away will only exhaust your team and make them lobby against Agile. Instead, find the next element to implement together, based on the feedback from the retrospective.
# 2. Don’t bureaucratise
Don’t try to put all the work you do on the board. Here I mean that sometimes it takes more time to create a ticket than do it right away. Also, some jobs involve daily or weekly scheduled operational tasks that rarely go not as planned.
My advice would be to leave this out of the board; rather, adjust the amount of project work you’re going to do taking into account your operational tasks, especially if you rotate them. We’ll look into “light-weight” Agile practices in one of the next blog posts, when I’m going to talk about structuring pet projects and volunteering work.
# 3. Don’t forget to write the docs
I’m sure everyone involved in building software has said this at least once: read the docs. But for others to read them, someone needs to write them first. Same about your way of working: to enjoy the smooth and productive Agile journey, you’ll have to keep certain artifacts. These would be your notes from the retrospective, backlog, issue templates, and even the meeting invites in your calendar. Some teams also document the principles they use when breaking work into manageable chunks (i.e., what is an epic, story, feature, and task).
I do believe it’s beneficial for the team to document their way of working evolution. Not necessary to be able to go a year back and plot charts of team happiness (see #2. Don’t bureaucratise), but to have a way to look a sprint back to compare and see if there’re any improvements on the points flagged before. I would also say, without such artifacts, it’s hard to build trust in the Agile rituals: if we spend hours getting the insights on how we work as a team, they need to be actionable, and we need a proof that the actions happened.
Alright, in this blog post I tried to be more practical and list the things I believe are the easiest to start with when planning to try out the Agile way of working. My main takeaway here is to treat finding a more satisfying way of working for the team just like any other project: plan, test, analyse, repeat. Speaking of analysing, in the next blog post in this series, I’ll give you some insights from the way of working survey I shared with my network last year.
