Tuesday, 27 July 2010

Where is your SWAT Team?

2001-02 While working with the organization I was working then, We faced a very critical issue. We wanted to work on a stronger road map for the product then and were always back pulled by issues around the smooth execution of the production systems, customer issues and rants etc etc. Every time we started working on the development windows we were pulled back either by down times or customer requirements , issues.

This hurts the road maps always and badly. A new feature would be compromised to an issue that the customer wants urgently. We killed almost a few important months of your roadmap that ways. The moment it was decided to have a dedicated Team to handle such issues... We formed a first unit of 2 Development engineers, dedicatedly working on critical day to day issues. Issues that were raised by customers and were urgent. Issues that needed quick response. Effect was, in 3 months time we were able to add up things that we were not able to get in 1.5 yrs.

The output was clear.. A dedicated Team working on second line issues and customer client issues is always a gem. Very Very High ROI.. because the Team actually sets to become the domain experts due to the variant area exposures.

We did the same thing in the organization we worked, in times of high delivery pressures and low Team sizes.. The SWAT Team we named it after (Special Weapons And Tactics). All through the last few years it has helped us balance our Teams and resources and Knowledge about the product. To that matter even the Trainees got to become the member of SWAT and got control on the product. we made our mistakes by pulling people from main stream development

Now this was us. How about you?

Do you shuffle your resources from your main stream Teams just to get some immediate issues resolved?

Do you focus on customer immediate issues than product future?

Do you compromise critical features for urgent customer issues?

Do you believe that your development Team produces much slower than it should?

Do you believe that your velocity is bad?

Well if any of the above questions go in a YES, Boy think over and find where your SWAT Team is.

Such a dedicated team to support urgent issues helps the product move forward. It is always in my experience that when development teams are shuffled in tasks it kills creativity , performance and of course above all the frustration that the teams face juggling tasks and work every other day.

If you dont have one .. Go find your SWAT Team

if you got one and abuse it ... Reform

Monday, 26 July 2010

Minimum Viable Product, Need for today, Necessity for tomorrow

Every one wants to launch it big, hugely big. A hype, A marketing base, plans and communications , blah blah blah.... in an attempt to make this big.. there is always a lot of bigger effort spent.. the bigger the effort the bigger the issues. Thus bigger your first version, bigger the problem. A while ago working with my current organization, I saw that the Team decided to build something new.. a shorter / mini version of a content management system, more robust , more architecturally strong, more envisioned. Perhaps the first version was a very very primary version.. a version that would just do the needful. There is no doubt that it was hugely successful. Bought by a major giant , having some real cool features, and scope to add new things in near future. All of this went by because of the simple and pragmatic approach was taken "Build what is atmost necessary".

We learnt, a bit late but we learnt it hard and well. We now start to work on a new feature addon to the system, A feature that would change life of the system and usage and sales and future. So I decided to ask this question to those selected few who are key and critical developers.... My question was
" What should we build? A Elephant or the sledge runner?"
The Team threw up all their ideas, brains and pros and cons.. in the end they concluded that the smaller they start and make it available the better they can make it for future. Experience backs it well. Define the minimum needs, instead of acting greedy and building everything in once. Avail the real-term feedback and then improvise. Define what is minimum instead of going with "Customers want this" because in the end customers dont know what they want.

Thats what Agile says, isnt it? Build in small phases , deploy regularly , get feedback and improvise?

Then came another question...
"How to define that Minimum of the Minimum Viable Product?"

A tricky question. I am sure this needs a better thought process than just a definition of X, Y and Z items. Its a iterative process that needs to be defined, Ask the question "Am I there yet? after every few days when you are defining the requirements."
I remember we did a documentary a couple of years ago... We started with a script that was conceptualised to be a city tour, it turned that we needed a proper theme to get attention of the audiences. We changed it. Then came the phase where decided cast of the documentary, we thought its too much, we changed. In iterations we went on and on to make a minimum script that would help us make a small piece that we could show others. As we progressed, we changed a lot of things based on the feedback that came out of the process. In the end it turned out that we were closer to make a commercial drama to make what it needed "Gather Audiences, and Get Applause". I know thats what they do with those Hollywood shows and movies.

A lot of times we make decisions driven by demands and not needs. MVP techniques you to help build a basic expectation first.

