With more than 60% of the population thriving on IT industry, I am sure you would have come across these often. Be it as a manager, lead, or resource, these scenarios are common place. And they go here not because i like them but i despise them.
1) This project is critical. We must deliver by this deadline
Run for your lives! The count down has begun. The world is coming to an end, as this functionality remains undelivered. In India, there is no project in IT which is not critical. I am sure that the 123 agreement, the CTBT, the delhi metro project don't even come near when it is about delivery of a patch deemed as highly critical but correction of a misspelled name, changing the text font, changing the background and what not. The crux is that people and specifically managers (now don't stare at me when i say that! All i am doing is referring to the common race) do not understand that by deeming something illogical as critical, all they are doing is increasing the frustration levels, uneasiness of the resources. Why on earth do we need to deem a project or a enhancement as critical when they can be lived without it. Remember the story of the boy who cried wolf?
2) Give us a rough estimate of how many man hours would it take?Siddharth, come on, you said it was 15 days. That was a commitment to the client we made. Its unprofessional to go back on that.
First of all, tell me this. Where the heck did you study?Didn't we all know what the word 'estimate' means? For the uninitiated, according to the online dictionary, it means A tentative evaluation or rough calculation, as of worth, quantity, or size. Please note the specific stress on rough. I really fail to understand how the word has been skewed to such an extent, that we fail to understand that an estimate refers to only a rough quantization and is not accurate. And if it were, it would not have been called an estimate. And why do we always have to associate the word estimate with professionalism? I can see no connection there. Couldn't we just do away with this practice?And are we paid labour, that our efforts are calculated in man hours. What a derision of the world of Information technology. We are engineers and let us maintain the dignity of the same.
3) Hmmm...so you said 4 days of effort. And you are 2 people. So that means this can be done in 2 days.
You fail to see that one of them has an experience of 4 years and i am a neophyte. How can we both be possibly giving the same delivery and with the same efficiency? If that be the case, man we really don't need those fat pay checks for the experienced ones, do we?
4) We need this, that, that, this, even this, even that in the demo. It cannot be done without it.
Now should i refer back to the meaning of the word demo? All i want to say is that, a demo by all means is a demonstration of the functionality and in no way the final product. We all understand this and still we want the slightest of the configurations in the demo. What for?So that the client suggests some changes and you redo the whole thing and waste those precious 'man hours'. Now, somebody said productivity right?
5) We have 2 resources dedicated full time for this.
Which resource are we talking about? Natural, energy, man made, conventional, non conventional? Ohh i failed to realise that you were talking about people. I just wish that we did away with this practice.
For me, all these are not critical remarks but something which i need to learn, infact we all need to. Maybe these are just the way it should be, but for me these are the lessons to be learnt. One of the person i had a chance to work under, was how i would want to grow into as a professional. Someone who places immense faith in people. Personally, i believe in the immense power of people over everything else. I would rather give complete power to the subordinates and let them come up with something. Because, in the end, thats what is important. The delivery and the satisfaction of people. One of the key ingredients of a leader.
And that brings me to another point. This is the reason why i feel that Agile is the way to go. Not because i feel that it is technologically superior or something. For me the sole reason for an interest in it would be its importance on people over processes. Protecting people from the clutches of unwanted processes. Lets go back to each one of the above and see how Agile fits in there, even though i do not know the ABC of Agile (well as of now, i stand uneducated on this topic, but not for long)
1) This project is critical. We must deliver by this deadline
Well, you are a stake holder in the development too. And you also know how much effort we are putting in. With the iteration planning meetings, burn down charts, you get to know
where we are standing. We understand that this is critical, and you also understand that we also are doing our best. And do not try to push us too hard. Our scrum master is there to save us from thy wrath.
2) Give us a rough estimate of how many man hours would it take?Siddharth, come on, you said it was 15 days. That was a commitment to the client we made. Its unprofessional to go back on that.
Agile, completely understands the true meaning of an estimate. While it does want it to get better and better in terms of accuracy, whatever could not go in can be put in the backlog. Its the best we could do. And all along we track the progress with the burn down charts. We know that we have got a dip there and haven't met the expectation. But we are trying to close the gap in the chart.
3) Hmmm...so you said 4 days of effort. And you are 2 people. So that means this can be done in 2 days.
Agile realizes that while one resource could do a job in 4 days, the same can be done by another in 2 days and vice versa. So, if i am better, i get the task during the IPM since my odds were the best (i said that i can do it in 2 days flat while others would have taken 4 days, and not only that, i still get to explain why i can do it in 2 days and why it should not take more than that). Realize that what i am good at, he might not be and vice versa.
4) We need this, that, that, this, even this, even that in the demo. It cannot be done without it.
For Agile, the working code matters more than anything else. It is not the super cool UI they want in the very first iteration. They would come up with a working functionality, and tell the client that all these cool things can be added to it in another iteration. And best of all, they include the client in the whole process.
5) We have 2 resources dedicated full time for this.
Hmmm...I don't really know how Agile would help here, but from what i could gather from Aman, he used to say that for Agile, it is two team members which are important. They would rather pair up and program and would never say that it would be completed in 2 days flat. They understand that 1+1 is not always 2 in any practical case and if it were it would be the epitome of synergy.
With these ramblings, i think i better get to what i was doing. High time i started writing those dreaded essays.
1) This project is critical. We must deliver by this deadline
Run for your lives! The count down has begun. The world is coming to an end, as this functionality remains undelivered. In India, there is no project in IT which is not critical. I am sure that the 123 agreement, the CTBT, the delhi metro project don't even come near when it is about delivery of a patch deemed as highly critical but correction of a misspelled name, changing the text font, changing the background and what not. The crux is that people and specifically managers (now don't stare at me when i say that! All i am doing is referring to the common race) do not understand that by deeming something illogical as critical, all they are doing is increasing the frustration levels, uneasiness of the resources. Why on earth do we need to deem a project or a enhancement as critical when they can be lived without it. Remember the story of the boy who cried wolf?
2) Give us a rough estimate of how many man hours would it take?Siddharth, come on, you said it was 15 days. That was a commitment to the client we made. Its unprofessional to go back on that.
First of all, tell me this. Where the heck did you study?Didn't we all know what the word 'estimate' means? For the uninitiated, according to the online dictionary, it means A tentative evaluation or rough calculation, as of worth, quantity, or size. Please note the specific stress on rough. I really fail to understand how the word has been skewed to such an extent, that we fail to understand that an estimate refers to only a rough quantization and is not accurate. And if it were, it would not have been called an estimate. And why do we always have to associate the word estimate with professionalism? I can see no connection there. Couldn't we just do away with this practice?And are we paid labour, that our efforts are calculated in man hours. What a derision of the world of Information technology. We are engineers and let us maintain the dignity of the same.
3) Hmmm...so you said 4 days of effort. And you are 2 people. So that means this can be done in 2 days.
You fail to see that one of them has an experience of 4 years and i am a neophyte. How can we both be possibly giving the same delivery and with the same efficiency? If that be the case, man we really don't need those fat pay checks for the experienced ones, do we?
4) We need this, that, that, this, even this, even that in the demo. It cannot be done without it.
Now should i refer back to the meaning of the word demo? All i want to say is that, a demo by all means is a demonstration of the functionality and in no way the final product. We all understand this and still we want the slightest of the configurations in the demo. What for?So that the client suggests some changes and you redo the whole thing and waste those precious 'man hours'. Now, somebody said productivity right?
5) We have 2 resources dedicated full time for this.
Which resource are we talking about? Natural, energy, man made, conventional, non conventional? Ohh i failed to realise that you were talking about people. I just wish that we did away with this practice.
For me, all these are not critical remarks but something which i need to learn, infact we all need to. Maybe these are just the way it should be, but for me these are the lessons to be learnt. One of the person i had a chance to work under, was how i would want to grow into as a professional. Someone who places immense faith in people. Personally, i believe in the immense power of people over everything else. I would rather give complete power to the subordinates and let them come up with something. Because, in the end, thats what is important. The delivery and the satisfaction of people. One of the key ingredients of a leader.
And that brings me to another point. This is the reason why i feel that Agile is the way to go. Not because i feel that it is technologically superior or something. For me the sole reason for an interest in it would be its importance on people over processes. Protecting people from the clutches of unwanted processes. Lets go back to each one of the above and see how Agile fits in there, even though i do not know the ABC of Agile (well as of now, i stand uneducated on this topic, but not for long)
1) This project is critical. We must deliver by this deadline
Well, you are a stake holder in the development too. And you also know how much effort we are putting in. With the iteration planning meetings, burn down charts, you get to know
where we are standing. We understand that this is critical, and you also understand that we also are doing our best. And do not try to push us too hard. Our scrum master is there to save us from thy wrath.
2) Give us a rough estimate of how many man hours would it take?Siddharth, come on, you said it was 15 days. That was a commitment to the client we made. Its unprofessional to go back on that.
Agile, completely understands the true meaning of an estimate. While it does want it to get better and better in terms of accuracy, whatever could not go in can be put in the backlog. Its the best we could do. And all along we track the progress with the burn down charts. We know that we have got a dip there and haven't met the expectation. But we are trying to close the gap in the chart.
3) Hmmm...so you said 4 days of effort. And you are 2 people. So that means this can be done in 2 days.
Agile realizes that while one resource could do a job in 4 days, the same can be done by another in 2 days and vice versa. So, if i am better, i get the task during the IPM since my odds were the best (i said that i can do it in 2 days flat while others would have taken 4 days, and not only that, i still get to explain why i can do it in 2 days and why it should not take more than that). Realize that what i am good at, he might not be and vice versa.
4) We need this, that, that, this, even this, even that in the demo. It cannot be done without it.
For Agile, the working code matters more than anything else. It is not the super cool UI they want in the very first iteration. They would come up with a working functionality, and tell the client that all these cool things can be added to it in another iteration. And best of all, they include the client in the whole process.
5) We have 2 resources dedicated full time for this.
Hmmm...I don't really know how Agile would help here, but from what i could gather from Aman, he used to say that for Agile, it is two team members which are important. They would rather pair up and program and would never say that it would be completed in 2 days flat. They understand that 1+1 is not always 2 in any practical case and if it were it would be the epitome of synergy.
With these ramblings, i think i better get to what i was doing. High time i started writing those dreaded essays.
