How to deal effectively with short 10 day sprints without feeling pressure?

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:and if he will be putting more user stories during the meeting itself , I will say ok if you want to add this buy the estimates are different.

Adding more stories shouldn't change the estimates for the original stories. The conversation should be about whether the new stories are higher priority than the original stories.

Satyaprakash Joshii wrote: I will not worry and keeping doing work according to my estimates whether they are taken or not.

Good plan!

Useful advice but if senior developer is piled with work , then it will not work exactly at this.

Your company sounds broken

[Junilu Lacar]

There is something fundamentally wrong with you saying, "I will keep working according to my own estimates." Estimates are supposed to be a way to tell other people when to expect your work to be done. That gives them an idea of how to plan at a larger scale, to see how your work fits in with all the other work that needs to get done. If estimates are used in any other way, that to me is a sign of dysfunction.

Estimates are not commitments either. You shouldn't have to think that just because you said "I estimate that this will take me 2 days to finish," you MUST be done in two days. Again, that's missing the point of giving an estimate. How many times do we have to go over this concept anyway? It seems we've tried to make this point numerous times in this thread but you keep coming back to using estimates as some kind measure of performance.

ESTIMATES ARE NOT A WAY TO MEASURE PERFORMANCE OR PRODUCTIVITY!!!

We are programmers, not psychics. I have never met a single developer who can foresee the future in terms of saying with 100% certainty that they can complete a non-trivial task that they have never done before, that they have no similar experience doing, and the details of which still have to be discovered through an iterative and empirical process. Anyone who says they can give 100% accurate estimates 100% of the time given these conditions is a big fat liar.

[Campbell Ritchie]

Junilu Lacar wrote:. . . just because you said "I estimate that this will take me 2 days to finish," you MUST be done in two days. . . .

Saying that sort of thing would be a serious mistake. You should suck through your teeth like a builder and say, “Oooooooooooooooooh! There's a good three days' work there, Guv.” They will worry a lot less when it actually runs into the fourth day.

[Jeanne Boyarsky]

Junilu Lacar wrote:Estimates are not commitments either.

Agreed. At the same time, if someone estimates that a task is going to be on Thursday, I should be pleasantly surprised if it is done on Tuesday. I shouldn't *expect* that which seems to be the problem at the original poster's company. They "estimate" for him and then get upset when he doesn't meet the date they made up.

Early in my career, a manager told me that she needed a task done on Monday. I said it would be done on Wednesday. She kept repeating it needed to be done Monday. (I think this was a ploy to work the weekend.) I responded my saying it would be two days late. Guess when I delivered?

I know more now and can negotiate scope. But my approach at that time was at least entertaining!

[Junilu Lacar]

Jeanne Boyarsky wrote:Early in my career, a manager told me that she needed a task done on Monday. I said it would be done on Wednesday. She kept repeating it needed to be done Monday. (I think this was a ploy to work the weekend.) I responded my saying it would be two days late. Guess when I delivered?

I know more now and can negotiate scope. But my approach at that time was at least entertaining!

And this is exactly what I meant by there being something fundamentally wrong with saying "I will work according to my own estimates."  It's that lack of negotiation of scope. The lack of transparency and collaboration. It's the implied passive-aggressive behavior of saying "Ok, you keep saying it's going to take two days but I know it's going to take four, so I'm just going to work based on me knowing it's going to take four days." While that helps you keep your sanity and perhaps your  dignity as a developer, it does nothing to address the urgency expressed by the people who are trying to coerce you into making a commitment to deliver sooner than you expect to be done.

The dysfunction of having an architect or manager who don't actually do the work impose their "estimates" NEEDS to be addressed. You need to have an honest and open conversation with them. Ideally, you would have some kind of mediator or facilitator guide that conversation so that there is some way to even out or counteract the imbalance of power between the two sides that are in conflict.

[Jeanne Boyarsky]

Junilu Lacar wrote:The lack of transparency

I was pretty transparent in saying I couldn't meet the date she was trying to impose . I wasn't willing to end the conversation making it sounding like I was promising to deliver on the date she "suggested."

I do get what you are saying and agree. It takes time to acquire the negotiation skill.

[Satyaprakash Joshii]

Junilu Lacar says

How many times do we have to go over this concept anyway? It seems we've tried to make this point numerous times in this thread but you keep coming back to using estimates as some kind measure of performance.

I had understood your point earlier. Estimates should come from me the developer. I will be giving the estimates.\

I just meant that in case the architect is not ready to take my estimates and forcefully adds his estimates, I will still be working with my own estimates (because I do not want to get my technique wrong by working without estimates. The technique is to have your estimates and work with them). My team , company can change in future but my technique is more important as it will be there with me irrespective of the company I work for. So , I will keep my technique correct in either case.

[Satyaprakash Joshii]

Jeanne Boyarsky says

But my approach at that time was at least entertaining!

Jeanne Boyarsky says

I wasn't willing to end the conversation making it sounding like I was promising to deliver on the date she "suggested."

I understand from this that one should say in that case with honesty that it will take these many more hours and not end the conversation with "ok" in such a case.  In that case if the architect ignores that  still forces his estimate, then it will come as spint goal not met at the end of sprint. In that case the explanation for it can be something like  " The tasks for this user story took more time than estimated. Thats all.

[Satyaprakash Joshii]

I have realised and learnt a lot of things in this post:

1) I realised that anyone working with self doubts at work can lead to problems. Do good work with correct approach and keep good

