Simplicity is the most difficult thing to accomplish

Recently, I read an interesting blog by Jason F. of 37 signals fame on simplicity. He wrote “the dirty little secret about simplicity is that it is most difficult to achieve”. I couldn’t agree more.

I still remember the time when we created about 30 odd variations of User Interface concepts for Ajeva. Each time, when the concept would be ready to be presented to the team, we would discover things which can be further improved or elements which can be eliminated. As we progressed, the process would be more of elimination than adding anything new. The more we thought about making the user interface usable, user friendly, the more we eliminated. We would organize and then re-organize and then again eliminate and then start over….

I do realize now, why many people come to me and appreciate Ajeva and its simplicity. What we finally got an outcome in Ajeva was a very simple and usable user interface which people would find friendly and easy to use.

Now I understand how ‘complex’ the process to attain ‘simplicity’ could be. A considerable amount of focussed thinking goes into making things simple.

Thanks Jason, for putting this up…it really made me look upon my work and appreciate every single interface that was rejected. Simplicity really is the most difficult thing to accomplish.

Whats your experience with simplicity? Do let me know your views, experience and insight.


My Experience with scrum and why it is such a great methodology

Scrum is now a buzzword in Software Development. When I heard about Scrum initially, my natural reaction was :  “oh okay….here comes yet another idea to develop software”.

As I started reading more and more about Scrum, I kind of got addicted to the way it changes the whole paradigm of software development. We got opportunities to implement it for a few clients and so here is a summary of my experience with Scrum:

1. Scrum is Software Development done backwards

Yes! that’s what I really mean. In scrum, the requirements are presented as an end result. For example, “As a guest user, I should be able to sign up”. Now, once the developers are presented with the end result, they start working backwards to achieve that. Everything starts from that point. No wonder why results wouldn’t be great.

2. Scrum focuses on End Business Value

In scrum, user stories are created keeping in mind End Business Value. As a result, client requirements becomes very specific. Since scrum forces to think from an End Business Value perspective, less important items weed out automatically.

3. Scrum is about daily success

In Scrum, practices like stand up meetings, small iterations and frequent feedback allows the team to achieve small goals daily. In no time, these smaller goals sum up into big achievements.

4. Scrum is about measured progress

For many of us in Project Management, when introduced to Scrum initially, we thought it would be a cool way to get away from likes of Gantt Charts and Critial Path, is’nt it? 😉 …Well, thats not the case.  Scrum does have something similar but the good news is that, it’s done very smartly. In Scrum, the project progress is measured in ‘Velocity‘. And since this is the most interesting part of Scrum, I would like to explain it some more:

In Scrum, every User Story entered by a customer is estimated in terms of ‘Story Points‘ by the development team. Story Points is relative estimation of a User Story based on complexity of that story relative to other stories. For Each Sprint (read milestone),  the team takes up User Stories with a goal to complete ‘X’ SPs (story points).  After 1 or 2 Sprints, the team knows how much SP’s it can finish in a given Sprint. The measure of a Team’s efficiency in acheiving software goals is termed as ‘Velocity‘.  Once a team knows it’s Velocity on a Software Development project…it becomes extremely easy to product features and shipment dates.

There is a lot more to Scrum than all this…I would rather let you explore it over the web. Here are some useful resources where I learned by baby steps in Scrum:

You Tube Video

Scrum Estimation at Agile Software Development

I would like know your experience on Scrum. What did you find out about Scrum and what have you learnt?

Wish you Happy Project Management with Scrum!

Choosing the right vendor for your next software development project

Your Business plan is ready, investors are convinced and you are kicking with energy and enthusiasm. And there comes the  task of choosing a software development team. It does get tricky…is’nt it? With multitude of options, it is easy to get carried away and make a wrong choice.  Some immediate questions that can tease you are…

  • Should I choose a freelancer team or an organization?
  • What kind of vendor should I go for, jack of all OR master of one?
  • What is the specific domain knowledge that my vendor needs to know (so I don’t have to waste my time spoon feeding) ?
  • Is the Vendor reliable ?

Inspite of online marketplaces like Elance and Odesk providing a detailed profile, rating and feedback history of vendors, it is imperative to make informed choices rather than purly relying on the numbers. Here are a few points to consider:

Identify the nature of your project

What is the size and nature of your project? If you have a small project with short term objectives, a freelancer would fit the bill. On the other hand, if you have medium to long term project, choosing a company would be the right way to go. While choosing a freelance, there is no guarantee of back up resources or long term availability.

Look for Specialist

As a thumb rule, look for specialist in the technology or domain you are dealing with. Even though a company might have a small team, but if they have already done the job you require, your life will be easier. It is wiser to spend time in searching for the right expert, rather than wasting time working with a wrong one!

Find out work history

The best way to assess a software vendor is to call up their existing clientele and ask them about their experience. Its better not to rely on the feedback of a single client but to call at least 2-3 clients.

Understand processes, talk to people

Try to understand vendor’s approach to software development and also talk to key contacts, possibly someone at the level of  project manager. The quality of process defines the quality of a product. If the vendor has right processes, your software is in safe hands.  Recently, agile methodologies like Scrum and XP have gained popularity. Most of the vendors would TALK about it, but very few implement them well. So be sure you ask the right questions AND to the right person.

Do not get carried away by size

Quality not quantity matters. Do not get deceived by head counts companies mention in their marketing website. Recently I came across a large company whose marketing site boasted of having 40 Rails developers and after reality check it was found there were only 2.

Trust your own findings, not the information

To sum up, rely on your instincts and real findings, rather than what is already presented.

I hope these ideas will do its bit in helping you find the right vendor. You can expect similar blog articles in coming weeks where I will explore deeper into certain specific areas like Agile and Scrum.

Do let me know your ideas/comments and how can I improve this post further.