A fresh look at Agile
It wasn’t too long ago that I equated the term ‘Agile’ with corporate speak.
Nothing more than a buzzword. The new hotness.
So I have to admit, I was a tad sceptical when I heard that HX embraced Agile.
How HX do Agile
For those unfamiliar with Agile, it’s generally considered a catchall term to describe a lightweight process of incremental delivery.
However, it’s not prescriptive as such and so is open to interpretation (and misinterpretation in some cases).
Scrum is the Agile methodology that best describes to process followed by the team at HX.
Our web team is divided into a number of smaller ‘pods’ - each aligned with one particular aspect of the product delivery lifecycle.
That said, each team follows broadly the same approach when it comes to planning and delivery:
We work from an activity backlog consisting of requirements (stories) for all of the products/systems we are working on.
Each sprint begins anew with a planning meeting in which stories are selected and estimated. The dev team choose which stories to implement.
Each story is assigned an estimate following a democratic procedure in which each dev decides how many work units they think it would require to complete.
The numbers do not directly translate to days per se, but are used instead as relative indicators of effort.
Two of the devs who offer the highest and lowest estimates then argue their cases.
When I first took part in this process, I was struck by what an effective, educational tool it can be.
Often, those with the most extreme estimates have an insight not shared by the team. Needless to say, the discussions that ensue are highly interesting and within a relatively short period of time, the group is invariably able to reach a consensus and the majority rule.
With estimates complete, the dev work begins, using Jira to manage issues and keep track of progress.
As the real work progresses, we have daily standups lasting around 10 minutes to discuss what we’ve worked on the previous day and what we plan to work on that day.
This is a useful process which puts everyone on the same page and is a chance to raise any showstopping issues.
After the sprint, the team meet for a retrospective to deconstruct the previous sprint. Specifically, what the team should continue doing, what they should start doing, and what they should stop doing.
In the short time I’ve been at HX, I’ve noticed some clear benefits that this style of workflow conveys:
Being able to work in short, two-week sprints gives a clear, time-boxed period of work. No matter what new requirements land on the doorstep, the workload for the sprint doesn’t change.
All tasks are visualised on a kanban board so its easy to see what’s being done by who, what stage they’re at and where the pinch points lie.
More time for development
Daily standups reduce the need for meetings and keep non-dev time to a minimum, meaning more time for coding. This invariably leads to…
Developers are able to choose and manage their workloads while keeping aligned with business needs. This is an empowering feeling.
Tasks are manageable. Knowing what you’re working on over the next two week reduces the anxiety.
Although I’m still fairly new to the process, I’ve noticed a few key practices that really make a difference:
Say it with numbers
Use numbered cards (we prefer Uno®) to estimate tasks. The ensuing discussion is always enlightening.
Also, be conservative in you estimates.
It’s better for team morale to deliver on what they set out to rather than to let one or two features slip.
Learn from past wind
Sprints are a great opportunity to learn what works and what doesn’t.
However, come the retrospective, it’s not always easy to remember what worked and what didn’t. So be sure to make notes as you go.
Keep in touch
Keeping in constant communication is a must. Short sprints require everyone to know not only what they’re doing but what everyone else is doing. So use tools to keep in contact.
I don’t think it needs to be said, but more eyes leads to better code. At HX, we have a practice of having at least 3 sets of eyes review every Pull Request.
Code reviews produce good discussions and are a great opportunity to learn new best practices.
Although not a practice that is mandatory at HX, pair programming is something we should all strive to do on a regular basis. Like code reviews, they provide a way for everyone to learn.
The process can be intense at first but it’s a great way to imbue others with domain-specific knowledge, particularly when getting to grips with a new codebase.
Although we do a lot of things right at HX, we are always looking to improve how we work.
The great thing about Agile is that it can be adapted to fit your team and therein lies its true value.
Finding what works and what doesn’t is a matter of trial and error. But with an open culture and active participation in retrospectives, processes can be overhauled to better suit your workflow.Tags Agile, Scrum