Finally Bangalore is blessed with a new airport. Few of us happened to travel from Bangalore to Mumbai on the inaugural day. While I was excited to be part of the new airport experience, I was scared that we would end up becoming victims to the chaos at the new airport on the first day. Well we really did not have a choice, so we embraced it.

The new airport is 45 Kms from the city. So we had to leave 3 hrs before the flight so that we could get there at least an hour before the flight takes off. Luckily it just too us less than an hour to get there. The airport looked beautiful from outside. It’s very nicely done. At par with most international airports.

When we reached the airport everything seemed fine. We did not find people running in different directions like headless chickens. But this joy did not last long. The most frustrating experience turns out to be a damn software installed at the airport.

Venkat Subramaniam and I show up at the airport, we are thrilled to see a checkin kiosk. Venkat and I rush to the kiosk to checkin.

While Venkat is happy and thrilled to be part of the new airport experience, the screen times out.

Venkat patiently goes thru the process again. And guess what he finds?

A touch screen. Notice we have to check the 4 check boxes, mostly meaning the same thing and there is no option to check all in one go. The funny thing is if you see the size of Venkat’s finger is equal to 2 check boxes put together. The problem is not that Venkat’s fingers are fat, but the items on the screen are so damn small. With great difficulty we click all the check boxes and then what next? Venkat and I stared at the screen for a couple of mins, we could not find any Continue or Next button. After a couple of mins, Venkat screamed in joy (or was is frustration), when he found :

A scroll bar at the right corner of the screen. With great difficultly we managed to scroll down and then clicked Continue. But I think by mistake we had forgotten to check one of the check boxes. It complained about it. (Well, they had validations.) After fixing it, we moved to the next screen, on the next screen, we entered our reservation number and finally it complained that they cannot check us in and asked us to see a representative at the checkin counter. All of this to finally go back and stand in the queue.
So what was the real problem with this software? I’m sure they would have functionally tested this software. The problem is they would have never tested it on a touch screen. It was simply not usable. This is an example of a disgusting user experience. If you find these guys, shoot them down. Such a disgrace to the software industry.

Screaming and yelling we go join the checkin queue. After waiting there for 10 mins, we were told that they had an issue. I guess they somehow heard Venkat’s talk on Agile tools and took automation too seriously. They forgot the porters. They thought they could eliminate manual labour and automate that. Turns out that they could not checkin anyone till they found some porters to lift the luggage off the belt.

Luckily we did not have any checkin luggage, so we could avoid the queue and get ahead.
Well if you live in Bangalore and have not visited the new airport, you are missing something.

Why are companies so afraid to Fail?

When I meet folks from companies, most of them want to implement Agile, but they want ready made solutions from experienced folks. Basically what they are looking for is a Dummy’s Guide to Agile Transition. They want a completed tested and proven approach (Best Practices) to adopt Agile. They want to make sure there is no room for failure.

Well I don’t really understand how can one learn new techniques/approaches without failing a couple of times? Isn’t failure an implicit part of learning? To really learn something, you need to understand its boundaries and test the waters yourself. Babies don’t learn to walk without falling/hurting themselves. IMHO, if you want a babysitter (Coach), all your life, you will never be able to appreciate and learn new concepts. I’m afraid you will learn how to be waterfall in a different way.

You could get a coach to help you avoid big failure and give a helping hand after a failure, but its unrealistic to expect that a coach will help you successfully transition without any failure. Hard learnt lessons stick around longer.

Directi has launched its first Treasure Hunt http://th.directi.com/. The target audience for this treasure hunt are the participants of the Great Indian Developer Summit. Hopefully we will come up with many more such contests to help us build a stronger community of software professionals in India.

On similar lines we are planning a series of contests focused on Software Design, UX, Testing, etc.  Watch out the Directi wiki for updates.

We have just finished with the Penn State University Project. This project was a way for me to evaluate the reverse sourcing phenomena and to make a difference to our education system by playing a demanding customer’s role for a University project. Overall I had a great experience doing this and the students really enjoyed working on this project. (I owe a separate blog to talk about the overall project, now that it is over). In this blog, I want to highlight something that I always felt about user stories but was not clearly able to articulate.

The Mystery of Shrinking Stories:

Over the last 5+ years of my experience with User Stories, I’ve seen people constantly trying to reduce the scope (size) of the user stories. (Jeff Patton has a really interesting blog about the same). Seeing this trend I’ve been frustrated a lot of time when my customer or team members don’t understand what is happening.