So when you plan for a feature, product ask your Product Owner on what is the MVP of the whole thing....

Monday, 19 July 2010

Why Feature needs a owner?

We usually think that the Product Owner owns everything associated with the Product... though in a broader terms this is OK... in reality this is a big headache.. specially when your product is getting bombarded with new Features....

In past I have realised that some features get built without thoughtful thinking and in attempts to tailor make the usage those features become a headache.. I once read a tweet (Don't know the source or remember the twitter-er) "Feature is like sex, one mistake and you have to support for life time" . Features need thoughtful thinking.. but more than thoughtful thinking it needs a owner... you may think that depending on the stages of the feature in development it can be owned by different people, theoretically this sounds Good... practically I think the approach has to be changed... You cant have different husbands for a women based on what stage your marriage is, isn't it? Similarly, Features need 1 owner for its lifetime... yet multiple people who support it in various phases..

So when someone says The Feature owner is :
  • Product Manager : When the Feature is Ideated :
  • Business Analyst : When the Feature is Documented :
  • Project Manager : When the Feature is planned for delivery :
  • Developer : When the feature is developed :
  • Tester : When it is tested :

He/She is getting rid of his/her responsibility... The feature needs a owner and it needs 1 owner.. So why is it so?

1. If the feature is not owned.. it will be driven by some customer who thinks its the best way they can have it and fits to the best of their requirement....

2. If the feature is not owned : Developer will develop with his own ideas.. and though it will be pragmatic to the product it may technically be a disaster to extend the feature...

3. If the feature is not owned : It will be directionless... I have seen features not reaching its end..they go on and on and on.

4. If the feature is not owned : It doesn't have a legitimate customer, everyone wants to use and mould it in the way they like

5. If the feature is not owned : From the beginning to end it is going to be a disaster.

So how does one own a Feature:

1. When the feature is ideated, think over it. Brainstorm the idea with tons of people.
2. When it is documented , get it reviewed by customers, internal users, everyone who is somewhere associated with the product or feature.
3. Discuss the wire frames and usability with people who would use it and who wont use it.
4. When in development phase, have a look at it every now and then.
5. Test , Test , Test and Test when the feature is in alpha, beta or UAT phase
6. Brainstorm the usage and usability with testers.
7. Promote the feature to be used by customers.
8. Enhance the feature , think about new addons to the feature every now and then.

Though these things look pretty difficult... if it is made a part of strict rules, the feature will benefit diamonds out of it... Finally what benefits is the product...

So who in your Team can do this? Who in your Team wants to take the ownership to make it successful? Remember its not just the Product Owner... Its a lot of you if you are closely or farely associated with the Product.....

Comment if you disagree?

Monday, 12 July 2010

My Love for IE6 - The reverse Truth

Oh well... we crib and shit on IE6 so often. We blame and blame IE6 so often.. the issues we face as web developers working with IE6 are sometimes nasty... We change for 6 and then it fails for IEY and for Chrome and for FireFox A.. woof... so much of pressure in these browser wars.. so while our friends at Chrome and FireFox and Opera are making our experience better.. we still have IE6's to add to our sufferings... But how can I forget the good old days IE6 gave us... A small poem that demonstrates my Love towards IE6... In a Benjamin Button way ;)

Oh! Dear IE , When will you die?
Everyday I see u, I feel to cry!

Oh! Dear IE, When will you Go?
See the thought within, makes my face Glow

Oh Dear IE, its just about time.
We wasted our efforts and paid every dime

Oh Dear IE, I love you anymore
My upgrades are freeze and apps are sore

Oh Dear IE, don't feel bad
I know once upon a time, you made all other browsers look sad

Oh Dear IE, you were once a hero
You had your days, when in hearts you were Zorro

Oh Dear IE, you made web look so cool
And all the happy developers life was easy when they just got out of the school.

Oh Dear IE, I know you will be the best
You have just came alive and in coffins are the rest

Oh Dear IE, I envision you rule the world,
You will fly very high and be a free bird

Oh Dear IE, the world is waiting for you,
When will web be fast, they got no clue

Oh Dear IE, the maturity of browsers sucks
I hope you get Ideated and let us make some bucks...

Now that I wait for you again.. I hope they listen(I wait for IE10)
Instead of sending another a bullet version, they make you a piston.

Wow... Life and love with IE... I hope it gets better

Thursday, 8 July 2010

Innovation and confusion models

While All my blogs are driven today Innovation and I get queries about confusions around Innovations.. I thought let me explain the different models different companies use to drive there Innovations... Well these are my definitions of it.. but I am sure you would understand that a lot of companies follow there Innovation models in these 3 categories at a higher level...

The Revenue Model :
The model where Innovation is directly linked to Revenue.. here the innovations are made to accelerate the companies growth and Innovation is purely driven by revenue model. E.g. Apple Innovations are driven always by a revenue model.. the Innovation comes on sale immediately after it is out.. Most of the time they are General.

In this model there is less scope of mistakes.. hence u see miniature bugs in Apple products (ignore the iPhone4) when they are launched.. of course no customer wants to pay for bugs..

The Trial and Error Model :
This model gives the Innovation to the word usually for free, initially maybe.. it is left to people for feedback and then once it matures based on community inputs and feedback it takes a better shapes.. I find most of the Open Source projects or even Google fitting into this model. See the examples of Google Wave , Orkut new UI , Buzz?

The Close to Object Model :
This model really drives company that Innovate only for there needs.. These innovations are more driven by internal needs than customer demands.. they are thoughts of 1 or more people who bring it to ease up jobs, they are no pure innovations but instead replicas to cater different needs.. Though these innovations have a certain value they don't have scope to become ultimate Innovations. I feel Yaawhoo falls under these category.. e.g is when Yaawhoo meme was introduced i feel it was a copy and not a Innovation. Yaawhoo Maps, Shopping etc

So what model does your company follow?

Wednesday, 7 July 2010

Make your Product a Platform, But wait first invest!!!

Why are apps so popular on iPhone and not on BlackBerry? Why does iPhone have such a huge developer community and why do you have to struggle to find a BlackBerry app developer? well leave BlackBerry out of this why do no other product has such a huge community of developers as compared to Apple...

Answer is simple... Apple is led by a Innovation method that leads to a revenue model. In clarity the developers find a platform on which they can build a huge set of apps and tools and use them as the product to earn revenue out of it. Similarly if you see the path taken by Amazon Web Services and Salesforce it is clearly visible that they have turned out from being niche products into very strong platforms. Millions of tools, apps , products and Integrations now revolve around such platforms and they have become the Oracle.

I recently read a small snippet that said that startups should build desktop and mobile apps in the early age of the launch to be successful... I think more importantly they should build a set of API's and SDK's around at the time of their launch. The API's will help them to let open features that can attract developers or products to build tools and apps around. I also feel that this should be a step to become a platform sooner or later. However one has to be careful that not all products have successfully become good platforms... a lot of vision, hard work and investment is needed to do that... Importantly right attitude is needed and long term thinking required from the stakeholders to do such thing...

Here are my few tips on why one should look to be a platform and what care should be taken...

Why Platform?

1. As opposed to a product with a few API's available, platforms gives luxury to community to build things around it. If people think they can build things around you and use it for some revenue creation... you are going to be successful on how fast you accelerate your platform.

2. A platform has a longer life than a product... specially because it always invites and controls a lot of apps around. More than anything you are sure you would always have a set of old customers who would stick to you ONLY.

3. If you are new it will open up new avenues for Integrations... if you are OLD.. you have scope to drive the market towards you.

4. In the world of clouds... just a set of API's will not take you anywhere.

But building platforms is not a easy thing like I said.. you need some support, trust , effort and vision... Above all I think an organization should think of becoming a platform only if:

1. They have readiness to Invest :
Platform building is more of investment for a long time to reap the benefits out on the later stage.. A lot of companies simply want to have quick small web services to fulfill immediate needs and that's it. A lot of times the created services or API's or SDK's are unaligned.. they simply cant cover one single module... Moreover if you have a set of API's or services created years ago, you need the thought to upgrade, refactor them sooner.

2. If you don't sow, it wont reap.
One of the products i worked on.. API's started to become key. So important to a level that a whole bunch of internal tools were created around to help the customers use them... however there was no effort to ideate and align the model of such API's to a platform... Effect? Well they just end up as API's.. and you always try to change the existing ones to fit the needs coming ahead.. without really building any new.. If you are not refactoring and re-architecting the core time and again... you are running at the speed of a celeron.

3. You have a strong marketing plan for your platform
A lot of products and platforms fail because they dont know how to market and sell there platforms.. sometimes to whom and sometimes where and why...A year ago I met a retailing tool provider who had some experience on Salesforce developer program... In his first meeting he asked me about all possible tools and products we use.. in his second meeting he came with 100 different ways of Integration of the apps with the products we use... Interesting? Yes your marketing Team should know who and how to market the apps...

4. Document , Document , Document
If you aint document your API's upfront and the platform details upfront.. chances are you will never do it.. Once I heard from myself say this while working on the Web services for our old product... "Everyday I sleep, I feel a missing organ of my body when I dont see a wiki driving the platform details with examples, samples , usability , case studies of the API;s and SDK... ". This should be your first step....

5. Separate vision for Platform, Aligned to a product roadmap
Imagine you have a CRM and to get it up and running as a platform you create some services for Lead Management, some for reports and some for CR.. its not going to work.. take the vision, pick the important piece of the app.. and build everything possible around it as API;s and SDK... let it be used by some... I always feel a need to have a separate vision for building a platform... in terms of scalability , performance , robustness and communication... and then align it into the roadmap...

6. Communication
Its not a cup of Tea.. believe me.. you cant just have 500 Services and API's and without effective communication. Services provided by products like Mashery can come handy here...remember if you removed a XML tag from your response it can break 20K tools using that service... and this is not a easy thing to manage and maintain.

Now if you are a startup, a settled product , a nice market product having some or no API's.. and you think your product has a good future... make it great... think on making t a platform... and think of investing in that platform... A platform is any CTO's dream... any Engineering Director's vision... how you make your Product achieve it is something you have to think... Go think

Tuesday, 6 July 2010

Innovation Teams and Internal credibility

Working with various organizations I have realized that there are 2 types of organizations with reference to Innovations....

1. Organizations that value Innovation and support the objective
2. Organizations that think Innovation is a superstitious concept.

I worked for both type of organizations, eventually there were people in organizations that believed in Innovations, but people within who dont realize what Innovation spans upto. And I worked for organizations which didnt believe in Innovation at all yet had people who were born Innovators. All of these experiences have added a great deal of value to my minimal viable version of awareness about Innovation. When I analysed more on why Organizations that dont believe in Innovations really dont believe in Innovations and why organizations that believe in Innovations fail.. I get through one important fact of life...

Internal Credibility

The trust of your own people. Believe me or not but most of the Innovation teams are challenged by Internal credibility.. to a fact that some Innovation teams do not even take off because there is lack of support from Internal people on it. When you hear statements like "I dont think this will work out", "What's the use of Innovation when the output is not in time?" and so and so.... believe me your Innovation sector is weak.... its time to reform the objective and expectations. A few months ago I sent a email to my team asking them to nominate themselves or Team members for what I called "Innovation Time off" a time off every week or part of every day to work on a project that can bring some Innovation to the Product we work on. In response I got 2 people who initiated thoughtful work on 2 important things...
1. A framework to change delegation model on UI.
2. A snippet that will remove client side dependencies of the application, to access client side data.

Both items rendered and ideate d in a different way for different things. Then came a time when support was needed... weeks of effort when doesn't show any tangible work value questions arise. This is the time when Internal credibility comes into question...

You need a reform when statements/questions like the one below are asked:

1. Is there a timeline to this deliverable?
2. How can we make sure that you get this done?
3. Can we do X instead of Y? Our customers need Y desperately.
4. Its hard for me to justify what you guys are doing, can you tell me what?
5. We failed doing Innovations last time, How sure are we about this time?
6. We have a Innovation team that cares of this. Ask them.

These are the things that takes the blood and oxygen out of your Innovators... If these questions come from customers its fine as they are expecting you to do something, however they dont come from customers.. when it comes from your internal staff... its a killer.

What can you do instead to support your Innovation teams?

1. Ask them on how is it going? Do you want brainstorming sessions to discuss more on your ideas?
2. Hand them a cup of coffee and take them on a Innovation stroll(I will write on this soon)
3. Offer help to support.
4. Innovation leaders should be made to present their progress in various internal meetings.

So what do you do when your Team tries to build a Innovation team? You standup with it or face your back?

How do you support your Innovators?

Do you think you have Innovators within?