April 24, 2012

Are you settling for mediocre solution?

"This is just an Intranet application"
"People would hardly use this feature"
"There will be only less than 100 users for this site"
How many times have you heard such arguments during discussions. I have heard similar comments many times and have also made such comments myself. I have just realized that I had been convincing myself with these arguments to settle with mediocre solution for some of the "interesting" problems.

There is one particular requirement in my recent project where I faced similar situation.

Initial approach:

We came up with some sort of a "conventional" solution to address a requirement. This approach was not very clean as it had couple of issues
- We were violating the general rule of the site to support browser back/forward actions
- We were using URL query param to hide/show few links
Even though we had these issues, I was convinced with the solution and wanted to go ahead with that. I had "strong" reasons (read as excuses :) ) for the same.

Reasons (Excuses):

  1. This application doesn't deserve "advanced/complex" features / This requirement is unwanted: This project has only 100 end users. We don't have to spend much time on building this "advanced/complex" features just for these users. I am not convinced yet that this requirement is needed.   

  2. Just enough design/This is an exceptional case: The conventional solution for this requirement works and we don't have to spend much time on this. We can violate the back/forward support for this requirement as it is an exception case.

  3. Story points: It is only a 2 (S/something) pointer and we can't spend much time on this story.

  4. This scenario would never happen: NO user would be performing these sequence of steps (Even though I don't have any metrics to support this claim)

But,
Luckily in my project, all mediocre/conventional solutions were challenged and the team was not convinced with my reasons. We had to come up with a better solution.

When we spent a little more time without thinking about excuses, we were able to come up with a better/cleaner solution. This out of the box solution met all our requirements and also made us feel good about. All it required was that little push from others and a little time to overcome the mediocre solution mode.

Now when I look back at my "strong reasons", everything seem to be flawed:
  1. I could not see the difference between unwanted feature and differentiators. Without these features (related to usability), our site would end up being mediocre. It would not be able to get more users on to the system.
  2. Looks like my notion of "Just enough design" also had "taking exceptions" for granted. In this particular case, I had already convinced myself that this requirement can take exceptions (like not supporting browser forward/backward) without exploring some more possibilities.
  3. Story points are just a metrics to track progress and it should not be used for killing innovation/thinking out of the box.
  4. I think, I had made up the "scenario would never happen" argument to support my "this is an exception" argument.

Lessons learnt:

Mediocre solutions come into existence only by convincing ourselves that it is the right thing to do in THIS  case/application. All it needs is a little more time to come up with a better alternative.
Team members should be constantly challenging each other on mediocre solutions in order to build a great product. It also helps the team to improve their technical and problem solving skills.

Are you coming up with excuses or a better product?

April 23, 2012

Physical card wall is injurious to health

...of the project.

Don't get me wrong, let me finish it. Only if your project uses ALM tools and physical wall at the same time.
NOTE: ALM tools - Agile Lifecycle management tools (like Mingle, Version One, etc)

Physical Wall Vs ALM tools wall


We are not getting into this argument right now. By now most of us would have used both and know the pros & cons of each. Personally, I am OK with any one of these.

Physical Wall & ALM tools - Hybrid approach


This is where I have a problem. In most the projects I have worked on, we have used this hybrid model. We would use ALM tools to create story, prioritize and for discussions with client but use physical wall to track the progress of the sprint/iteration.

Issues (I faced) in this approach

  1. No single source of truth: Few things would be up-to-date in physical wall but not on the tool and vice versa. Consider this case - You find that a story card is 'In Dev' lane in physical wall and 'In QA' lane in ALM wall. Does this mean that:
    • Story is 'Dev complete' and moved to 'In QA' by dev in ALM wall but not on Physical wall.
    • QA found a bug and moved the story back to 'In Dev' in physical wall but not on ALM.
    We cannot be sure and usually we end up chasing the team members working on the story for "correct status". Is it worth maintaining two walls?

  2. Duplication of effort: Duplication is painful even here. Imagine that you just did your team sign up on the physical wall. How motivated would you be to update the exact same information on the ALM tool. So you can't complain the team for not having things in sync.

  3. ALM Tool is not a boon anymore but a burden: In most of the teams I have been, it is a burden for few individuals (like PM, BAs, sometime Devs) to keep the ALM tool in sync with the physical wall. A tool that was supposed to be helping the project becomes a burden.

  4. Invalid metrics: ALM tools provide lot of useful metrics that can be used to track the project and make some useful decision. Since the tool is not used properly, metrics provided is also invalid.

  5. Wrong/Incomplete status on the wall: One of the projects I worked on had distributed team members. The physical wall in offshore would have only the stories that are worked on by offshore team members as it was hard/painful to track the cards worked on by onshore members. This wall was actually projecting wrong state of the project to everyone. It is better not to have such a wall than to have with wrong/incomplete information. (In this case, we stopped having the physical wall)
And there are few more...

It is hard to convince everyone and remove the physical wall from a project team that is used to having it.

Arguments in favor of Physical wall

Here are the few arguments that I have faced in favor of Physical wall:
  1. I am used to doing signups and track things on Physical Wall
  2. I prefer to physically feel story cards than rely on software tools.
  3. Physical wall can promote more collaboration within team.
  4. I have to click through 100 links to get the information I need in the ALM tool.
  5. It is easy to refer to physical wall and get any information almost immediately. I don't want to login to ALM tool every time.
  6. I prefer Physical Wall over ALM tools, it is simple.
  7. It just takes couple of minutes to sync both tool and physical wall. Why do you bother?
  8. Physical wall is an information radiator. Anyone walking-by can know the status of the project
  9. Last but not the least - There are other major issues in our project. Can we look at this later? - :( YOU CAN NEVER FIND AN ANSWER TO THIS.

My take

I could find convincing reply to the above questions except the last two:
  1. Reality: ALM tool has become a necessity in most of the projects because of the benefits and flexibility it brings in. Also, physical wall is not an option for a distributed team. It is the reality and you can't escape from ALM tools in many cases. 

  2. Single source of truth: As discussed in the issues section, we all love to have single source of truth than to end up with conflicting information.

  3. Personal preference is not an option: I can't introduce a new language or a framework into a project since I am comfortable in using it. When we are working as a team, we discuss the pros/cons and decide on one tool/language/framework. If ALM tool can't be replaced, try to embrace it rather than fighting it and maintaining a physical wall. 

  4. Other benefits does not outweigh the issues: Few people claim that physical wall improves collaboration and some of them prefer to see stories as physical cards & track it through different lanes. On the collaboration part, I am not sure whether there is any fact to back this but I think ALM walls can also have the same effect. On the second benefit, most of the ALM tools provide standup / dashboard view, that mimics the physical wall. Even if we assume that the above benefits cannot be met with a tool, these are only side effects of a physical wall and it would take a back seat considering the issues it brings along.

  5. Access to information immediately: Most of the ALM tools have long user session time, so we can keep a tab open in our browser(just like email/facebook) to refer whenever we need any information. So we can get necessary information in a click instead of the need to login everytime.

  6. ALM tool usability (100 click syndrome): It would take a day or two to get used to any new tool. Most of the product development companies would have usability experts to make the interface as easy as possible to stay in business. If we could just spend that short time to get used to the tool, we won't be exaggerating and complaining about "100 clicks" needed to do an operation in ALM tool.

  7. Information radiator: Like build monitor, if each team can project their card wall on a monitor, it would still act as an information radiator. Even though this cannot exactly replace the physical wall, it is a trade off decision we have to go with to see the benefits of using just the ALM tool.    

  8. And last, Does it really worth it: When you can get all the information that is needed from ALM tools dashboard/standup wall, why do we need to replicate the information on physical wall?
Even though we were able to try without physical wall successfully in a small team, I was not able to try it in my 20 member project because of the last argument(10 - Other issues take priority). But I would definitely try it in future.

You could help in refining this by sharing your comments, views and experience. Also, it would be great if you shed some light on how you overcame the issues in the hybrid approach I mentioned earlier.