Thursday 30 December 2010

Agile Myths?? No Agile excuses

My last post for the year. While I will retrospect this year on the Objectives page.. I want to mention that this year has been one hell of a year. One of the farce thing that came and strike me every time this year was the myths that surround Agile...

I drafted a few of the Agile myths or maybe we can say excuses used under the name of Agile... lets see what Agile is not..

1. A requirement document is not Agile, Agile is a discussion you have to build a feature with its flow and pro's and con's over a white board, which you then slice to develop items.

2. Agile is not a requirement that is changing every now and then. It is a requirement that is built with a smaller set of features and then evolved in later releases.

3. A working code is not a complete feature, a part of the demo-able piece that can be improvised.

4. Bad programming to meet deliverables is not agile. Agile instead is a program that can be improved and improvised. And of course same steps / mistakes dont occur again.

5. Agile is about improvising.. not making mistakes as habits.

6. Agile is not just a concept... its a mind set.

7. Agile is not testing what is written, It is testing what is not written.

8. Agile is not just about 2 weeks iterations, kick off's , plans and releases. Agile is about collaboration every day, white boards every week, demo's every few days, feed backs every now and then.

9. Agile is not CHANGE. Agile is improvement, tweaks, functional improvisation.

10. Agile is not FREEZE. Agile is define a Minimum Viable Feature and achieve it in phases.

11. Agile is not INDECISIVENESS. Agile is starting with a shorter sight to build a grand vision.

If Agile is just a process for you, You should be dead by now.. if you ain't you will surely die. Agile is a life style.

Wednesday 22 December 2010

Will products ever outdate Online Help and be Innovative?

Huh? From Management to Online help, never an easy journey... I speak because I am completely pissed off setting up my machine with a developer environment and do some pair development with my kids.. (Thanks to @rishanimates for setting up a version of eclipse on my machine that works) . So I use one of the most popular mobile development platform, dump the SDK so i can get a fresher work on some idea and then he gets stuck... we refer various online help manuals and example's available together and believe me.. what we need is what we don't get... so then a manual of 10K pages is in front of me and I have to refer to it to find that one piece which probably is not even listed there... moreover I also have to find the right word in context so I can get to the relatively closer contextual page... The whole process takes me ages and I am still left with no answer...

While doing this I am constantly reminded of Google's early year acquisition [Vark.com], a bot , a service that lets me ask questions and get answers socially. Now imagine if your users asks questions within your product and get answers to them from within your product users??? well you don't need to build a unused piece of constantly maintenance needing element.

Well the day is not far... when I was reviewing a Harvard Business Archive article on How to Stop trying to delight your customers I came across Virtuoz .. a virtual agent that answers basic questions and reduces the load of your Customer Services... of course increases your loyalty points with your customers... but then why not take a step further... instead of maintaining a data of support queries... why not let the community build this data and questions? of course with a view of moderated answers?

Here is how I think it would work....

1. User adds a bot to his IM or sees a link on your application.
2. He hits it and asks a questions
3. A bit of AI and it sorts a lists of matching questions asks to confirm
4. Meanwhile goes in the back end and fetches a response to some of the answers a preview of which is up to the user to select
5. Both questions and answers are stored.
6. Admin piece to moderate and update the Questions and Answers database
7. 2nd Version to let user select an option of product area or type of question and then guides to appropriate question and answer.. like a IVR that you face on phone when you call your banks, Airline etc

Hmmm sounds yummy... then is it a question of how much time to build? well with the options available it looks to be a sweet deal... Google App Engine of course...

Have a look at XMPP Driven mechanisms I maybe the last one to think that this can work best for several products... but it sounds real and value driven...

Looking for a fresh mind to help me do this... Are you ready?

Now do you think you can enhance your help files and be more interactive with your customers... make them feel like they are getting help real time?


Wednesday 15 December 2010

What is blocking your Innovation Path?


I was questioned by a colleague yesterday, a question I determine to answer through this blog post. The question was "do you remember of any Innovations we did in the last 2 years?". My answer is NOT REALLY. And I have no hesitation in saying this. I think while the whole world is claiming on Developers been Gods - @Scobleizer in his latest post, How Facebook is made by Developers - Techcrunch, And how Google Dev community is the maximum value driver in Innovation. While there are success stories of how developers really make the future of Innovation bright in any organization... I think many of them forget to mention the determination from the Management, The Vision to Innovate, The attitude to learn from failures, and the readiness to accept failures, the faith in developer community and last but not the least the work load on your teams. I believe there are multiple more elements that drive Innovations... many of them written in the posts previously written.

