Select Page

I spent a fair bit of my career as a developer with an eCommerce Service Provider in Toronto, Canada.  Our flagship product was a homegrown proprietary eCommerce platform, which for years successfully supported the needs of a number of major online retailers with FTD, Lucasfilm, Warner Brothers, and Newline to name a few. During my time there, I learned a great deal about what goes into building and maintaining scale-able, eCommerce websites like Starwarsshop.com; and this I did by having to survive the onslaught of thousands of nerds (including myself), simultaneously clamoring to buy their very own Darth Tater online.

Focusing on our software development methodology however, a couple of issues routinely surfaced as part of almost every new implementation:

Lack of Team Involvement

First, we, as developers were never involved with a project until an official “kick-off”.  As part of this meeting, we were provided the predetermined estimates for the project as well as our delivery deadlines for each major phase.    At a high level, there were only 3 major dates on these “project plans”:

  • QA:  When the project was expected to be code complete and delivered to our internal Quality Assurance team for testing
  • UAT: When internal testing was expected to be completed, and the project delivered to the client for their own testing and approval
  • Launch:  When the project went live

Of course, there were other minor milestones scattered through the plan, but it was this triad of dates that were the focal point of our delivery.

Where these dates and estimates came from did not matter;  what was relevant was that none of us plebes, the poor souls actually doing the work, had any involvement or input into the next few months of our professional lives, and as we all gazed blankly at the PowerPoint decks our overlords were using to try to get us excited about the project, we all knew that another death march had likely begun.

Lack of Client Involvement

Second, clients never got to see any real output or progress for their project until the User Acceptance Testing phase, which was typically at least ¾  of the way through our timeline.    Following weeks of late nights and gallons of caffeine-laden drinks, we’d end up delivering a half-baked version of the website to UAT for client-testing, usually along with a series of caveats just to let them know that we actually knew about all the things that were missing or not working.   This was when the real fun began as untested integrations that were ‘built to specifications’ failed, clients realized that the wire-frames and mocks they had spent weeks of time and money on, didn’t in practice translate to a good user experience, etc.

As an organization we’d always eventually work our way through our problems,  launch the finished product, spend weeks repairing the relationship with the client, and eventually move on to the next project.  It was always as battle-scarred warriors however, the worse for wear, and with resolutions to learn from our mistakes destined only for /dev/null.

This pattern was the “modus operandi” for the company for quite some time.

It was in 2008 that through a colleague I was first exposed to Scrum, and two things immediately caught my attention:

Team Involvement

Scrum is about the early and continuous involvement of the members of your development team (yes, all of them) in the collaborative solutioning and estimation process of software development projects.   By virtue of this, team members are engaged, have input in the project, and have some proverbial “skin in the game”.   By-products of this are better estimates,  higher quality software, and a level of commitment and engagement from team members that is much harder to achieve given traditional frameworks and development methodologies.

In a properly executed Scrum implementation where team members are involved, they:

  • … collaboratively provide solutions to problems, not just do what they’re told
  • … estimate solutions and are not simply told told how long tasks will take
  • … find ways to improve the quality of their  work without accepting the status quo
  • … take ownership when issues arise
  • … follow through with their commitments to get things done

If none of the above apply to your team, there’s a good chance they are not engaged and whether you think you are or not, you are most definitely not running Scrum.

Client Involvement

Given Scrum’s iterative nature and its goal to reach a Minimum Viable Product quickly, clients and stakeholders (aka Product Owners) are exposed to a working product early in the project life-cycle and are able to progressively see their vision take shape layer upon layer, sprint after sprint.  With regular demonstrations of working software and the opportunity to provide feedback which is incorporated into the team’s backlog, clients are engaged at a very high level with the project.   This framework is deal for avoiding major surprises, and mitigates risk factors early in the development process.

In an effective Scrum implementation, clients:

  • … participate in reviews/demonstrations of  features every sprint, and are encouraged to provide feedback
  • … are actively involved in grooming the team’s backlog of work to ensure the highest value items receive top priority

If these are foreign concepts to you,  then you are not practicing Scrum.

 

Scrum was a revelation to me.  Now, a Development Manager, but having spent a number of years toiling as a developer in an environment where I felt I never had a true voice,  I quickly gravitated towards it and along with a few like-minded allies began vocally challenging the “old” way of doing things.    Progress was slow and arduous.  Despite our appeals, we never had the kind of buy-in required from the top brass of the organization to make real change happen.    Things came to a head in 2011, with the company in real financial trouble and a key relationship with a critical client deteriorating rapidly.   With just cause, the client was tired and fed up with missed deadlines, poor software, and not having a realistic idea of where we stood with respect to any of our committed delivery dates.    Under our traditional delivery model, project manager after project manager had been parachuted in at various points in the project, but inevitably, without a real framework to operate in, they failed.   It was obvious that unless there was major change in the way we delivered software, the client, and most likely our company along with them, would be lost.  It was at this point that we finally got buy-in and an active commitment from our executive management to officially pursue Scrum.

Suffice it to say that our path forward was not easy and involved many difficult discussions and hard work.  It took time for us to convince the members of our development teams that the company was trusting them to be more than proverbial “grunts” and that it needed their help in guiding the project to success.  And likewise, we had to regain the trust of the client by showing them regular, bite-sized victories on a consistent basis.   Slowly but surely, however, things changed.   Team members bought into our new approach,  morale improved, software quality improved, and along with these, our deliveries became consistent and predictable.   The client began to see real value delivered on a bi-weekly basis as part of our sprints and over time, we saw an incredibly encouraging and validating change in their attitude as they shifted their focus from the rapidly improving immediate state of affairs to the growth and expansion of the platform we were building them.

Alas, the story doesn’t end with a remarkable recovery, a flood of new clients ready to sign multi-million dollar deals, and most importantly, my comfortable retirement on a tropical island.   Despite the dramatic improvements within our culture and organization,  the vicious arm-bar of technical and financial debt brought about the company’s inevitable tap-out some months later.   But, all was not lost.   Based on performance, our now-happy client and the development team responsible for it’s turnaround were acquired by a 3rd party,  and even now, five years after introducing Scrum,  still practice it and still remain a profitable and valuable endeavor.

 

If you are experiencing the issues outlined earlier,  I would encourage you to take a close look at the level of involvement of your teams and clients.   Are your development teams active and continuous contributors to your software projects?  Are your clients receiving regular demonstrations of what the team has built and are they continually involved in shaping the product you’ve been tasked with building.   If not, then you should consider Scrum as an option.  It really does work.