Say NO TO AGILE

I had a 15 minute debate today with a very good friend. While I started this blog, I had just finished the conversation and while I finish this blog I have decided to give him a call and tell him DONT THINK OF AGILE..To give a bit of a background to this... I received this call just 30 minutes ago where a friend banged greetings and then asked "Is this Agile any good?".. A few questions and I was sure that Agile is not working for him... Going over those thoughts and discussions I really feel pity when people without understanding the need, necessity and requirement of Agility rule out the benefits, perks and values of Agility. I have no hesitation in saying that Agile is not just about a process... I think Agile is more than a attitude... And if you want to find and enjoy benefits of Agile.. you need to be prepared to learn, invest and work on Agile Teams.

So what are those things that should act as a hint to you.. so you can make this decision to say NO TO AGILE? As a manager, lead, stakeholder, product Boss or CEO.. you definitely need to understand when and where you SHOULD NOT do Agile...

1. When your Sr. Management thinks every feature has a fixed number of developer days.

2. When your Organization thinks that a product is just fully ready as a requirement document or mockup is

3. When any of the following do not understand what Agile is CEO, CTO, Product Manager, Development Lead

4. When any one in your team thinks Agile is ONLY for co-located teams

5. When anyone in your team thinks Agile means no due date

6. When anyone in your team thinks Agile is a PROCESS and it should be strictly followed

7. When anyone in your team thinks PROCESSES and reports make products and Agile is just another one

8. When your Product owner does not know how to progress with the product

9. When your product team thinks that the feature can evolve as the development proceeds

10. When your product team does not document clearly on what they need from development

11. When your development think that Agile is for extended development time

12. When your developers value completion of feature more than quality of the product

13. When your development is only about coding once and re-visiting back only when needed.

14. When Agile is just not going down your throat.. and you are making decisions in your team.

15. When Agility is only for a brand new product development

16. When Agile is a way to hide your incompetence and quality issues

I asked my friend to revaluate WHY Agile.. and then decide to do Agile or not... Do you think it is a right suggestion?

Read More

Build to the end and decide when to Release....

Attended the iDilute meeting last weekend, a meeting with some 6-7 odd highly energetic and intellignet brainstormers... One of the topic of discussion was around the success of various startups and products in todays competitive markets. While brainstorming products , methodologies , product management and development teams.. we discussed the best approaches that work for each of them. One of them i couldnt just stop myself from wiring over here... A topic that gets you in the war zones... How to decide your release dates...

Release dates Huh?, I believe a very instrumental element in the success of Product Management and ofcourse development teams.. So how do most of the products or companies define what they are releasing and when? Simple... They analyse the market, they find the feature that their customers like / need / want , They define the spec, they estimate , they plan a release date, they create a WBS , they scope and descope the features and wants and must haves, they start working on it and on the scheduled release date they release it[Most times this is a changed date]. In the middle a lot of things change... sometimes requirements, some times markets, sometimes products and sometimes visionaries... most of the time its time that changes, its customers demands that changes... a major killer in this approach is that the expectation changes... I realise when we started working in August '09 on the product we launched this year.. the expectation was to have a JUST new UI, when it reached towards its mid-phase the expectation changed to a MOST POWERFUL UI, when the delivery date neared the expectation was we are building THE MIRACLE PRODUCT. In the end satisfaction when compared with expectations is always 1: 1 milion , and you know which way it goes.... So then how do companies like Facebook work? How do they keep up to the expectations of their customers? How do they bring great features consistently and effectively... This meeting enlightened me of a smarter way they work... One of the attendees who also happens to be an ex-employee of #FB explained the approach of "Build to the end and release" i.e. Work on your product/module till it has neared the completion and then decide when to release it.

Smart, isnt it? pull a roadmap, punch an estimate for every feature [As a project] start working with the plan, be as much agile as you can, define requirements , evolve and once it is ready.. go ahead and say it is going to be ready in XXX days... then let the product team plan the communication and the release date.. Well so much of headache's it avoids for strong , disciplined agile teams...where features are built by what they are meant to do and not by how much we can fit in to the neck of development time available... The quorum debated over this, almost half of the attendees been the traditional managers for whom the only way to complete the thing was to plan it to th end... yet.. I found some real good points in this approach...

1. We all know that our poject costs overshoot the budgets - If you tell me you have always managed within budgets, I have to say you are lying.

2. We all know requirements change - Even if your spec writer is your own customer who wants what he writes.

