Ok, I’ll gladly admit it – I was never very fond of ”process methodologies” or any fancy way to describe how, why and when I should do my work. A little childish perhaps and probably not very professional. So there, I’ve said it.

But I never was a very normal developer. Not even normal. Or developer.

From the middle of the 90’s and onwards I went from one project to the next. Never really did what it said on my business card since I always had a weird ability to get involved in all sorts of projects across many different parts of the organisation.

For me, developing code was merely a weapon in the arsenal but not a skill that I had the luxury of dedicating myself to. The days were putting out fires or – in rare occasions – having days to come up with an urgent solution to whatever challenge ”du jour”. Once in a while a project manager would pop his/her head in and talk waterfall/Gantt-chart, everybody would nod and then go about their business.

Was it stressful? You bet (mostly benign).
Was it fun? Almost always.
Was the customer happy? Oh, heck yeah!

Did it feel good to always churn out one-off’s with next to no option of optimizing/refactoring/improving over time? Not even close – and no amount of documentation can erase the fact that quality was always the lowest priority.

When I finally got around to focus on development, that was also when I was more than ready for structure and some form of common practice. This was absent in almost all of my previous experience, except for some homegrown methods of pushing paper and blame around. No, a framework of tools setting standards, boundaries and allocating resources was what was needed – and I was willing to take anything!

And then I got in the first project a handful of years ago where I got the first taste of ”agile” and ”scrum” – oh, how it did sound good on paper and how it did feel like the right way to do web development.

So we went to work. And planned. And developed. And did the standups in the morning… for hours?! And looked at waterfall-charts. Because even though scrum sounds nice, it may be a little too much. So the organisation cherry-picked the harmless bits and left the actual working components. Like trying to get the square peg through the round hole and not noticing the obvious incompatibilities. I didn’t renew the contract when it ended.

Next project shortly after seemed much better – I was more focused in terms of technology and the organisation was really keen on scrum. Alright, my enthusiasm may have cooled quite a bit but I was still open to see if we couldn’t get it right this time. So we talked scrum. And then we talked some more. And – OMG, as the kids say – did ”scrum” go down in epic flames.

If the previous project cherry-picked from the toolbox, this was more like a hideous remix of completely misunderstood concepts with only a faint resemblance of agile. We’re talking zero definition of roles, ”scrum master” with megalomania, information-indigestion and oblivious management – a tale of good intentions going from bad to toxic in a very short while. And an obvious reminder how important the work climate is for productivity.

So once again, I didn’t renew the contract.

Fast forward to today and on to my current project. It’s fair to say that when joining X-Team I had a “love/hate”-relationship with scrum… just without the love. I was very cynical and even so it seemed incredible that it really couldn’t be done right – is third time a charm, possibly?

And then the shock: from Day 1 with X-Team, I got involved in the daily scrum, participated in the obligatory milestones from sprint startup to finish. And it worked! And I was a convert – was it really this simple? Is it really this efficient in real life and can it deliver on the promises?

I would say so, yes. And I went from being very dismissive about scrum having seen it done so wrong so often that I had almost given up hope that it could be done right – until X-Team.

Now I’m part of a big team spanning numerous vendors and our primary partner. Many different roles from backend to front-end, with operations and testing thrown into the mix – a huge potential for slow turning wheels and an ever-growing backlog.

Besides a well-planned foundation at the beginning of the project and a thoroughly trained organisation I would attribute the amount of discipline and motivation as the most important factors to the success.Discipline meaning that we try our hardest to stick to the scrum manifesto and even if we may add our ‘own flavor to the sauce’, it’s still generic enough for new developers to get accustomed to the process very fast.

This brings motivation when everybody involved can see that the project methodology actually makes our lives easier, enhances productivity and gives clarity and transparency for all. Today I’m an avid fan and added a “scrum master” certification notch to my belt not so long ago – something I had not thought possible before.

In closing, thanks for reading this far. To sum up my most important points about scrum, how to implement and how to practice, I’ll leave you with this small list.

SO SHOULD I EVEN USE SCRUM/AGILE?
Yes, definitely. It’s actually hard to do it wrong and almost requires conscious effort to eff up. That said, “some assembly required”.

WHAT ARE THE BIGGEST PITFALLS?

• Cherrypicking!
  Don’t do it. Unless you’re super-hardcore-experienced-scrum master you stick to orthodox scrum and stick hard. Do it right, or don’t do it.
• Implement without training.
  I don’t even know why anyone would do this – if you expect some sort of snake oil you’re sadly mistaken. Implementing scrum is painstaking, time consuming and hard.
• Giving up.
  So you’ve done a couple of sprints and the results are not anywhere what you expected? Management breathing heavily in the background? Pressure is mounting and action is required so scrapping everything and going back to “your old ways” could calm The Brass and get development back on right track..?
  Don’t fall for the temptation. Stay calm and scrum on. Maybe you need outside help, freeze production or something else but there was a reason you shifted to scrum/agile in the first place – it may not come instantly but it will come.

PS. Chronology and certain events have been altered for dramatic effect/to make a point/to not drag it on forever/paint with a broad paintbrush(?).