9 ms·

I have totally opposite experience from what you wrote. We have fast changing application and we use scrum and sprints to fend off business people. Because one

by ozim 6y ago

I have totally opposite experience from what you wrote. We have fast changing application and we use scrum and sprints to fend off business people. Because one day they want one thing, next day 10 things more. With sprint I can tell them to go away and make priorities because team is not capable of handling those 10 more tasks. Which in turn makes it predictable for business people because they know my team will be able to put those 10 things in next sprint (if those are soooo important, which later always turns out not really) and have it ready in production in 4-6 weeks. With product owner and "refinement meetings" I don't have business/sales people coming to me with stupid ideas and trying to force me to implement something. They have to put more work in it so that I get structured stream of work, of course it is not always perfect but better than random sales hitting you with something by your desk. What is important I have my team "burn down rate" which helps to communicate it clearly and they cannot argue with the number. Other important part is that estimations are done by dev team and I think important part is that our management is not arguing with the estimations. They show trust in developers and are not trying to push down estimations or improve burn down. So in my view my team has more power over the process not the managers. What managers/sales get form it is clear information that they can use in their work. Unfortunately I don't think it is the case for much companies.

gregoriol 6y ago
It seems like your team is at war within your own company. You are actually building a wall! That doesn't feel right, and doesn't feel any more positive than what the previous comment was describing.
- lifeisstillgood 6y ago
  Perhaps think of it more as a cell wall - some things can pass through by osmosis, but ti is a much more controlled thing.
- pulse7 6y ago
  I don't see it as a wall, but defined order (how new tasks are put into the queue) instead of chaos (when sales people come directly to the developer's desk and order new requests without others involved)...
- madeofpalk 6y ago
  But this is exactly why we have these processes! Companies have trouble prioritising and planning _at scale_ - they're constantly at war with themselves - so we introduce a process to manage the inefficiencies of many people, with conflicting priorities and points of view, trying to develop a product.
- theshrike79 6y ago
  It's not a wall, more like a moat with a drawbridge :) The drawbridge is lowered every two weeks and that's when the team delivers and demonstrates the stuff they did during that time. This is also the time the stakeholders get to present the prioritised list of work that needs to be done during the next two weeks (Product backlog). During the two week period if the stakeholders need to communicate to the Fort of Scrum, they can shout from the other side of the moat and the Scrum Master is the only one with access to the only tower in the castle where the shouting can be heard. The team has complete autonomy and peace to work for the two weeks.
  - dopidop 6y ago
    And here I am, building tunnel under the moat, being cozy with the stakeholder in order to influence his decision and secure some sprints that make sense ( for my team, I absolutely don’t care about the product, it’s a lost cause behemoth, the product will be fine. )
    - beardedetim 6y ago
      I thought someone was digging a tunnel next to mine!
- mmcnl 6y ago
  I don't think so. Within a company departments can have different interests that sometimes clash. A mature team would notice this tension and signal this to the stakeholders. I think developers often think that people outside scrum teams have a well thought through plan of things they are doing. That's often not the case, they're just trying to figure out what they need to do to get things done. If a team signals that business people need to make a priority call, that brings a lot of clarity. I think it's a good sign.
- louwrentius 6y ago
  Exactly, it seems to me they aren't taken seriously / respected by the business side as professionals that can work autonomously. Using scrum/agile to fix a lack of trust, not sure how that's going to work out long-term.
  - ozim 6y ago
    I would describe someone who has defined process, defined check-in periods, defined communication lines and is following it as a professional. How do you work as a professional autonomously without setting rules for work and setting up process for regular progress check-in?
- ozim 6y ago
  I propose that you read "The Phoenix Project (A Novel About IT, DevOps, and Helping Your Business Win)". I don't feel like I am building a wall, I am building a structured approach to communication and software building that is predictable to deliver value to our business and our customers.