3. We all know that we like to change and tweak , sometime reform what we built - Even if we say that there exists a CR procedure

4. We all know that we change scope, time or cost to achieve what we planned - Even if we say we did it right.

5. We all know that there are a bunch of angry , unhappy customers sitting there - Even if we write testimonials on our websites.

6. We all know we are atleast 10 years late - Even if we claim we are the first to reach there

When we know we do all of this...then isnt build until you done and then fix expectations a better approach? I remember how much i cursed this approach when one of the Product contact we use was not telling us the release date for the third party viewer software we were using for the Version 20 of their release... I wondered how they managed millions of users and hundreds of big clients... only to learn this year, that if you have to give out quality, you have to accept facts of development attitudes.

Now.. back to reality? Will this approach be adapted by smaller companies? By companies who has a shouting customer who will not renew their contract if X thing is not delivered by Y date? Well the decision is not on can this be done... the decision is Do we want quality....

I wish to trigger this some day, maybe not today... tomorrow definitely.

Thanks to the iDilute forum.

Read More

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?

Read More

Teams, Collaboration and Yammer

One of the challenges we Project Managers face in our routines and project cycles is a lack of communication. X knows something that is missed out of communication to Y and so on. Everyone in the Software Teams need a way to communicate with the ton with ease... We all then start relying on our time killer Emails... Yes we send emails to aliases and then we rely on emails back.. responses that come from specific groups.

8 Months ago we switched to Yammer, The core idea was the remote teams that we were working with in the UK, France , Germany , US , Chennai and Pune needed a common way to communicate.. a way that doesn't restrict us to certain tools and software's, yet allow sending message to many at a time, yet allow getting responses from many at a time, yet have a thread and a link to replies, yet have a phone, Black berry , Desktop or web application that can work for anyone and everyone, yet allow sharing files and pics and above all be available from anywhere, everywhere all the time.

To our luck Yammer has turned out to be quite a relief as people can ask for quick answers / doubts to a bigger group and get answers and updates all the time. I would recommend Yammer for collaborative teams due to the flexibility and the app support that it provides with ease. Above all an unadministered domain in Yammer will cost you nothing, It can miraculously change the way your team interacts...

Ignore those chat sessions that will happen, but can be really a lifeline to the diminishing integration you are facing in your teams... So if you like Yammer don't hesitate to Thank me for it.. and get your colleagues to read more of this blog as I am more keen to share the Project Management tools that worked for us and in what way....

There are other similar collaborative tools that I gave some try but could never switch as Yammer did what we wanted... but in case you are interested go on and look for Socialcast , Shoutem

Read More

How much Rework you have to do?

I have been closely monitoring and also involved in the current project that we have being working on. When I say closely I really mean closely. In the last few Iterations I have being harassed by the fact called rework in the development that we begin on August 17th and 6 months from then.. I see that we have spent a considerable amount of work trying to avoid rework.. yet rework is inevitable.

We as a Team recently decided to run a check on the reasons for rework, this was due to the fact that the Team has being talking about refactoring within a month of development of the item. As a manager any type of rework is a time waste. When people moved to the lean principles the core objective was to eliminate waste (in other words rework).

We decided to find the root cause of rework... and here is what I found... maybe interesting if you have a Team doing a considerable amount of development....some of these elements if taken care can really really help you eliminate some waste... a lesson for future a learning from past....

1. Understanding

50% of the rework is caused due to the fact that the developer does not understand what he has to do and he ends up jumping into the feature development. A big job here is to involve the developer in the upfront understanding of the feature and system. Not only it is associated with the developer but analysts also tend to write use cases without fully understanding a feature... result is rework after some amount of development is done.

A timely feedback and understanding of the features can help a developer build a right feature with minimum amount of rework.

2. Test Driven Approach

How many of your developers after completing the features run a test script written by the QA , Analysts? It is important that the developer approves every Acceptance Test , every negative test before he calls in the feature as done from development. A test driven approach is not just for feature but also for the code... A peer review can ensure the facts covered or uncovered by the piece of code written.

3. Break up and Build up of Tasks

4 out of 10 developers break up tasks out of a feature... I haven't seen any building a task out of features... a micro view is what a developer build out of a feature they work on... how beneficial it will be if you build a macro view of combination of features? Well the Architect and Managers have architectural views at higher level.. but if you understand the fact that what other features may need you may avoid duplicate work or rework.

