Agile is about more than methodolgy.
I used to be of the opinion that agile was, for the most part, simply a process; and as far as processes go, a fairly useless one. If you’re going to total a day or so writing stories, scoring and doing a retrospective in any given arbitrary “sprint”, then I used to think that was silly. Why not instead spend that day getting on with the work?
So when I arrived at SoPost back in March, I have to say I was sceptical about the fact we’d be working in an agile way. Especially since for the most part I was the only one working there most days of the week.
I’ve since done a total 180° on my opinion. I don’t know exactly what “flavour” of agile we use at SoPost, but I’d say it comes close to scrum and I know it’s making me a better “everything”; Here’s why
Larger tasks are broken down into smaller stories
We take a large bit of functionality such as “a customer can gift an item to another customer using an email address” and that gets broken down into much smaller components, or “stories”
As a group we then score our stories into Fibonaaci numbers based on the complexity of story. We can choose from 1, 2, 3, 5, 8, 13 and 21. Where 1 is clear, precise and easy to implement and 21 is vague, broad and very unclear about implementation.
When each story is scored, it goes into the backlog where it awaits someone on the team to pick it up.
Only stories less or equal to five make it into the backlog
If a story is scored greater than five, it does not make it into the backlog because it’s deemed to be not specific enough. This is bad because stories that aren’t specific enough are –
- harder to merge into the codebase because they tend to require a more thorough code review
- are more likely to introduce more serious bugs into the code
- are more likely to generate more conflicts when attempting to merge back into the development branch.
Small stories rule because every change is small and targeted to a specific story. There is no room to add a feature just “because you’re in there and it’ll take a few seconds”. No, you write and tests the code to do the only the stuff mentioned in the story; no more, no less.
You learn how to write unsmelly code
Because each story is small and focused on the story, the code tends to be tight, robust and have good longevity. If it doesn’t, then any potential smelliness gets caught at the code review stage and you get feedback on how to reduce/eliminate the stench, before the code makes it into the development branch.
You learn how to develop incrementally and asynchronously
I was so use to developing on a linear fashion that this one crept up on me. The code grows story by story. You try to avoid (but it’s not always possible) writing a story that depends on anything other than code that’s available in the development branch. This make me better because I try to affect the necessary functionality by writing as little code in as few places as possible.
You learn to respect code standards
In a team of five writing code together, you have to respect, implement and be totally aware of coding style. There is no deviation “because you wanted to try something new”, because in doing so you’d introducing ambiguity. When the next designer or developer picks up the work and there’s two ways of doing the same thing it’s not clear which one should be use.
It’s not all down to agile though
There’s other tools and workflows that are adding to my skillset and whilst the agile way of working is no doubt the corner stone there are a few other things &dnash;
- six thinking hats, definately a book you should read
- Following the git-flow
- Jenkins, hubot and Janky.
I’ll blog more about these other things later, but for now, I’m an agile convert but still sane enough to know you shouldn’t agile all the things.