input_sh 6y ago
I mean I get the problems you're facing, but is there anything about scrum specifically that makes it easier to deal with them? We just have a list of tasks we need to work on organised by priority and a quick estimate of the time needed to implement it. We don't need to meet every morning to follow that list, going through the list and re-arranging it once a week is fine. If someone outside of our team wants to know what we're doing, they can look it up. And they trust us that we know how to prioritise tasks related to our own product. I've worked within a scrum team before this and I prefer this approach so much more. Prior to this I never knew what I would face that day. It's whatever the project manager told me I should face in the morning meeting, even if it meant setting aside something I didn't quite finish yesterday but could finish within an additional hour or two.
- madeofpalk 6y ago
  You found a loose "lowercase A"/kanban approach that works well for your team! I also kind of prefer a kanban approach, if it works well for the test of the team/company. > It's whatever the project manager told me I should face in the morning meeting Just to be really clear - this is not "scrum". People can have a really difficult time with "agile" and related practices because they're often conflated with bad people/managers/teams. For most of my developmement career I've followed some sort of agile-two-week-sprint-scrum-with-daily-standup process and I've never been told what tasks I'm doing each morning. I've never experienced this problem you started (but ive definitely had other problems!) At the risk of being a bit no true Scottsman, the best agile practicioners (and I don't mean the Deloitte/Thoughtworks paid-by-the-buzzword type) advocate for finding a process that works well for your team, picking bits from the larger "Agile Toolbox". That's True Agile.
  - teh_klev 6y ago
    > finding a process that works well for your team, picking bits from the larger "Agile Toolbox". Absolutely this.
  - rorykoehler 6y ago
    We’re constantly refining our processes. It’s like any other part of the business in that it benefits in having a design thinking methodology applied or else it goes stale and fails to keep up with changing dynamics of the business and beyond. For example we decided to do fewer releases against conventional wisdom because we realised our customers were not able to keep up with training and other internal processes they are required to conduct for compliance reasons.
g051051 6y ago
My last place had those problems, but scrum was used in the opposite way. If we pushed back on things, we weren't "agile". Burn down was used a a club even though the model they chose would usually result in everything pending until the last two days of the sprint. Our estimations were completely ignored, plus the fact that they were estimations. We would make estimates, and be told they weren't commitments. Later when stuff would be pulled into the sprint, the team lead and manager would lower them, and we'd be castigated for not meeting them.
- house9-2 6y ago
  > We would make estimates, and be told they weren't commitments. Yeah, this is ridiculous; Scrum actually changed the term from ‘Commitment’ to ‘Forecast’ back in 2011. But the industry didn’t pay attention to that minor but important change. - https://www.scrum.org/resources/commitment-vs-forecast https://www.scrum.org/resources/commitment-vs-forecast
danjac 6y ago
> We have fast changing application and we use scrum and sprints to fend off business people. Because one day they want one thing, next day 10 things more. Then you are using Scrum to obfuscate a core communications problem in your company. Either the business people are clueless about what they want and are flailing around in a panic, or they are not able to communicate their needs to you properly, or you are unable to understand their real business requirements, or they insist on micromanaging every aspect of your product. Or some combination of these factors. You should not have to "fend off" your professional colleagues, you should be able to have an adult conversation with your peers and frame requirements and expectations accordingly. If your company culture prevents this then that's what you need to fix, not further burden the team with the demands of Scrum.
- __oh_es 6y ago
  Totally - you shouldn’t. But sometimes you have to use common tools and practices to protect your teams workload and manage the expectations of an often frustrated larger business. Plus not everyone has the privilege of a good base experience, or the option to just find a better cultured company.
- neuronic 6y ago
  It's nice of you to write that and you aren't even wrong but what is he supposed to do about it? File a case to have the business people fired? You're phrasing it as if OP is the problem but he isn't, at least not the most significant part about it. Have you ever been in an enterprise environment where people simply and subtly tell you to fuck off if you want to "have an adult conversation with your peers"? Now you're stuck with the shitty situation and need to start fending idiots off because there is often ZERO interest to improve things like communication. It's often not a startup with 10 people where you can grab a coffee and go "Hey guys let's talk about our communication issues!". These topics are highly political once a company is large enough and they are extremely rigid and hierarchical. Exceptions exist but they are, well, exceptions. Sorry, but I felt this post was almost accusing OP of inaction when that's a pretty easy thing to say from the outside.
  - 6y ago
templarchamp 6y ago
Yes, until one of the 10 tasks flips one of the assumptions and changes a large scale decisioning system on its head...The processes work for certain type of projects. F-16 pilots have different concerns than 737 jets than a tractor trailer driver than a bicyclist, if moving from point A to point B is what matters..
zeroc8 6y ago
Well, I enjoy talking to the front line aka sales people to hear what's going on out there. I appreciate their input. While there might be lots of stupid ideas, there are also good ones, and some times I feel like it is a reality check which helps to get out of the developer bubble.
- ozim 6y ago
  Difference is in talking as bouncing off ideas and sales pushing work on you or talking nicely and expecting you do things for him/her.

by ozim 6y ago

gregoriol 6y ago

It seems like your team is at war within your own company. You are actually building a wall! That doesn't feel right, and doesn't feel any more positive than what the previous comment was describing.

lifeisstillgood 6y ago
Perhaps think of it more as a cell wall - some things can pass through by osmosis, but ti is a much more controlled thing.
pulse7 6y ago
I don't see it as a wall, but defined order (how new tasks are put into the queue) instead of chaos (when sales people come directly to the developer's desk and order new requests without others involved)...
madeofpalk 6y ago
But this is exactly why we have these processes! Companies have trouble prioritising and planning _at scale_ - they're constantly at war with themselves - so we introduce a process to manage the inefficiencies of many people, with conflicting priorities and points of view, trying to develop a product.
theshrike79 6y ago
It's not a wall, more like a moat with a drawbridge :) The drawbridge is lowered every two weeks and that's when the team delivers and demonstrates the stuff they did during that time. This is also the time the stakeholders get to present the prioritised list of work that needs to be done during the next two weeks (Product backlog). During the two week period if the stakeholders need to communicate to the Fort of Scrum, they can shout from the other side of the moat and the Scrum Master is the only one with access to the only tower in the castle where the shouting can be heard. The team has complete autonomy and peace to work for the two weeks.
- dopidop 6y ago
  And here I am, building tunnel under the moat, being cozy with the stakeholder in order to influence his decision and secure some sprints that make sense ( for my team, I absolutely don’t care about the product, it’s a lost cause behemoth, the product will be fine. )
  - beardedetim 6y ago
    I thought someone was digging a tunnel next to mine!