4. Refactoring Yes , Reorganizing NO

Give time to your developers when they write code... not to let them re-organize what they deliberately left out or to cover what they did not finish.. but to reform the code in a better way. If your developer comes to you the next day after he finished a feature asking for a refactoring time, he has messed it up.. and the refactoring time is not the quality time.. its the development time.. he is running short on estimates.

Clearly define refactoring time.. and that is not development or bug fixing time.

5. workarounds vs Driveways

Developers always tend to bring workarounds as permanent solutions... they think from a granular perspective... train your teams to answer a few WHY... when they ask or suggest a solution?

Questions like :

Why this has to be done?

Why can it be not done later?

Why it was not done earlier?

Why this time?

Agile Teams eliminate the rework element to a bigger extend.. Agile Test Driven Teams eliminate it a very large extent. Agile behavioral development Teams can eliminate the larger chunk too... but yet Agile Teams too have to put rework. The project plans have to consider this fact and build an expectation accordingly. As a manager it is our job to ensure that we consider a few of the above elements and avoid some rework.. after all it is boring, time consuming and unpleasantly wasted.

Read More

A bad day in the life of a Project Manager

Well planning can be so important an element in the life of a project Manager.. they end up planning and risk managing everything.. everything. The profession takes up so much on them that they end up tying up everything with their profession. The more Alpha Manager you are the more this is imbibed in your life. Though planning and risk managing being an integral part of the life of a manager somethings like today can happen.. and we can it a Bad day.

For you to know today I had an expensive bad day. Here is the sequence of events for you to know... tell me where to improve ...

So first I let you see how I planned my travel below:

11th December : Pay the bill in the night so I dont have to struggle in morning

" Booked the cab at 4: (He can come by 4:15 , worst case 4:30, I still am 15 mins ahead of Bus)

12th December : wake up 3:00 AM (worst case 3:30 , i put a BB alarm and a wake up call)

" : Get ready 4:00 AM

Cab : 4:15 AM - worst case 4:30

Bus to LHR : 4:40 - 7:00 - 3 hrs in advance (worst case 6 AM bus reach there at 8:30)

Reach Frankfurt 12:20 by 9:50 flight , worst case 2 with a 11:30 flight.

And here is what happened...

1. I was supposed to travel from Cwmbran to Pune today morning... As planned I started at 3:30 AM in the morning, ready by 4 to catch a bus from the Newport station at 4:45 AM. The cab driver was asked to pick me up at 4:15.. He doesn't turn up until 4:20.

2. I make a call to the cab service as there is no one on the Hotel Reception in the early morning. Cab service says the Cab driver has started as expected, should be there anytime.. I wait till 4:30 , call again. Cab driver reaches 4:35... speeds me up the station, I see a few other passengers, also waiting to go to Heathrow. Bus doesnt arrive. Somebody tells me that the bus might have left. We all look at each others faces... 4 of us.

3. I call the National express to change the ticket... The support office doesn't respond. Then a lady picks up the phone on my 3rd call overall 11th call. We are asked to wait for the next bus at 6:00 AM I calculate 6 + 2:30 hrs Alrite I am still 1:30 hrs earlier on the airport. Bus comes, but the co-ordinator can only allow one extra passenger.. the oldest one takes the seat. We 3 decide to take the Train.

Result : 34 GBP wasted.

4. 6:40 AM Train to Padington(I am still 1 hr ahead on the airport as per paper), I buy a ticket to Paddington and subsequently heathrow 66 GBP. Train delays by 8 mins. Surprise , Surprise.. this train goes to Gliucester and other few stations before it reaches Paddington (Expected time 9:30 AM on Paddington). At Reading, announcement for further delay of 10 mins.. we get down take a Rail Air to heathrow, thinking it will take us there by 9:30 (30 mins ahead of my flight), Another collegue who was with me had already lost his connection.

Rail Air reaches Heathrow at 10:05 tks to Traffic

Result : Flight to Frankfurt off. 66 GBP wasted.

5. I walk the ticket desk, they give me an alternative at a cost of 188 GBP. A flight at 11:45 AM that will reach Frankfurt at 2:00 PM, 40 minutes ahead of my connection. I checkin the lugggage.. flight overfull. Ofcourse expect nothing much but delay. I arrive FRA at 3:00 PM.

Result : Flight to Pune off, Tickets had to be changed for the next day travel, 188 GBP wasted

