Agile, Scrum, Jira
Atlassian Jira is a hell of a tool. It’s the tool for anybody that’s interested in working Agile.
In this post I want to explain some Jira practices I’ve been employing during my work as a Department Jira Administrator. If you’re a starting Jira enthusiast, you might find some of these tips useful. Keep in mind that I have no ‘formal’ Jira training – everything I know is learned-by-doing in the last 18 months.
Alright, let me first start off that the amount of misinformation regarding the word ‘Agile’ – both online and offline – is just staggering.
Being agile is the ability to quickly adapt to a changing demand.
These changes in demand can originate from the market, a single customer or your own team as it changes through time and requires new impulses for improvement. Being ‘agile’ is thus almost entirely based on empirical data. This means that if it some process or product doesn’t meet the requirements – check what’s wrong and do something that works. You can read the original ‘manifesto’ here.
It would be a problem if everybody took this to heart and started improving items on their own. This would become a chaotic mess and denies people of measurement points that allow to check if the improvement really did work. This is where Scrum comes into play.
Scrum is a ‘light’ framework that provides users some core rules on how to provide rhythm in a team while it is working on the improvements (of the product or team itself)
I won’t go into too much detail here, but you can read the Scrum Guide if you’re interested.
One example of this rhythm is the rule that the amount of work should be split in ‘Sprints’ of 2 weeks.(3 or 4 weeks is also possible, but you can’t switch) After a Sprint, the team discusses what went well in the last Sprint and how they can improve in the next. Because of the strict cadence of 2, 3 or 4 weeks it’s possible to discuss points for improvement and have a clear deadline and point of measurement.
Now, the interesting thing to notice is that Scrum is a very light framework. This is because it is a mindchild of ‘being agile’. Therefore it cannot impede with a team’s need to adapt to its changing needs. Instead, it leaves great freedom for teams to implement their own ideas. Some of these ideas work really well and are added to the so-called Scrum ‘Complementary practices’
The Scrum ‘Complementary practices’ are basically a jungle of anything that anybody thinks it should be.
This is because Team A in Singapore had a great idea and posted it somewhere online. Team B in Great Britain picks up on it and writes about their own great idea. Person C takes from both and writes his own theory. The end result is a mix of anything. This is the most confusing part of Scrum (to me at least) because suddenly the Core Scrum guide is no longer ‘the truth’ but rather the absolute basics. Every company uses its own ‘complementary practices’ which doesn’t really help in the confusion.
I consider “Scrum And Xp From The Trenches“ a good (free) ebook about the complementary Scrum Practices
Atlassian Jira is one of the complementary practices. It’s a web-based tool that supports its users in their interpretation of Scrum.
And, as a closing note – the idea to use little cards to visually show the progress of an item in a process is called ‘Kanban’. Pfew!
In the next post I’ll talk a bit more about Jira!