Scrum in the Real World

Written by Mark Hillyard
@BeyondMark

I have been working in an agile environment, in one way or another, for over a decade. I was not always aware of this. I am not sure my company was aware of it either, at least not for the first few years.

It started with very tight development cycles. We were expected to release fully functional software in six-week increments. Granted, that is longer than what Scrum suggests, but at the time, it felt extremely abrupt. But we adapted. We became the masters of release-fix-release-fix ad infinitum. Our customer base developed a love-hate relationship with our methods. Initially, our developers put out very buggy code that was fixed, in production, over the course of the first few weeks of a systems existence.

Over time, as we grew and became more well known, the tolerance for bugs diminished…rapidly. Our development teams once again had to adapt. They began to plan better, promise fewer features for the initial launch, and add those bells and whistles in the first few production updates. They stopped developing in production (something that I, as a SysAdmin, welcomed with open arms). We began to communicate more openly, which was a substantial departure from my first few years there. Soon, we were able to release completely new platforms in 3-4 weeks. Functionality was added rapidly, what few bugs were found were quickly captured and remediated. Weekly planning sessions began to happen, not because management demanded it, but because we found we could be more efficient if we discussed what was being released that week, and what the operations team could expect from the developers (and vice versa). Suddenly, we were practicing agile without having really discussed doing it. A lot of the development teams leaned toward Kanban, or at least a modified version of it. Storyboards popped up as websites, we even sent some development managers to conferences to learn more about it. But at the core of it all, we had gotten there on our own. It didn’t really occur to me just how much our development and operations teams clawed their way to agile efficiency until after I had left. As I reflect on my experiences now, I am very proud of the legacy that those first few, pioneering developers established.


Interested in how Scrum & ITSM can work together?
Our free ebook covers that very ground.


Now I’m on the development side of the house. My job is about designing and implementing enterprise software for companies large and small, and we have worked very hard to maintain an agile approach to everything we do. All of us have taken courses, gotten certifications and researched how to implement Scrum, and we have adapted much of the framework to our core business: ITSM process improvement. Every weekday morning, I have been a part of a daily Scrum. For most of my time here, that call has taken place at 5:15 (6:15 when the rest of the U.S. comes to their senses for a few months every winter and fixes their clocks). That daily call has evolved and changed many times over. It has not always resembled a daily Scrum as most would recognize it. As many times as we have, as an organization, decided to really follow the framework, we have come up short. Not for lack of trying. I think for us, it has always been a challenge because of our often competing schedules, and our always wildly disparate geographic proximity. Ours has been a struggle between sharing our daily workload and trying to solve problems in 15 minutes or less. Which, for the record, is no picnic that early in the day. For the whole of this year, my team has expanded even deeper into the agile mindset. We have organized our development into two week sprints. There are planning sessions, reviews and retrospectives. We have officially declared a Scrummaster. And it has, along with more than a little frustration, made us much better at what we do. Sometimes it seems like we meet way too often, and for too long when we do meet. Retrospectives, while helpful, seemingly take an eternity when there is work that could be getting done. But we are better for it. Each of us is accountable for our work. It is not perfect. Plenty of time is stolen by high priority items that are not a part of the current sprint. We continue to grow and adapt. We continue to improve.

When I took my first class in Scrum, I thought it was both brilliant and completely unrealistic. I had a lot of trouble grasping that this was how a successful organization should operate. I was still stuck in the old school of thought, of waterfall releases and 6- 12- even 18-month development lifecycles. But the truth is, none of us can afford that kind of mindset anymore. If I tried to develop anything over an 18-month period, by the time I completed my work, the technology would have changed, improved or completely vanished from the industry. My product would be obsolete months before its initial release.

The reality that I’ve come to recognize, and the framework that I now fully embrace, is of iterative improvement. My work, my progress, even my own personal projects outside the office, have become blocks of weekly releases. It doesn’t always work the way I wish it would. We aren’t agile 100% of the time. But we are getting there. And I am so much the better for it.

Originally published June 06 2015, updated January 01 2019