6. I decide to wait on the airport, instead of sneaking into a hotel. Remembered my last experience when Heathrow was closed at 11: in the night and I had to wait on the airport all night to take an early morning 6' AM flight to Paris. I decide to take up and go to the Frankfurt city. I buy the Train tickets, call the Hotel get myself booked for 90 EURO night. Just before I step on the train I feel a shivering effect.. My winter jacket got left over at the Lufthansa Ticket Desk. I run back and search for it. Lady tells me that it is kept in the lost and found section.. I run to that section without knowing how to prove its my Jacket... lucky enough the nice person on the counter lets me take it back. Its 5 now and I am sitting in the Hotel. First thing my tired mind tells me to do is Blog this experience...

Now.. if you have seen the Actual Plan (Over Plan) and the Actual execution... you can call this my most expensive Bad day in life. I hope no one ever misses a connection

Read More

Ownership - The Beauty spot

Nobody washes Rented cars - So how do you expect employees to own things they dont think they own?

Your Team members are owners of what they do? Do they call themselves owners? do they own what they do? Is there enough ownership in your Team? You know where I am getting at with these questions don't you?...

Ownership is that action which comes from you and your team when you give an all out effort and commitment to what can lead you succeed. Ownership... Yes, the beauty spot of the Team... its that dimple on the rosy cheeks of success that every Manager wants to see. So do you see the scar of not having ownership within your Team? Or do you face problems getting Team own something? Or commit to Ownership? Yes? My dear friend you have a problem in Management then.

Managers who fail to generate a feeling of Ownership in the Team, fail to succeed in building great teams. The feeling of Ownership cannot be forced on the Teams and Managers who think they can do that eventually lead the Teams to fail. Yes, this beauty spot is not something that can be enforced on employees or Team members.. If you want to have your Teams possessing at-most levels of Ownership, then you need to go dig some ground and build the foundation of it... this foundation is made up of certain crucial elements that help Ownership feelings takeover the minds and brains of your Teams and Employees. So what are these elements that let you bring Ownership in your Team?

1. Fun

A lot of organizations lack this element, which is a prime element in building the foundation. If you come to work and sit around 50 frown faces, that dont even smile at each other.. you are going to miss something very important. And you are going to miss it badly even if you are doing good. This is a element driven by culture, so if you can bring fun in your workspace , in your team, in your behaviors.. you are going to let the Team members enjoy what they do.... and did Adam and Eve tell us that they did what they enjoyed the most????

Add fun to your teams :

1. Have casual times in the work hours so that the Team can crack jokes, feel the humour, enjoy, relax...

2. Dont leave any opportunity to discuss topics that are on and off works with the Teams.. let a crowd be involved in such discussions so they realize they are learning something....

3. Have team building events

4. Small Stress Busting games once a month

How does this help????? Well if they enjoy where they are, they would enjoy what they do....

2. Challenge

A lot of times our jobs get boring... routines you know what I mean? Build this element into your culture that you get challenged and you challenge... I honestly mean that ask Why??? this can help the Team develop a spirit to handle anything that comes to them.. questions , issues , problems and solutions. If a developer says that he is scared of something, throw him a challenge covering some risks. A few months ago YN (Yogesh Nimbalkar) one of our prominent developers told me that he was not so sure about UI development... we threw him a task to build a slide show , he came back with a cool charts functionality. If your culture promotes challenges, you are sure you would have the Team members looking forward for more coming there way.

3. Connection

You come to office at 8

You drink COffeee

You work on your desk

You have lunch at 12

You drink coffeee at 3

You leave office at 5

Is that all you are meant to do? Do you know if your colleague sitting beside you is wearing a new shirt today? Or why your product had a downtime yesterday? Or why your boss is looking sad today? Or why your pair was off yesterday? Or where he is going for the weekend party? Well connection is needed to get this feeling of ownership. If you are not connected to the people you work with, your product , your work , your machine how would you show ownership? A strong connection has to be built, your culture has to let it build so that people can remain connected and improve the connection with everything they do.

4. Love

If love can get a blind man see the world through imaginary eyes, love can also create a feeling of very strong ownership. If you love something you would care about it, you would fight for it. Yes let your culture promote love... for the Product you work on, for the workplace , for the desks they sit on, for the people they work with, for the job they do, for what and how they do it..

1. Max is a terrific developer, he loves technology. Thus he builds great stuff.

2. Max is an amazing person, but he hates programming. Can he make a great developer?

