5 ms·

What is now called "agile" (which has been bastardized from the late 90's "XP") is specifically designed to stop this from happening: every day, you have to "st

What is now called "agile" (which has been bastardized from the late 90's "XP") is specifically designed to stop this from happening: every day, you have to "stand up" and recite what you did yesterday and what you're going to do today. If "scrum" is being followed properly, there's somebody listening who's actually recording what you said you were going to do yesterday and compare it to what you say you did yesterday and call out any discrepancies. So no, you don't need permission to do something as long as it only takes an hour or so and you can hide it somewhere in your daily standup tasks. Anything that takes longer than this needs to be reviewed and approved - and this is entirely the point of the methodology and the only reason it's ever adopted.

wellthisisgreat 5y ago
> every day, you have to "stand up" and recite what you did yesterday and what you're going to do today. If "scrum" is being followed properly, there's somebody listening who's actually recording what you said you were going to do yesterday and compare it to what you say you did yesterday and call out any discrepancies. This is the best explanation of this metgodology I’ve ever read
- Stratoscope 5y ago
  > This is the best explanation of this metgodology I’ve ever read [emphasis added] I assume that is a typo, but if it is, it's my favorite typo of the week, because it reflects so well how I feel about that kind of daily standup: scrum masters who act like little tin gods. Most of the companies I've worked with take a more practical approach, but I have been involved with some who did it exactly the way GP described. It really rubbed me the wrong way.
  - wellthisisgreat 5y ago
    Absolutely a typo :) thanks for bringing it to my attention (obviously not fixing it)
- Mauricebranagh 5y ago
  Isn't this counter to what RAD/AGILE what have you? Yesterday a look at solution a for problem y and it turns out that was a dead end so we wont do that any more. Today Looking at solution b for y or can we solve y by doing something else
probablyfiction 5y ago
Exactly. Agile is sold as a way to increase productivity, but the practices seem to be about reducing autonomy for team members.
- phone8675309 5y ago
  "Increased productivity through micromanagement" is a manager's most exciting dream, and that's what agile (big A or little a) provides.
Delmania 5y ago
> If "scrum" is being followed properly, there's somebody listening who's actually recording what you said you were going to do yesterday and compare it to what you say you did yesterday and call out any discrepancies. Seems to me that if you can't justify why not keeping your stated commitments was in the interest of the team and the company, then the issue is with your communication and not the process itself.
- dkarl 5y ago
  Exactly. And if somebody wants to complain about a process methodology not working because management at their company is stupid or a bunch of assholes: nothing fixes that. 90% of the time the cure for needing to do "undercover" work is explaining that it is needed to accomplish what the company expects to get out of a task. It often happens that incorrect assumptions get embedded in a plan, and an engineer is asked to do X on the assumption that doing X will also accomplish Z, and they think, "Ugh, they want me to do X but they won't give me time to do Y and Z, what the fuck do I do, Z isn't going to get done and then it will be my fault because I was tasked to do X and they think that's the same thing." Just communicate: "I think what is expected is that if we do X then Z will also be accomplished. In this case, doing X won't accomplish Z. We will also need to do Y and Z, which is additional work." Then if they say, "Just do X," you don't have to fret about Y and Z, because you have set expectations appropriately. In a dysfunctional environment, where the scrum master or project manager is mechanically executing a process without knowing what any of it means, you may need to escalate or reach out beyond the team to find somebody who appreciates your warning that X will not accomplish Z. Of course there may be no such person, but in that case, no process will save you. I've even seen this used effectively to talk about technical debt. "Look, I think the assumption in management is that we're making progress on moving away from the legacy services and deprecating our old auth solution, but in fact, if we do this we will be making ourselves even more dependent on the legacy services, and we'll be adding new public APIs that can't be properly secured. I just want to be sure that [manager's name] is aware that that is how we're shaving a month off this plan." Needle scratch, management wasn't aware that there was any downside to the expedited plan that project management had squeezed out of the engineers, because project management did not understand the language of technical debt. It was all engineer blah blah to them, and it didn't occur to them that management needed to hear it.
matwood 5y ago
> So no, you don't need permission to do something as long as it only takes an hour or so and you can hide it somewhere in your daily standup tasks. If you're having to hide work that you think is a good use of your time, then communication and process has already broken down. It doesn't matter what methodology you claim to be using or complaining about.
- commandlinefan 5y ago
  So... in other words, exactly what I said: "agile only exists to explicitly prevent people from spending time on anything other than what they've asked for, and been granted, permission to do"?
  - matwood 5y ago
    No. Working on a team does that and has nothing to do with agile. Prior to agile ever existing I wouldn't go off on my own doing whatever I wanted for more than a day or so unless I checked in with my team. It's not about asking or granting permission, it's about being a good team member and communicating. "Hey commandlinefan, I know you've been waiting a week for X, but I decided to go do Y. Oh, you needed X to finish something important, and could have gotten someone else to do it if I let you know? Yeah, I don't like to ask for permission."
geoduck14 5y ago
Middle manager here! There are many different categories of "my team is working on something unapproved", and my response is varies greatly. Here are some categories: 1) I found a problem. I spent 5 minutes opening a ticket. - Great. Thanks 2) I found a problem. I spent 2 hours figuring out whose fault it is. - Hmmm, does the problem really matter? Can we just fix it on our side? 3) I found a problem. I spent 2 hours fixing it. - Is this really our problem to fix? Can we open a ticket and move on? (Note the similarity with #2) 4) I accomplished the task in a new way. - Is new also better? Does the solution also align with some ambiguous objectives that I haven't fully disclosed to you? Do I need to include you in more meetings so you understand more weird objectives (and then waste more time!) 5) I did a cool thing that you didn't even thing about! - How can I present this so Sr leaders get excited and approve working on this more? #5 is by far the best, and I genuinely enjoy a teammember who is excited about something that also makes a positive impact - and I LOVE telling leaders why we need to change direction because of something new and cool that MY TEAM FOUND.
- sobani 5y ago
  > some ambiguous objectives that I haven't fully disclosed to you Isn't the one of the major pillars of Agile to let the devs know about all the objectives, so they can make better solutions? You know, the sole reason the Business Owner is one of major the scrum roles?
- nzmsv 5y ago
  In your opinion, are the 5s possible without spending time on 2s, 3s and 4s? If one always stops working on a ticket after 5 minutes (scenario 1) and files a ticket "to be closed later" rather than investigating - and getting in trouble depending on how the investigation goes (2, 3) - how does the developer get enough expertise to get the big wins? How does a developer get experience implementing 5s without hitting an occasional 4?
  - geoduck14 5y ago
    Thanks for your question! My original comment is all about how you present your self in the daily standup. You get 10 mins in the stand up. What do you say? "I spent 30 minutes trying to fix a trivial thing that will get resolved as soon. As I get off the call" - bad idea "Work is going slower than expected, but I'm making progress. Make sure leaders know this is REALLY hard" - better idea "I spent all day making mistakes, but I eventually got something better than planned" - This is good Here are some tips: ASK FOR HELP. If it is a real problem, don't wait until stand up to ask for help. Don't focus on the problems. If you talk about how you can't access email, it sounds like you spent 8 hours waiting for the email to come back (which, if true, I need to know about it much sooner) Help me brag about you. I REALLY need to tell leaders that the team is rocking. Let me know when you: solve a hard problem, get good results, teach someone else something good, learned something from someone else. You AND I benefit if you do well.

wellthisisgreat 5y ago

> every day, you have to "stand up" and recite what you did yesterday and what you're going to do today. If "scrum" is being followed properly, there's somebody listening who's actually recording what you said you were going to do yesterday and compare it to what you say you did yesterday and call out any discrepancies. This is the best explanation of this metgodology I’ve ever read

Stratoscope 5y ago
> This is the best explanation of this metgodology I’ve ever read [emphasis added] I assume that is a typo, but if it is, it's my favorite typo of the week, because it reflects so well how I feel about that kind of daily standup: scrum masters who act like little tin gods. Most of the companies I've worked with take a more practical approach, but I have been involved with some who did it exactly the way GP described. It really rubbed me the wrong way.
- wellthisisgreat 5y ago
  Absolutely a typo :) thanks for bringing it to my attention (obviously not fixing it)
