On Agile software development
An often distorted view
In the past year, I’ve run many interviews for project-manager and engineering roles. One common thing I’ve noticed is that the industry’s idea of what Agile means, is incredibly varied, going from something that is waterfall under a different name, to a style that requires specific “Agile roles” in a team.
In this post, I’ll go through what the initial idea of Agile was, and what it should be; hopefully, this will help people realise how far from the original purpose they’ve steered.
Scrum Master
Let’s start by talking about any team with a person dedicated to increasing everybody’s productivity. Every team that feels the need for it is, in my view, a team without professional people that you can trust, and a team with whom I probably would not enjoy working. The whole point of Agile is to operate in a group where collaboration, curiosity and ownership are the driving factors, and each member of the team should be happy taking turns to get involved and help other members.
Stand-up meeting
Stand-up is where the team shares their updates and has the chance to ask for help. It is usually held in the morning, but it’s not essential. Each story requires a different amount of time, engagement and communication; there won’t always be an update from everyone.
A warning sign is when each member is directly asked to provide an update, even when there is nothing new to discuss; this usually indicates a lack of trust, or professionalism, from one of the two parts. This ideally short meeting can quickly become distorted and micro-managed, transforming it from a useful tool to a tedious process.
Grooming
This meeting should be all about discussing what’s next and exploring ideas but without any commitment. The ticket should remain quite vague, with only a short explanation of what the goal is. Talking about problems and solutions allows the entire team to get a chance to say what they think and to increase domain knowledge sharing.
It’s essential to keep the above in mind. A grooming meeting can get very ugly, becoming a planning meeting lacking in defined scope, where each ticket gets discussed and written down in minute details.
Planning
Planning should be all about reviewing and expanding the tickets discussed during grooming. When talking about them, the team can add details and acceptance criteria. Acceptance criteria don’t have to be comprehensive yet but should describe what we expect from a working feature.
A planning session should last two hours for a one week sprint, with an additional two for each consecutive week.
To create good user stories, follow the INVEST rules:
| Rule | Description |
|---|---|
| Independent | User stories are independent of each other. They can be implemented in no particular order |
| Negotiable | Details should be left out of a card up until it will be kept up to do the work; This allows the card to be negotiable between developers and the business needs |
| Valuable | Must have clean and quantifiable value to the business |
| Estimable | Must be concrete enough to allow a developer to estimate it |
| Small | It should not be larger than the work that one or two developers can get done in a single iteration |
| Testable | It should have clear acceptance tests, provided by the business, and implemented by the QA. Once they pass, the story is considered done. Developers and QA should communicate, discuss and work together, if necessary |
The iteration
Once the sprint starts, team members will begin picking up stories; this is where I often see the most confusion. Business, devs and QA should work together on each ticket from the start, discussing the story and adding happy and unhappy paths. I see many teams working in turns, with dev doing all their work and then passing the story to the QA, who then takes the story and implements their tests. This way of working is not collaborative, and by the time a dev says that the code is ready it’s usually too late to make any necessary changes quickly. Ideally, dev and QA must start working together on the ticket, with dev running all the tests as soon as they are available to establish a quick feedback loop.
One piece of advice that I would give to each team is to start in the simplest way they can to manage stories and their progress. Many modern tools provide so much choice, but they add complexity to something designed for streamlining development.
Software development methodology
The point of any Agile team is to provide working software at the end of each sprint. I often see teams defining themselves Agile, but without following the necessary methodologies required.
Simple Design
To be able to deliver value at the end of each sprint, code must be written in a way that minimises complexity and enables easily testable code.
Pair Programming
Pair Programming comes from the spirit of knowledge sharing and collaboration that Agile promotes. By pair programming, each member of the team will know more about the domain. It is easier to reach a satisfactory solution by working together.
Test Driven Development
By the end of each sprint, all the stories should be ready to be released. How can you be sure if your code works as expected? The solution is to write your code, alongside a test that verifies your assumptions, so that each line of code is only added when necessary for the test to pass. This technique goes hand in hand with Simple Design.
Definition of done
The point of each sprint is to deliver code ready to be released if the business decides that it is the right moment.
How do you know when your code is ready to be released? When all the tests are passing.
If a team is not confident enough in their code and tests, it should sound like a big warning, and the team must work out why and how to fix it as soon as possible.
Retro
One of those meetings that people not confident in Agile tend to underestimate.
Without a retro, a team won’t be able to improve quickly. By removing the obstacles that cause the most pain, they can be sure to check the effectiveness of their teamwork.