Let your Teams love everything that is linked to your work. Managers, Collegues, Work, Product , Technology. If they love it, they will like it too ;)

5. Collaboration

Improve on collaboration. Dan today told me that he is amazed the way we communicate and collaborate in our Teams.. Collaboration leads to inspiration... people with different mindsets coming together and trying to achieve common goals ends up inspiring and motivating each other. Today we are a global company with teams spread out in France , UK , Germany , US , Wales , Pune , Chennai...just for what we do... even if there were a few more locations and more developers every where we would have being communicating and collaborating more and effectively?

Let locations, people , Teams and team members collaborate.. create an opportunity for them to collaborate.. for instance a travel together for 2 people who speak limited with each other. Or an off topic task where these 2 people have to speak to each other. Easy way on a picnic ask these guys to pick each other up? Do come car pooling? Well all are mechanisms of collaborating.. try em out.

6. Choice

Zaheer a long time ago collegue of mine always wanted to be a Programmer.. he hated what he did.. which was inventory Management and web design. For a long time (3 months) he kept on doing the same with a lot of hatred... Yes he did not love what he did... We then chose to tweak what he did.... we gave him a choice of doing the Web Design with some programming to ease up his job.. which would mean writing automated scripts to handle inventory management at the same time do the web designing. He happened to deliver both ahead of time and quality. Sometimes its about choice, understand the choices of your teams when you speak to them, if they are asked to do what they prefer to do... they would own what they would be doing.

7. Goal and Results

Isnt it important to let the Teams know on what is expected after all? Well if they know the Goal and the outcomes of what they are doing.. they would definitely like it. If you tell your Team that you plan to build a web that will rule the future of internet like Gooogle is doing... do you think people will not want to own what you want them to do? or what they are doing?

Some scared mouses may run away, but anyways do you need people who are not committed to organizational goals?

8. Opportunity

Give opportunity every single time you can... Make the Max do the trickiest elements of development, Let Max handle strong modules independently, Let the Max decide what technology to use for the product development. Given an opportunity creates a feeling of rhythms and growth and employees and Team members like the fact very much... they thus commit themselves to what they do.

If your best developer is always developing, he may unlike what he is doing after a while. But if your best developer is doing different things in different ways every time he would take it as an opportunity. Let them travel whenever you got a chance... they would have a feeling of reflective investment and thus they would want to contribute more than what they could have.

9. Failures

Let them taste failures and stand by them when they fail. Though the objective here is to not let anyone fail.. but in professional lives it is important to fail. Its failure that teaches them on how best to do things next time.. you can be there to help them fail on smaller things so they can succeed on larger things.

Max started to build a feature , he failed miserably doing so. His Manager stood by him and they worked out the best way to make it work in future. Result Max built the same thing with enhanced capabilities.... 2 reasons that contributed that....

1. Feel of failure invokes lust for success.

2. Backup in bad times gives more confidence..

So.. do you think you do any or all of these? If not think of ways to get these elements imbibed in your culture... if you are building a product for future with a Team that will define this future... this investment is necessary... atmost necessary.

Lets Own what we do! What our Teams do !!!

Read More

Products , Product Managers and Product Owners

Had an amazing discussion over a thread with Rick Chapman over the role and future of Product Managers and SaaS products. I am amazed that reading Rick over SaaS University and Soft Letter gives me a feel that he understands SaaS well... However I am not very convinced on the thread that is shared over PRODUCT MANAGERS and SaaS where Rick says that SaaS Products dont need Product Managers...

SaaS products introduced the real concept of democracy into Web Application domain... It sooner appeals to me as OF THE CUSTOMER, FOR THE CUSTOMER By a Developer who looks it as a CUSTOMER

The reason I think the Product Managers are must for any product (Be it SaaS or an Enterprise solution) :

1. Any product needs to have a life cycle.. if products don't have life cycles development doesn't need to have life cycles. A Product Life cycle within itself means a necessity or a definition of its owner and Manager.. and who is the product Manager in this case? I don't determine a developer to be the Product Manager and I would hate to call the end user as the product Manager here..

2. I want the blue button here
Every customer makes several demands on the product. The product Managers derive these demands to a conclusive path , turn it on to as a feature that many others would like to do with a product. Imagine every developer delivering same feature in different colors at different times??? well somebody has to manage it and this somebody is no one else than the Product Manager to me...