confidence, self esteem at work. A developer having self doubt can even be exploited.

2) The agile sprints will be more successful if developers have their say in the estimates. Ideally developers should give the

estimates.

3) It is not necessary the senior most developer works the fastest. It is good for senior member in the team to work fast, and have some hours in the week for other things because their responsibility is also to mentor juniors, check if they are stuck anywhere, give them direction, bring insights.

[Jeanne Boyarsky]

This seems like something to talk to your manager about. That you believe the architect is committing to dates that are unrealistic. You brought this up and were overruled.

[Satyaprakash Joshii]

Jeanne Boyarsky says

She kept repeating it needed to be done Monday.

Jeanne Boyarsky says  

I responded my saying it would be two days late.

Jeanne Boyarsky says

I wasn't willing to end the conversation making it sounding like I was promising to deliver on the date she "suggested."

What is a way of not ending such a conversation without "ok" if you are being told as you mentioned above and then you are told that again ?

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:What is a way of not ending such a conversation without "ok" if you are being told as you mentioned above and then you are told that again ?

Atrophy. Keep insisting that you don't agree with estimate until the other party gives up.

This comes with the risk of you being labeled as argumentative. So you have to feel safe in your job to do this. But it forces the conversation that really needs to be had.

[Campbell Ritchie]

You are going to end the conversations with, “All right, then, but it still won't work,” and start the next conversation with, “I told you so.”

That isn't good

[Junilu Lacar]

Satyaprakash Joshii wrote:My team , company can change in future but my technique is more important as it will be there with me irrespective of the company I work for. So , I will keep my technique correct in either case.

Certainly, this attitude is coming from a good place. However, estimates have no direct relation to your "technique" as you call it, if I understand what you're referring to correctly. Again, your understanding of the problem is what influences your estimates and how close they get to the actual time it takes to complete the work. If your understanding changes and you realize that it would take longer than you originally thought, no amount of "technique" will help. It is what it is and only when you fully and clearly understand what the extent of "what it is," really is can you give an estimate that is reasonably close to what your actual will be.

Writing programs often doesn't lend itself well to knowing the exact extent of the work beforehand, especially if you have never done something it before. It is empirical work. You discover things as you go and you need to adapt. Again, no amount of technique will help you know up front whether or not your estimates are going to be "accurate". It's all about clearly and fully understanding what the heck it is you need to do.

[Junilu Lacar]

Campbell Ritchie wrote:You are going to end the conversations with, “All right, then, but it still won't work,” and start the next conversation with, “I told you so.”

That isn't good

Absolutely agree.

I don't know if this will work in OP's situation since I have the impression that the manager and architect are of a fixed mindset and very command-and-control type people. Ideally, you should be able to discuss their concerns with them and to figure out what motivates them to do what they do. What value do they think they get from imposing their estimates on the developers instead of having the developers give their own estimates?

Point out the dysfunction and the detrimental things their actions have on the teams and individuals the work with. Try to find alternative ways to address their concerns that are aligned with the values and principles of agility. This is a complex conversation to have and it's difficult to quarterback and coach from afar. If he's lucky, OP can have a fruitful conversation like this with his manager and architect. Given what has been said about these people already in this thread though, I doubt there's much OP can do to change their minds or their ways. We can only hope for the best for OP. Good luck.

[Campbell Ritchie]

Junilu Lacar wrote:. . . the manager and architect are of a fixed mindset . . .

Do we know whether it is only this particular team or department with that problem, or the whole company?
Also, do the company worry when they find all their staff asking for references so they can apply elsewhere?

[Satyaprakash Joshii]

This comes with the risk of you being labeled as argumentative. So you have to feel safe in your job to do this.

Not thinking about arrogance but I have realised that the only way to work in IT Industry is to do good work with good approach and work with a lot of self confidence while not be afraid of anyone.

[Satyaprakash Joshii]

Do we know whether it is only this particular team or department with that problem, or the whole company?
Also, do the company worry when they find all their staff asking for references so they can apply elsewhere?

Most employees seem to be under pressure and staying late etc. However there is 1 guy I have seen who can work even faster than the pace they expect despite being a junior resource. Till now I have seen just 1 such guy. Else most are under pressure . Despite being a company with less than 100 resources in India, the number of employees leaving the company and joining the company look quite high every now and then.

[Satyaprakash Joshii]

Junilu Lacar says

They have to change their mindset and meet you in "the middle". Only in that middle ground where the team can willingly and honestly agree to the work they will own can there be any hope of bringing back rationality, transparency, honesty, and integrity into the situation.

Yes , as you had said in advance , this looks like to have happened a bit now at the cost of me being labelled "not aggressive". However, I have heard this "non aggressive" for few other resources too.  My attitude is to try and understand what exactly is aggressive and do my part in that direction but as Jeanne Boyarsky said it is a "management buzzword".  

[Satyaprakash Joshii]

Whatever be the case , I have learnt a lot in this thread and it has changed my mindset. I understood that there was 1 mistake that was from my side too that I was not confident at work . Employees who are confident would do better for the company and for themselves too. Other than that I have realised the other things listed by me few posts above.

[Junilu Lacar]

Good luck, Satya. Let us know how things are going in a month or so. Hopefully, you can report back here and say you've found a new job where management takes care of their developers and tries to protect them from pressure rather than putting them under pressure.

All the best.

[Jeanne Boyarsky]

Also, you are a developer and not a resource! A stapler is a resource.