I recall a sunny day on a terrace, at a wharf on one of the city islands of Amsterdam. Holding a book called Project Management with Scrum by Ken Schwaber, I was about to discover about the way of working I grew to love so much.
The Scrum framework is lightweight, and easy to get started with. But it is not something you “just do” starting day one. Instead, it is something that your team or your organisation can become. This is extremely challenging, and hard to get right. It demands a culture of brutal transparency, and if missed, this can cause your organisation to half ass the adoption. On the other hand, its empirical and iterative character shows forgiveness to those who really want to learn by doing. This is about learning how to deliver value to the client each iteration, and learning what the best process is to achieve that every iteration. This is also what is the essence of Scrum for me.
It demands a culture of brutal transparency, and if missed, this can cause your organisation to half ass the adoption.
It was 2009 when I first read Ken’s book. At that time, I was working on contracts as a requirements analyst on various e-commerce projects. I also tried project management in that area, but I decided to leave that behind me; too many failed attempts to achieve fixed goals at a fixed price, in a fixed time frame over too long a horizon. Many of the projects ended in exhausted team members, bullying managers and disappointed clients. For me it seemed to be the inevitable reality of software development. That was until I read Ken’s book.
Though not common practice as it is today, Scrum was already quite a phenomenon emerging at the horizon of software product development. As soon as I started reading the book, it was as if I was given the perfect explanation to all the misery I experienced in my past projects. At that moment my key take away of the book, was that our traditional way of developing software products didn’t account for the most important factor in its success and failure: the human being. It also taught me about our limited capability to create practical order out of chaos for any periods longer than a month. It taught me to respect those who do all the legwork, and how shielding a development team from daily interruptions is the work of a hero. It taught me about focus, and the power of commitment to that focus. I taught me how work is useless if the result is not subjected to inspection at regular, short intervals. The book spoke to me as the herald of the change that would relieve us from the suffering that is traditional software development.
It taught me to respect those who do all the legwork, and how shielding a development team from daily interruptions is the work of a hero.
Little did I know how difficult applying Scrum would prove to be. Not long after I read the book, I was given the opportunity the fulfil the role of Scum Master for a team working on the replacement of an e-commerce platform. Their current Scrum Master had fallen ill, and the project manager trusted me with the task. We didn’t think it was very far a stretch from the role of team lead. Right? Well, at least it was a great opportunity for me to try out this new role and framework.
Unfortunately (depending on how you look at it) it took us only three sprints to find out that Scrum was something the development team was only allowed to do, as long as management could make us adhere to the strict set of agreed requirements (i.e. just rebuild the old thing with new tech), set budget and delivery date. We weren’t expected to deliver working increments of software product that delivered value to a changing organisation at all. We were expected to build a thing they already had! And most importantly we weren’t doing it fast enough. No learning needed, no inspection allowed. Period. It was needless to say, that Scrum was soon to be scrapped, in order to meet strict deadlines and scope in this straight rebuild.
We were expected to build a thing they already had! And most importantly we weren’t doing it fast enough.
Although my first taste of Scrum was a disappointment, it was a first taste of the fun and hardship I was to have over the coming years. Since that first opportunity I decided I wouldn’t let a chance pass by to get a grasp on this freaky framework and that cool Scrum Master role.
It has been 10 years now, and it has taken me that long to begin to understand what Scrum really is, and how it helps organisations shape themselves to become better at learning how to build valuable products. Yet still, after all these years Scrum still surprises me with the silly simplicity it demands to battle needless complexity. During those years I came to love the role of Scrum Master, and how I can teach teams and organisations to face the chaos. Creating little pieces of order, to locally reduce entropy, and create beauty in function and structure. I just love it!
Using Scrum as it is intended demands transparency through inspection, but offers forgiveness in its iterations. It demands courage, but offers respect when it is shown. This doesn’t just involve Scrum Teams, but the entire organisation it is part of. At my start as a Scrum Master ten years ago, I had no clue of this. Many sprints and projects later, bruised and battered, but strengthened and with some trophies on a shelf, I feel more committed and courageous than ever.
Do you want to be courageous, but need some help? Do you think Scrum is the way forward for your organisation, but are you struggling to make it work? Just drop me a message, and we’ll see what’s holding you and your organisation down!