3. Agile is a better glove, but Agile is not the placeholder
With increasing importance of Agile, like Waterfall model Agile is getting misused.. Agile is the best development approach for product development.. specially when a product is appended with features, functions and technical aspects.. Agile can support development process but need an owner who owns the product and doesn't allow sloppy developments happening all over the product.. expecting a Scrum Master , Development Manager or a Product Manager to do this is a disaster..

Many more that I can think of.. but I guess I would first like to read what Rick has to say and then post my thoughts over..

Read More

What can ruin your Project?

You definitely dont need to list down the elements that will ruin your projects, its simply because anything and everything can ruin your project. Considering the fact that usually it is been blamed on:

1. Technlogy
2. Bad Project Management
3. Poor communication


What do you think you will answer if this is asked?

Read More

How to loose your Best Guy?

OK with reference to my earlier post on How to loose you best guy... My mentor has finally decided to go... It was his last day yesterday and one of the most vulnerable days of my life... Not closely working with a mentor is like not been with your family... and the respect I have for Kari as a mentor and as a friend cannot be just sentenced here....

on How to loose a guy like Kari from your team here are the tips:

1. Keep him away from work and people for long
2. Drive all his ideas into Trash
3. Do not let him do what he is Best at
4. Do let him do what he does not like
5. Help him loose his confidence by doing things that a Data Operator can do
6. Do not let him learn and earn experience from the bigger brains

follow a few or all of this and it wont take more than moments to loose such a Gem from your Team.

Read More

What is a Project for you?

reading through PMBOK (For those Managers who are new to PMI ;) it is the Project Management Body of Knowledge), This definition hit my mind :

"A project is a temporary endeavor undertaken to create a unique product, service, or
result." Well when the PMI defined this they definitely had more to say ... but while I would like to elaborate on this definition leaving aside the technical definitions of the project... It would be good to know what does a Project mean to you?

As per PMI it means that a Task that has some definite begining and some definite end which is derived from the output of the task compels to form a Project... Now lest go beyond these lines and understand what else does a Project contains when it is defined.....

A Project is definitely a task that involves one or more full time and/or part time resources.

WHat more can you think of?

Read More

Are your Best Guys in Action?

Lately reading the Technical Interview I took from Suresh and to my earlier post regarding the Diminishing Software Quality I am really really sad when I look at the way the software's are developed and manhandled afterwords... A simple question I ask to myself looking at the IT Industry boom in India is "Are the Best Guy's doing what they are Best at?" ... Surprised to listen? I myself feel NO.. The Best Programmer in a Technology within a Year wants to be Technical Lead, A Technical lead wants to be an Architect or Manager within a few months and a Manager wants to be a Delivery Head , Delivery Head to be the VP and the VP to be the CEO... Well No one really thinks beyond a CEO do they?

Looking aback I really feel that a team member who is best at coding is pushed to designing (The management Sales BUZZ WORD "GROWTH OPPORTUNITIES" sucks here), A Web Designer been asked to be a Animator because the company has got the project and they want to show him his growth prospects, A Technical lead who never thought outside beyond technology is asked to do People Management and poorly enough an illeterate (I really am talking here about everyone who are not business blooded) is asked to run an organisation.

After you have a read of this can you go,check and let me know if you think:
1. The Best Guys are doing what they used to do best and with evolving and surprising results?

2. All who are a part of your Team are there just because they are best at what they are doing?

3. Growth for them is designed in such a way that it is directly proportionate to the Aspiration and the exposure to achieve the aspiration?

4. People are not pushed to do things just to keep them within or make them run for a Mirage?

5. You are doing something you are Best at?

6. You are doing something for a long time and yet you want to do because everytime you do the same you think you have learnt more?

Huh? So many dammn questions and the answer is just one... "Diminishing Quality" So what to do about this? Lets make our Growth Planners added with a spice of an entity that tells us what we are best at, Let our employers know what we can do best for them, Let our resumes show what best we can bring to the given organisation and finally Let us take a Pledge that we will CARE ABOUT THE SOFTWARE WE DEVELOP Not for the sake of it but for a reason that can help the Software development Industry achieve the goals for what it was intended to have started...


Regards
Sameer Shaikh

P.S. Please do not take a Pledge just becuase you want to seen, Mean it.

Read More

DOING A JOB or DoING it RIGHT

"When there's a gap between someone doing a job and doing the right thing, then management has failed"

