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

[Satyaprakash Joshii]

Not if there are bugs and therefore rework. I was talking to someone today (not on my team) who wasted a couple hours on what could have been a ten minute task because of being pressured/distracted. Definitely not better.

Thank You.

This is logically correct. What can a proper way to put this forward to the architect without sounding that I am complaining for something? I communicate with architect using emails, chats and Skype meetings.

[Junilu Lacar]

In Thinking Fast and Slow, Daniel Kahneman writes:

One of the significant discoveries of cognitive psychologists in recent decades is that switching from one task to another is effortful, especially under time pressure.

Daniel Kahneman, PhD, was awarded the Nobel Memorial Prize in Economic Sciences for his groundbreaking work in applying psychological insights to economic theory. This book is about the work he did that got him the award. He writes about System 1 and System 2 thinking which are "automatic" and "effortful," respectively.  This article explains System 1 and System 2 thinking further: https://bigthink.com/errors-we-live-by/kahnemans-mind-clarifying-biases.

Programming involves System 2 thinking. Programming is effortful thinking: it requires energy to think and find ways to ensure you're writing a program correctly. We are often mentally and physically exhausted after a long day of programming. Going back to your scenario of "finishing" multiple tasks, it's highly improbable that finishing 6 to 7 tasks in 40 hours, under pressure, results in work that is comparable in quality as the work done on 4 tasks that are completed at a pace where focus and attention to detail can be sustained. Add on to that the effort involved in task/context switching and your scenario of 6 or 7 tasks under pressure versus 4 tasks at normal pace becomes very far-fetched and improbable.

[Junilu Lacar]

Satyaprakash Joshii wrote:This is logically correct. What can a proper way to put this forward to the architect without sounding that I am complaining for something? I communicate with architect using emails, chats and Skype meetings.

That was pretty much the same thing I was saying, except Jeanne has a way with words that goes over more nicely with people. I must learn how to express things more like Jeanne does.

Anyway, I doubt there's much you can say to your architect. As we've seen with Jeanne and myself, the messenger is often just as important as the message. I don't know the exact nature of your organization or your reporting structure or your relationship with the architect but I'm willing to bet that the architect sees you as an underling. It's hard for people to take advice from underlings, especially if the advice involves something they were not doing well. You've already established that your team culture is not exactly one of transparency and owning up to mistakes. The architect would have to acknowledge being wrong about his methods. Doing that at all is going to be difficult. Doing it based on the opinion of an underling, well, it's probably not going to happen.

It might be better if someone else, someone who is more impartial and objective, pointed some of these things out to your architect and ScrumMaster. Ideally, you'd have a coach who pulls them aside and explains to them the errors in their methods.

[Liutauras Vilda]

Satyaprakash Joshii,

Cowgratulations, your topic has been picked to be published in CodeRanch's August journal.

[Jeanne Boyarsky]

Agreed on Junilu's advice to find an ally. Given the architects point of view, he/she doesn't see you as an equal who can suggest stuff. One approach that (is unlikely to but) might help is to send your architect a link to a short article that explains the concept. Then you can share it as "I read something interesting and was wondering if we could try it out for a sprint" vs "you are doing it wrong".

Does your team have retrospectives? What format do they use? I ask because this might suggest a way of productively bringing this up.

Another question is the communication channels. I notice that in person and phone aren't options. (Unless the Skype meetings can be one on one). Are you in an offshore type arrangement where your development shop is viewed as a factory?

[Jeanne Boyarsky]

Junilu Lacar wrote:That was pretty much the same thing I was saying, except Jeanne has a way with words that goes over more nicely with people. I must learn how to express things more like Jeanne does.

Gee thanks. I learned how to communicate by watching others. So it is definitely learnable by observation!

[Junilu Lacar]

Jeanne Boyarsky wrote:So it is definitely learnable by observation!

It's best to learn from some of the best.

[Satyaprakash Joshii]