mmcnl 6y ago
I don't think so. Within a company departments can have different interests that sometimes clash. A mature team would notice this tension and signal this to the stakeholders. I think developers often think that people outside scrum teams have a well thought through plan of things they are doing. That's often not the case, they're just trying to figure out what they need to do to get things done. If a team signals that business people need to make a priority call, that brings a lot of clarity. I think it's a good sign.
louwrentius 6y ago
Exactly, it seems to me they aren't taken seriously / respected by the business side as professionals that can work autonomously. Using scrum/agile to fix a lack of trust, not sure how that's going to work out long-term.
- ozim 6y ago
  I would describe someone who has defined process, defined check-in periods, defined communication lines and is following it as a professional. How do you work as a professional autonomously without setting rules for work and setting up process for regular progress check-in?
ozim 6y ago
I propose that you read "The Phoenix Project (A Novel About IT, DevOps, and Helping Your Business Win)". I don't feel like I am building a wall, I am building a structured approach to communication and software building that is predictable to deliver value to our business and our customers.

input_sh 6y ago

I mean I get the problems you're facing, but is there anything about scrum specifically that makes it easier to deal with them? We just have a list of tasks we need to work on organised by priority and a quick estimate of the time needed to implement it. We don't need to meet every morning to follow that list, going through the list and re-arranging it once a week is fine. If someone outside of our team wants to know what we're doing, they can look it up. And they trust us that we know how to prioritise tasks related to our own product. I've worked within a scrum team before this and I prefer this approach so much more. Prior to this I never knew what I would face that day. It's whatever the project manager told me I should face in the morning meeting, even if it meant setting aside something I didn't quite finish yesterday but could finish within an additional hour or two.