Mauricebranagh 5y ago
Isn't this counter to what RAD/AGILE what have you? Yesterday a look at solution a for problem y and it turns out that was a dead end so we wont do that any more. Today Looking at solution b for y or can we solve y by doing something else

probablyfiction 5y ago

Exactly. Agile is sold as a way to increase productivity, but the practices seem to be about reducing autonomy for team members.

phone8675309 5y ago
"Increased productivity through micromanagement" is a manager's most exciting dream, and that's what agile (big A or little a) provides.

Delmania 5y ago

> If "scrum" is being followed properly, there's somebody listening who's actually recording what you said you were going to do yesterday and compare it to what you say you did yesterday and call out any discrepancies. Seems to me that if you can't justify why not keeping your stated commitments was in the interest of the team and the company, then the issue is with your communication and not the process itself.

dkarl 5y ago
Exactly. And if somebody wants to complain about a process methodology not working because management at their company is stupid or a bunch of assholes: nothing fixes that. 90% of the time the cure for needing to do "undercover" work is explaining that it is needed to accomplish what the company expects to get out of a task. It often happens that incorrect assumptions get embedded in a plan, and an engineer is asked to do X on the assumption that doing X will also accomplish Z, and they think, "Ugh, they want me to do X but they won't give me time to do Y and Z, what the fuck do I do, Z isn't going to get done and then it will be my fault because I was tasked to do X and they think that's the same thing." Just communicate: "I think what is expected is that if we do X then Z will also be accomplished. In this case, doing X won't accomplish Z. We will also need to do Y and Z, which is additional work." Then if they say, "Just do X," you don't have to fret about Y and Z, because you have set expectations appropriately. In a dysfunctional environment, where the scrum master or project manager is mechanically executing a process without knowing what any of it means, you may need to escalate or reach out beyond the team to find somebody who appreciates your warning that X will not accomplish Z. Of course there may be no such person, but in that case, no process will save you. I've even seen this used effectively to talk about technical debt. "Look, I think the assumption in management is that we're making progress on moving away from the legacy services and deprecating our old auth solution, but in fact, if we do this we will be making ourselves even more dependent on the legacy services, and we'll be adding new public APIs that can't be properly secured. I just want to be sure that [manager's name] is aware that that is how we're shaving a month off this plan." Needle scratch, management wasn't aware that there was any downside to the expedited plan that project management had squeezed out of the engineers, because project management did not understand the language of technical debt. It was all engineer blah blah to them, and it didn't occur to them that management needed to hear it.

