A Day in the Life of a Scrum Team

Credit for this video goes to my good friend and co-worker Najati. We need to make a new one when we move to the new space!

Agile software development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability throughout the life-cycle of the project. It chooses to get things into action quickly, rather than to plan at length. The plan evolves as actions are taken.

Like more developers out there, I've always worked in a traditional "Waterfall development model".

The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance.

I started working on this project about a year ago with no idea of what "Agile" meant. I didn't even know there was another way of doing things. I just knew deep down that there was something terribly wrong with the existing process. I have worked on other large scale projects that involved about a dozen developers, a handful of project managers, requirements analysts, documentation specialists, segregated QA specialists, "imaginary" clients (we never saw them), endless and often meaningless meetings. Those were the days when I would come to work shying away from all human contact, hide in my little wired prison, do the standard 15 minutes of actual work per 2 hours, and sneak away in the afternoon hoping the clueless PM wouldn't bug me about coming in to work on the weekend because he couldn't properly prioritize the project. And I don't blame the PM for being clueless. I was clueless. Just about everybody on the project was usually clueless. But it was nobody's fault. It was simply "the process" that was broken.

Within the first week of going to BusinessWeek and working on this new project, I felt something totally different. I actually ENJOYED coming in to work. I still enjoy it. I like, no I LOVE, what I do. What do I love about it? Here's a few things that come to mind:

• No more 100+ page requirements. So how do we know what to do or what to work on? We have single page "user stories", with the product owner close by at all times to answer any questions if need be. I personally HATE to read lots and lots of detailed documents. I much rather sit with someone and talk about a feature.
• I don't work in a cubicle. I don't even have walls around me. What IS around me? PEOPLE. Smiling, talking, breathing, smart and very talented people. Tear down those walls! (We literally tore down the cube walls.)
• Short and meaningful meetings. There are only about 2-3 meetings that are required and we actually look forward to them most of the time. 1) we meet once a week to estimate new "stories" to work on. We give the product owner an idea of the difficulty of the story so that he/she can prioritize it accordingly. 2) we commit to a number of stories to work on for the next 2 weeks (called an iteration). 3) we have "retrospective" meeting once every 2 weeks to discuss the ups and downs (or opportunities) of the previous iteration. This is an opportunity for the members of the team to reflect on the last two weeks, identify problems and commit to resolving them.
• Communication. We are a loud bunch. We are constantly talking to one another. To product owners. To project owners. Even to our clients. Communication is encouraged and most of the time, unavoidable.
• Our Scrum master! What is scrum, and "who's the master!" you ask? I'll let mr. google answer the first and I'll just say that our scrum master protects us form the "outside" world in terms of the project and allows us to focus on the work at hand. We rarely get distracted by last minute requests coming from higher executives. We very rarely go to meetings that we don't need to be in. We basically don't have to deal with a lot of "crap" for lack of a better word. Not that the "crap" isn't important, it's just not important to us when we're "in the zone". Distractions are very costly, and the Agile process understands this. The scrum master is there to enforce this distraction rule and deal with the "crap". Thanks scrum master!

I can go on for days talking about this great process and how it has made "work" so much more enjoyable, but I will stop here. In conclusion I'd like to say that personally for me, it has been a tremendous experience working on this project while utilizing the agile/scrum process. It has truly made me an advocate of the philosophy behind it and I hope to spread the word by blogging about it.

In future posts, I hope to share some of the cool "technological" wizardry of the BusinessWeek Business Exchange. The site is currently in the "alpha" phase and soon to be made available to the public in a "beta" mode. Once that happens, I intend to highlight some of the cooler features and maybe create some tutorials and what not. So until then, keep an eye on http://topicexchange.businessweek.com/, as the site may go live sooner than you think!