Comments for epistemologic http://epistemologic.com Amit Rathore's blog about software development and project management Sat, 17 May 2008 00:56:51 +0000 http://wordpress.org/?v=MU Comment on Why work at ThoughtWorks? by Ravi Mohan http://epistemologic.com/2007/02/01/why-work-at-thoughtworks/#comment-7863 Ravi Mohan Fri, 18 Apr 2008 12:26:18 +0000 http://epistemologic.wordpress.com/2007/02/01/why-work-at-thoughtworks/#comment-7863 Amit, As far as I know you **didn't** write that line. I got it from Nirmal's comment dated March 19! Of course I am assuming you replied to me and not to someone else. I know you better than to think you would write such .. ummm.. suboptimal .... sentences, Cheers, Amit,

As far as I know you **didn’t** write that line. I got it from Nirmal’s comment dated March 19!

Of course I am assuming you replied to me and not to someone else.

I know you better than to think you would write such .. ummm.. suboptimal …. sentences,
Cheers,

]]> Comment on Why work at ThoughtWorks? by Amit Rathore http://epistemologic.com/2007/02/01/why-work-at-thoughtworks/#comment-7862 Amit Rathore Fri, 18 Apr 2008 04:42:54 +0000 http://epistemologic.wordpress.com/2007/02/01/why-work-at-thoughtworks/#comment-7862 Yes, you're right of course. I wrote this when I was purely a developer, and the PM persona was definitely someone other than me :) In the intervening couple of years, I've gone back and forth between playing a dev-role and a PM-role - and have written things from a PM point of view. Not this one! Yes, you’re right of course.

I wrote this when I was purely a developer, and the PM persona was definitely someone other than me :) In the intervening couple of years, I’ve gone back and forth between playing a dev-role and a PM-role - and have written things from a PM point of view.

Not this one!

]]> Comment on Why work at ThoughtWorks? by Ravi Mohan http://epistemologic.com/2007/02/01/why-work-at-thoughtworks/#comment-7860 Ravi Mohan Fri, 18 Apr 2008 01:09:23 +0000 http://epistemologic.wordpress.com/2007/02/01/why-work-at-thoughtworks/#comment-7860 "Especially in Agile where the team works very closely, have developers and leads around does make a manager’s life easier. I typically like to involve my team while I am estimating for a requirement/story." Maybe the sentence is poorly constructed but if the "I" in the sentence refers to a PM, I'd like to point out that it is not the PM's job to "estimate for requirements/stories", whether you "involve your team" or not. One of the key practices of agile is that (s)he who does the work estimates the time it takes. The idea that the PM estimates the effort and the developers supply the effort as per that estimate is pre-agile. “Especially in Agile where the team works very closely, have developers and leads around does make a manager’s life easier. I typically like to involve my team while I am estimating for a requirement/story.”

Maybe the sentence is poorly constructed but if the “I” in the sentence refers to a PM, I’d like to point out that it is not the PM’s job to “estimate for requirements/stories”, whether you “involve your team” or not.

One of the key practices of agile is that (s)he who does the work estimates the time it takes.