My answer to the question raised is going to come in a series of blog posts, while this post is going to be focused on the Agileness as a potential blocker to Innovation. Please note that I see Agility as a potential blocker only. So the short and frequent but shippable product takes the precedence, the Team get busy in finishing the tasks planned for Iterations, their visibility to the product and the vision is limited to the set of iterations and releases. Obviously if you are going to have a busy team of developers just working to get a feature right out of the developer machine to the customer, they are going to loose an important element of their attitudes... Innovation.

In my experience agility has all potential reasons to create enough blockages to Innovations... here is why:

1. Multiple short and frequent releases mean that those releases are focused to get small issues / bugs fixed for your customers, maybe some small features that are likely to help your product improve. This means that the focus of your team is on that release and those set of small items. Development or Product teams, both are going to fence themselves into the barriers of those monthly / 2 monthly release cycles.

2. Yes the quality and the speed of development increases with effective agility, but then it also increases the iterations in building requirements, delivering those requirements to a complete set of functional piece. All in all you are working fast and quality, but with no newness.

3. Products may have roadmaps, however the long term features that are going to be a part of your 1-2 years roadmap is not getting resourced. Majority of your discussions are restricted to what is coming in the next release, and many times it is doing something this release to win a deal. Majority of times these items that are big chunky development or Innovation pieces get outdated, Thanks to the market conditions, Technology updates or competitors.



4. If you are catching up, You are not Innovating. A major set of companies/products who tend to catch up with competition have failed to be ahead in the race, as they are always in a mode of catchup.. they are making their Teams to work on those things that the competition has and that is taking the energy out... remember this catching up never ends... I see this race for Myspace... though the new Myspace is really nice.. I believe it is just trying to catch up with Facebook... same thing happening around with Yahoo for instance. So while you are busy catching up with 1 competitor... a whole bunch of competition is busy not catching up with you instead Innovating... Imagine what would happen if you want to catch up with RT like function of Twitter, Like like function of Facebook, A gooogle like search , A Quora like simplicity.... Gosh.. you gonna be One hell of a busy Team.

5. Innovation is not copying. SAP-Oracle is a recent example. If you are busy copying features, you are taking your product years back.. because that is when those products started thinking of it, and did it. In the process of agility many people tend to copy smaller set of features into short releases... this causes Teams to defocus.

6. Innovation is not 1 person telling and other people doing. You cant just free up 1 person to tell you what your product needs... there is a whole lot to do. Agility drives responsibility of Product Innovation on a few less. This is one big trouble... if you dont have 100 ideas every moment, you are going to work on 1 Idea which is probably not well validated or Innovative.

7. Iterative Freeze is needed... One of the problem of been agile is that there is always a backlog... believe me or not.. run an eye on past few releases of your agile team and see the amount of backlogs, Technical debts... many of these are due to the indecisive, iterative feedback sets. One or the other team member will have one or the other change and this change is going to get a lolly in your backlog.

Having said this.... I also want to say that some of these issues can still be tackled to keep the Innovation momentum up in a agile Team. A few of my thoughts...

A. Have streams of development. 1 that focus on short term goals, another that is always working on Innovation items with a longer release plan. This is not catching up though. Had Facebook tried to get into the Phone market, they would have lost focus from the Social Business, the vision of which is to be Social leader and not collaborative struggler.

B. Leave Agile teams with lull releases. Yes everyone wants CUSTOMER DELIGHT. But keep a set of releases empty.. so your teams get time to breathe...this breathing period can really help them Innovate.

C. Small inputs can turn into Big Innovations.. Promote and Provoke your agile team members to Innovate.. Appreciate the items they do on their own... If they are taking you away from your product vision, Guide them but dont reject them hard. Recently a developer bought a cool module for customizable design and formatting. This input was bought down with a statement that it is not needed for the product, Disappointed developer kept another cool Idea of real time previews undisclosed.

D. Make agility your strength, not your weakness... Break up your Innovations into smaller phases, instead of going on a all out war on it. If you are able to get a cool thing for your product increasing the customer UVP.. even if it comes in phases.. Your speed can get things in time, your attitude and quality will give perfection to your Innovation. people will like it. As YT said...Think whatever you do is your Version 1.0 while 2.X is waiting in queue.

E. Imbibe a Innovation culture... Not a THIS IS NOT YOUR JOB CULTURE. If Facebook is successful it is because it has a great Team to support great Ideas and great vision. Unlike Yahooo whose better technology just cant be met by its product ideas and vision. Unlike Myspaces scalability that just is useless as the product doesnt have a great usability and vision further. Unlike Zoho's apps whose Technology is just not able to catch up the cool features and usability of the product...

Now.. that you are one hell of a Agilist.. take a step back, retrospect how Innovation is going in your Team.. and take a leap to improvise the Innovation process.... Let Agility be your glucose in this short sprint.