Now I don't remember which Article or Blog I read this and unfortunately not able to find the exact place even after doing so many searches, I am actually forced to link this to the Harry Potter book specially because of the incidences happening over there... BTW This post was written when I was in the Godric's Hollow where Harry has just survived the Deathly attack.I am having a feel that its the Voldermort's mismanagement that is killing him. Be it not managing Snape to kill Dumbledore or be it not getting hold of the Undesirable one while leaving the dudesley's. Anyway forget it, coming back to the Fun. The root cause of failures in management are linked to doing wrong things at right times.Yes say for example "Taking your kid out in rain when he has just come out of cough and cold" Or "Having a quarrell with your wife when she is in a real bad mood" too many more things really, yeah wrong things at right times....

So while we think that its a managements failure when the right things are not done and the jobs are just done as a Project Manager certain things really can be credited on the path to "Why My Software Projects Fail". Lately while realising and analysing the follies and faults a Project Manager can do while reacting to situations can definately lead to the worst. Through a Project Managers career comes occasions like :
1. Biz critical situation needs to be responded by a Software support.
2. Risks need to be managed by playing with resources (doesnt only include Man Power).
3. Values need to be staken at the cost of situations...
more of course that you wont like me to write here.... under these situations the Best Manager's takes a call that can suffice and satisfy the needs and what plays a major role here is the time taken between the agreement on decission and actual implementation. If you are a cricket fan and had watched the 2nd day play of cricket Test Match between Englad and India you will agree Vaughan's decission to let Panesar continue a longer spell of bowling thinking that his spin will bowl out India short;) Unfortunate the decission was wrong. I have seen Managers who want to do everything in one shot right from decission to implementation and 11 out of 10 times it results into failures (however there is NO MANAGER IN THE WORLD WHO SAYS I DID THIS WRONG) If you dont believe this ask your Manager why a person who was fired recently becuase he been not productive or having other issues was HIRED at all? Well the answer wont be My choice was wrong it will be "He was better now he changed" so anyways.. taking decissions hastily is a art of Mis Management that can kill success... And I believe it is "JUST DOING THE JOB"

Yet another place to measure how it can affect in doing the right thing or just doing the JOB. A Father of an Indian girl's decission to hurriedly (without proper investigations or checks) of the groom she is marrying can result in disaster of a spoiled marriage, while if the fixing of marriage and the actual marriage takes long its possible that you might find the defects of the groom/bride way in time... definately leading to a find of successful marriage.

So next time you are to make a decission just dont make it "IT WILL BE DOING YOUR JOB" take time and then implement no matter it gets late it will be a right thing ;)

Read More

Move To Thrash

A Few weeks ago we developed this feature for one of our key Customers on a key Project... what a thing it would be I realised if I get this Button in the Project Management to:

1. Thrash the Communication problems
2. Thrash the delays in the deadlines
3. Thrash the bugs in the system to never restore
4. Thrash the hurdles in the way of a successful growing product
5. Thrash the banners that do not motivate anyone from getting motivated
6. Thrash the fear so as to enable everyone to grow equally
7. Thrash barriers that cause project delays and confusion.

and last but not least solemnly thrash the erosion of quality code.

This is just to make the challenges of Project Management look a bit easier.

Read More

Creating a Bug?

I always think that Management is all about investing keeping in mind the ROI. Eventually lot of the Managers today know investing but not sure if they understand how and where to generate the ROI from... Well the reason why my post hits the blog is a recent incident that happened... Around a month ago I met a mother of a kid from my son's nursery school and while talking to her I realised that she was planning to get her child out of the school to a new one because she thinks that the school is putting too much pressure on her son and she wants her son do some painting and dancing along with swimming. Lately when I saw her again while going to drop my son to the school we had a chat that hit my mind badly.... She wanted to invest some more time so that her son learns been a bit pressured to study and manage things out...

Goshh.... Well you don't need to meet a mother to know the problem we have here... darn.. I think it sheer BAD Management well in our day to day lives as Project Managers we face similar things... things that can hurt damm hard... wana know How?

Tom is a Manager by mind, Developer by heart, QA by lungs and a Leader by Ears and ofcourse a Dictator by attitude... To be honest he is Jack of All and King of None... His Manager Harry invested time on him to create a backup, while everything went fine.. the Jack attitude took Tom to mis understand and interpret things negatively... eventually it resulted into a Over head for Harry.... the final outcome of the investment was Tom was out working for another company in the same way he started with Harry...

So whats the problem here? Lets relate the 2 stories to find whats the ROOT Problem here...

Read More