matwood 5y ago

> So no, you don't need permission to do something as long as it only takes an hour or so and you can hide it somewhere in your daily standup tasks. If you're having to hide work that you think is a good use of your time, then communication and process has already broken down. It doesn't matter what methodology you claim to be using or complaining about.

commandlinefan 5y ago
So... in other words, exactly what I said: "agile only exists to explicitly prevent people from spending time on anything other than what they've asked for, and been granted, permission to do"?
- matwood 5y ago
  No. Working on a team does that and has nothing to do with agile. Prior to agile ever existing I wouldn't go off on my own doing whatever I wanted for more than a day or so unless I checked in with my team. It's not about asking or granting permission, it's about being a good team member and communicating. "Hey commandlinefan, I know you've been waiting a week for X, but I decided to go do Y. Oh, you needed X to finish something important, and could have gotten someone else to do it if I let you know? Yeah, I don't like to ask for permission."

geoduck14 5y ago

Middle manager here! There are many different categories of "my team is working on something unapproved", and my response is varies greatly. Here are some categories: 1) I found a problem. I spent 5 minutes opening a ticket. - Great. Thanks 2) I found a problem. I spent 2 hours figuring out whose fault it is. - Hmmm, does the problem really matter? Can we just fix it on our side? 3) I found a problem. I spent 2 hours fixing it. - Is this really our problem to fix? Can we open a ticket and move on? (Note the similarity with #2) 4) I accomplished the task in a new way. - Is new also better? Does the solution also align with some ambiguous objectives that I haven't fully disclosed to you? Do I need to include you in more meetings so you understand more weird objectives (and then waste more time!) 5) I did a cool thing that you didn't even thing about! - How can I present this so Sr leaders get excited and approve working on this more? #5 is by far the best, and I genuinely enjoy a teammember who is excited about something that also makes a positive impact - and I LOVE telling leaders why we need to change direction because of something new and cool that MY TEAM FOUND.

sobani 5y ago
> some ambiguous objectives that I haven't fully disclosed to you Isn't the one of the major pillars of Agile to let the devs know about all the objectives, so they can make better solutions? You know, the sole reason the Business Owner is one of major the scrum roles?
nzmsv 5y ago
In your opinion, are the 5s possible without spending time on 2s, 3s and 4s? If one always stops working on a ticket after 5 minutes (scenario 1) and files a ticket "to be closed later" rather than investigating - and getting in trouble depending on how the investigation goes (2, 3) - how does the developer get enough expertise to get the big wins? How does a developer get experience implementing 5s without hitting an occasional 4?
- geoduck14 5y ago
  Thanks for your question! My original comment is all about how you present your self in the daily standup. You get 10 mins in the stand up. What do you say? "I spent 30 minutes trying to fix a trivial thing that will get resolved as soon. As I get off the call" - bad idea "Work is going slower than expected, but I'm making progress. Make sure leaders know this is REALLY hard" - better idea "I spent all day making mistakes, but I eventually got something better than planned" - This is good Here are some tips: ASK FOR HELP. If it is a real problem, don't wait until stand up to ask for help. Don't focus on the problems. If you talk about how you can't access email, it sounds like you spent 8 hours waiting for the email to come back (which, if true, I need to know about it much sooner) Help me brag about you. I REALLY need to tell leaders that the team is rocking. Let me know when you: solve a hard problem, get good results, teach someone else something good, learned something from someone else. You AND I benefit if you do well.