24.COM - Pre Scrum: The waterfall methodology in which development occurred sequentially, flowing steadily downwards through the different phases (like a waterfall) proved ineffective on various levels.
Lack of careful planning was a huge concern and human interactivity within the development cycle was poor. Our basic strategy at the time was having the project manager and product owner draw up a collective plan together and then establish a deadline (!) as to when the product would go live. Communication with the developers was by means of a 800 (minimum) paged technical specification which was prone to change at least seventy times a day.

From this the developers were left to delve into the coding, following the process in a top to bottom approach with very little communication occurring. In fact the only line of communication was between the project manager to the solution architect to the lead developer and then (maybe) down to the developers (normally via MSN or Skype. The waterfall methodology seemed implanted in the communicating process as well…like a bizarre case of broken telephone.

Closer to the product launch date, the PO would suddenly discover that fundamental functionalities were left out. These could range from something mundane like forgetting user authentication in forms to important functions such as bad button styling. Because of this, deadlines would get pushed out and the product re-evaluated. Developers, normally passive, would now vent and rage as their frustration at having to re-code an entire application. The spec would be re-evaluated and updated and the waterfall would commence yet again. This would happen quite a few times.
This dismal and bleak picture was, in a nutshell, our early development process at 24.COM.

24.COM - Post Scrum: The effectiveness of this framework is immediately seen: From the projects inception, everyone is involved. And by that, I mean everyone. Managers, architects, developers, designers and even the lesser-spotted, seldom seen, product owner. All of the role players and the developers, the people that are going to do the actual work are present and (keyword) COMMUNICATING.

The developers are not only communicating only in strange snippets of ampersands and clicks of code but are able to give actual feedback. They get to determine the deadline with the PO, because they know as to how long each component is going to take. There is no Hierarchy because the developers at times need to play the role of a Solution Architect as well.

In Sprint1 planning, developers are in constant communication with the PO as to what the products expectations are. Story writing occurs and the PO explains to the developers (from user perspective) what each component does and how it all fits in. There is a 360 degree conversation occurring and suggestions and ideas are thrown around. Developers commit to the amount of Story Point they will complete in a Sprint. For the first time developers are given a chance to communicate using a sophisticated mechanism to out-rival any instant messaging system: their VOICE.

In Sprint Planning 2, The developers breakdown each task that is associated to a story. The thinking caps go on and a hearty discussion ensues as to what, and how each functionality has to be approached.
At the end of the Sprint a review takes place, giving the developers an opportunity to review and demo the work that they have done this far to the PO. The retrospective is always the most interesting bit of the process. Here what went well and what can be improved on gets discussed and this continues through the project lifespan, improving the team dynamic and the ensuring the process goes much smoother.

Since 2007 when our organization adopted the scrum framework there has been huge positive changes in our managing of projects at 24.Com. I am very lucky indeed to be part of an organization that has adopted scrum and once you have been a part of scrum, the question often get asked: why have we not adopted this kind of framework along time ago? The answer is simply: We have. We simply forgot how to communicate better and Scrum exposes this. With this is mind, I leave you with the following mantra:

“To listen fully means to pay close attention to what is being said beneath the words. You listen not only to the music, lyrics or words, but also, to the essence of the person speaking. You listen not only for what someone knows, but for what he or she is.”
“Ears operate at the speed of sound, which is far slower than speed of light the eyes take in. Generative listening is the art of developing deeper silences in yourself, so you can slow your mind and hearing to your ears, at natural speed ,and hear beneath the words to their actual meaning.”