Get Into This

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!

Due to the Transit strike, I decided I should try walking to work from Brooklyn. I mean, people ride their bikes from BK to Manhattan all the time, how far can it really be? I left my house around 10:15 am, stopped at a local deli and got a nice egg, ham and cheese sandwhich and started my little journey across the Williamsburge bridge with my roommate. 20 minutes into it and my lower leg muscles were starting to hurt a little bit. I think it was because of the uphill climb to the arc of the bridge. Once we passed that part, I was totally fine. Two hours later and I finally made it to work. All in all not a bad walk.

This brings us to Wayfaring.com:

With Wayfaring.com you can explore maps created by others, or create your own personalized map. Share them with friends or the whole world.

And that is exactly what I did. I signed up, which took about 2 minutes and started to create my own custom map. This is a feature that I REALLY wish Google maps had already. Being able to plot multiple points on a map is a really nice feature. Being able to plot out a whole route and share it with the world is even cooler. I think this is a great service and very easy to use. Here is the map of my transit strike journey to work from Brooklyn.

A group of about 30 web startups have put together an initiative called the Structured Blogging Initiative, in an attempt to bring some order and standardization to the blog-o-sphere. What is their meaning of structure? According to the site:

Structured Blogging is a way to get more information on the web in a way that's more usable. You can enter information in this form and it'll get published on your blog like a normal entry, but it will also be published in a machine-readable format so that other services can read and understand it.

Think of structured blogging as RSS for your information. Now any kind of data - events, reviews, classified ads - can be represented in your blog.

Structured Blogging makes it easy to create, edit, and maintain different kinds of posts and is very similar to an edit form on a blog. The difference is that the structure will let users add specific styles to each type, and add links and pictures for reviews.

This opens up a whole new world of collaborative sharing of information, beyond the boundaries of what is possible and available right now. Imagine blogging about the sale of your 1949 Ford Mustang and having that information automagically posted up on multiple forums and picked up by specialized search engines (like technorati) that search blog sites, but being able to filter your search by model, year, price, etc. Another quote from the site explains it:

Using Structured Blogging, job listings can be created, posted, searched, and found by any service; buyers and sellers of goods can publish what they want to buy or sell and have those posts searched and listed by any number of search services.

Visit the Structured Blogging site to read more

A list of ten things to keep in mind if you are considering a web startup. Here's a sampling:

#5: Be User-Centric
User experience is everything. It always has been, but it's still undervalued and under-invested in. If you don't know user-centered design, study it. Hire people who know it. Obsess over it. Live and breathe it. Get your whole company on board. Better to iterate a hundred times to get the right feature right than to add a hundred more. The point of Ajax is that it can make a site more responsive, not that it's sexy. Tags can make things easier to find and classify, but maybe not in your application. The point of an API is so developers can add value for users, not to impress the geeks. Don't get sidetracked by technologies or the blog-worthiness of your next feature. Always focus on the user and all will be well.

[source: evhead.com]

Jason Fried of 37signals mentioned a great book on their blog today. I read the recommended pages (pages 1-6 and 61-64) and I have to agree that the book seems very interesting. Definitely adding this book to my wishlist!

[source: 37signals]