One approach that (is unlikely to but) might help is to send your architect a link to a short article that explains the concept. Then you can share it as "I read something interesting and was wondering if we could try it out for a sprint" vs "you are doing it wrong".

What about sending an email to architect and manager saying " Being closely working with the team, I have some suggestions which can be better for the team. 1) Every developer should work not with the target of showing the happy flow but with intention of completing the task because otherwise it will create a mess which will take more time for himself or other developer to clear later on. "

I am the team leader of our small team where we work from offshore and work is given from onshore by architect and manager,  so me sending such suggestion should be logically correct. Or is there any better way to put this on email?

[Junilu Lacar]

Satyaprakash Joshii wrote:...an email to architect and manager saying " Being closely working with the team, I have some suggestions which can be better for the team. 1) Every developer should work not with the target of showing the happy flow but with intention of completing the task because otherwise it will create a mess which will take more time for himself or other developer to clear later on.

The reasoning you give is illogical. How are showing the happy flow and completing a task opposites of each other? How does showing happy flow create a mess? How does completing a task prevent a mess? How is any of that even related to any of the cause-and-effect relationships we've discussed so far in this thread? I don't see how you can answer these questions logically.

[Satyaprakash Joshii]

This is because the architect asks to complete the task as soon as possible, show it to be working and take up the new task without caring about quality at all.  If any developer for example me or anyone is asked is the task completed and he replies says yes, he is asked to give demo of it (which may be just running a happy flow) and is them asked to take up new task. It often happens that developers on pressure say I have completed the task today and show it to be running but that does not gaurantee that all scenarios are running fine and it has good quality and less bugs. Later on if  issue comes the developer would be working on new task now and not available to correct the code. If work in a code which I get to be running and I can show the demo fine but I can see some visible major obvious issue, I won't call the code complete. Let me know of this is incorrect.

[Junilu Lacar]

My comment had nothing to do with what you said being correct or incorrect. I said that what you said is illogical, meaning that there was no coherent thread of logic running through all your statements that pulled them together into a solid argument. Neither does your last explanation for that matter.

I suggest you go back over what has been discussed so far and really understand what it is we're suggesting. Part of the problem may be that you just don't know how to express yourself in a way that we find convincing and true to the argument, the main points of which can be summarized as:

1. Whoever does the work should be the one who gives estimates

2. Estimates are inherently inaccurate; don't play the game of "giving accurate estimates."

3. Don't use estimates to people's feet to the fire in order to get as much work done. Estimates are not commitments.

4. Predictability comes from consistency and flow. If you are consistently writing poor-quality software, then you will predictably have lots of rework and consequently, poor and unpredictable flow. If your work is consistently sized and you consistently build with a focus on quality, then you can achieve more predictable flow.

5. Pressuring people to finish work is usually counterproductive. Help them find ways to work smarter and more effectively instead and create an environment where they can focus on doing their jobs well.

6. Task switching is waste.

[Junilu Lacar]

Let me put it this way: You want to change the architect and manager's way of dealing with the developers. Currently, they pressure the team and use estimates as commitments. You want them to let up the pressure. You need to argue the point that undue pressure on the developers is counterproductive and will result in less productivity because of increased likelihood of poor quality in the work. We have given you many points to support the position that developers should be allowed to estimate their work so that they are more realistic and account for the time it takes to do the work with all the due diligence necessary to produce quality work.

[Jeanne Boyarsky]

I came across a nice cartoon in this space. Estimates are not motivation to work faster

[Satyaprakash Joshii]

Junilu Lacar wrote: Part of the problem may be that you just don't know how to express yourself in a way that we find convincing and true to the argument.

What did I do wrong and how can I do that differently?

Overall, the thread was quite useful and I have gone through it again. Also,  thanks for summary too.

[Satyaprakash Joshii]

Junilu Lacar wrote:and you consistently build with a focus on quality, then you can achieve more predictable flow.