The idea that the PM estimates the effort and the developers supply the effort as per that estimate is pre-agile.

]]> Comment on Why I don’t use real hours for sprint planning by Ravindar http://epistemologic.com/2008/03/14/why-i-dont-use-real-hours-for-sprint-planning/#comment-7858 Ravindar Thu, 10 Apr 2008 01:17:01 +0000 http://epistemologic.wordpress.com/?p=94#comment-7858 Oh yeah one more thing, this strategy has helped us even in very difficult times right now. I would not say we are perfect, far from it, but we have become good. Although things have gotten tough over the past couple of months with ever changing direction and much more, the team is still sort of together on this strategy, atleast I think. We did loose a little direction, but I think considering where we are as an organization this has really helped us keep our sanity. Oh yeah one more thing, this strategy has helped us even in very difficult times right now. I would not say we are perfect, far from it, but we have become good. Although things have gotten tough over the past couple of months with ever changing direction and much more, the team is still sort of together on this strategy, atleast I think. We did loose a little direction, but I think considering where we are as an organization this has really helped us keep our sanity.

]]> Comment on Why I don’t use real hours for sprint planning by Ravindar http://epistemologic.com/2008/03/14/why-i-dont-use-real-hours-for-sprint-planning/#comment-7857 Ravindar Thu, 10 Apr 2008 01:06:30 +0000 http://epistemologic.wordpress.com/?p=94#comment-7857 So obviously I agree with you Amit. As you know I actually implemented this strategy, with lot of stealth. We used to be a team that used to do sprint planning in which we would discuss till the cows came home about how many hours a task takes, what it should look like etc. etc. Well with gentle persuasion, the team saw the folly of their ways. We realized that maintaining sprint backlogs and all the activities associated with it were causing pain and in-fact slowing us down. So today we maintain a prioritized list of product backlog user stories(broken down to a reasonable size, which is an art in itself that you get better at as you learn and adapt) and the team picks off the top of the stack. So for example, the team is mature enough to know that to get a list of items on the UI, they need a UI pick list, database table etc etc, and don't feel the need to do this breakdown and estimate it. We do draw a line in the sand, your so called end of sprint. I still have to maintain a sprint backlog but no one on the team really cares about it. Over the past six months the team members felt it was a phony success and that real success was delivery as you pointed out. Obviously this comes with a mature team, but I think it is achievable. Also, obviously, there are teams that will find this too extreme and would like the rhythm approach. I guess every team finds their own path with this. I for one have become a fan of as Ravi Mohan pointed out: "pick the top priority card and work on it, damn the estimates" So obviously I agree with you Amit. As you know I actually implemented this strategy, with lot of stealth. We used to be a team that used to do sprint planning in which we would discuss till the cows came home about how many hours a task takes, what it should look like etc. etc. Well with gentle persuasion, the team saw the folly of their ways. We realized that maintaining sprint backlogs and all the activities associated with it were causing pain and in-fact slowing us down. So today we maintain a prioritized list of product backlog user stories(broken down to a reasonable size, which is an art in itself that you get better at as you learn and adapt) and the team picks off the top of the stack. So for example, the team is mature enough to know that to get a list of items on the UI, they need a UI pick list, database table etc etc, and don’t feel the need to do this breakdown and estimate it. We do draw a line in the sand, your so called end of sprint. I still have to maintain a sprint backlog but no one on the team really cares about it. Over the past six months the team members felt it was a phony success and that real success was delivery as you pointed out. Obviously this comes with a mature team, but I think it is achievable. Also, obviously, there are teams that will find this too extreme and would like the rhythm approach. I guess every team finds their own path with this. I for one have become a fan of as Ravi Mohan pointed out: “pick the top priority card and work on it, damn the estimates”

]]> Comment on Estimation considered harmful by Slade Stewart http://epistemologic.com/2007/05/12/estimation-considered-harmful/#comment-7856 Slade Stewart Wed, 09 Apr 2008 00:51:03 +0000 http://epistemologic.wordpress.com/2007/05/12/estimation-considered-harmful/#comment-7856 Great post. It's really good to see hard questioning around the idea of 'why we're so keen on estimating' in the industry, even if I don't completely agree (I suspect overall neither do you, completely) with the premise that 'all estimating is evil and unnecessary'. Some semi-random thoughts around that area (that, taken as a whole and thematically, might strike **someone** as a cogent and cohesive reply post - who knows?) -- 'The need for accurate estimates' is one of those deeply-grained assumptions that no-one ever seems to question. People can give textbook answers as to why, but when you compare reality to the theoretical reasons, they don't jibe -- One answer to 'why we need estimates' (an answer implicit in the literature of 'old-school' software development as well as agile) is 'to help the business plan' (timing, budget, etc.). However, in my experience, time and again, both in internal IT shops and 'external product development shops', it begins with the pretending that we can estimate things accurately, and then when the dates aren't hit, what adjustment is made? just 'get it done as quickly now as possible'. No 'we'll drop this feature' or 'if we exceed the budget by this much the project isn't worthwhile' or any of that stuff touted in the older textbooks or the new Agile textbooks. Just 'get it done as quickly now as possible'. You alluded to this in your post (i.e., 'what is necessary will get done when it gets done, and we just have to live with that'). If the decisions were really being made based on accuracy of the estimates, I would expect to see some changes when the estimates change (in more Agile / RAD / whatever shops, the changed estimates are earlier. In more traditional shops, the changed estimates are often 11th-hour. But in any case, in my experience the result is usually the same - 'just get it done as fast as you can') -- I'll go ahead and say it: deep down, most managers, business sponsors, product owners, all those types, cling to 'accurate estimates' for one main reason: they have a voice of dread that tells them they don't have any control over a software development project (who does, when it comes right down to it?), and insisting on 'sticking to estimates' is their ritual, their talisman, that gives them the illusion of control and is the only thing that can quiet that voice -- I think the reason a lot of Agile books don't just come out and say these things outright is because then the people who need to buy off on Agile would not buy off on it. I can understand this - in my opinion, Agile is overall a Good Thing, and why encourage 'throwing the baby out with the bathwater'? Great post. It’s really good to see hard questioning around the idea of ‘why we’re so keen on estimating’ in the industry, even if I don’t completely agree (I suspect overall neither do you, completely) with the premise that ‘all estimating is evil and unnecessary’. Some semi-random thoughts around that area (that, taken as a whole and thematically, might strike **someone** as a cogent and cohesive reply post - who knows?)
– ‘The need for accurate estimates’ is one of those deeply-grained assumptions that no-one ever seems to question. People can give textbook answers as to why, but when you compare reality to the theoretical reasons, they don’t jibe
– One answer to ‘why we need estimates’ (an answer implicit in the literature of ‘old-school’ software development as well as agile) is ‘to help the business plan’ (timing, budget, etc.). However, in my experience, time and again, both in internal IT shops and ‘external product development shops’, it begins with the pretending that we can estimate things accurately, and then when the dates aren’t hit, what adjustment is made? just ‘get it done as quickly now as possible’. No ‘we’ll drop this feature’ or ‘if we exceed the budget by this much the project isn’t worthwhile’ or any of that stuff touted in the older textbooks or the new Agile textbooks. Just ‘get it done as quickly now as possible’. You alluded to this in your post (i.e., ‘what is necessary will get done when it gets done, and we just have to live with that’). If the decisions were really being made based on accuracy of the estimates, I would expect to see some changes when the estimates change (in more Agile / RAD / whatever shops, the changed estimates are earlier. In more traditional shops, the changed estimates are often 11th-hour. But in any case, in my experience the result is usually the same - ‘just get it done as fast as you can’)
– I’ll go ahead and say it: deep down, most managers, business sponsors, product owners, all those types, cling to ‘accurate estimates’ for one main reason: they have a voice of dread that tells them they don’t have any control over a software development project (who does, when it comes right down to it?), and insisting on ’sticking to estimates’ is their ritual, their talisman, that gives them the illusion of control and is the only thing that can quiet that voice
– I think the reason a lot of Agile books don’t just come out and say these things outright is because then the people who need to buy off on Agile would not buy off on it. I can understand this - in my opinion, Agile is overall a Good Thing, and why encourage ‘throwing the baby out with the bathwater’?

]]> Comment on Why I don’t use real hours for sprint planning by Premanand Chandrasekaran http://epistemologic.com/2008/03/14/why-i-dont-use-real-hours-for-sprint-planning/#comment-7848 Premanand Chandrasekaran Thu, 20 Mar 2008 21:42:06 +0000 http://epistemologic.wordpress.com/?p=94#comment-7848 Amit, Very well said. I'd like to take what you're saying a step further. In my ideal world, we shouldn't be required to estimate at all. Just keep picking the next important thing and get it done. If something starts taking too long, discuss alternatives. Obviously, high levels of maturity and trust are needed for this arrangement to work. In this life, maybe... Amit,

Very well said. I’d like to take what you’re saying a step further. In my ideal world, we shouldn’t be required to estimate at all. Just keep picking the next important thing and get it done. If something starts taking too long, discuss alternatives.

Obviously, high levels of maturity and trust are needed for this arrangement to work. In this life, maybe…

]]>