The problem was the stories were too granular that it was easy to miss the big picture.

Functional Areas :

To avoid this problem we started grouping the stories into functional areas. The Product Owner would identify the highest priority functional area and we used that functional area to identify our iteration/sprint stories. The developer would come up with a list of stories and tasks that fit under that functional area. (Mostly this would be done before the planning meeting). In the planning meeting we would have a collaborative session with the Product Owner to decide what stories need to go into the iteration/scrum based on the estimates. But we still had a big estimation session and then we would identify a list of stories. This clearly simplified our planning meeting, but

• The team members still did not have 100% clarity during the iteration/sprint on why certain stories made it and some did not.
• Both sides felt like there was a compromise in terms of the identifyed stories. The Product Owner might want some story but the developers would say its not possible because the estimate is high on it. The Developers might want to work on some story because it makes sense from a technical point of view, but the Product Owner did not prioritize that story.
• Also another problem we ran into was there were a lot of times when we wanted to pick stories from different functional areas. But in this approach we could pick up stories only from one functional area.

Using Themes instead of Functional Areas

We used different approaches to identify Themes.

1. First we started off with identifying a list of high priority stories and then tried to put a theme around it. This clearly did not work as well.
2. Some times we tried to identify a list of high priority functional stories and use a theme for the technical stories. This worked well when the technical debt was really high. For Example, Refactoring is a theme for this iteration/sprint.
3. Finally we asked the customer to identify a theme and the developers would then identify stories based on the theme. This was very similar to the functional areas except that now we could identify stories from different areas.

Again we had similar issues with previous approach.

Each Iteration/Sprint has a clear Goal

Finally we tried having a goal per iteration/sprint. The Product Owner would communicate the goal to the team; the theme would discuss about the goal with the PO and get their clarifications. After which the developers would come up with a list of stories that will help them achieve that goal. Sometimes they might only be able to achieve part of the goal, and then the goal will be updated accordingly.

This gave the business folks to clearly communicate what they wanted to see at the end of the iteration and also that fits into our release goal (each release had a clear goal, but before this we did not have a goal per iteration/sprint). For the developers this meant they could thin slice the stories accordingly to fit into the iterations. Suddenly developers moved from an estimation mindset to a budgeting mindset. Also from the PO’s perspective the story is really the goal, which is fairly high-level and the developers used user stories as tasks to keep track of progress and to split work amongst them. I was never a fan of tasks under the stories and this helped us get rid of them. Technically user stories (not really give by the user, written by the development team from user’s perspective) became our tasks and the goal became our user stories. This way we were able to make our stories quite large in scope (really, its one story per iteration/sprint). There is a similar concept in Scrum. They talk about Goals for a sprint, but there are multiple goals per sprint. In our case we had only one goal per sprint and we had stories under that.

What we did on the Penn State Project:

We started off with me (Customer or Product Owner) explaining them the overall vision of the project. So that, all of us has the same mental model. We used a mindmap for this. Next, I started of setting a goal for the iteration and also giving them a list of high priority stories (since they were new to the whole concept of stories). After a few iterations, I just gave them goals, asked them to email me the stories the next day and then in our bi-weekly demos, they would demonstrate each story and I would get to rate if they fulfilled the goal or not.

Some sample Goals are:

• Have at least one conference up and running
• Build versioning into the system ( This meant they had to add version each page, each artifact under the page, version templates, version the whole conference, there could be multiple conference under one site, so version all of them)
• Add template support (This means layout templates, Style sheet, include template, etc)

This has been my experience of moving away from Granular User Stories to Goals. I would love to hear your experience.

I just got back from Chandigarh after participating in the Agile Chandigarh 2008 workshop.

Vikram Dhiman did a great job of organizing the workshop. I really appreciate his initiative.

We had over 35 participants from 11 different companies. I was surprised by the level of Agile knowledge the participants had.
I ran the Waterfall to Agile demo followed by Agile Overview presentation. After this, Vikram gave a great presentation on Agile Myths. The last presentation of the day was from Rajesh. Rajesh spoke about the role of a manager. Rajesh was just introduced to Agile by Vikram a couple of weeks back. Rajesh has been doing Management consulting for the last 15+ year and he was happy to see that Agile is embracing what he calls “Common Sense” management.

Vikram will upload all the slides soon.

Thanks to all the participants and organizers. I wish more people take up initiatives like this, so that we can spread the agile awareness faster and move up the value chain.