I did not understand the meaning of predictable flow here? If it is all about writing quality code then why is it being called as predictable flow.

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:What did I do wrong and how can I do that differently?

I don't think you did anything wrong. However, I don't think your argument would work here. The architect is trying to get them to commit to more work in a sprint. It isn't that he is ignore paths other than the happy path.

Satyaprakash Joshii wrote:I did not understand the meaning of predictable flow here? If it is all about writing quality code then why is it being called as predictable flow.

In Scrum, there is the concept of "velocity". That's the number of story points/amount of work that a team can accomplish in a sprint.

[Satyaprakash Joshii]

got it thank you.

[Junilu Lacar]

Satyaprakash Joshii wrote:

Junilu Lacar wrote:and you consistently build with a focus on quality, then you can achieve more predictable flow.

I did not understand the meaning of predictable flow here? If it is all about writing quality code then why is it being called as predictable flow.

Flow means that you have a consistently steady stream of stories coming into your development pipeline and you're doing the necessary work at a sustainable pace to produce a steady stream of increments of shippable software.

Quality issues like bugs, integration problems, configuration problems, infrastructure problems, security problems, etc. make that flow of stories-to-software inconsistent because they introduce variations and disruptions. Time you spend on dealing with quality issues is time that could have been spent producing more valuable software. Therefore, the flow becomes unsteady and less predictable. The more quality issues you have, the less steady and less predictable your flow will be. That is, the rate at which you produce valuable software will be more erratic and unpredictable.

Therefore, good code promotes flow which increases your predictability. When you're predictable, estimates will be more reliable. In fact, when you're very predictable, estimates become redundant.

[Satyaprakash Joshii]

I tried to follow the advice and the results looked fine for few sprints. The cases of "sprint goal not met" also got reduced to minimum. However yesterday the architect called me on skype messenger and said he wants to let me know the feedback about me. He said I am not aggressive in work and need to be aggressive. He said being senior in the team, they have more expectations from me to work aggressively and not slow.

[Paul Clapham]

It sounds to me as if the architect and you have different approaches to risk-taking. Doing something "aggressively" seems to me to mean that things might "fight back" -- in this case, the code you design and implement might subsequently fail because of undiscovered bugs.

Now to me, and maybe to you too, undiscovered bugs seem like a bad thing. But it's possible that in your environment they aren't all that bad. There are environments where it's better to get some code out into the field and deal with the bugs later, for example when you want to release something before a competitor does. On the other hand if an undiscovered bug in code which you release causes thousands of your customers to file incorrect tax returns, that's definitely a bad thing. And on the other other hand, maybe delaying a release to fix everything might cause thousands of your customers to file late tax returns. Also a bad thing.

I don't know what kind of environment you're working in, so either of those scenarios might be realistic. So maybe you need to talk to the architect and discuss reasonable levels of risk in your work.

[Satyaprakash Joshii]

Ok, I will see what I can do from my side on that aspect.

Also,  I have decided to speak up. I have decided to speak to the manager on the below about the architect :

1) There have been multiple times when architect said something during the stand up meetings but said something else during the demo. Example he first said let us quickly show this demo after 3 days.  I told that in this much time only happy flow will be possible. He said that is fine. However when I showed that during the demo he showed he is surprised why the rest was not complete.He does this on multiple occasions. I will speak up this to the manager.

2) The architect told me to find and do code quality fixes while doing the coding itself. This is a good thing and I am already doing it now. However he says to quickly show the demo and take up new tasks after that  ignoring the visible bugs. Also he says that he thought this was already completed when he is being given status daily in stand up calls. When I had an issue with a design and got stuck, I sent email immediately to the architect. He did not reply for and after long time during the meeting we could discuss that and the demo. Was was scheduled 2 days after that How can all this be possible together.


I will keep my resume ready but at least speak up.

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:Also,  I have decided to speak up. I have decided to speak to the manager on the below about the architect.

