Satyaprakash Joshii

I work in a team at offshore which works with onsite team and follow 10 day sprints. During the first day of the sprint the architect from onsite gives the requirements in Power point PPT diagrams. During the sprint also some requirements changes. Since, I am the senior most in the offshore development team, I share this with rest of team and we all work on these requirements. It has been seen that at the end of 10 day sprint when we give a demo , some of the requirements have been missed or wrongly implemented.

The reasons for this are :

1. On first day of the sprint during our evening (end of the day) on skype meeting, we are shown and shared with at PowerPoint presentation slide has diagram of what we are supposed to implement in the remaining sprint. After seeing the diagram some doubts/clarifications come to mind, I ask immediately which he speaks and I note down quickly. I need to try to minimise any errors in noting down the clarification correctly.


2. The diagram shown on the first day is good but bit abstract so there would be a lot of design implementation doubts which get cleared in coming days.

3. Some of the doubts/clarification do not immediately come to the mind during the meeting on first day of the sprint and come to mind at a later stage. I send email to ask these questions of the next day.

This causes 2 problems :

1) Once the reply comes, it may be 3rd or 4th day of the sprint and we are left with lesser days to implement.
2) There may be error in my understanding of the requirement implementation  which architect from onsite intends to give us and what I understand as we have to implement.


What can be a way to make sure that the requirements are not missed and we end up implementing exactly as the architect wants us to implement?

Thank You.

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 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".  

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.

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.

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 ?

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 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.

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.

Finally, NOBODY codes 80 hours a sprint. Even if your workweek is 40 hours, you do go to the bathroom right?  And attend Scrum meetings (or status meetings.)

That is a good point.


During the meeting at the start of meeting, the architect wants add more user stories saying I think it is doable. He says to give estimates and if I tell the estimates on higher side he gets upset . I have decided that my strategy now will be such that during the meeting at the start of sprint when he will be talking of estimates, I will say I will do estimates after this meeting 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. I will stop the conversation here and work with my own estimates which I will keep separately (in case he does not take my estimates) and let whatever happens. I will not worry and keeping doing work according to my estimates whether they are taken or not.

I'm not suggesting overtime. Senior devs typically spend less hours per week coding so there is more time for the other activities. However, they also tend to code faster overall

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

Mentoring others. Identifying problems in advance. Pushing back when what the team is asked to do doesn't make sense. Offering design options.

Some of these activities require some time to be spent. Suppose it requires 2 hours of time in a week ( 4 hours in a 10 day sprint) and I am working on a user stories for 80 hours. So does time for such activities has to be taken during those 80 hours only or the user stories have to be for 80-4 =76 hours?

Thanks. As I am the senior most developer in the team, what all actually are the ways in which I am supposed to contribute more than other juniors? (I understand that working on the aggressive estimate 'given' to me is not one of the ways).

Well sure. Different people code at different rates. However, there's not a one to one mapping with experience/pay. Lots of factors go into it.

Yes. I am the most senior developer in the team. They have more expectations from me.

I'm one of the faster programmers. I can definitely code more than twice as fast as some of my teammates. However, this doesn't make me do twice as many tasks. I spend time on analysis, pairing, helping others develop their skills, etc.

This is a good point.

Does analysis here mean analyzing the requirement?. Deciding where one would spend time requires authority too.

Which implies that Developer Y or Z were slacking before and not doing their best

Assuming Developers X,Y,Z were all doing their best. Suppose management have expectation that some work can be done in say 16 hours with quality and without ignoring bugs. Developer X takes 32 hours for it doing it with the same quality and without ignoring bugs.Since their expectation is not met, they replace him with developer Y who does this in 24 hours with same quality and without ignoring bugs. They replace him with developer Z who does this in 16 hours with same quality without ignoring bugs. Would this way they would not succeed in getting what they wanted?

This thread has changed my mindset in professional world.

Although it is not good for me but I am thinking that their strategy may still work for them. They may try this with Developer X and it may not work but they may replace developer X with Developer Y and as everyone has different speed may be Developer Y or Developer Z be able to work at double the speed while maintaining quality and not ignoring bugs.


In a team all developers are at different experience level and different salary. So does the management expect the senior most developer or the developer hired at higher salary to work more faster then others (while maintaining quality and not ignoring bugs)?


If they think that "Yes this is not Agile so what? This is customized agile".


What does working aggressively actually mean?