Get Into This

Here's a fun video from last winter ... when the project was still young and we were all getting used to the Agile way of working. Almost a year later and things haven't changed much (in a good way.)

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!

So the news is finally out, and people are starting to talk. For about the past 2 years, one of which I have been intimately a part of, Businessweek has been thinking up and developing the "Topics Exchange". I won't bother going into the details of the site and what it is, as other sites have already done this. What I want to touch upon here is the process which was used to develop the site. Namely, the Agile Process.

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!

So how hard can it be to find the "payment" option on the DMV site to pay for a violation? Well, how about I let you try for yourselves and see how long it takes you. I swear it took me almost 30 minutes just to find the page with the little credit card icons on it, and that wasn't even the page with the form to fill in your info.

I don't know who designed that site or decided that they should fill all the pages with endless ramblings, but I would really love to know if they've ever used the site themselves. It is the most useless piece of crap I've seen in a long time. Why is there so much text explaining every little detail that I nor anyone else cares about. Just show me a damn form to fill out, take my money and leave me alone!

the letter I received in the mail instructed that I had to make a payment within 30 days or my license would be suspended. The letter said that I had the option to pay online and the only link that was provided was the following:

http://nysdmv.com/drp.htm

Ok, are you ready? Click on that link and try to find the credit card payment page. Go go go! and good luck, you'll need it!

Update 10/13/2006: Put in a flag to check when an image is being swapped so that the user clicks don't register until image has fully loaded. This fixed the fast-click / double-click issue (on both the thumbnails as well as the back/next links)

Also updated the mouse hover area for the thumbnail activation to be 25px from the top by default (used to be 50). This is ofcourse configurable. I will have full explanation on how to use the gallery soon.

Demo page has been updated. You may also grab a zipped up version of the whole project here: gallery.zip.

I'm been playing around with jQuery a lot lately. It's definitely not the holy grail of Javascript toolkits, but I like it. The community created plugins and the documentation are great.

Anyway, here is my second jQuery application/plugin. It's an image gallery with smooth transitions, thumbnails and pretty reflections. Of course, this is the first version (something like a beta) and definitely not ready for prime time. However, feel free to grab it and use it as you please. A link back would be appreciated.

Just so that I can display the gallery here, I've put it within an IFRAME. Visit the original page to view/grab the source.

note: the IFRAME is causing some weird effects on the mouseover on the image as the thumbnails are loading. This doesn't happen on the actual demo page.

Update 10/17/2006: As requested, I've added two new arguments to the menu that will toggle the hide on page load (hideOnLoad) and also toggle the autohide (autoHide) when the mouse leaves the menu area. The 2nd argument is only useful when the triggerEvent is set to click or dblclick

Update 10/21/2008: As a request from a reader, I've modified the code a little so that setting loadHideDelay: 0 and hideOnLoad: true will cause the menu to be hidden on initial page load. Click on the menu below to see it in action.

Update 03/04/2009: Decided to upgrade to the latest version of jQuery (1.3.2) and rewrite the code using jQuery UI instead of the Interface plugin.

Here is my first jQuery plugin. It is a very simple sliding menu using the effects provided by Interface (think Script.aculo.us for Prototype). Now using jQueryUI for sliding effect.

I really like jQuery. I also really like Prototype and Script.aculo.us. I've come to learn that each one has its strengths and weaknesses and you should decide which one to use based on your needs. I use them both, depending on the project at hand.

Here's an example of the menu in action (click menu label). This particular menu has the following options set: triggerEvent: 'click', hideOnLoad: true, autoHide: false, loadHideDelay: 0

The defauly behavior of the menu is to hide after 1000ms (1 sec.) and to display when your mouse hovers over the "menu" label. The menu will also auto-hide after 1000ms when the mouse leaves the menu area. Most of these values, including the sliding effect, can be customized.

Visit this example page to view the source and see how to use the menu and customize it. I haven't provided alot of documentation on it, but the source code is pretty self explanatory.

required files:

• jquery-1.3.2.min.js
• jquery.ui-1.7.min.js
• rb_menu.js