Good! Your manager could become an ally here in having reasonable expectations.

[Satyaprakash Joshii]

When I talked with the manager regarding it, he told me that you are hard working and organised but not aggressive in work. Also,I said that quickly showing something to be working fine in the demo and take up next task but ignoring bugs and code quality issues may later result in rework in correcting the code and doing code quality fixes for which one may not even get time later on. To this he said they(he and architect) decide the estimates after a lot of thinking and it should have enough time for writing quality code without ignoring bugs.

[Junilu Lacar]

It's "leaders" like those that put the "Faux" in Faux Agile and the "Dark" in Dark Scrum  

I sympathize with your situation and hope you can find a better place to work soon.

[Junilu Lacar]

This is from the Official Scrum Guide (emphasis is mine):

"The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate."

Unless that manager and/or architect are the ones performing the work, they have no right to impose the estimates they "thought hard about" on people like you who will do the actual work.

[Satyaprakash Joshii]

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?

[Jeanne Boyarsky]

Satyaprakash Joshii wrote: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.

Which implies that Developer Y or Z were slacking before and not doing their best. Pessimistic assumption for management to make! Unless they did something to change it like provide training or a framework that makes things faster or something.

Satyaprakash Joshii wrote: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)?

It's not linear, but on some level yes. I expect an experienced person is going to complete a task faster than an entry level person at the same quality outcome. Similarly, if someone is new to a language, I expect them to be slower.  Noticed how one of these is tied to salary and the other is not.

But coding faster isn't the biggest value of more experienced/expensive developers. Having an insight that saves a week of work is way more valuable than working faster.

Satyaprakash Joshii wrote:What does working aggressively actually mean?

Management buzzword .

[Satyaprakash Joshii]

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?

[Jeanne Boyarsky]

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.

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.

[Satyaprakash Joshii]

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.

[Junilu Lacar]

Agility is not about making developers "produce more, faster" -- Seems like most people who claim to do Agile these days are getting it wrong. WTH.

Agility comes in the long run when developers are given the space to do their work at a SUSTAINABLE pace. That means they are allowed the time to write quality code. They are allowed time to learn. They are allowed time to make mistakes and learn even more.

When you have managers and tech leads cracking the whip as you have been describing, that's not developing at a sustainable pace. They are only driving your organization to the breaking point faster. When that happens, everybody loses.

[Jeanne Boyarsky]

Satyaprakash Joshii wrote:

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.
....Deciding where one would spend time requires authority too.

So you are the most senior developer but not empowered to make these decisions. That seems awkward!

[Junilu Lacar]

"Deciding where one spends time requires authority, too" --

Product owner - decides which stories developers should spend their time on.

Devs - decide whatever the h*ll to spend their time on, as long as it's spent on the stories the product owner has told them to spend time on getting DONE.

That's the division of authority you should have.

[Satyaprakash Joshii]

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

[Jeanne Boyarsky]

Satyaprakash Joshii wrote: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).

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

[Satyaprakash Joshii]

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?

[Jeanne Boyarsky]

Satyaprakash Joshii wrote: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?

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. Also note that many of these activities save the team time in the long run. For example, mentoring a junior dev lets him/her complete tasks faster. Identifying problems in advance saves tons of time that would have been wasted.

That is how it is supposed to work. It sounds like your company is disfunctional and just wants you to crank out code without complaining.

Is there anyone at your company that is senior and you can trust to ask for advice. Even if he/she isn't allowed to do anything but code, you can talk during lunch to get advice, right?

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.) Also, I bet you have other activities like performance appraisals or company meetings.

[Rebekka Broadhurst]

This sounds like a bad planning. You probably should bring it to your team lead's attention as it will only be getting worse. You shouldn't be in a constant crunch (unless you're working in Rockstar - but that's not OK too)

[Campbell Ritchie]

RB, welcome to the Ranch

[Satyaprakash Joshii]

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.