madeofpalk 6y ago
You found a loose "lowercase A"/kanban approach that works well for your team! I also kind of prefer a kanban approach, if it works well for the test of the team/company. > It's whatever the project manager told me I should face in the morning meeting Just to be really clear - this is not "scrum". People can have a really difficult time with "agile" and related practices because they're often conflated with bad people/managers/teams. For most of my developmement career I've followed some sort of agile-two-week-sprint-scrum-with-daily-standup process and I've never been told what tasks I'm doing each morning. I've never experienced this problem you started (but ive definitely had other problems!) At the risk of being a bit no true Scottsman, the best agile practicioners (and I don't mean the Deloitte/Thoughtworks paid-by-the-buzzword type) advocate for finding a process that works well for your team, picking bits from the larger "Agile Toolbox". That's True Agile.
- teh_klev 6y ago
  > finding a process that works well for your team, picking bits from the larger "Agile Toolbox". Absolutely this.
- rorykoehler 6y ago
  We’re constantly refining our processes. It’s like any other part of the business in that it benefits in having a design thinking methodology applied or else it goes stale and fails to keep up with changing dynamics of the business and beyond. For example we decided to do fewer releases against conventional wisdom because we realised our customers were not able to keep up with training and other internal processes they are required to conduct for compliance reasons.

g051051 6y ago

My last place had those problems, but scrum was used in the opposite way. If we pushed back on things, we weren't "agile". Burn down was used a a club even though the model they chose would usually result in everything pending until the last two days of the sprint. Our estimations were completely ignored, plus the fact that they were estimations. We would make estimates, and be told they weren't commitments. Later when stuff would be pulled into the sprint, the team lead and manager would lower them, and we'd be castigated for not meeting them.

house9-2 6y ago
> We would make estimates, and be told they weren't commitments. Yeah, this is ridiculous; Scrum actually changed the term from ‘Commitment’ to ‘Forecast’ back in 2011. But the industry didn’t pay attention to that minor but important change. - https://www.scrum.org/resources/commitment-vs-forecast https://www.scrum.org/resources/commitment-vs-forecast

danjac 6y ago

> We have fast changing application and we use scrum and sprints to fend off business people. Because one day they want one thing, next day 10 things more. Then you are using Scrum to obfuscate a core communications problem in your company. Either the business people are clueless about what they want and are flailing around in a panic, or they are not able to communicate their needs to you properly, or you are unable to understand their real business requirements, or they insist on micromanaging every aspect of your product. Or some combination of these factors. You should not have to "fend off" your professional colleagues, you should be able to have an adult conversation with your peers and frame requirements and expectations accordingly. If your company culture prevents this then that's what you need to fix, not further burden the team with the demands of Scrum.

__oh_es 6y ago
Totally - you shouldn’t. But sometimes you have to use common tools and practices to protect your teams workload and manage the expectations of an often frustrated larger business. Plus not everyone has the privilege of a good base experience, or the option to just find a better cultured company.
neuronic 6y ago
It's nice of you to write that and you aren't even wrong but what is he supposed to do about it? File a case to have the business people fired? You're phrasing it as if OP is the problem but he isn't, at least not the most significant part about it. Have you ever been in an enterprise environment where people simply and subtly tell you to fuck off if you want to "have an adult conversation with your peers"? Now you're stuck with the shitty situation and need to start fending idiots off because there is often ZERO interest to improve things like communication. It's often not a startup with 10 people where you can grab a coffee and go "Hey guys let's talk about our communication issues!". These topics are highly political once a company is large enough and they are extremely rigid and hierarchical. Exceptions exist but they are, well, exceptions. Sorry, but I felt this post was almost accusing OP of inaction when that's a pretty easy thing to say from the outside.
- 6y ago

templarchamp 6y ago

Yes, until one of the 10 tasks flips one of the assumptions and changes a large scale decisioning system on its head...The processes work for certain type of projects. F-16 pilots have different concerns than 737 jets than a tractor trailer driver than a bicyclist, if moving from point A to point B is what matters..

zeroc8 6y ago

Well, I enjoy talking to the front line aka sales people to hear what's going on out there. I appreciate their input. While there might be lots of stupid ideas, there are also good ones, and some times I feel like it is a reality check which helps to get out of the developer bubble.

ozim 6y ago
Difference is in talking as bouncing off ideas and sales pushing work on you or talking nicely and expecting you do things for him/her.