Early in 2015, we decided to “get serious” about this whole Scrum/Agile/Project Management thing, believing that we just didn’t have enough cred as a software team if we were using something as beautifully simple and intuitive as Trello.
Oh the naivete!
So we embarked on an arduous (but not as interesting) Homeric adventure with Atlassian’s flagship product, Jira.
We swallowed the bitter (and very large) administration pill and went deep down the Jira rabbit-hole, waving a very tearful goodbye to our beloved Trello as we went.
We were adopting the Scrum methodology wholesale and figured Jira would help us to keep track of our velocities with oodles of charts and graphs about how productive and lean we were being whilst keeping our sprints tight and light at the same time.
We were officially very serious and could prove it by how diligent and painful our project management had become.
Well, fast forward two years and we have given Jira the boot. Why, you may ask? Let’s break it down…
So the setup itself was a herculean task. Let me first say that I am not a sys-admin by a long shot, or even a moon-shot, so its possible that the configuration methodology was just too complex for me, but I have trudged my way through many other painful systems *cough* Sharepoint *cough* without much trouble, so it’s not all on me.
Me, setting up Jira
Fortunately, I have forgotten most of it, so I won’t go into too much detail (not that I could, it was a blur then and is still) but suffice to say it was tedious and convoluted.
Jira’s typical workflow dictated that we have multiple Kanban boards, one for each project, but all that did was refrigerate our project data (more on this in another post), making it difficult to ensure that our resources weren’t being doubled up between projects, and besides, it wasn’t any different to how we were using Trello.
We wanted to visualise our project stream in one view, if at all possible, so that we could work on limiting our work in progress and manage our resources better. So I ended up hacking the system slightly to achieve what we wanted, using the Epics as a Project in the Backlog view.
While it was quite klunky (yes, that is a word), it gave us a way of seeing all our projects in one screen, and from here we could build our backlogs across projects, assign estimates to tasks, see who was working on what and then build our sprints accordingly.
Only As Good As…
I’ve always said, it doesn’t matter how well thought out a software system is, it’s only as good as the people using it, and if people don’t use it, well, that says a whole lot doesn’t it?
One of the tricky things about scrum is that the methodology is predicated on one team working on one project, whereas with Brave, we have one team working on about 15+ projects at any one time. Marshall McLuhan once said, “First we build the tools, then they build us” and it couldn’t have been more true with Jira. We were forced to try and shoe-horn our internal processes around the limitations of the system itself and as soon as the going got tough, Jira got sidelined.
To be honest, I got pretty peeved when people stopped using the system every time things got a little crazy, considering how long it took me to set the damn thing up, but I realised that it wasn’t a flaw of the team (or the system, necessarily), but rather we just weren’t compatible.
I once heard a great story about a US Air Force official who visited a Soviet Air Force hangar and was flabbergasted at the chaos that the hangar was in, comparing it proudly to the pristine conditions of US Air Force hangars. The Soviet hangar marshal shrugged and said simply “this is what it is like in war-time, messy and chaotic. We are used to it, so when the madness comes, we dont freak out.” This was our experience with Jira in a nutshell, it demanded automaton-like administrative prowess which was fine in “peace-time”, but when the fog of war descended, it was all but useless.
Things get messy in war-time
Self Management For-The-Win
Late 2016 we started looking for a way out, and revisited our old love, Trello. Unfortunately, by this point we had moved on, and while we weren’t as “serious” about project management any more, we certainly had matured into a more sophisticated team. We were adopting the Teal notion of self-management with great effect, and we wanted something with a little more flexibility than Trello could give, but that wasn’t as rigid as Jira. Enter Asana.
Asana struck a successful middle ground between Jira and Trello, giving us much of the more fine-grained control that Trello couldn’t, but with a lot more freedom and flexibility that Jira proclaimed to offer, but never truly did. As I mentioned already, we had also eschewed the traditional centralised PM approach for a more self managed ethos, where essentially the team is able to use Asana as a way of keeping track rather than explicitly forcing the team into standardised workflows.
Ironically, we have gone back to one project per board, but since we have an awesome new office space, we now have a great big board situated centrally in the office that we use as a visual reference point for all the projects on the go, so we have a good mix of refrigerated (digital) and radiated (physical) project data.
So there you have it. Jira sucks, Asana doesn’t. No wait, that’s not quite fair. Jira doesn’t suck, but it doesn’t rock either. We just weren’t compatible. I don’t regret trying it, because now we can say that we gave it a good go, and it also made us realise that software doesn’t make us good, we do. There is great power that comes from understanding both your strengths and your limitations, and we realised that we aren’t as excited about administration as we felt we should be. We like things a little chaotic and messy, it’s in our DNA, and quite frankly, makes us better soldiers.