Ask HN: Do you think Agile/Scrum is beneficial for software delivery?
708 comments
I just don't get it why developers like Scrum.
The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship. Standing around a table in the morning like assholes is not my idea of fun. Same for the "product owner" concept. If I develop something, I am the owner. I generally hate being micromanaged and being assigned microtasks that gives "them" total control over my workday while I have no idea what "they" are doing the whole day.
Scrum was the reason why I left my last company and I'm much happier now in my new company, where we do not have any process at all, just a common goal. Instead of standups, the team gathers for a coffee in the morning. If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult. That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines.
So no more Scrum for me. Never.
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.
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.
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.
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.
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.
> 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.
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.
Exactly. When I first learned about Agile development they clearly stated there is no "Agile process". It is simply having only the minimum amount of actual documented/enforced practices needed to ensure smooth development. Is your team struggling to finish tasks because they're not communicating enough? Have a morning check-in where anyone who is having an issue can state their issue, someone else can chime in that they can/know how to assist, and they can discuss it afterwards. Team being overwhelmed by requests for new/unplanned work? Set up a task tracking system and prioritize your tasks ensuring things get done in the order they need to be with none forgotten. Software development doesn't look the same anywhere you go. What works for one team/customer/environment won't necessarily work for any other. Agile is adapting the process to the people. Alternatives like CMMI do the opposite by forcing the people to adapt to the process.
The number one issue I've encountered in my area is companies that say they use Scrumm when they really don't. Scrumm is a very specific, defined process, and as they clearly state in their "handbook" if you're not following the process exactly as it's described then you aren't doing Scrumm. Period.
The number one issue I've encountered in my area is companies that say they use Scrumm when they really don't. Scrumm is a very specific, defined process, and as they clearly state in their "handbook" if you're not following the process exactly as it's described then you aren't doing Scrumm. Period.
> finding a process that works well for your team, picking bits from the larger "Agile Toolbox".
Absolutely this.
Absolutely this.
I agree with this.. I've personally been more effective in an async communication type of approach. Communication over email, slack messages, ticket comments.. just leave a comment on my ticket, give me time to ponder on it, then I'll respond. If there's anything mission critical that really requires everyone to sit down in a room together, then we can schedule a meeting.
I accept that not everyone's like me, though.
I accept that not everyone's like me, though.
I think your preferred way of working is pretty close to what scrum aims to achieve. Often scrum gets implemented in totally the wrong way so I can understand your negative experience.
The scrum guide is treated as a holy text by some, but (as the scrum guide even states) agile teams should be self-organising and pick and choose what tools work for them.
> 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.
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.
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.
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.
I’d like to double down on your defense of OP.
Communication overheard is an inherit trait of large organizations. To some degree we can improve this with digital technology, but it’s a fundamental problem.
If you need to rewire the communication pathways of 10 people, the complexity can be up to O(n^2) because you might need to make adjustments for how every individual is getting signal from other individuals. As organizations grow the old pathways of communication are less optimal, but it’s also more expensive to rewire communication. To some degree corporate communication overhead buys stability and consistency across the organization.
You should attempt to optimize communication with those nearest to you in a large workforce, but at a certain point all you can do is give feedback to corporate about the communication pain points. If you work in a large organization and you can optimize your local communications to be completely optimal you probably aren’t communicating with enough people to have a full impact on the organization.
Communication overheard is an inherit trait of large organizations. To some degree we can improve this with digital technology, but it’s a fundamental problem.
If you need to rewire the communication pathways of 10 people, the complexity can be up to O(n^2) because you might need to make adjustments for how every individual is getting signal from other individuals. As organizations grow the old pathways of communication are less optimal, but it’s also more expensive to rewire communication. To some degree corporate communication overhead buys stability and consistency across the organization.
You should attempt to optimize communication with those nearest to you in a large workforce, but at a certain point all you can do is give feedback to corporate about the communication pain points. If you work in a large organization and you can optimize your local communications to be completely optimal you probably aren’t communicating with enough people to have a full impact on the organization.
I'm not accusing the OP of inaction: on the contrary, they are attempting to rectify the problem with Scrum, so they are trying to do something.
What I am saying is that using Scrum to paper over a dysfunctional organization merely adds more dysfunction. It's a bit like the old joke: you have a problem, you adopt XML as the solution, now you have two problems. If you have a dysfunctional organization, then you either fix that if it's in your power, grin and bear it if you can't, or leave if that's an option. You're not going to fix it with Scrum (or for that matter, Kanban or any other off-the-shelf process).
What I am saying is that using Scrum to paper over a dysfunctional organization merely adds more dysfunction. It's a bit like the old joke: you have a problem, you adopt XML as the solution, now you have two problems. If you have a dysfunctional organization, then you either fix that if it's in your power, grin and bear it if you can't, or leave if that's an option. You're not going to fix it with Scrum (or for that matter, Kanban or any other off-the-shelf process).
You’re offering criticisms of what OP is trying to do, but you have not offered an alternative. What is your solution?
Thus far, your position on this is too rigid and does not account for the spectrum of: org size, type, age, etc. It lacks maturity and awareness of the realities of many organizations.
If you’ve found a place where you can implement this stance: great! The vast majority of people are not in that position, and criticizing them for it is not a great look.
Thus far, your position on this is too rigid and does not account for the spectrum of: org size, type, age, etc. It lacks maturity and awareness of the realities of many organizations.
If you’ve found a place where you can implement this stance: great! The vast majority of people are not in that position, and criticizing them for it is not a great look.
The vast majority of software engineers can’t change employer?
No, this is obviously not what I said. Nor is changing employers automatically better. There are (as I suspect you already know) a myriad of factors involved in choosing an employer and choosing to leave.
The implication that this is “the solution” is pretty naive.
The implication that this is “the solution” is pretty naive.
Then you are using Scrum to obfuscate a core communications problem in your company.
No, they're using scrum to guarantee a minimum level of effective communication. Business people don't have to be "clueless" to be constantly shifting priorities: they are reacting to the day-to-day business realities of client requests and biz dev opportunities. They're acting professionally, and in good faith. But if the dev team constantly reacted to those shifting priorities, the constant context shifting would kill their productivity and morale. Scrum provides a minimal set of tools and practices to ensure stability for the dev team, so they aren't constantly in reaction mode and have space to think about the product and be proactive.
I'm constantly amazed by people who talk about the "burdens" of scrum, like it's a lot of work that wouldn't otherwise happen. Really? Let's look at all that "extra" work:
- talking to your teammates daily to share progress, but more importantly raise red flags if there are impediments
- demo-ing your work periodically to verify that the stuff the team says is done actually meets expectations
- periodically taking some time to design the software, maybe refactor stuff that isn't correctly modeled, and planning your work
And that's pretty much it. Do people really work in places where they don't do any of that stuff? They just wing it, test everything at the end, and hope for the best?
No, they're using scrum to guarantee a minimum level of effective communication. Business people don't have to be "clueless" to be constantly shifting priorities: they are reacting to the day-to-day business realities of client requests and biz dev opportunities. They're acting professionally, and in good faith. But if the dev team constantly reacted to those shifting priorities, the constant context shifting would kill their productivity and morale. Scrum provides a minimal set of tools and practices to ensure stability for the dev team, so they aren't constantly in reaction mode and have space to think about the product and be proactive.
I'm constantly amazed by people who talk about the "burdens" of scrum, like it's a lot of work that wouldn't otherwise happen. Really? Let's look at all that "extra" work:
- talking to your teammates daily to share progress, but more importantly raise red flags if there are impediments
- demo-ing your work periodically to verify that the stuff the team says is done actually meets expectations
- periodically taking some time to design the software, maybe refactor stuff that isn't correctly modeled, and planning your work
And that's pretty much it. Do people really work in places where they don't do any of that stuff? They just wing it, test everything at the end, and hope for the best?
> Business people don't have to be "clueless" to be constantly shifting priorities: they are reacting to the day-to-day business realities of client requests and biz dev opportunities.
That makes the business people sound a lot like the guy in Office Space who takes the specs to the engineers. If they are just a secretary who will rapidly oscillate priorities based on what customer yelled the loudest yesterday that isn't very useful to the business. The purpose of a product team or anyone in that capacity is to try and understand client needs prior to the client actually having them, rapidly changing priorities is generally evidence of that not happening.
That makes the business people sound a lot like the guy in Office Space who takes the specs to the engineers. If they are just a secretary who will rapidly oscillate priorities based on what customer yelled the loudest yesterday that isn't very useful to the business. The purpose of a product team or anyone in that capacity is to try and understand client needs prior to the client actually having them, rapidly changing priorities is generally evidence of that not happening.
> If they are just a secretary who will rapidly oscillate priorities based on what customer yelled the loudest yesterday that isn't very useful to the business
This is a gross mischaracterization, and depends greatly on the industry, stage of the product, nature of the customer, etc. I've seen major organizations shift an entire 6-12 months of roadmap to cater to one or two key customers with unique requirements, just based on the sheer size of the revenue from the deal.
Re-prioritization happens for many reasons, and while it's absolutely true that rapidly shifting priorities can be a major red flag and may be extremely detrimental, it's also true that sometimes this is just the nature of the beast. And when that's the case, having a good business/product/whatever you label it layer to shield the engineering teams is critical.
> The purpose of a product team or anyone in that capacity is to try and understand client needs prior to the client actually having them, rapidly changing priorities is generally evidence of that not happening.
Again, this depends on the kind of software shop this is. If you're building the next social media platform, you have an entirely different set of problems and concerns from a behemoth enterprise software platform trying to beat the other behemoth for that next $30M deal.
This is a gross mischaracterization, and depends greatly on the industry, stage of the product, nature of the customer, etc. I've seen major organizations shift an entire 6-12 months of roadmap to cater to one or two key customers with unique requirements, just based on the sheer size of the revenue from the deal.
Re-prioritization happens for many reasons, and while it's absolutely true that rapidly shifting priorities can be a major red flag and may be extremely detrimental, it's also true that sometimes this is just the nature of the beast. And when that's the case, having a good business/product/whatever you label it layer to shield the engineering teams is critical.
> The purpose of a product team or anyone in that capacity is to try and understand client needs prior to the client actually having them, rapidly changing priorities is generally evidence of that not happening.
Again, this depends on the kind of software shop this is. If you're building the next social media platform, you have an entirely different set of problems and concerns from a behemoth enterprise software platform trying to beat the other behemoth for that next $30M deal.
Agreed. Most of the complaints I read that aren’t just related to awful management are typically to the effect of “I’m being required to function as part of a larger organization instead of doing what I want.”
There are no perfect solutions to project management, and if you prefer to work in tiny organized communes without corporate direction then that is your prerogative. I’ll be right there with you. Otherwise, it sounds like some developers here are just annoyed that their team and departments don’t revolve around their individual desire to not be managed.
There are no perfect solutions to project management, and if you prefer to work in tiny organized communes without corporate direction then that is your prerogative. I’ll be right there with you. Otherwise, it sounds like some developers here are just annoyed that their team and departments don’t revolve around their individual desire to not be managed.
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.
Plus not everyone has the privilege of a good base experience, or the option to just find a better cultured company.
How do you solve it when you have Billy and Bob.
Billy is working on customers X, Y, Z.
Bob is working on customers C, F, G.
Billy and Bob want different things for different customers. Billie gets commission on solving stuff for his customers, Bob for his own. Both of them promise their customers everything next month.
Now you have 10 developers and Billie convinced 5 of them that building his things is important. Other 5 devs are convinced by Bob to work on his ideas. Developers are not informed about how much each customer is worth, as they don't need it for their jobs (just as Billie and Bob don't have any access to source code, databases and servers). Remember you need to have "least knowledge/privilige" principle because you don't inform all employees on all details of company deals (because I am writing about B2B products).
For me professional way is to have a product owner who listens to both of them, knows how much each customer is worth for the company, checks with the team how much each feature costs and makes priorities. You create a single line of communication and defined process. You communicate in a clear way what can be achieved when, well maybe with a bit of a slip here and there. Billie and Bob get one person to communicate with, get clear forecasts that then they can communicate back to the customers.
Maybe that is different if you have B2C products because then you don't have such scenario there.
Billy and Bob want different things for different customers. Billie gets commission on solving stuff for his customers, Bob for his own. Both of them promise their customers everything next month.
Now you have 10 developers and Billie convinced 5 of them that building his things is important. Other 5 devs are convinced by Bob to work on his ideas. Developers are not informed about how much each customer is worth, as they don't need it for their jobs (just as Billie and Bob don't have any access to source code, databases and servers). Remember you need to have "least knowledge/privilige" principle because you don't inform all employees on all details of company deals (because I am writing about B2B products).
For me professional way is to have a product owner who listens to both of them, knows how much each customer is worth for the company, checks with the team how much each feature costs and makes priorities. You create a single line of communication and defined process. You communicate in a clear way what can be achieved when, well maybe with a bit of a slip here and there. Billie and Bob get one person to communicate with, get clear forecasts that then they can communicate back to the customers.
Maybe that is different if you have B2C products because then you don't have such scenario there.
Or there are just multiple stakeholders with differing needs.
The benefit of having a single PO is that they reconcile the competing priorities and the developers don't have to do it themselves.
The benefit of having a single PO is that they reconcile the competing priorities and the developers don't have to do it themselves.
All true but do you have any practical solution to dealing with incompetent micro-managing middle managers when you don’t have the power to fire them?
Yeah. I'm glad this person is not on my team. The whole attitude sounds toxic as fuck.
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.
> 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
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
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.
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.
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.
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. )
I thought someone was digging a tunnel next to mine!
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.
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.
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)...
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.
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.
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.
Using scrum/agile to fix a lack of trust, not sure how that's going to work out long-term.
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?
How do you work as a professional autonomously without setting rules for work and setting up process for regular progress check-in?
Perhaps think of it more as a cell wall - some things can pass through by osmosis, but ti is a much more controlled thing.
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.
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.
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..
> If I develop something, I am the owner.
Funnily enough, it's precisely this attitude which has led to the creation of the product owner role, and Scrum in general.
Most developers I know are emphatically NOT good product people (despite what they may think).
A good product owner is quite difficult to find, as they need to combine: i) a user-centric view of what the product needs to be, ii) a business-centric view of what needs to be released, and when, iii) a developer-centric view to make the 'best' product, from a programming perspective, and looking towards the long-term.
> That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines
This is all well and good until a competitor launches before you (with an inferior product), takes all your market share, and when you eventually launch you're having to play catch-up trying to steal clients. Meanwhile the competitor is reinvesting their initial revenue in making their product better to match yours, which means they keep their clients, keep getting revenue, investment etc.
You may have a better product, but you'll end up going bust.
Funnily enough, it's precisely this attitude which has led to the creation of the product owner role, and Scrum in general.
Most developers I know are emphatically NOT good product people (despite what they may think).
A good product owner is quite difficult to find, as they need to combine: i) a user-centric view of what the product needs to be, ii) a business-centric view of what needs to be released, and when, iii) a developer-centric view to make the 'best' product, from a programming perspective, and looking towards the long-term.
> That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines
This is all well and good until a competitor launches before you (with an inferior product), takes all your market share, and when you eventually launch you're having to play catch-up trying to steal clients. Meanwhile the competitor is reinvesting their initial revenue in making their product better to match yours, which means they keep their clients, keep getting revenue, investment etc.
You may have a better product, but you'll end up going bust.
+1 to your third point especially. I'll even add that Agile development can be a big bonus in any market that has the potential for rapidly changing needs. Even if you don't lose out to your faster competition you may still end up releasing to a market that's no longer looking for the solution that you "perfected". Agile development allowing you to release a functional product as soon as possible, and adding to it as resources allow means you can pivot your development to meet new demands instead of bogging yourself down trying to produce the perfect solution to a problem that continues to evolve.
I think it's possible to have rapid releases without all the typical trappings of scrum. See: Facebook, who are decidedly not bust.
Maybe the answer is just 'hire better engineers'. Where better means they're good at the product decisions too.
Maybe the answer is just 'hire better engineers'. Where better means they're good at the product decisions too.
I found this really depends how "scrum" is implemented. Personally as a developer I like several features of scrum:
- regular retrospectives, for improving the process
- regular demos, for having a continuous process showing value and that we are aligned with the companies goals (anybody who thinks the development team have done nothing for the last x months can simply be pointed to the demo recordings page on the intranet)
- some kind of short regular meeting throughout the sprint to update the PO ("daily standup", but does not necessarily need to be daily, or standing up), who can reset expectations, as opposed to announcing at the last minute it won't be ready.
- and a regular planning session with the product owner to work with them to figure out how to bring value to the business quicker, push back on things that aren't that valuable, etc.
But of course this really depends on how the process is implemented and the environment you're in. If retrospectives and demos are often cancelled because "we need to ship this feature to this customer now!", if the daily standups become all about "why is this not done yet, how much longer will it take" rather than an honest peer-to-peer "are we on track for delivering this, what does the PO need to find out/inform stakeholders of/what blockers are there" and the PO doesn't include development staff in the backlog refinement and just dumps tasks on the development team, then yes, you will have an experience that sucks.
So as a developer, I like doing scrum when it is implemented in a way that the dev team and PO are viewed as peers and we don't skip any of the meetings. And I hate doing scrum when it's essentially just being given a load of tasks that I have no say over, no retrospective to improve things, etc.
YMMV (depending greatly on the setup/environment you are working in, I think)
(edit for formatting)
- regular retrospectives, for improving the process
- regular demos, for having a continuous process showing value and that we are aligned with the companies goals (anybody who thinks the development team have done nothing for the last x months can simply be pointed to the demo recordings page on the intranet)
- some kind of short regular meeting throughout the sprint to update the PO ("daily standup", but does not necessarily need to be daily, or standing up), who can reset expectations, as opposed to announcing at the last minute it won't be ready.
- and a regular planning session with the product owner to work with them to figure out how to bring value to the business quicker, push back on things that aren't that valuable, etc.
But of course this really depends on how the process is implemented and the environment you're in. If retrospectives and demos are often cancelled because "we need to ship this feature to this customer now!", if the daily standups become all about "why is this not done yet, how much longer will it take" rather than an honest peer-to-peer "are we on track for delivering this, what does the PO need to find out/inform stakeholders of/what blockers are there" and the PO doesn't include development staff in the backlog refinement and just dumps tasks on the development team, then yes, you will have an experience that sucks.
So as a developer, I like doing scrum when it is implemented in a way that the dev team and PO are viewed as peers and we don't skip any of the meetings. And I hate doing scrum when it's essentially just being given a load of tasks that I have no say over, no retrospective to improve things, etc.
YMMV (depending greatly on the setup/environment you are working in, I think)
(edit for formatting)
Scrum can only be successful if everyone is viewed and respected as peers. This is a hard requirement for scrum to be scrum. Otherwise it's just micro management.
Often neglected are the Scrum values: Commitment, Courage, Focus, Openness, and Respect. Values form a foundation for success. When agile principles are ignored and Scrum values not incorporated, Scrum (or any other methodology or set of practices) can become just a control mechanism for Taylor-istic "resource management." Scrum can be a great way for a software engineering team to and operate when they understand and apply the values and use it to self-organize, deliver regular increments of valuable software, inspect and adapt.
Otherwise known as "I like doing scrum when it's not scrum but a totally different, less onerous, process I've incorrectly identified as scrum"
If you think SCRUM (done well or at least competently) is onerous then I am afraid your not doing SCRUM properly
No true Scrumsman?
Every time this topic comes up on HN it devolves into "if you think it's bad you are not doing it correctly". Perhaps everyone is indeed doing it wrong, but when 90+% of the intended audience is "doing it wrong" it might also be the case that the system is either too difficult too learn for most teams or the system does not match the incentives imposed by the environment it is typically deployed into.
To add onto this: the argument of "you're doing it wrong" would never pass a usability or safety test, but this gets conveniently glossed over whenever the Scrum debate comes. Trying to wave the point away just makes matters worse. If that crowd believes this point is moot, they should actually defend why the 90% doing it wrong doesn't have any significance.
> If that crowd believes this point is moot, they should actually defend why the 90% doing it wrong doesn't have any significance.
I have a lot of sympathy for this perspective.
I also notice that 90% of everyone does everything wrong.
I don't know how to reconcile those two observations.
I have a lot of sympathy for this perspective.
I also notice that 90% of everyone does everything wrong.
I don't know how to reconcile those two observations.
By admitting it is both right and wrong, and it entirely depends on the context and purpose whether one should decide it is "right" or whether it is "wrong".
Kids are using electrical plugs wrong when they stick a pointy object in it. That doesn't mean electrical plugs without child safety close to the ground aren't potential hazards.
Kids damaging their hands doing control-stick spinning minigames using a N64 controller without gloves are "doing it wrong", they could just wear gloves. Still, Nintendo lost that case, and such minigames were deemed problematic.
People browsing a website where the links turn invisible, the mouse doesn't turn into a pointer, the browser doesn't show it is loading and no loading icon is shown, are "doing it wrong" for not just waiting 10 seconds for the page to load. Despite that, UX practices rightly condemn this kind of behavior: at least add an "alive" indicator.
To some degree, you have to make things "stupid proof". That's part of this field. If for some reason, Scrum allows managers more power to micromanage, that's a potential hazard which has to be admitted. That's the problem with the "you're doing it wrong" argument. It doesn't acknowledge potential hazards. Instead, it tries to circumvent that discussion and blindly assumes that developers both can and should "just fix it" when managers are doing it wrong. There's no discussion to be had when everything goes back to "you're using the tool wrong", even if that tool is designed poorly.
What's worse, go and be the guy telling managers that Scrum should be getting them out of a job. The only people I see doing that are the people not dependent on managers, e.g. Uncle Bob and Allen Hobub, and anonymous reactions here. When you're the one who might lose their job making that statement, suddenly, suffering under misimplemented Scrum and whining about it on the internet doesn't seem so weird anymore.
Kids are using electrical plugs wrong when they stick a pointy object in it. That doesn't mean electrical plugs without child safety close to the ground aren't potential hazards.
Kids damaging their hands doing control-stick spinning minigames using a N64 controller without gloves are "doing it wrong", they could just wear gloves. Still, Nintendo lost that case, and such minigames were deemed problematic.
People browsing a website where the links turn invisible, the mouse doesn't turn into a pointer, the browser doesn't show it is loading and no loading icon is shown, are "doing it wrong" for not just waiting 10 seconds for the page to load. Despite that, UX practices rightly condemn this kind of behavior: at least add an "alive" indicator.
To some degree, you have to make things "stupid proof". That's part of this field. If for some reason, Scrum allows managers more power to micromanage, that's a potential hazard which has to be admitted. That's the problem with the "you're doing it wrong" argument. It doesn't acknowledge potential hazards. Instead, it tries to circumvent that discussion and blindly assumes that developers both can and should "just fix it" when managers are doing it wrong. There's no discussion to be had when everything goes back to "you're using the tool wrong", even if that tool is designed poorly.
What's worse, go and be the guy telling managers that Scrum should be getting them out of a job. The only people I see doing that are the people not dependent on managers, e.g. Uncle Bob and Allen Hobub, and anonymous reactions here. When you're the one who might lose their job making that statement, suddenly, suffering under misimplemented Scrum and whining about it on the internet doesn't seem so weird anymore.
The problem is often not scrum but the organization. Any organization can misuse any framework for micro management. Scrum is only successful when it empowers developers. If scrum doesn't empower you, then do something else or try to figure out what's stopping you from being empowered.
Scrum requires some premises that many businesses have problems adapting to if they've had a micro managed process before.
Scrum is, for better or worse, an all or nothing if it is to reach its full potential. Once you have "real" Scrum, you can start adapting the overall process through retrospective. But if you start your scrum adventure with "Scrum but..." then it's not going to deliver of the promises.
Scrum is, for better or worse, an all or nothing if it is to reach its full potential. Once you have "real" Scrum, you can start adapting the overall process through retrospective. But if you start your scrum adventure with "Scrum but..." then it's not going to deliver of the promises.
It is not just micromanagement, it is also the rest of the business culture. Ego-less development and placing the team over the individual can great for productivity. These productivity gains accrue to the profit of the wider company and _might_ partially flow back to the team, possibly as a bonus or possibly as promotions. However, effacing yourself for the team is unlikely to result in the kind of visibility needed for career progression and with software salaries being what they are that can mean a difference of hundreds of thousands in income over the years.
In a way, scrum and its team-based mechanics form a kind of prisoners dilemma where the first team member to claim credit will gain much more of the value generated than their peers. These incentives need to be taken into account in any framework based on teams cooperating, because they have the potential to rapidly poison any team where people are jockeying for promotion.
In a way, scrum and its team-based mechanics form a kind of prisoners dilemma where the first team member to claim credit will gain much more of the value generated than their peers. These incentives need to be taken into account in any framework based on teams cooperating, because they have the potential to rapidly poison any team where people are jockeying for promotion.
> it might also be the case that the system is either too difficult too learn for most teams or the system does not match the incentives imposed by the environment it is typically deployed into.
The system is simple; the implementation is often shallow and ritualistic, imitating the how without understanding the why. But the way that the question was asked leaves a lot of room for interpretation. I think it is important to consider a technique as it was intended vs as it is implemented. It would be the same for TDD, or pair programming, or object-oriented design patterns, and so on.
When implemented properly, scrum is beneficial, because it makes it easier for the information to flow through the team and for the team to adjust to the reality. When implemented poorly, it is a hurdle, because it degenerates into a bunch of pointless rituals.
The system is simple; the implementation is often shallow and ritualistic, imitating the how without understanding the why. But the way that the question was asked leaves a lot of room for interpretation. I think it is important to consider a technique as it was intended vs as it is implemented. It would be the same for TDD, or pair programming, or object-oriented design patterns, and so on.
When implemented properly, scrum is beneficial, because it makes it easier for the information to flow through the team and for the team to adjust to the reality. When implemented poorly, it is a hurdle, because it degenerates into a bunch of pointless rituals.
The "system" for dieting is also simple (eat less, sport more), and yet many people struggle with that too. What would be really interesting is a scrum variety that is easy for people to follow without losing effectiveness.
> The "system" for dieting is also simple (eat less, sport more), and yet many people struggle with that too.
Yes, but do people then go around saying "this dieting thing is totally dumb and a complete waste of time", "I just don't get why anyone would go on a diet", etc.? And how do those who have managed to stick to a diet and think they have benefited from it look at such people? Because this is the attitude that I think I am seeing in many comments in this thread.
Yes, but do people then go around saying "this dieting thing is totally dumb and a complete waste of time", "I just don't get why anyone would go on a diet", etc.? And how do those who have managed to stick to a diet and think they have benefited from it look at such people? Because this is the attitude that I think I am seeing in many comments in this thread.
Scrum is not dieting, it is just a particular diet. Dieting is agile. And it turns out that Scrum, like all faddy diets, only works for a very small percentage of teams, probably due to their particular character.
That character of enjoying being micro-managed as far as I can tell.
That character of enjoying being micro-managed as far as I can tell.
> That character of enjoying being micro-managed as far as I can tell.
We still haven't established what is it about scrum that makes you say micromanagement. Do you regard all prescriptive statements as micromanagement? Is a software framework, such as Ruby on Rails, or Laravel, or Django micromanagement? Are code reviews micromanagement? Is version control with git micromanagement?
We still haven't established what is it about scrum that makes you say micromanagement. Do you regard all prescriptive statements as micromanagement? Is a software framework, such as Ruby on Rails, or Laravel, or Django micromanagement? Are code reviews micromanagement? Is version control with git micromanagement?
Bad scrum is like the product organization going on a diet but the product owners/managers are still addicted to eating junk food.
I like the analogy.
I like the analogy.
Which is the point I hoped I had made, In fact when I was young I worked on a project for BS5750 (aka ISO 9000) and the v senior guy at BSI mentioned that very thing to me.
The difference between scrum and agile as I see it is that scrum is proscriptive enough that you can tell it doesn't work.
Agile is vague and handwavey enough that you can never really be sure that you're doing it or not. I think that was by design - a badly written rulebook won't spread as easily as a religion you can project your own hopes and dreams on to.
Agile is vague and handwavey enough that you can never really be sure that you're doing it or not. I think that was by design - a badly written rulebook won't spread as easily as a religion you can project your own hopes and dreams on to.
The best about such a process is when you have grown up above the book and can adapt it to what best suits your context.
otherwise known as "I'm not going to let Deloitte dictate the One True Method for building software and instead going to think critically about our own team".
Whether you're "Capital A-Agile" or not - following a bible down to the letter - is so completely irellevent. SCRUM is never the goal, developing software effeciently is. It's a means to an end. If you can think critically about what your team/company needs to do this, then you should.
Whether you're "Capital A-Agile" or not - following a bible down to the letter - is so completely irellevent. SCRUM is never the goal, developing software effeciently is. It's a means to an end. If you can think critically about what your team/company needs to do this, then you should.
This reminds me of the only company I've worked in that attempted to adopt scrum. We almost spent more time debating about whether a particular practice was scrum or not than we did actually doing that practice.
Have you read the manifesto? The whole point of agile is to continuously adapt the process to fit your team. Following SCRUM to the letter is exactly the thing you shouldn't do.
> Have you read the manifesto?
I'm sorry, but the basis of scrum is the scrum guide[0], not the agile manifesto. The scrum framework is fairly rigid (three roles, five events, three artifacts), and I do not remember whether it allows for much flexibility (one role instead of three, two events instead of five, two artifacts instead of three, that kind of thing).
[0] - https://scrumguides.org/scrum-guide.html
I'm sorry, but the basis of scrum is the scrum guide[0], not the agile manifesto. The scrum framework is fairly rigid (three roles, five events, three artifacts), and I do not remember whether it allows for much flexibility (one role instead of three, two events instead of five, two artifacts instead of three, that kind of thing).
[0] - https://scrumguides.org/scrum-guide.html
> when it's not scrum but a totally different, less onerous, process
Can you elaborate on what in the parent comment is not part of scrum?
Can you elaborate on what in the parent comment is not part of scrum?
What? It’s the opposite
He likes doing scrum when it’s actually scrum and not “scrum”
He likes doing scrum when it’s actually scrum and not “scrum”
I think that standing up is actually really important!
We use it to keep things short and focused, since everyone wants to get back to their work and can not do stuff while also taking part in the daily.
We use it to keep things short and focused, since everyone wants to get back to their work and can not do stuff while also taking part in the daily.
> I think that standing up is actually really important!
Alas, it seems many people don't - I think I've only been at one place in the last 10 years who actually cared about keeping standups short and focused. I've been at places where standup was 20 people and took an hour every day.
Mind you, I've been at places where standup was only 5 people and still took 30+ minutes every day...
Alas, it seems many people don't - I think I've only been at one place in the last 10 years who actually cared about keeping standups short and focused. I've been at places where standup was 20 people and took an hour every day.
Mind you, I've been at places where standup was only 5 people and still took 30+ minutes every day...
Yes, this is a known trick and that's why it's used in scrum. Like you say it also helps keep things focused as people pretty much cannot do anything but listen.
A famous example of that trick is the UK's Privy Council: "Customarily the sovereign remains standing at meetings of the Privy Council, so that no other members may sit down, thereby keeping meetings short." [1]
[1] https://en.wikipedia.org/wiki/Privy_Council_of_the_United_Ki...
A famous example of that trick is the UK's Privy Council: "Customarily the sovereign remains standing at meetings of the Privy Council, so that no other members may sit down, thereby keeping meetings short." [1]
[1] https://en.wikipedia.org/wiki/Privy_Council_of_the_United_Ki...
> The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship. Standing around a table in the morning like assholes is not my idea of fun
The morning standup works great when it's all technical people. Keeps the team up to date with each others' progress and cuts down on "I spent three weeks being stuck" problems. Here's what I'm doing, and what I'm doing next, here's what I need a little help on.
When management get involved and the meeting starts with jira thrown up on the screen, sure, then it's terrible.
> If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult.
Here's the problem with that, not every schedule can take that 3 day lag, and someone has to make a decision about whether the product actually needs that new framework, or if it's going to be good enough without.
Maybe you're great at making those decisions, but I've seen many times when people end up going off down rabbitholes either just chasing something shiny, or through a sense of perfectionism that actually holds back release.
The morning standup works great when it's all technical people. Keeps the team up to date with each others' progress and cuts down on "I spent three weeks being stuck" problems. Here's what I'm doing, and what I'm doing next, here's what I need a little help on.
When management get involved and the meeting starts with jira thrown up on the screen, sure, then it's terrible.
> If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult.
Here's the problem with that, not every schedule can take that 3 day lag, and someone has to make a decision about whether the product actually needs that new framework, or if it's going to be good enough without.
Maybe you're great at making those decisions, but I've seen many times when people end up going off down rabbitholes either just chasing something shiny, or through a sense of perfectionism that actually holds back release.
The morning coffee also works great. I really do not understand why there is a need for formalism here.
There is a meeting for what's planned for the week. There are the informal gatherings, like lunch. And if someone is stuck with something, he or she just asks for help. Easy as that.
It helps to give a forum to bring up being stuck, and an opportunity for others to hear it when they're not caught up in the middle of their own stuff.
Plus some people don't know when to ask for help, or when they're (for instance) duplicating effort.
Informal gatherings are not an appropriate venue - if this stuff only comes up then, then lunch gatherings are now work, and they're mandatory.
Plus some people don't know when to ask for help, or when they're (for instance) duplicating effort.
Informal gatherings are not an appropriate venue - if this stuff only comes up then, then lunch gatherings are now work, and they're mandatory.
> Plus some people don't know when to ask for help, or when they're (for instance) duplicating effort.
This is the gist of it. Some people just have this (very sincere) belief that everyone else are clueless idiots and need to be nurtured, protected and helped. This is the spirit of our age, and Scrum in particular is just another manifestation of this belief.
This is the gist of it. Some people just have this (very sincere) belief that everyone else are clueless idiots and need to be nurtured, protected and helped. This is the spirit of our age, and Scrum in particular is just another manifestation of this belief.
I don't think everyone else is a clueles idiot, but there are a lot of them around.
If you have a small(ish) team of great people you can get a lot done with a very informal process. When you start to grow, or you're not necessarily hiring the best there are, you start to need this stuff.
And you don't always need the self-motivated, highly productive builders. Someone has to make small tweaks, pad out the automated test cases, maintain things, document etc etc.
If you have a small(ish) team of great people you can get a lot done with a very informal process. When you start to grow, or you're not necessarily hiring the best there are, you start to need this stuff.
And you don't always need the self-motivated, highly productive builders. Someone has to make small tweaks, pad out the automated test cases, maintain things, document etc etc.
I'm not arguing this, but what does it have to do with standups?
> The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship.
Interesting that it's never mentioned that Jeff Sutherland and Ken Schwaber, the creators of SCRUM both come from the military.
In my experience SCRUM delays and systematizes everything and kills creativity. Kind of like the military.
Interesting that it's never mentioned that Jeff Sutherland and Ken Schwaber, the creators of SCRUM both come from the military.
In my experience SCRUM delays and systematizes everything and kills creativity. Kind of like the military.
> In my experience SCRUM delays and systematizes everything and kills creativity. Kind of like the military.
Systematizing everything and killing creativity is an essential part of making software projects less risky for companies. One of the largest risks to many software projects is the "bus factor" risk, where one employee leaving will scupper the entire project because they were the only ones who knew how it worked. If you have large sums of money riding on the success of a project, it makes sense to invest some time in processes that can mitigate the effect of one team member leaving. It's no surprise that these processes mimic the military, armies are entirely built around the idea that anyone can die at any moment without much impact on the mission.
Systematizing everything and killing creativity is an essential part of making software projects less risky for companies. One of the largest risks to many software projects is the "bus factor" risk, where one employee leaving will scupper the entire project because they were the only ones who knew how it worked. If you have large sums of money riding on the success of a project, it makes sense to invest some time in processes that can mitigate the effect of one team member leaving. It's no surprise that these processes mimic the military, armies are entirely built around the idea that anyone can die at any moment without much impact on the mission.
Your basing this on what military / historical experience?
At the sharp end of a military I certainly see SCRUM/RAD/DSDM as analogous to the ww2 German style of pushing tactical decisions down to a lower level rather than rigid command from above ala the French.
At the sharp end of a military I certainly see SCRUM/RAD/DSDM as analogous to the ww2 German style of pushing tactical decisions down to a lower level rather than rigid command from above ala the French.
Another thing nobody talks about much is that Executives and VP level people love to hire people from the military, because they do exactly what you tell them and rule with an iron fist.
Im sure there are ex-military people who are chill, but ive seen some insane ones running tech verticals in the past.
Im sure there are ex-military people who are chill, but ive seen some insane ones running tech verticals in the past.
Heheh, you are clearly doing it wrong.
1) Non-technical people outside do not get the power. On the contrary its the team that gets much more power. The team is in charge of doing the planning, etc. If the team says: "we will deliver in 2 weeks", manager has no power to force them. Unless he says something like: "ok, in that case I do not need it and do this one instead - that will bring more money".
2) You do not have to stand for the daily. Some teams do it so it involves a little bit of exercise. But you can just as well lean or sit with your coffee and casually share your progress. Like a kitchen talk.
3) Product owner does not OWN your code you fool :D You are the owner. Product owner commands the product. So if you implement a message queue thats great, you can be proud. But was it really needed? Does it bring any money, stability, a value in general to the product? That is something that usually you cannot answer, because you are focused on the quality of the code and do not care about the bullshit numbers right? But in case you do, you are aware of the whole situation, the market, all the customers etc. and you engage in that part, then you are super senior team member, you are self-organized and you actually do not need a product owner. That is like endgoal for Scrum. To create such teams (with such great and senior team members).
4) Scrum does not prevents you from rewriting the code until its perfect. Like where did you get that twisted idea? Scrum even says that tech debt (bad code, needs refactoring, etc.) is incredibly dangerous and should be avoided!
Simply put, if you and/or people in your team and around are assholes that push just for the deadlines (and bureocracy) and do not care about the quality, that is completely 100% on you/them, not on Scrum. Scrum tells you NOT to do it and gives you the power to resist people that are trying to force you to do it like that. Scrum encourages you to share the knowledge and work with others to produce better quality and make your day more easier, comfortable without micromanaging, etc.
1) Non-technical people outside do not get the power. On the contrary its the team that gets much more power. The team is in charge of doing the planning, etc. If the team says: "we will deliver in 2 weeks", manager has no power to force them. Unless he says something like: "ok, in that case I do not need it and do this one instead - that will bring more money".
2) You do not have to stand for the daily. Some teams do it so it involves a little bit of exercise. But you can just as well lean or sit with your coffee and casually share your progress. Like a kitchen talk.
3) Product owner does not OWN your code you fool :D You are the owner. Product owner commands the product. So if you implement a message queue thats great, you can be proud. But was it really needed? Does it bring any money, stability, a value in general to the product? That is something that usually you cannot answer, because you are focused on the quality of the code and do not care about the bullshit numbers right? But in case you do, you are aware of the whole situation, the market, all the customers etc. and you engage in that part, then you are super senior team member, you are self-organized and you actually do not need a product owner. That is like endgoal for Scrum. To create such teams (with such great and senior team members).
4) Scrum does not prevents you from rewriting the code until its perfect. Like where did you get that twisted idea? Scrum even says that tech debt (bad code, needs refactoring, etc.) is incredibly dangerous and should be avoided!
Simply put, if you and/or people in your team and around are assholes that push just for the deadlines (and bureocracy) and do not care about the quality, that is completely 100% on you/them, not on Scrum. Scrum tells you NOT to do it and gives you the power to resist people that are trying to force you to do it like that. Scrum encourages you to share the knowledge and work with others to produce better quality and make your day more easier, comfortable without micromanaging, etc.
First of all, I'm not making the decision by myself, but discuss it with my peers before doing so.
Second of all, the product owner does not command the product. We all do. At least that's how we see it here and it works out quite well. And we are not wasting time on childish stuff like giving story points to our micro tasks or sprint retros.
And of course we care about the business numbers. Or do you think developers are too stupid to realize that this is what counts in the end?
Everything you said is great, but it's not how it plays out for a lot of developers. The people and the politics don't go away because some rules have nominally been adopted. Politically adept people¹ in manager/PO roles will continue to pretend they're following the rules while doing whatever they damn well please.
And when what they please is to micromanage or worse, the developers haven't suddenly gained people savvy because of these rules. They will have just as much trouble fending off the problems as before. Possibly more, in fact, because the (Scrum) rules can be used as cover. Or lead the developers to believe they're protected by the rules, so they don't need to be aware of politics.
---
¹"Sociopaths" if you will, but in the "Gervais Principle" meaning, not the DSM.
And when what they please is to micromanage or worse, the developers haven't suddenly gained people savvy because of these rules. They will have just as much trouble fending off the problems as before. Possibly more, in fact, because the (Scrum) rules can be used as cover. Or lead the developers to believe they're protected by the rules, so they don't need to be aware of politics.
---
¹"Sociopaths" if you will, but in the "Gervais Principle" meaning, not the DSM.
I came from the company that virtually invented Scrum (Easel Corp / Jeff Sutherland) -- showing my age now, I assure you -- it wasn't invented to give non-technical people the power over developers. In fact, it was quite the opposite. It was created to help developers ensure that their lives could be validated in the timebox of work that was required of them. No offense, but you need to probably work in a better Scrum environment. Sounds like you haven't experienced Scrum properly.
Exactly. As far as I know, scrum doesn't have managers. Just don't tell that to the managers ;-)
as soon as he went all "the managers", i knew he'd been poorly educated around Scrum. The funny think about Scrum is that upper management doesn't like it. They'd rather operate in a waterfall approach because they can blow up roadmaps and not have any trace of the offense. With Scrum, you can do the "Ok, but that will require you remove X points from this Sprint and replace that work." Which has a check and balance on that sort of problem when someone wants something unplanned or changes scope on things. Scrum's s a tool to ensure that you have some level of "management" for the management but also it demonstrates how developers aren't always magicians. That's what people who don't like Agile/Scrum don't quite get.
I don't want to be "that guy" but everything you're describing above is not a symptom of Scrum per se but of a toxic working culture. Scrum does not suggest micromanagement or assigning tasks, the goal is for the team to be given a goal and work out what is needed to be done to achieve it. The team works together, no passing back and forth.
As for the PO being a "they" that's something that needs to be addressed. I'm not going to assume ill intent on your part, so let's assume this is again a symptom of a poorly performing team rather than you (or the PO) being unreasonable. But also bear in mind that the PO going off doing "stuff" is generally supposed to be all those things that get in the way of development, e.g. talking to stakeholders & customers, addressing prioritisation problems and trying to prevent the team being overwhelmed with too many goals at the same time.
I'm definitely not saying that micromanagement doesn't happen but I'm saying that you could take your new company's approach (no processes, just let the devs do anything) to the old company and you would have many more problems. It all, as ever, boils down to working culture and practices, and a company that is agile in name only. You can't fix that by splitting things into 2 week chunks and making people talk to each other once a day.
As for the PO being a "they" that's something that needs to be addressed. I'm not going to assume ill intent on your part, so let's assume this is again a symptom of a poorly performing team rather than you (or the PO) being unreasonable. But also bear in mind that the PO going off doing "stuff" is generally supposed to be all those things that get in the way of development, e.g. talking to stakeholders & customers, addressing prioritisation problems and trying to prevent the team being overwhelmed with too many goals at the same time.
I'm definitely not saying that micromanagement doesn't happen but I'm saying that you could take your new company's approach (no processes, just let the devs do anything) to the old company and you would have many more problems. It all, as ever, boils down to working culture and practices, and a company that is agile in name only. You can't fix that by splitting things into 2 week chunks and making people talk to each other once a day.
We do have a process. But it's less formal. Weekly meetings, priority lists, technical discussions, business discussions. If a problem comes up, we just talk to each other. It's easy and makes for a pleasant environment.
One thing I've learned over a long career in software is that a "bad" process that is followed precisely with top to bottom buy-in will always out perform the "best" process with lots of exceptions and lukewarm buy-in.
If you want something like Scrum or agile to work, you must have technical project managers that are independent and, quite frankly, they need to be assholes holding both the tech side and the business side equally accountable.
If you want something like Scrum or agile to work, you must have technical project managers that are independent and, quite frankly, they need to be assholes holding both the tech side and the business side equally accountable.
I see what you mean, and perhaps many/most standups feel pedantic.
But more generally, even in the total absence of "managers" and non-techies, communication is a good thing? Teams not individuals create great projects. Adhoc comms are great, but catching up with other technical folk casually over coffee daily for a couple mins (not more!) seems like a good idea?
Perhaps it's more the pedantic _format_ or feel of most standups that are what's terrible?
But more generally, even in the total absence of "managers" and non-techies, communication is a good thing? Teams not individuals create great projects. Adhoc comms are great, but catching up with other technical folk casually over coffee daily for a couple mins (not more!) seems like a good idea?
Perhaps it's more the pedantic _format_ or feel of most standups that are what's terrible?
Teams are supposed to be self-organising in Agile.
When you implement an anti-agile process such as SCRUM and don't let the developers choose how to communicate, then no, it's not true that more communication is better.
When you implement an anti-agile process such as SCRUM and don't let the developers choose how to communicate, then no, it's not true that more communication is better.
Scrum is only anti agile if you read the guide and think it must be done exactly by the book.
Scrum dictate Planning, Review, Daily and Retrospective. How you do planning, review daily and retrospective is fluid and often adapted during retrospective. When you start you do it by the book and morph it into what suits the team and organization best.
Scrum dictate Planning, Review, Daily and Retrospective. How you do planning, review daily and retrospective is fluid and often adapted during retrospective. When you start you do it by the book and morph it into what suits the team and organization best.
Individuals and interactions over processes and tools
It's the first thing in the agile manifesto. The FIRST.
And yet here you are talking about processes and tools and claiming it's still agile.
It's the first thing in the agile manifesto. The FIRST.
And yet here you are talking about processes and tools and claiming it's still agile.
> And yet here you are talking about processes and tools
First, the Agile Manifesto is not rejecting "the items on the right". It recognizes their value.
Second, the four principles of the Agile Manifesto are extremely general. It does not offer any recommendations on how to achieve the "items on the left". Scrum has a set of concrete recommendations for doing that.
Third, scrum respects all the "items on the left" of the Agile Manifesto. It emphasizes the importance of "individuals and interactions", of "working software", of "customer collaboration", and of "responding to change", and offers a framework for achieving them.
First, the Agile Manifesto is not rejecting "the items on the right". It recognizes their value.
Second, the four principles of the Agile Manifesto are extremely general. It does not offer any recommendations on how to achieve the "items on the left". Scrum has a set of concrete recommendations for doing that.
Third, scrum respects all the "items on the left" of the Agile Manifesto. It emphasizes the importance of "individuals and interactions", of "working software", of "customer collaboration", and of "responding to change", and offers a framework for achieving them.
First, you're focusing on the very things it says not to.
Second, you're focusing on the very things it says not to.
Third, you're focusing on the very things it says not to.
You can't win this, Scrum is usually a proscribed process from management forced onto teams.
That's, by very definition, is the antithesis of agile. Agile is supposed to be about self-organising teams that decide how they work best. If that's scrum, fine, but if that's imposed by management, it's not agile, it's anti-agile. SCRUM, SCRUM masters, SCRUM cards, etc., etc. etc. are all anti-agile by very definition.
Second, you're focusing on the very things it says not to.
Third, you're focusing on the very things it says not to.
You can't win this, Scrum is usually a proscribed process from management forced onto teams.
That's, by very definition, is the antithesis of agile. Agile is supposed to be about self-organising teams that decide how they work best. If that's scrum, fine, but if that's imposed by management, it's not agile, it's anti-agile. SCRUM, SCRUM masters, SCRUM cards, etc., etc. etc. are all anti-agile by very definition.
> If that's scrum, fine, but if that's imposed by management, it's not agile, it's anti-agile. SCRUM, SCRUM masters, SCRUM cards, etc., etc. etc. are all anti-agile by very definition.
There's a lapse of logic that is happening somewhere in the middle of this passage.
You can say that self-organising teams can decide that they work quite well within the scrum framework. Good.
You can say that self-organising teams can also decide that they do not like the formalisms of the scrum framework, and prefer some other set of guiding principles to achieve their agile ideals. Good.
You can also say that the management may muscle their incompetent way in and impose scrum upon the unwilling team, and by doing so divorce scrum from the agile principles that it was intended to uphold. Fine.
But what you cannot do is to conclude from the last statement that scrum is anti-agile. Just as you wouldn't conclude — if the management were so insane as to demand that all their teams program only in ruby — that ruby is an anti-agile programming language. What happened in that last statement has nothing to do with scrum and is no fault of scrum.
There's a lapse of logic that is happening somewhere in the middle of this passage.
You can say that self-organising teams can decide that they work quite well within the scrum framework. Good.
You can say that self-organising teams can also decide that they do not like the formalisms of the scrum framework, and prefer some other set of guiding principles to achieve their agile ideals. Good.
You can also say that the management may muscle their incompetent way in and impose scrum upon the unwilling team, and by doing so divorce scrum from the agile principles that it was intended to uphold. Fine.
But what you cannot do is to conclude from the last statement that scrum is anti-agile. Just as you wouldn't conclude — if the management were so insane as to demand that all their teams program only in ruby — that ruby is an anti-agile programming language. What happened in that last statement has nothing to do with scrum and is no fault of scrum.
I've never met an actual, real developer (not manager or business wonk) who actually liked Agile. At most, people seem to tolerate it.
I don't like Agile when it's sold as such. I absolutely refuse to discuss Agile with certificate peddlers. SAFe is the worst of the bunch, with expiring certificates, they make money on renewal.
I'm a developer now managing product. if you apply a historical analysis perspective, Agile has either influenced our process, or our process may be described as post-Agile.
We have a backlog, organized by priority. We have self-organizing teams. Teams make their own planning and own their backlog. I, as the person responsible for product, take time meeting the people involved in making the product work in the market. Such as legal, finance, etc etc. The team does not have to participate in this, but they are welcome to.
What I have fought hard for is to not have management push tech stacks at teams. Developers get to decide, unless there is a legacy situation, and then they get to decide if they want to work with it. And we have a clearly defined org culture. That's as in who gets paid more, promoted, and why.
The developers have a higher-than average salary (algo for market value known to all and published internally), a % set bonus from total net, and an option to go for a higher % of bonuses by forgoing some of their salary. Some people like a known salary, some prefer a chance for a higher pay-out with more risk involved.
I'm writing a master's thesis on project management at the moment, part-time, and have had to do entirely too much reading up on Agile and project management history. Like I wrote, we can absolutely be classified as Agile. We just don't have it pushed down our throats, and we have a realistic culture - our part of the business is dependent on excellent developers, we treat them with respect, give them decision-making power, offer a share of the profits, and expect them to care about the product as a whole and their part in it.
If the "Agile" you have been exposed to does not treat developers with respect, nor establish a mutually beneficial organizational culture, the market will sort the organization out, as long as developers remain a crucial part of the equation.
I'm a developer now managing product. if you apply a historical analysis perspective, Agile has either influenced our process, or our process may be described as post-Agile.
We have a backlog, organized by priority. We have self-organizing teams. Teams make their own planning and own their backlog. I, as the person responsible for product, take time meeting the people involved in making the product work in the market. Such as legal, finance, etc etc. The team does not have to participate in this, but they are welcome to.
What I have fought hard for is to not have management push tech stacks at teams. Developers get to decide, unless there is a legacy situation, and then they get to decide if they want to work with it. And we have a clearly defined org culture. That's as in who gets paid more, promoted, and why.
The developers have a higher-than average salary (algo for market value known to all and published internally), a % set bonus from total net, and an option to go for a higher % of bonuses by forgoing some of their salary. Some people like a known salary, some prefer a chance for a higher pay-out with more risk involved.
I'm writing a master's thesis on project management at the moment, part-time, and have had to do entirely too much reading up on Agile and project management history. Like I wrote, we can absolutely be classified as Agile. We just don't have it pushed down our throats, and we have a realistic culture - our part of the business is dependent on excellent developers, we treat them with respect, give them decision-making power, offer a share of the profits, and expect them to care about the product as a whole and their part in it.
If the "Agile" you have been exposed to does not treat developers with respect, nor establish a mutually beneficial organizational culture, the market will sort the organization out, as long as developers remain a crucial part of the equation.
Small a, fine, it's a positive little adjective. Big A, run for the hills.
If you are on a project with more than one person having some kind of process is a good thing.
‘Agile’ gives you the flexibility to determine what that process is. Scrum is a different story.
‘Agile’ gives you the flexibility to determine what that process is. Scrum is a different story.
I am a real developer who likes agile, nice to meet you :)
I see the Product Owner role the most critical for the success of Scrum in general. This is for PO's simple yet not given properties - vision about the product, vision of success, and the ability to express this.
Everybody else in Scrum is depended on the PO's abilities. One can train to improve the expression and prioritization skills, but it's very hard to train to develop or (even to appropriate) a vision about the product and the success.
This becomes even more acute in corporate environment, most PO are recast from former Project or Product Managers, who by definitions are Managers, not visionaries, nor intended customers of the product.
As a result, that critical element - the product vision - simply cannot be shared. It's just another "Quarterly Goal" in disguise - "the stonk must up!".
So the corpo-Scrum has a greater chance to devolve into shared lack of vision and collaboration theater.
One could paraphrase "Show me your PO, and I will tell what your Scrum is".
Everybody else in Scrum is depended on the PO's abilities. One can train to improve the expression and prioritization skills, but it's very hard to train to develop or (even to appropriate) a vision about the product and the success.
This becomes even more acute in corporate environment, most PO are recast from former Project or Product Managers, who by definitions are Managers, not visionaries, nor intended customers of the product.
As a result, that critical element - the product vision - simply cannot be shared. It's just another "Quarterly Goal" in disguise - "the stonk must up!".
So the corpo-Scrum has a greater chance to devolve into shared lack of vision and collaboration theater.
One could paraphrase "Show me your PO, and I will tell what your Scrum is".
I really haven't experienced this sentiment. It sounds like you had a bad experience. Scrum can be amazing depending on who is implementing it. Even 7 years ago at AWS, micromanagement wasn't and couldn't afford to be a thing, yet we were most definitely a Scrum team. It was what held us together despite the lack of management. Yeah there would be arguments between PMs and devs, but that is healthy, and most often the PMs lost said arguments. Everyone was placed adjacent to one another, and I adjacent to the project manager, which gave ample time for arguments, but in a way that was better for the team as a whole. It introduced a sort of democracy with continual meetings to ensure that we were working efficiently at any given time.
Agree completely, for a period of time I was working scrumless and quite happy with it. Got a new manager and some new tech leads join and suddenly we need several stand ups, scrums, and checkins because they don’t know how else to figure out what’s going on. It sucks.
I’ve never witnessed “I’m having trouble on this” -> “Oh I ran into that before, have you seen X” in an official Scrum. Official Scrums are just status updates for your manager/other authority figure.
We’re also cargo culting other processes (sprint planning) that don’t even fit in with how our company does planning - we do everything quarterly, most tasks aren’t really re-assignable - so it’s just a shaming session for people who underestimated task lengths or are running behind.
I’ve never witnessed “I’m having trouble on this” -> “Oh I ran into that before, have you seen X” in an official Scrum. Official Scrums are just status updates for your manager/other authority figure.
We’re also cargo culting other processes (sprint planning) that don’t even fit in with how our company does planning - we do everything quarterly, most tasks aren’t really re-assignable - so it’s just a shaming session for people who underestimated task lengths or are running behind.
But, ironically, you are being 'Agile' in this new role.
I mean the term is sooo elastic it is hardly meaningful, but if you have a high skilled team, with clear shared concrete goals, producing code at pace, where the code is the measure of progress then that meets pretty much all the things that got written down in the Manifesto.
The fact that the manifest is just an observation of what we all know - how it feels to do really good work in a team, well, great.
The problem with Agile / work / life is that its hard to get all those pieces together and just as hard to maintain.
I think Programmer Anarchy is closest to the right idea. Get a bunch of (skilled) programmers together and give them a direction. But it is called anarchy to emphasise the idea you cannot have non-programmers in charge, or an organisational hierarchy getting in the way.
Changing that is what derails almost all Agile projects - its why Acqui-hires fail to keep the esprit d'corps, its why startups slowdown as they grow, its why steam engines were great before the factories, its ... humans aren't good at letting emergent order handle their day to day lives.
tl;dr - its not Agile or Scrum. Its us - its the difficulty of organising humans, its the constant fight against entropy, its scale and centralised planning vs letting the market decide.
We should all probably live and work under the Dunbar number, and allow markets to find where value is created.
I see ledgers as enabling that. The supply chain will set us free.
I mean the term is sooo elastic it is hardly meaningful, but if you have a high skilled team, with clear shared concrete goals, producing code at pace, where the code is the measure of progress then that meets pretty much all the things that got written down in the Manifesto.
The fact that the manifest is just an observation of what we all know - how it feels to do really good work in a team, well, great.
The problem with Agile / work / life is that its hard to get all those pieces together and just as hard to maintain.
I think Programmer Anarchy is closest to the right idea. Get a bunch of (skilled) programmers together and give them a direction. But it is called anarchy to emphasise the idea you cannot have non-programmers in charge, or an organisational hierarchy getting in the way.
Changing that is what derails almost all Agile projects - its why Acqui-hires fail to keep the esprit d'corps, its why startups slowdown as they grow, its why steam engines were great before the factories, its ... humans aren't good at letting emergent order handle their day to day lives.
tl;dr - its not Agile or Scrum. Its us - its the difficulty of organising humans, its the constant fight against entropy, its scale and centralised planning vs letting the market decide.
We should all probably live and work under the Dunbar number, and allow markets to find where value is created.
I see ledgers as enabling that. The supply chain will set us free.
Actually, SCRUM was designed to make software dev teams less dependant on management. The problem you describe arose when consultancies decided that this is something that can be wrapped in a powerpoint lsidedeck and sold as "more results faster" to top management for $$$.
That being said, I do not think from your description you have experienced either SCRUM nor Agile.
That being said, I do not think from your description you have experienced either SCRUM nor Agile.
Your experience is not about Scrum, but about a poorly implemented management: the process or tools proposed by Scrum (or Agile) is there to help the team, and allow to do, make their magic, not to micro-manage and assign tasks. Your previous team clearly failed at it, or we should say it succeeded at using a trending keyword to make their own agenda.
Your new team example doesn't seem much better to me: even-though the freedom you like is what should be, the lack of process can't work in any reasonable even middle-size team. The process is not about slowing you down or giving power to management: it should be there to help you as a team member keep the vision and target, and sharing. How would you know how to collaborate with others on the team if you don't have any way to know what they are doing or how would you improve your creativity if you don't have any feedback on what you are doing?
Your new team example doesn't seem much better to me: even-though the freedom you like is what should be, the lack of process can't work in any reasonable even middle-size team. The process is not about slowing you down or giving power to management: it should be there to help you as a team member keep the vision and target, and sharing. How would you know how to collaborate with others on the team if you don't have any way to know what they are doing or how would you improve your creativity if you don't have any feedback on what you are doing?
I think the goal of scrum is exactly what you are striving for: to only have the end result count. If you can achieve this without a process, that's great. However, that puts a big responsibility on the developer: you need to weigh development effort against business benefits and really try to understand the customer. If you are up for it and capable of it, that's great, then you don't need scrum or any framework. You are then the owner, period. However, in my experience, most developers do not really care about the business side of things. Also there expertise is often not in prioritizing development efforts to maximize business value. So I can completely understand what you are saying, but most developers are not you (in my experience) and they do not naturally own the things they create.
Sounds like zombie scrum. A good scrum team will be self-driven. Micro-management from external sources is an anti-pattern and usually means you have a poor scrum master who doesn't understand that their job is to protect their team.
> in my new company, where we do not have any process at all, just a common goal. Instead of standups, the team gathers for a coffee in the morning. If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult. That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines. So no more Scrum for me. Never.
I love this. Mind sharing the name of the company?
I love this. Mind sharing the name of the company?
> If I develop something, I am the owner.
How do you, as a product owner, coming up with new features? How do you, as a product owner, prioritize one feature over other?
How do you, as a product owner, coming up with new features? How do you, as a product owner, prioritize one feature over other?
100% agree with this.
Amen to that
by any chance is your new company hiring?
It forces junior engineers to communicate which is great when you're still learning. Also some people really need "microtasks."
IMO: Agile produces worse software but when done correctly with a reasonable boss the work environment it produces is much simpler socially.
IMO: Agile produces worse software but when done correctly with a reasonable boss the work environment it produces is much simpler socially.
I think you need to separate Agile from Scrum to be honest.
Agile is at is core just some suggestions for teams to work well together. There are no stand ups or sprints or whatever.
Scrum was created by one of the creators of the agile manifesto as a way to see consulting/training around the 'Agile' idea (timeframes may differ a bit, but they were linked). There is an interview/article by one of the creators of the agile manifesto (Kent Beck maybe?, will try to dig it up and edit the answer if I find -> was Robert C. Martin, see below) where he explains a bit the story and compares it to Agile (and basically says scrum has nothing to do with the original agile manifesto)
On a personal level, I hate scrum. The stand ups, the sprints, the retros or grooming or whatever they have nowadays. It is literally one of the first questions I ask in an interview about their processes and excuse myself from the process if I see if they follow it. It may work for others, but for me personally, I hate it with a fervour.
Though I agree with the Agile manifesto though, unfortunately it isn't very 'manager' friendly so you usually get scrum instead.
Edit: link to a reference to the article, can't find the original but found this: https://www.aaron-gray.com/a-criticism-of-scrum/#scrum-strai...
Agile is at is core just some suggestions for teams to work well together. There are no stand ups or sprints or whatever.
Scrum was created by one of the creators of the agile manifesto as a way to see consulting/training around the 'Agile' idea (timeframes may differ a bit, but they were linked). There is an interview/article by one of the creators of the agile manifesto (Kent Beck maybe?, will try to dig it up and edit the answer if I find -> was Robert C. Martin, see below) where he explains a bit the story and compares it to Agile (and basically says scrum has nothing to do with the original agile manifesto)
On a personal level, I hate scrum. The stand ups, the sprints, the retros or grooming or whatever they have nowadays. It is literally one of the first questions I ask in an interview about their processes and excuse myself from the process if I see if they follow it. It may work for others, but for me personally, I hate it with a fervour.
Though I agree with the Agile manifesto though, unfortunately it isn't very 'manager' friendly so you usually get scrum instead.
Edit: link to a reference to the article, can't find the original but found this: https://www.aaron-gray.com/a-criticism-of-scrum/#scrum-strai...
I've found the retrospectives to be the most valuable part of the scrum ceremonies, taking the time to talk through what could be improved etc.
Stand-ups tend to be too much of a status report to the manager and are more valuable when its the developers talking between themselves and sharing knowledge of their work.
My biggest dislike for Scrum is how managers can use it to turn "agile" into basically a MS Project plan from the estimates.
Stand-ups tend to be too much of a status report to the manager and are more valuable when its the developers talking between themselves and sharing knowledge of their work.
My biggest dislike for Scrum is how managers can use it to turn "agile" into basically a MS Project plan from the estimates.
> are more valuable when its the developers talking between themselves and sharing knowledge of their work
This is the biggest lie of standups. No one gives a shit about standups. Everyone is waiting for their turn and then not listening to others. Let's stop pretending. If they need help, they'll reach out to the expert on 1:1 basis. Way more productive, way more concise, better bonds, privacy and learning experience.
No one waits until standup and be like "Gee.. I should ask this help in front of 8 others and waste everyone's time".
This is the biggest lie of standups. No one gives a shit about standups. Everyone is waiting for their turn and then not listening to others. Let's stop pretending. If they need help, they'll reach out to the expert on 1:1 basis. Way more productive, way more concise, better bonds, privacy and learning experience.
No one waits until standup and be like "Gee.. I should ask this help in front of 8 others and waste everyone's time".
This is completely false for the majority of places I've worked. Plenty of people don't notice how much they've got stuck, or don't know who the right expert is, or feel self-conscious about interrupting them to ask a question. Having a daily scheduled time where all the experts are available and everyone should check whether they're getting bogged down is a big help.
I've experienced the kind of "standup" you describe too, but it usually coincided with not actually following the rules for what a standup is (e.g. not actually standing up) and a bunch of other fake agile.
I've experienced the kind of "standup" you describe too, but it usually coincided with not actually following the rules for what a standup is (e.g. not actually standing up) and a bunch of other fake agile.
Huh? How are people not contacting the experts or reaching out for help? Seems fundamental to being a professional, doesn’t matter what profession.
That seems like a bad culture more than anything else.
That seems like a bad culture more than anything else.
I've worked in a range of different cultures, and you're exactly right. It's "bad culture", it's people who are oriented towards individual competition rather than collaboration. It's when your SME's tear down others for not finding their specialized knowledge as "obvious". It's where the pervasive attitude is anti-documentation, anti-code comments ("if it was hard to write, it should be hard to read") - It's when members are not attuned to the possibility that others lack context because they're in a narrow role without exposure to what the broader team is doing. But mostly, it's just people being assholes.
Being "stuck" working in a company like that really sucks. You can spend years spinning your wheels just trying to keep up. Working at a company that fosters collaboration and non-judmental attitudes. . . it's like night and day, and you can grow your skills and get out of a narrow role, and look at the big picture.
These are the kinds of things that every engineer needs to learn to look for when you're doing an interview somewhere.
Being "stuck" working in a company like that really sucks. You can spend years spinning your wheels just trying to keep up. Working at a company that fosters collaboration and non-judmental attitudes. . . it's like night and day, and you can grow your skills and get out of a narrow role, and look at the big picture.
These are the kinds of things that every engineer needs to learn to look for when you're doing an interview somewhere.
I consider my job very uninteresting, utterly useless and it really sucks but not because of assholes - thank god.
I understand your take, thanks for the contrast.
I understand your take, thanks for the contrast.
Most developers are introverts, everyone has their own pride, and a lot of the time the difference between a getting stuck because you're missing something and getting stuck because what you're doing is just genuinely hard is not at all obvious - especially when you're in the tunnel-vision of trying to solve the problem and in a workplace where you've deliberately eliminated distractions and interruptions (which is a very good thing on the whole, but comes with its own costs).
What?
How is the best situation for a prideful introvert to have a scheduled meeting every morning where they can make it known to the entire team exactly how stuck they are?
If anything those are the exact traits that make devs prefer 1-on-1 communication.
How is the best situation for a prideful introvert to have a scheduled meeting every morning where they can make it known to the entire team exactly how stuck they are?
If anything those are the exact traits that make devs prefer 1-on-1 communication.
How else to learn humble, team-oriented, potentially uncomfortable honesty but regular practice?
Psychological safety is the biggest factor in overal team performance and morale. That safety comes from trust, and that trust comes from routine demonstration of vulnerability and support.
Lone wolf rockstars can have their own moments of self-defeat and wheelspinning too. But if they haven’t developed a sense of courage and humility to admit it and bring it to the team, then the whole team is now literally bottlenecked on their ego.
Psychological safety is the biggest factor in overal team performance and morale. That safety comes from trust, and that trust comes from routine demonstration of vulnerability and support.
Lone wolf rockstars can have their own moments of self-defeat and wheelspinning too. But if they haven’t developed a sense of courage and humility to admit it and bring it to the team, then the whole team is now literally bottlenecked on their ego.
>That safety comes from trust, and that trust comes from routine demonstration of vulnerability and support
That's my intuition about what's wrong with these ceremonies: they look like they are trying to foster those things by enforcing the superficial behaviours seen in good teams, but it is just the effect. A team with trust, close bonded and efficient has "standups" and "retros" in an organic way, because that's the effect of a team that work together.
I always felt these methodologies try to turn it around, as in "let's force the superficial behaviours we see in good teams, so it will make other teams as good". But it doesn't work that way and it ends up being a tool for managers.
That's my intuition about what's wrong with these ceremonies: they look like they are trying to foster those things by enforcing the superficial behaviours seen in good teams, but it is just the effect. A team with trust, close bonded and efficient has "standups" and "retros" in an organic way, because that's the effect of a team that work together.
I always felt these methodologies try to turn it around, as in "let's force the superficial behaviours we see in good teams, so it will make other teams as good". But it doesn't work that way and it ends up being a tool for managers.
It’s a nice story about rockstars: when the mythical 10x engineer gets stuck, PMs fucking PANIC.
Lul, you are over-estimating managers capabilities to differentiate a 10x developer from a 0.1x developer.
> How is the best situation for a prideful introvert to have a scheduled meeting every morning where they can make it known to the entire team exactly how stuck they are?
Because the whole team's doing it, because it creates a space where it's ok to have got stuck, and because the once-a-day schedule sets a clear expectation about how long it's ok to be stuck for without at least considering asking for help.
If you were happy getting yourself unstuck asking for help 1-on-1 you can still do that, and you'll never be stuck when it comes to the standup, so it should be no skin off your nose. The standup is for the sake of the people who would previously be stuck quietly for days at a time.
(though if I'm on the receiving end, I'd prefer to nudge you towards asking in standup or at least in an async way, rather than interrupting my own flow by asking me for help)
Because the whole team's doing it, because it creates a space where it's ok to have got stuck, and because the once-a-day schedule sets a clear expectation about how long it's ok to be stuck for without at least considering asking for help.
If you were happy getting yourself unstuck asking for help 1-on-1 you can still do that, and you'll never be stuck when it comes to the standup, so it should be no skin off your nose. The standup is for the sake of the people who would previously be stuck quietly for days at a time.
(though if I'm on the receiving end, I'd prefer to nudge you towards asking in standup or at least in an async way, rather than interrupting my own flow by asking me for help)
I empathize with devs that are introverts. They'd rather not be in the stand up in the first place.
Well that is something they will need help in learning to overcome software is a team endeavour.
Stop conflating introversion with whether or not somebody is a 'team player'.
Did I say "team player"
Sometimes you spend all day banging your head against the wall and just forget. The stand up gives you space and a reminder to tell other people you’re stuck.
Ego, experts having no time on their calendar etc. I found that daily scrum created better communication in our team, where there was none before.
Except this is completely anti thetical to the idea of stand ups which are supposed to be peer to peer as opposed to a more expert to non expert relationship.
What you’re really looking for is office hours.
If you’re self conscious about asking questions, how is it easier to do it in the moment with your entire team also listening in, as opposed to a direct IM, or email if you’re worried about disturbing the busy expert?
And how often do people have questions for experts? More often during the beginning of a project, then there’s a lull, then maybe some more questions as you find things you hadn’t thought of, then another lull, and then more questions towards the end where you are trying to close all the loose ends.
Daily standup requires you take up the expert’s valuable time in equal amounts during all those periods. And you have a bunch of people listening in who have no reason to be in that conversation. (A single 15 minute standup with a team of 8 is straight up 2 hours down the drain. And that does not include any of the context switching costs, or the cost of interrupting someone doing deep work).
Wouldn’t it be much bette to setup a 1 hour meeting on day 1 of the project with the expert (doesn’t stand up add a whole role, scrum master, whose only purpose is to direct people to the correct experts, basically? Well, use them if you don’t know who the expert is...prior to scrum we simply went to our team lead for situations like that). A 30 minute follow up at the end of the week.
Then another 30 minute follow up a week later and a 1 hour meeting a week later close to the end of the project.
That’s 3 hours worth of time from the expert in a span of 3 weeks, but the expert gets to hold forth for those entire 3 hours, without having to waste 12 out of 15 mins listening to useless crap. That’s a straight up 20% saving over the stand ups, gets you a full 3 hours from them, as opposed to 20% of the time, gets their attention in decent chunks of times, where you can have a real discussion, interrupts them 4 times over 15 working days as opposed to 15 times, and only includes those who are directly relevant to the discussion as opposed to everybody.
What you’re really looking for is office hours.
If you’re self conscious about asking questions, how is it easier to do it in the moment with your entire team also listening in, as opposed to a direct IM, or email if you’re worried about disturbing the busy expert?
And how often do people have questions for experts? More often during the beginning of a project, then there’s a lull, then maybe some more questions as you find things you hadn’t thought of, then another lull, and then more questions towards the end where you are trying to close all the loose ends.
Daily standup requires you take up the expert’s valuable time in equal amounts during all those periods. And you have a bunch of people listening in who have no reason to be in that conversation. (A single 15 minute standup with a team of 8 is straight up 2 hours down the drain. And that does not include any of the context switching costs, or the cost of interrupting someone doing deep work).
Wouldn’t it be much bette to setup a 1 hour meeting on day 1 of the project with the expert (doesn’t stand up add a whole role, scrum master, whose only purpose is to direct people to the correct experts, basically? Well, use them if you don’t know who the expert is...prior to scrum we simply went to our team lead for situations like that). A 30 minute follow up at the end of the week.
Then another 30 minute follow up a week later and a 1 hour meeting a week later close to the end of the project.
That’s 3 hours worth of time from the expert in a span of 3 weeks, but the expert gets to hold forth for those entire 3 hours, without having to waste 12 out of 15 mins listening to useless crap. That’s a straight up 20% saving over the stand ups, gets you a full 3 hours from them, as opposed to 20% of the time, gets their attention in decent chunks of times, where you can have a real discussion, interrupts them 4 times over 15 working days as opposed to 15 times, and only includes those who are directly relevant to the discussion as opposed to everybody.
You're not asking 'the expert', you're asking everyone in the team.
'The expert' may turn out to be the junior you just hired.
It's also about flagging issues. Sometimes 'This is not working' is not synonymous with '...because I haven't figured out how to do it.'
It can also mean 'This is actually broken' and the team hasn't realised.
'The expert' may turn out to be the junior you just hired.
It's also about flagging issues. Sometimes 'This is not working' is not synonymous with '...because I haven't figured out how to do it.'
It can also mean 'This is actually broken' and the team hasn't realised.
That's a great point. And here is a real example that happened recently at work. One of my teams needs to create the ability for their low-level code to be able to respond to HTTP requests for command and control. So they have all immediately started trying to figure out how to do this. Except I happen to know that another of my teams already did this exact same thing in another project, packaged it up and published it...and the source code is already sitting there on github waiting to be re-used. There is zero overlap between the two teams (two totally different departments) except for me, so in this case I (as a lowly engineering manager whose coding days are long behind me) am able to solve a problem and save time/wasted effort Now, if we didn't do dailies, of course this would come up at some point but we'd have lost a week of productivity or more.
> stand ups which are supposed to be peer to peer as opposed to a more expert to non expert relationship.
Right - I'm taking the assumption that everyone will have their own area of expertise, and "the expert" for a given issue might be any one of your peers.
> If you’re self conscious about asking questions, how is it easier to do it in the moment with your entire team also listening in, as opposed to a direct IM, or email if you’re worried about disturbing the busy expert?
Because there's a specific time at which you're expected to do it. It's very easy to keep putting off an IM/email, thinking you'll just spend a bit more time trying to figure it out yourself first. And the expert has already been disturbed, so there's no need to feel guilty about interrupting them.
> Wouldn’t it be much bette to setup a 1 hour meeting on day 1 of the project with the expert (doesn’t stand up add a whole role, scrum master, whose only purpose is to direct people to the correct experts, basically? Well, use them if you don’t know who the expert is...prior to scrum we simply went to our team lead for situations like that). A 30 minute follow up at the end of the week.
No, having experienced both approaches. You're so much more productive if you have direct, daily access to the expert. On day 1 you don't know what questions to ask; most of what a programmer spends their time doing is exploring the problem space. If you've got a daily iteration cycle where you ask a couple of questions, try things out, and then come back the next day with some follow ups based on what you've learnt, you get a whole lot more done.
> That’s 3 hours worth of time from the expert in a span of 3 weeks, but the expert gets to hold forth for those entire 3 hours, without having to waste 12 out of 15 mins listening to useless crap. That’s a straight up 20% saving over the stand ups, gets you a full 3 hours from them, as opposed to 20% of the time, gets their attention in decent chunks of times, where you can have a real discussion, interrupts them 4 times over 15 working days as opposed to 15 times, and only includes those who are directly relevant to the discussion as opposed to everybody.
It doesn't end up being "useless crap"; everyone is part of the same team delivering the same product, so it's important to have cross-pollination about what's everyone else is doing.
Of course if someone has particular expertise that warrants holding forth for an hour on the subject, it might be worth scheduling a time for them to do that. But there's definitely no substitute for having everyone available every day, at the same time as the rest of the team.
Right - I'm taking the assumption that everyone will have their own area of expertise, and "the expert" for a given issue might be any one of your peers.
> If you’re self conscious about asking questions, how is it easier to do it in the moment with your entire team also listening in, as opposed to a direct IM, or email if you’re worried about disturbing the busy expert?
Because there's a specific time at which you're expected to do it. It's very easy to keep putting off an IM/email, thinking you'll just spend a bit more time trying to figure it out yourself first. And the expert has already been disturbed, so there's no need to feel guilty about interrupting them.
> Wouldn’t it be much bette to setup a 1 hour meeting on day 1 of the project with the expert (doesn’t stand up add a whole role, scrum master, whose only purpose is to direct people to the correct experts, basically? Well, use them if you don’t know who the expert is...prior to scrum we simply went to our team lead for situations like that). A 30 minute follow up at the end of the week.
No, having experienced both approaches. You're so much more productive if you have direct, daily access to the expert. On day 1 you don't know what questions to ask; most of what a programmer spends their time doing is exploring the problem space. If you've got a daily iteration cycle where you ask a couple of questions, try things out, and then come back the next day with some follow ups based on what you've learnt, you get a whole lot more done.
> That’s 3 hours worth of time from the expert in a span of 3 weeks, but the expert gets to hold forth for those entire 3 hours, without having to waste 12 out of 15 mins listening to useless crap. That’s a straight up 20% saving over the stand ups, gets you a full 3 hours from them, as opposed to 20% of the time, gets their attention in decent chunks of times, where you can have a real discussion, interrupts them 4 times over 15 working days as opposed to 15 times, and only includes those who are directly relevant to the discussion as opposed to everybody.
It doesn't end up being "useless crap"; everyone is part of the same team delivering the same product, so it's important to have cross-pollination about what's everyone else is doing.
Of course if someone has particular expertise that warrants holding forth for an hour on the subject, it might be worth scheduling a time for them to do that. But there's definitely no substitute for having everyone available every day, at the same time as the rest of the team.
> It doesn't end up being "useless crap"; everyone is part of the same team delivering the same product, so it's important to have cross-pollination about what's everyone else is doing.
And in the same breath, it is a pipe dream to believe this can be achieved in 15-30 minutes every day. That's part of the controversy behind daily scrum: as a status update tool (which, yes I know, it "isn't supposed to be"), it is too long and there are better methods which can be automated. As a tool to actually share things, it is far too short. In both cases, it is incredibly disruptive and goes against most existing theories on flow and productivity. Planning an hour session later is a mitigation tool, though it is arguably an extremely poor one.
>But there's definitely no substitute for having everyone available every day, at the same time as the rest of the team.
And you know that based on an experiment which has been going on in an extremely informal manner for 20 years? Remote work was deemed "impossible" and "no substitute for real work", but many of us seem to do just fine. Let's not count our chickens before they hatch.
And in the same breath, it is a pipe dream to believe this can be achieved in 15-30 minutes every day. That's part of the controversy behind daily scrum: as a status update tool (which, yes I know, it "isn't supposed to be"), it is too long and there are better methods which can be automated. As a tool to actually share things, it is far too short. In both cases, it is incredibly disruptive and goes against most existing theories on flow and productivity. Planning an hour session later is a mitigation tool, though it is arguably an extremely poor one.
>But there's definitely no substitute for having everyone available every day, at the same time as the rest of the team.
And you know that based on an experiment which has been going on in an extremely informal manner for 20 years? Remote work was deemed "impossible" and "no substitute for real work", but many of us seem to do just fine. Let's not count our chickens before they hatch.
> goes against most existing theories on flow and productivity
There's no contradiction; the whole premise is that those are measuring the wrong thing, that the cost of misalignment and building useless things dominates those concerns. That matches my experience.
> Let's not count our chickens before they hatch.
Look, if you've got some magic way to make things work then great. But an hour at the start, thirty minutes each week, and an hour at the end, is absolutely no substitute for having someone in your daily standup; I've done both (or pretty close to it) and it's night and day.
There's no contradiction; the whole premise is that those are measuring the wrong thing, that the cost of misalignment and building useless things dominates those concerns. That matches my experience.
> Let's not count our chickens before they hatch.
Look, if you've got some magic way to make things work then great. But an hour at the start, thirty minutes each week, and an hour at the end, is absolutely no substitute for having someone in your daily standup; I've done both (or pretty close to it) and it's night and day.
I partially agree but have found it useful to just air my thoughts briefly as there is not always an obvious expert for every subject
"I am not sure about the best way to proceed..." Or "I think I am going to try X not Y..." Or "I got some weird error I don't understand so I am going to be trying to work that out today..."
Often someone will pipe up and say they've had some experience there or faced same issue before and let's talk after the standup or they have a fix in the pipeline for that so don't worry about it until next Tuesday etc etc.
I guess if your colleagues don't listen in meetings though you have a different problem.
I personally find that standups that focus on the outstanding tickets help me to focus on actually working on the tickets themselves :) rather than getting distracted onnbusy work or investigating some curious bug or refactoring something if I have to standup the next day and say "I did nothing on those tickets assigned to me".
"I am not sure about the best way to proceed..." Or "I think I am going to try X not Y..." Or "I got some weird error I don't understand so I am going to be trying to work that out today..."
Often someone will pipe up and say they've had some experience there or faced same issue before and let's talk after the standup or they have a fix in the pipeline for that so don't worry about it until next Tuesday etc etc.
I guess if your colleagues don't listen in meetings though you have a different problem.
I personally find that standups that focus on the outstanding tickets help me to focus on actually working on the tickets themselves :) rather than getting distracted onnbusy work or investigating some curious bug or refactoring something if I have to standup the next day and say "I did nothing on those tickets assigned to me".
But why would you wait to ask until the next day, at a fixed time?
You're looking at this from the long angle. Of course you shouldn't wait.
However, many people, without explicit prompting, will in fact never ask these types of questions at all. That is the value of the daily stand-up: it ensures that everyone is prompted to as these things AT LEAST once every day, rather than holding onto them for who knows how long.
I'd also note that, without dailys, it's rather rare to have the entire team together in the same room, especially now with Covid. Ideally you'd ask this type of thing on email or slack, but lots of people just don't bother unless you give them this explicit time for it.
However, many people, without explicit prompting, will in fact never ask these types of questions at all. That is the value of the daily stand-up: it ensures that everyone is prompted to as these things AT LEAST once every day, rather than holding onto them for who knows how long.
I'd also note that, without dailys, it's rather rare to have the entire team together in the same room, especially now with Covid. Ideally you'd ask this type of thing on email or slack, but lots of people just don't bother unless you give them this explicit time for it.
Is there another way to achieve this objective without a daily standup?
Possibly yes, though I don't know of one which isn't more draconic (e.g. end of day reports) or manipulative (e.g. forcing the team to have coffee/lunch together every day). My point was that dailys are a real solution to a real problem, not that they are utterly indispensable and irreplaceable.
I don't see how a stand up helps. If a person doesn't have the good sense to ask on Slack/room 'Hey, does anyone know how to render a Bezier Curve in OpenGL' (or whatever) and needs to wait 24 hours to do it in a group setting, then it is a problem of communication with that person/team. Now because some people have this problem, the rest of the team has to be interrupted, do a little song and dance ritual and waste their time (and probably lose focus on what they were doing).
I'm sorry, I just can't see it. If people don't bother to do what they are paid to do, then have a chat with them/fire them in the worst case and let the people that act professional and grown ups work in peace.
I'm sorry, I just can't see it. If people don't bother to do what they are paid to do, then have a chat with them/fire them in the worst case and let the people that act professional and grown ups work in peace.
Firing someone for not asking enough questions seems extreme.
The way I've seen this happen is that someone is assigned a task to render Bezier Curves in OpenGL, they work on it for a few days stumbling through, and 5 days later when they are done with the task that was assigned to them, they try to commit and find out that someone else had been given a task to remove all curves from the display and replace them with octogon segments or whatever.
With a daily scrum, they would say "I'm working on the Bezier Curves feature today" and someone else would be able to quickly tell them there's a problem with that.
In some teams, this kind of communication happens naturally all the time, but in others, people get focused on their own tasks and avoid it, either not paying attention to group chatter or simply not sending out wild questions. 15-30 minutes of lost focus for everyone everyday is really not that big a cost to pay to ensure this happens early. With any luck, a tight knit team would anyway spend that long on coffee together every day, so the daily just formalizes some informal process which already existed - no extra cost.
The way I've seen this happen is that someone is assigned a task to render Bezier Curves in OpenGL, they work on it for a few days stumbling through, and 5 days later when they are done with the task that was assigned to them, they try to commit and find out that someone else had been given a task to remove all curves from the display and replace them with octogon segments or whatever.
With a daily scrum, they would say "I'm working on the Bezier Curves feature today" and someone else would be able to quickly tell them there's a problem with that.
In some teams, this kind of communication happens naturally all the time, but in others, people get focused on their own tasks and avoid it, either not paying attention to group chatter or simply not sending out wild questions. 15-30 minutes of lost focus for everyone everyday is really not that big a cost to pay to ensure this happens early. With any luck, a tight knit team would anyway spend that long on coffee together every day, so the daily just formalizes some informal process which already existed - no extra cost.
I didn't mean to suggest firing them if they don't ask questions per se. But lets imagine there is no daily scrum for whatever reason, people are working on their own things, if they don't ask for help and get stuck for 5 days in something without saying a word, I would have a chat with the person asap. If this continued, then yes, probably fire them as they aren't working.
And with the octagon example, there should be some kind of ticket for Bezier Curves and Octogons, if they cancel each other out, who in the hell created those tickets/decided on them? And again, you don't need a daily stand up to have an idea of who is working on what. The ticket board/tracker should give you a good idea if someone is doing Bezier Curves and you pick Octogons.
> 15-30 minutes of lost focus for everyone everyday is really not that big a cost to pay to ensure this happens early.
The problem it isn't 15-30 minutes. It is much more, because unless you are managing with strict work hours, and can make sure the stand up isn't delayed or interrupts someone's work, you are losing a lot more of the developers time. Context and focus is lost if you were in the middle of a task. Time is lost getting back to the place where you were, etc.
It may help with 'bad teams', but if the punishment for good teams is to do that because of the others, then I am sorry, I'm out. Makes no sense.
If it works for you and your team, more power to you. But not for me. (And I would really advise folks to try and understand if the team actually feels stand ups (or any other thing really) are a positive for the people involved, or they are just to 'scared' to raise concerns to not be that guy, as I have seen this happen a lot, going with the flow, but the moment they can speak freely, raise all concerns)
And with the octagon example, there should be some kind of ticket for Bezier Curves and Octogons, if they cancel each other out, who in the hell created those tickets/decided on them? And again, you don't need a daily stand up to have an idea of who is working on what. The ticket board/tracker should give you a good idea if someone is doing Bezier Curves and you pick Octogons.
> 15-30 minutes of lost focus for everyone everyday is really not that big a cost to pay to ensure this happens early.
The problem it isn't 15-30 minutes. It is much more, because unless you are managing with strict work hours, and can make sure the stand up isn't delayed or interrupts someone's work, you are losing a lot more of the developers time. Context and focus is lost if you were in the middle of a task. Time is lost getting back to the place where you were, etc.
It may help with 'bad teams', but if the punishment for good teams is to do that because of the others, then I am sorry, I'm out. Makes no sense.
If it works for you and your team, more power to you. But not for me. (And I would really advise folks to try and understand if the team actually feels stand ups (or any other thing really) are a positive for the people involved, or they are just to 'scared' to raise concerns to not be that guy, as I have seen this happen a lot, going with the flow, but the moment they can speak freely, raise all concerns)
[deleted]
The entire idea of "standups" is one most people get wrong about scrum. There is no such concept as a standup in scrum, but rather, it's called the Daily Scrum: https://scrumguides.org/scrum-guide.html#daily-scrum
> The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is not a status meeting, nor a place to ask the "3 questions", it's a planning meeting, plain and simple. You don't have to walk the board and not everyone needs to take a turn saying what they're up to. It's a communication tool that provides an opportunity to inspect and adapt. The structure of it is totally up to the team.
> The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is not a status meeting, nor a place to ask the "3 questions", it's a planning meeting, plain and simple. You don't have to walk the board and not everyone needs to take a turn saying what they're up to. It's a communication tool that provides an opportunity to inspect and adapt. The structure of it is totally up to the team.
Seems overkill since plan is to execute the plan we discussed in the sprint. So, why do we need to remind everyone daily that we're just following the plan?
If I am blocked, I don't need the rest of the team. I will fire an email or document and tag people on Github that its blocked.
Also, why are emails not a thing anymore? Email is amazing. Apparently, its old fashioned now. Whatever is happening in tech companies, we need to stop and evaluate what the hell are we doing. It would be a great experiment (I think Gumroad is doing it? I don't remember) where there are no meetings, no slack, and only email, adhoc 1:1s.
I feel like we're not talking about the elephant in the room here and finding ways to justify stand ups or scrum or whatever.
If I am blocked, I don't need the rest of the team. I will fire an email or document and tag people on Github that its blocked.
Also, why are emails not a thing anymore? Email is amazing. Apparently, its old fashioned now. Whatever is happening in tech companies, we need to stop and evaluate what the hell are we doing. It would be a great experiment (I think Gumroad is doing it? I don't remember) where there are no meetings, no slack, and only email, adhoc 1:1s.
I feel like we're not talking about the elephant in the room here and finding ways to justify stand ups or scrum or whatever.
> Seems overkill since plan is to execute the plan we discussed in the sprint. So, why do we need to remind everyone daily that we're just following the plan?
It's the question whether we can adjust "things" to be able to reach the sprint goal. It's the goal that counts, not the way imho.
> Also, why are emails not a thing anymore?
Emails have their Pro's & Con's - I prefer them, but not everyone is able to be precise and on-point in written language. Also, you need to be able to express your feelings in written language. That's one of the reasons I use emojis even in emails. The ascii-ones, but still...
> I feel like we're not talking about the elephant in the room here and finding ways to justify stand ups or scrum or whatever.
Well, I can see the elephant. But people have different opinions on this topic - something you need to accept.
It's the question whether we can adjust "things" to be able to reach the sprint goal. It's the goal that counts, not the way imho.
> Also, why are emails not a thing anymore?
Emails have their Pro's & Con's - I prefer them, but not everyone is able to be precise and on-point in written language. Also, you need to be able to express your feelings in written language. That's one of the reasons I use emojis even in emails. The ascii-ones, but still...
> I feel like we're not talking about the elephant in the room here and finding ways to justify stand ups or scrum or whatever.
Well, I can see the elephant. But people have different opinions on this topic - something you need to accept.
> Emails have their Pro's & Con's - I prefer them, but not everyone is able to be precise and on-point in written language. Also, you need to be able to express your feelings in written language.
This is exactly the opposite of what professionals do. They should be able to write well. It is not optional, it is an expectation. Feelings should not be part of a technical discussion.
In a few years, we're gonna get emojis in an RFC. Just wait, you!
This is exactly the opposite of what professionals do. They should be able to write well. It is not optional, it is an expectation. Feelings should not be part of a technical discussion.
In a few years, we're gonna get emojis in an RFC. Just wait, you!
> Feelings should not be part of a technical discussion.
Looks like we need to agree to disagree here.
;)
Looks like we need to agree to disagree here.
;)
Which implies that at least one of you is dishonest or irrational or too lazy to continue the debate. ;)
See: Are Disagreements Honest? by Tyler Cowen & Robin Hanson, 2002
See: Are Disagreements Honest? by Tyler Cowen & Robin Hanson, 2002
Interesting paper. I guess the biggest problem here lies in the fact that there can only be so much truth seeking. So, with more time and effort, we could come to a conclusion that suits both. But... I don't have that time, to be honest. ;)
The “3 questions” are alluded to in the text you linked (emphasis mine):
>The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
> Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
While I agree with your point that the format is flexible, asking the questions is a good way to keep people on topic.
>The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
> Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
While I agree with your point that the format is flexible, asking the questions is a good way to keep people on topic.
For sure, I agree that if your team finds the 3 questions helpful then definitely do it. I was just trying to remind people that they're not mandated. People like to scream about how annoying "standups" are how going around the room asking everyone the 3 questions is a waste of time and for many teams that is probably true, in which case, change the format to something that is useful.
I admit I often don’t pay attention during standup. But I definitely do save non-urgent questions for standup vs. interrupting team members (and myself) from whatever they are working on.
I've been in a team that didn't let people talk in turns, but instead quickly went through all the unfinished tickets and asked if they were still going well. That worked better.
That's where the retrospectives are good again, having that time every 2 or 3 weeks to ask questions like "Are we getting any value from the stand-ups?" Then could try not having stand-ups for a sprint, or indefinitely, and see if they're missed or not. Or try not having the project manager present at them for a sprint.
If a team has a good culture around knowledge sharing etc then quite possibly its not required, while for other teams that short time all together is better than nothing.
If a team has a good culture around knowledge sharing etc then quite possibly its not required, while for other teams that short time all together is better than nothing.
In what percent of real-world scrum situations do you think the team has control over their own processes?
The biggest value is not asking for help, it's about synchronizing work.
Hey guys, in order to complete this library upgrade task today i need to do a major refactoring in common.js, so if you all could avoid tasks in this area until tomorrow so we all can avoid nasty merge conflicts it would be great, thanks.
Or hey, looks like this this test case from nightly is failing? Did anyone change something here recently? Who will take a look at it?
If your standups don't sound like this and only becomes a place to report status and excuses for being stuck (asking for help) to your PO or scrum master, then you have a lot to work on. Unfortunately the later version is very common and often hard to get out of.
Hey guys, in order to complete this library upgrade task today i need to do a major refactoring in common.js, so if you all could avoid tasks in this area until tomorrow so we all can avoid nasty merge conflicts it would be great, thanks.
Or hey, looks like this this test case from nightly is failing? Did anyone change something here recently? Who will take a look at it?
If your standups don't sound like this and only becomes a place to report status and excuses for being stuck (asking for help) to your PO or scrum master, then you have a lot to work on. Unfortunately the later version is very common and often hard to get out of.
This is the truth.
Let’s say you have a stand up that is developer only and has only 5 developers. Well within the 2 pizza box limit and really how much smaller can a team get.
A standup where developers are sharing what they are working on and people are actually paying attention means that as a developer I have to pay attention to 4 different technical discussions in the span of 15 mins.
The context switching and mental energy required to do that is tremendous especially when you may already be in the midst of working on your own complicated and mentally taxing project.
And this is the best case scenario. Throw in larger teams, throw in non devs, etc and it only gets exponentially more complicated from there.
The whole idea behind daily stand ups is broken.
What you want, at most, is a 1-2 per week regular status update, at the end of the day, when you’re already mentally tired so the time wouldn’t be better spent elsewhere, and good enough team relation building that you can approach each other directly when you need something.
Agile/scrum tries to replace team building with status updates. When in reality, what one needs is team members to get familiar enough with each other so they know that Jack really gets the post lunch slowdown, so after lunch is probably the best time to approach him because he may not be actively working on anything, while Jill likes to sort out all her emails and communications first thing in the morning and then focus on her work in long uninterrupted stretches, so that’s when I should reach out to her for questions/discussions.
And you need to build the ability in your teammates to be able to think about the bigger picture, and decide whether the question they need answered by Jill right now while she is in the middle of her deep work is really urgent and important enough that it warrants breaking her flow or not, or if it can wait till the next day or if it’s short and simple enough, till you guys get lunch together today.
The Big Lie is that team building can be replaced by process. And the Big Lie is pushed (with the best intentions) because team building cannot be packaged and sold as a 3 day workshop (well, it is, but that comes across as inauthentic and doesn’t usually work well, and team retreats have lost the majority of their flavor because honestly I don’t want to get to know the vast majority of my colleagues outside of our work lives). What it comes down to is good leadership to build a strong team culture, and that’s harder to find and develop.
So instead of making the effort and learning to accept that you will have failures where the wrong person is made team leader, or they were made team leader too early and building feedback mechanisms to identify such mistakes and hopefully correct them ASAP, we resort tom3 day workshops that teach agile and that you can replace culture with regular stand up meetings.
A standup where developers are sharing what they are working on and people are actually paying attention means that as a developer I have to pay attention to 4 different technical discussions in the span of 15 mins.
The context switching and mental energy required to do that is tremendous especially when you may already be in the midst of working on your own complicated and mentally taxing project.
And this is the best case scenario. Throw in larger teams, throw in non devs, etc and it only gets exponentially more complicated from there.
The whole idea behind daily stand ups is broken.
What you want, at most, is a 1-2 per week regular status update, at the end of the day, when you’re already mentally tired so the time wouldn’t be better spent elsewhere, and good enough team relation building that you can approach each other directly when you need something.
Agile/scrum tries to replace team building with status updates. When in reality, what one needs is team members to get familiar enough with each other so they know that Jack really gets the post lunch slowdown, so after lunch is probably the best time to approach him because he may not be actively working on anything, while Jill likes to sort out all her emails and communications first thing in the morning and then focus on her work in long uninterrupted stretches, so that’s when I should reach out to her for questions/discussions.
And you need to build the ability in your teammates to be able to think about the bigger picture, and decide whether the question they need answered by Jill right now while she is in the middle of her deep work is really urgent and important enough that it warrants breaking her flow or not, or if it can wait till the next day or if it’s short and simple enough, till you guys get lunch together today.
The Big Lie is that team building can be replaced by process. And the Big Lie is pushed (with the best intentions) because team building cannot be packaged and sold as a 3 day workshop (well, it is, but that comes across as inauthentic and doesn’t usually work well, and team retreats have lost the majority of their flavor because honestly I don’t want to get to know the vast majority of my colleagues outside of our work lives). What it comes down to is good leadership to build a strong team culture, and that’s harder to find and develop.
So instead of making the effort and learning to accept that you will have failures where the wrong person is made team leader, or they were made team leader too early and building feedback mechanisms to identify such mistakes and hopefully correct them ASAP, we resort tom3 day workshops that teach agile and that you can replace culture with regular stand up meetings.
> The Big Lie is that team building can be replaced by process.
This! They try to do it backwards: instead of building the team that will organically end up having standups over coffee in the morning, forcing the behaviour in the hopes that will build the team.
This! They try to do it backwards: instead of building the team that will organically end up having standups over coffee in the morning, forcing the behaviour in the hopes that will build the team.
> have to pay attention to 4 different technical discussions
Seems like a mistake to have actual technical discussions in a stand-up. So yesterday I've worked on X feature, I've gotten pretty far but I'm being blocked because of a dependency on Y feature. I'd like to continue today, developer Z (who is working on Y feature) can we discuss this after the stand-up? Of course, I could've communicated this before - and maybe I've already done that, but the rest of the team doesn't know. What if they want to pick up a new story that has a dependency as well. Should all this communication just happen in emails or slack messages? That's fine I guess but it doesn't hurt to have 15 minutes to get a good view of what the rest of the team is doing.
Once you get into the nitty gritty you should honestly just say hey let's take a subset of this group and discuss it after. Works for us. Non-dev people shouldn't be there, or at least shouldn't get turns unless they're actually working on issues in the sprint.
Seems like a mistake to have actual technical discussions in a stand-up. So yesterday I've worked on X feature, I've gotten pretty far but I'm being blocked because of a dependency on Y feature. I'd like to continue today, developer Z (who is working on Y feature) can we discuss this after the stand-up? Of course, I could've communicated this before - and maybe I've already done that, but the rest of the team doesn't know. What if they want to pick up a new story that has a dependency as well. Should all this communication just happen in emails or slack messages? That's fine I guess but it doesn't hurt to have 15 minutes to get a good view of what the rest of the team is doing.
Once you get into the nitty gritty you should honestly just say hey let's take a subset of this group and discuss it after. Works for us. Non-dev people shouldn't be there, or at least shouldn't get turns unless they're actually working on issues in the sprint.
I will second retros. I have seen team cohesion go up and down based on the quality of the retros. It is really hard to do a good retro, and ideally no one from management should be present for at least half of it. Making a space where people feel comfortable airing grievances and feel supported can really smooth out a lot of friction. Bonus points when common pain points are made known so tooling and process can be identified to make everyone’s job easier too.
> I will second retros. I have seen team cohesion go up and down based on the quality of the retros.
Could it be the other way? That the quality of the retros went up and down based on the team cohesion? If that's the case (and I believe it is most of the times, in my experience), the retros are just an artifact, not the real mechanism.
Could it be the other way? That the quality of the retros went up and down based on the team cohesion? If that's the case (and I believe it is most of the times, in my experience), the retros are just an artifact, not the real mechanism.
There’s a lot to this, bad moral lead to bad retros. But I’ve seen a team with very high cohesion shut down completely when a particularly toxic manager was present in a single retro. It was very illuminating to watch. When no one feels safe to talk in a retro that’s going to bleed into the rest of the interactions at the company. And while the reverse is true too, it can be set up to be slightly assymmetrical. If you can make a safe space for the group somewhere even if it’s only an hour twice a month it can really help alleviate toxicity elsewhere. It’s not a magic bullet, and honestly I don’t know how repeatable what I’ve experienced is. We had a really good facilitator on loan from another team at one point, and I’m not sure we could have kicked off some of our changes without this person.
> ceremonies
That has always sounded super pretentious to me. It's a damn meeting, not a wedding or a funeral.
That has always sounded super pretentious to me. It's a damn meeting, not a wedding or a funeral.
The biggest improvement we made to our dailies was to break up the traditional three question structure. Nobody really cares about your status from yesterday. Especially since we work together every day and are a self-organizing team that does not need to report to a manager on a daily basis.
Instead we talk about our plans for the day, ask a lot of questions and plan our collaboration and problem solving sessions. These dailies are usually shorter and I feel like I get much more value from them.
Instead we talk about our plans for the day, ask a lot of questions and plan our collaboration and problem solving sessions. These dailies are usually shorter and I feel like I get much more value from them.
The ‘correct form’ for the stand up is tricky, and probably varies on team size. For a small team (e.g. 4 devs) you probably care a lot about what the others are doing as you’ll likely be interacting with it closely (reviewing it, building on it), sometimes larger teams (e.g. 7 devs) then it might never come your way.
I’ve found that people who stick to the classic “what I did yesterday, what I’m doing today, what blockers are there” set tend to provide really short ‘bland’ updates e.g. “I was working on task foo, I’ll be doing more on foo today and possibly starting work on bar, I don’t have any blockers”. If you’re not paying attention you can miss the fact that the same update has been reported for 3 days in a row and actually there is some unexpected complexity and/or a simpler solution has been missed.
For me, the best stand ups give a little more information and can be a trigger for a follow up chat after the standup. “Yesterday I was working on task foo, today I’ll be doing a bit more because I found doing XXX is a little trickier than expected - but I’m still hoping to get onto bar, no blockers - unless my idea for XXX doesn’t work”
I’ve also found this sort of issue made worse on projects where the Project Management have decided that we shall be “Agile” and do scrum. You then end up with a non-technical PM acting as the scrum master and mandated “best practice”. This always stifles any technical discussion as it is ‘noise’ to them, despite being ‘signal’ for technical folk....
I’ve found that people who stick to the classic “what I did yesterday, what I’m doing today, what blockers are there” set tend to provide really short ‘bland’ updates e.g. “I was working on task foo, I’ll be doing more on foo today and possibly starting work on bar, I don’t have any blockers”. If you’re not paying attention you can miss the fact that the same update has been reported for 3 days in a row and actually there is some unexpected complexity and/or a simpler solution has been missed.
For me, the best stand ups give a little more information and can be a trigger for a follow up chat after the standup. “Yesterday I was working on task foo, today I’ll be doing a bit more because I found doing XXX is a little trickier than expected - but I’m still hoping to get onto bar, no blockers - unless my idea for XXX doesn’t work”
I’ve also found this sort of issue made worse on projects where the Project Management have decided that we shall be “Agile” and do scrum. You then end up with a non-technical PM acting as the scrum master and mandated “best practice”. This always stifles any technical discussion as it is ‘noise’ to them, despite being ‘signal’ for technical folk....
IME the first thing to go out of the window in any company of any reasonable size are retrospectives. Especially when they start to suggest change.
At best you get the chance of feedback with nothing implemented out of it.
At best you get the chance of feedback with nothing implemented out of it.
Then you've got lucky, last retro I went.... Managers were present, tech lead sucking leaking asses with their wide ears opened, and best devs leaving to better horizons.
>Stand-ups tend to be too much of a status report to the manager
Why is your manager present at the stand-up? It's just for the developers.
Why is your manager present at the stand-up? It's just for the developers.
> I've found the retrospectives to be the most valuable part of the scrum ceremonies
Sprints are just the periods of time between retros.
Sprints are just the periods of time between retros.
I've found the opposite. Retrospectives consist of a bunch of bland statements with any actionable items getting discarded immediately after.
It doesn't help that few people take it seriously. And there's always one or two people that talk out the entire meeting, ruining any chance of it working for the rest.
It doesn't help that few people take it seriously. And there's always one or two people that talk out the entire meeting, ruining any chance of it working for the rest.
No offense but it seems like you're part of the problem then. I've also had retrospectives where bland statements were the norm but as a team you should be able to say to each other, alright nice that the teamwork was great but is there anything new?
> any actionable items getting discarded immediately after
Except that, that's bad and honestly I've never experienced it that way. Maybe because I'm vocal and harp on about things if they don't change but yeah. An actionable item either becomes an email (which we will follow up on during the sprint, if nothing happens it comes back next retro) or an issue in a sprint / kanban board.
> And there's always one or two people that talk out the entire meeting
You've got to claim a stage here. Or if it doesn't pertain to you specifically, help teammates who do get snowed under by explicitly asking them.
I'd really not want to work in the environment you're describing, but I think I'd give it a shot to change it before leaving.
> any actionable items getting discarded immediately after
Except that, that's bad and honestly I've never experienced it that way. Maybe because I'm vocal and harp on about things if they don't change but yeah. An actionable item either becomes an email (which we will follow up on during the sprint, if nothing happens it comes back next retro) or an issue in a sprint / kanban board.
> And there's always one or two people that talk out the entire meeting
You've got to claim a stage here. Or if it doesn't pertain to you specifically, help teammates who do get snowed under by explicitly asking them.
I'd really not want to work in the environment you're describing, but I think I'd give it a shot to change it before leaving.
Scrum is basically warmed-up Taylorism[1] for the 21st century, couched in buzzwords like "sprints" and "retros". It's an attempt to make software development an industrial process, stripping developers of autonomy and creativity in return for predictability. Certain managers like it because it generates metrics, even though the metrics are meaningless drivel("we completed 20 story points this sprint!"), because they like to be "data-driven".
[1] https://en.wikipedia.org/wiki/Scientific_management
[1] https://en.wikipedia.org/wiki/Scientific_management
The irony is that one could still have predictability and metrics without Scrum, and they would likely say as much if not more. Instead of expecting your devs to manually participate in rituals, you can use their actual output over a large time frame and extrapolate those.
Admittedly, that is my biggest problem with Scrum. Humans are by default the most volatile factor. While we could minimize its contribution, Scrum instead inflates the importance of the human factor. Example: estimating.
Grooming the back log for priority with just the people who are critical in deciding that priority, is common sense. Almost every methodology recommends this. Yet estimating is a tough sell: at the start, it is largely deemed useless due to inexperience. Yet as experience in estimating furthers, so too do metrics become available which make estimating unnecessary. Worse is when estimating and even re-estimating practices can easily eat entire days worth of productivity (a few hours per person + a high likelihood of hours around that meeting to be less efficient than could-be, loss or lack of flow). This is before we add that estimating has very little empirical evidence behind it (#NoEstimates) and psychological effects make things even more volatile (anchoring effect, Parkinson's Law, etc.)
I can't speak for others, but I went into this field because I want to minimize the human factor in anything mundane or boring, allowing people to maximize their participation in anything fun and exciting. For me, Scrum does the exact opposite.
Admittedly, that is my biggest problem with Scrum. Humans are by default the most volatile factor. While we could minimize its contribution, Scrum instead inflates the importance of the human factor. Example: estimating.
Grooming the back log for priority with just the people who are critical in deciding that priority, is common sense. Almost every methodology recommends this. Yet estimating is a tough sell: at the start, it is largely deemed useless due to inexperience. Yet as experience in estimating furthers, so too do metrics become available which make estimating unnecessary. Worse is when estimating and even re-estimating practices can easily eat entire days worth of productivity (a few hours per person + a high likelihood of hours around that meeting to be less efficient than could-be, loss or lack of flow). This is before we add that estimating has very little empirical evidence behind it (#NoEstimates) and psychological effects make things even more volatile (anchoring effect, Parkinson's Law, etc.)
I can't speak for others, but I went into this field because I want to minimize the human factor in anything mundane or boring, allowing people to maximize their participation in anything fun and exciting. For me, Scrum does the exact opposite.
> The irony is that one could still have predictability and metrics without Scrum
I like to think that it would take a technically competent manager to understand the progress and performance of the developers. OTOH, with Scrum, you can generate numbers, however meaningless, without such prerequisites.
That's probably why some managers like it.
I like to think that it would take a technically competent manager to understand the progress and performance of the developers. OTOH, with Scrum, you can generate numbers, however meaningless, without such prerequisites.
That's probably why some managers like it.
Honestly, while my cynical self would love this to be true, generating basic metrics (numbers of bugs solved, number of features added, average time a developer spends in meetings, etc.) doesn't require a lot of technical competence and already say far more than a vague metric like "velocity" (which, most of the time, is really just speed). Especially if the tool allows one to do this with a few clicks.
More likely is that, if teams were truly "self-managing", the number of management, management-lite and pseudo-management roles should be lowering drastically every year (or at least converting to hybrid roles). Yet I barely if ever see a Scrum adoption result in the majority of managers losing their jobs or changing the type of role they are performing. I also doubt data scientists would appreciate these middle-school tier statistics be called data science.
More likely is that, if teams were truly "self-managing", the number of management, management-lite and pseudo-management roles should be lowering drastically every year (or at least converting to hybrid roles). Yet I barely if ever see a Scrum adoption result in the majority of managers losing their jobs or changing the type of role they are performing. I also doubt data scientists would appreciate these middle-school tier statistics be called data science.
> stripping developers of autonomy and creativity
Why would you say that? There's nothing in the theory of scrum that makes a claim on the autonomy and creativity of developers. On the contrary, if you look in the scrum guide, you will find words like self-management, and independent, and cross-functional.
> Certain managers like it because it generates metrics, even though the metrics are meaningless drivel("we completed 20 story points this sprint!")
Story points do not figure anywhere in the theory of scrum. It is quite a different invention.
Why would you say that? There's nothing in the theory of scrum that makes a claim on the autonomy and creativity of developers. On the contrary, if you look in the scrum guide, you will find words like self-management, and independent, and cross-functional.
> Certain managers like it because it generates metrics, even though the metrics are meaningless drivel("we completed 20 story points this sprint!")
Story points do not figure anywhere in the theory of scrum. It is quite a different invention.
The theory (I'd prefer the word "hype") and practice of Scrum are two entirely different things. And of course, if and when it all goes wrong, you're just not doing Scrum right.
> The theory (I'd prefer the word "hype") and practice of Scrum are two entirely different things. And of course, if and when it all goes wrong, you're just not doing Scrum right.
I'm really struggling with this argument.
So if someone reads a text, picks from it things that he likes, throws away things he doesn't like, tries to apply the result in practice, but without success — how come he gets to blame the original concept rather than his own invention? Why call the method derived via picking, choosing and mixing with bits from other texts by the same name as the original text? What makes people think that they are "doing scrum" when they are not?
I'm really struggling with this argument.
So if someone reads a text, picks from it things that he likes, throws away things he doesn't like, tries to apply the result in practice, but without success — how come he gets to blame the original concept rather than his own invention? Why call the method derived via picking, choosing and mixing with bits from other texts by the same name as the original text? What makes people think that they are "doing scrum" when they are not?
>Scrum was created by one of the creators of the agile manifesto as a way to see consulting/training around the 'Agile' idea (timeframes may differ a bit, but they were linked).
Scrum was actually created by two Japanese dudes [0], and was for the manufacturing industry.
[0] https://en.wikipedia.org/wiki/Scrum_(software_development)#H...
Scrum was actually created by two Japanese dudes [0], and was for the manufacturing industry.
[0] https://en.wikipedia.org/wiki/Scrum_(software_development)#H...
Japanese also came up with Kaizen, which Scrum should be about but isn’t, along with Kanban, the process- not the generic term for workflow that some use it as.
While we’re on the topic of Agile, though, it’s best not to forget its eXtreme Programming roots.
While we’re on the topic of Agile, though, it’s best not to forget its eXtreme Programming roots.
XP for me is the core of agile software engineering I can relate to, principle driven rather than process focused a'la Scrum.
For me scrum optimises for a very narrow perspective of software development which did not align well with long term and sustainable software engineering and ownership. If i was far less than generous I'd say scrum is design for children rather than responsible adults.
For success as a leader i should be focusing on building and fostering a team than does not need the self imposed constraints of scrum but are rather conscientious and vested enough to build and deliver what the company needs and the team can maintain.
For me scrum optimises for a very narrow perspective of software development which did not align well with long term and sustainable software engineering and ownership. If i was far less than generous I'd say scrum is design for children rather than responsible adults.
For success as a leader i should be focusing on building and fostering a team than does not need the self imposed constraints of scrum but are rather conscientious and vested enough to build and deliver what the company needs and the team can maintain.
Scrum, for me, is not for development but for Operations, I don't even like the term scrum but simply WhiteBoard Meeting. Flatten structure, everyone knows what everyone else is doing, chance to mention things on one's mind, perhaps a hiccup from the day or shift before, not hosted by a ScrumMaster just rotate around the team, everyone has a voice, strict visible time limit.
It's super in Operations.. not super in Development.
Sprints make no sense at all. If you can do it you can do it. Stay at it and go on a spectrum of pumping consistent results to once in a blue moon creating something special. Sprint adds nothing to that other than a phrase to use in a conference call to hide ineffective working practices. I have Sprinted on a 35 hour working week, I have also worked normally on a 35 hour working week. Results are similar aside from stress others show where Sprint = Haste, and Haste != Speed or Quality.
It's super in Operations.. not super in Development.
Sprints make no sense at all. If you can do it you can do it. Stay at it and go on a spectrum of pumping consistent results to once in a blue moon creating something special. Sprint adds nothing to that other than a phrase to use in a conference call to hide ineffective working practices. I have Sprinted on a 35 hour working week, I have also worked normally on a 35 hour working week. Results are similar aside from stress others show where Sprint = Haste, and Haste != Speed or Quality.
Here here. Loved XP, still try to let it influence what I advocate for at my place of employ. XP leans heavy on discipline. It succeeds well when there's an environment of trust towards the team, and the team values discipline as a way of working better together.
Yep. We wanted XP. We got Scrum instead.
XP is awesome. YAGNI forever.
Scrum is pretty lightweight. A lot of people add to the core of Scrum and refer to the whole thing as Scrum when that is not accurate. A few uber coders in a garage cranking out their dream idea may not need Scrum. In my experience, it’s most needed in the corporate world where there are tons of development teams being hounded by managers and product owners to constantly cram more and more work into a fixed amount of time left before some arbitrary deadline, and getting management buy-in on Scrum or something similar can actually be a much-needed protection for dev team sanity.
This sums up my thinking. Scrum is a contract between developers and managers, especially non-technical managers.
Developers have always complained about being micromanaged or being given business objectives that don't make sense or about changing requirements or some such. But non-technical managers at the same time typically complain that their developers are prima donnas and that their team produces unpredictable and non-repeatable results.
If you understand KPI's, you understand scrum. Scrum exposes the development process to managers and in theory is supposed to give them a better idea of what the team is doing, what they're having problems with, and what the consequences of their management directives are. If that leads to better management of the team, scrum is a success.
Developers have always complained about being micromanaged or being given business objectives that don't make sense or about changing requirements or some such. But non-technical managers at the same time typically complain that their developers are prima donnas and that their team produces unpredictable and non-repeatable results.
If you understand KPI's, you understand scrum. Scrum exposes the development process to managers and in theory is supposed to give them a better idea of what the team is doing, what they're having problems with, and what the consequences of their management directives are. If that leads to better management of the team, scrum is a success.
Yes, and Scrum done well can promote a sense of well-being through fulfillment of points and provides rhythmic but varying work for those that like process.
Done poorly it may create a wealth of problems. The cadence may create undue sense of urgency that may lead to unhealthy levels of stress or to depression and desensitization of missing work targets. Nonsense competition may arise due to points and velocities.
Done poorly it may create a wealth of problems. The cadence may create undue sense of urgency that may lead to unhealthy levels of stress or to depression and desensitization of missing work targets. Nonsense competition may arise due to points and velocities.
But Scrum reinforces all of that; arbitrary deadlines, sprints check; lack of control, product owner the only named role check; process centric, corporate compatibility check.
The achilles heel of Scrum is that it sold out the prescriptive XP practices that enforce sustainable software engineering discipline as well as communication with business concerns in order to sugar coat the fast feedback cycles. Scrum/Kanban feedback is about "doing the right thing". XP feedback is about "doing the thing right". Codebases on projects using Scrum/Kanban without XP technical practices tend to molder and succumb to what I like to call "Scrumrot" within about 18 months. Seen it happen many times.
I worked at a company where the CEO was into Kaizen and brought it up frequently at team meetings. It was otherwise as dysfunctional as any place I've ever worked. It was also my first, and hopefully last, exposure to "full court" Scrum. Both of these are now flags to me that a company is more into process than results, which is sad, because they both came from good places.
That article doesn't even create anything. It's a comparative summary of existing practices in the manufacturing sector. The word "scrum" appears, exactly once, as part of an incoherent rugby metaphor.
Elevating a waffling HBR feature to the status of antecedent decalogue is totally on brand for the clerical formalists that promote Scrum.
In high performance teams, Agile begins where Scrum ends, and as the remarks here extensively demonstrate, awful working environments won't be improved by a bunch of ceremonies.
Elevating a waffling HBR feature to the status of antecedent decalogue is totally on brand for the clerical formalists that promote Scrum.
In high performance teams, Agile begins where Scrum ends, and as the remarks here extensively demonstrate, awful working environments won't be improved by a bunch of ceremonies.
Thank you for the info. I will leave the comment as is for reference.
Again, thank you!
Again, thank you!
Are you totally anti process? If not, which process do you find more palatable than scrum? Your comment is eye opening for me because I don’t know that I’d find a job if I decided scrum was a dealbreaker. What kind of projects or companies do you target that don’t have some flavor of scrum?
I’ve always felt scrum adds value for new teams who haven’t worked together or on greenfield projects in a space the team hasn’t worked before. That’s when the standups identity impediments. That’s when retrospectives uncover process or people issues. Once the team hits a stride it’s time for the training wheels to come off and then it’s just a Kanban board.
I’ve always felt scrum adds value for new teams who haven’t worked together or on greenfield projects in a space the team hasn’t worked before. That’s when the standups identity impediments. That’s when retrospectives uncover process or people issues. Once the team hits a stride it’s time for the training wheels to come off and then it’s just a Kanban board.
If you’re looking for a book — shape up — from basecamp goes through how they develop software and it looks great ! I am giving it a try. It’s very agile but not scrum.
I also agree that after a team gels together there’s no need for a lot of the overhead that comes with scrum.
My experience in organizations have always been to continuously shape the process depending on how the team feels about it and not call it scrum
I also agree that after a team gels together there’s no need for a lot of the overhead that comes with scrum.
My experience in organizations have always been to continuously shape the process depending on how the team feels about it and not call it scrum
We've been using this since late 2019, and generally been loving it. The concept of things being bets, plus fixed-time variable-scope are amazing, imho.
I've interviewed with a couple teams that are using Shape Up and I got the general sense that the developers were happy with the process.
Here is the readable on the web version: https://basecamp.com/shapeup/webbook
Obligatory PDF: https://basecamp.com/shapeup/shape-up.pdf
Shape Up Your Agile (article): https://thinkfractional.blog/shape-up-your-agile/
Here is the readable on the web version: https://basecamp.com/shapeup/webbook
Obligatory PDF: https://basecamp.com/shapeup/shape-up.pdf
Shape Up Your Agile (article): https://thinkfractional.blog/shape-up-your-agile/
> Are you totally anti process?
Not speaking for OP but agile, straight from the manifesto, itself is anti-process, at least in the sense where...
> If not, which process do you find more palatable
Is a cogent question.
Which process do /you/ find productive and helpful? What would you change? What would you emphasize? Process is a tool to serve you and your peers and your stakeholders. Not to pay fealty. Not to choose sides. It can be picked into pieces and rearranged. It can be recalled or reorganized whenever it’s unsuitable.
Not speaking for OP but agile, straight from the manifesto, itself is anti-process, at least in the sense where...
> If not, which process do you find more palatable
Is a cogent question.
Which process do /you/ find productive and helpful? What would you change? What would you emphasize? Process is a tool to serve you and your peers and your stakeholders. Not to pay fealty. Not to choose sides. It can be picked into pieces and rearranged. It can be recalled or reorganized whenever it’s unsuitable.
The good agile teams I've been on had a LOT of process and were very disciplined.
But it was a process we decided on as a team, not something a consultant had read in a book.
But it was a process we decided on as a team, not something a consultant had read in a book.
Precisely. The best tool is the one people are bought into.
Exactly. Sorry for the ambiguity in my wording. I meant that the manifesto (like teams that do well adopting/reflecting it) is against proscribed process.
> the manifesto, itself is anti-process
I don't think that's true, it's "people over processes", it doesn't imply a "no processes" stance, just that you shouldn't _force_ a process and you should adapt.
IMO that's what the agile manifesto is about: adapting.
I don't think that's true, it's "people over processes", it doesn't imply a "no processes" stance, just that you shouldn't _force_ a process and you should adapt.
IMO that's what the agile manifesto is about: adapting.
But that's the opposite of my experience with agile and Scrum in the companies, where it is used as an excuse for non tech managers to enforce what they feel works better for them. In terms of control or, in some cases, micromanagement.
I've never had an issue communicating with a team without scrum, even when very new. On the other hand, communication gets worse with scrum, in my experience. Because everyone knows that the meetings are the time to communicate problems, they often delay all communication until the next day. And in some cases the morning meetings drag out to noon because that's when all the communication is going on, when it really just involves 2-3 people.
Individuals and interactions over processes and tools.
If the team likes scrum thats fine but picking scrum vs kanban, or bitbucket vs gitlab vs cvs, those are details a team cam and should be in charge of and revisit whenever they feel like. Because all that matters is working code, and what gets you there is skilled people that communicate well.
If the team likes scrum thats fine but picking scrum vs kanban, or bitbucket vs gitlab vs cvs, those are details a team cam and should be in charge of and revisit whenever they feel like. Because all that matters is working code, and what gets you there is skilled people that communicate well.
Working code is not all that matters, typically a business needs some predictability in output in order to plan ahead. If the business can’t function well because delivery is unreliable, sooner or later there won’t be any money rolling in to fund developers writing that code. Not every company will have enough ”skilled people that communicate well” for this to be an automatic byproduct of developers doing their thing, especially in larger or immature organizations.
> typically a business needs some predictability in output in order to plan ahead. If the business can’t function well because delivery is unreliable
the problem is that this assumes that estimates can be accurate, which in some projects may be the case, but in general there are always unexpected problems, things you didn't know you didn't know, etc.
If it happens that a company goes under because they lost all income because there was no deliverability, the problem was the company had the wrong team of engineers. Either too much "isolated geniuses" or too much inexperienced. Sometimes also happens that the management decides the way of doing work without technical involvement. Even companies I've been that decided to rewrite a mature and solid big piece of software, because they "needed to use more strategic technologies". Meaning, the technologies that were the "cool thing to use if you are a cool startup". And they use Agile (so they claim).
the problem is that this assumes that estimates can be accurate, which in some projects may be the case, but in general there are always unexpected problems, things you didn't know you didn't know, etc.
If it happens that a company goes under because they lost all income because there was no deliverability, the problem was the company had the wrong team of engineers. Either too much "isolated geniuses" or too much inexperienced. Sometimes also happens that the management decides the way of doing work without technical involvement. Even companies I've been that decided to rewrite a mature and solid big piece of software, because they "needed to use more strategic technologies". Meaning, the technologies that were the "cool thing to use if you are a cool startup". And they use Agile (so they claim).
It doesn’t assume that estimates are accurate in that they need to approach perfection, but it does assume that good processes and tools can help make them reliable enough to be useful for the business over time (who of course still have to take the remaining uncertainty into account).
There is a reason the agile manifesto starts with the line I quoted. The number one mistake made is thinking that some tool or process will let them crank out code steadily though inefficiently with developers of unknown ability. But if you dont have those individuals interacting well there is no tool or process that can save you.
> The number one mistake made is thinking that some tool or process will let them crank out code steadily though inefficiently with developers of unknown ability.
Here’s where I disagree and would say that a well-functioning process certainly can help with that, albeit not perfectly, of course. And that is by aiding the invididuals involved in interacting well.
Here’s where I disagree and would say that a well-functioning process certainly can help with that, albeit not perfectly, of course. And that is by aiding the invididuals involved in interacting well.
When the manifesto came out I thought it was a great idea, as I recall. But now I can't recall what was in it. Something about "people, not popcorn." Or was that The Cathedral and the Bazaar?
You can say we should separate agile from scrum, but scrum basically is agile today (and Kanban!), modulo the odd free thinking, practically self-managed shop. Agile comes in via consultant after a shop declares itself on a "burning platform."
What it's become, IMO, is work about work. I hated it.
The only contact I have with it now is when my manager has to hang up the phone because she has to go to the standup of other managers. (I drive a truck.)
You can say we should separate agile from scrum, but scrum basically is agile today (and Kanban!), modulo the odd free thinking, practically self-managed shop. Agile comes in via consultant after a shop declares itself on a "burning platform."
What it's become, IMO, is work about work. I hated it.
The only contact I have with it now is when my manager has to hang up the phone because she has to go to the standup of other managers. (I drive a truck.)
The infamous scrum of scrums. Always makes me laugh. I think all status meetings should be abolished, without exception. Meetings should be for making a decision with all the players present.
Scrums and such meetings are for the benefit of the organizer (boss, ...). Only exception is if someone is blocked but he is bad at expressing it directly to the person responsible.
I've been part of many meetings/scrums where the point was that the manager gets the info of how things are progressing but the meeting itself was net negative for the developers as they lost their flow and some of their time.
I've been part of many meetings/scrums where the point was that the manager gets the info of how things are progressing but the meeting itself was net negative for the developers as they lost their flow and some of their time.
Or requirements writing sprints. How agile, how aware of the limitations of big up front design.
> but for me personally, I hate it with a fervour
Is it possible to fall in love with someone so quickly over one line written on the web?
Is it possible to fall in love with someone so quickly over one line written on the web?
I am taken but thank you for the laugh :)
Agile indeed.
> Agile is at is core just some suggestions for teams to work well together
I don't think that's right. Agile is a way to manage projects as an alternative to waterfall. The 'communication' stuff on top of that might work well with it, but that's all to do with how you run your agile process. Agile itself is just about the order you do stuff.
Imagine that for your project, there 3 'features' that are needed. Each feature needs, designing, implementing and validating (testing it works). You end up with this grid of all the work that needs doing:
In Agile, you progress through the grid left to right. First you work on feature 1, doing design, implementation and validation, and only then do you move on to feature 2, then feature 3.
The reasons for doing this are many and varied. The obvious ones being that in waterfall you don't have anything useful until everything is done, whereas in Agile at least you have F1 fully done a third of the way through. This also means that you can decide that F3 is more important than F2, and then later that F4 which you'd never heard of is needed when F2 isn't (and you can decide this as you go along).
This bare concept of agile is almost always what you want to do, particularly for software projects. The concepts of backlogs, sprints etc. are all the process that has built up to make this work in real life. Approaches such as Scrum have then built on top of that giving a whole lot of extra practices about how teams should work. A lot of that is variable in usefulness and how well it is used. You don't want to get away from the underlying value of the agile process though.
I don't think that's right. Agile is a way to manage projects as an alternative to waterfall. The 'communication' stuff on top of that might work well with it, but that's all to do with how you run your agile process. Agile itself is just about the order you do stuff.
Imagine that for your project, there 3 'features' that are needed. Each feature needs, designing, implementing and validating (testing it works). You end up with this grid of all the work that needs doing:
F1 F2 F3
Desi
Impl
Vali
In Agile, you progress through the grid left to right. First you work on feature 1, doing design, implementation and validation, and only then do you move on to feature 2, then feature 3.
The reasons for doing this are many and varied. The obvious ones being that in waterfall you don't have anything useful until everything is done, whereas in Agile at least you have F1 fully done a third of the way through. This also means that you can decide that F3 is more important than F2, and then later that F4 which you'd never heard of is needed when F2 isn't (and you can decide this as you go along).
This bare concept of agile is almost always what you want to do, particularly for software projects. The concepts of backlogs, sprints etc. are all the process that has built up to make this work in real life. Approaches such as Scrum have then built on top of that giving a whole lot of extra practices about how teams should work. A lot of that is variable in usefulness and how well it is used. You don't want to get away from the underlying value of the agile process though.
[deleted]
> Scrum was created by one of the creators of the agile manifesto
I can't wrap my head around this. The first item of the agile manifesto literally says:
Individuals and interactions over processes and tools
I can't wrap my head around this. The first item of the agile manifesto literally says:
Individuals and interactions over processes and tools
From the link
> When [the three of us, along with many others] created the Agile Manifesto in 2001, Kent Beck reiterated his vision to heal the divide between business and development. Kent created the website, and we were stunned when thousands upon thousands people signed this website. So we decided to form an organization – the Agile Alliance. I was the first chairman of this organization. The next chairman was Ken Schwaber. He decided he wanted to do something else. He wanted to make the alliance a revenue making machine…
> Ken came to me some time later, telling me he was going to make a class called Certified Scrum Master Class. I thought it was a dumb idea. But a dumb idea that works is not a dumb idea. People came and liked it. The more he charged, the more people came. He started giving out certificates, and he made a little organization off to the side – the Scrum Alliance. Lovely thing to happen.
> When [the three of us, along with many others] created the Agile Manifesto in 2001, Kent Beck reiterated his vision to heal the divide between business and development. Kent created the website, and we were stunned when thousands upon thousands people signed this website. So we decided to form an organization – the Agile Alliance. I was the first chairman of this organization. The next chairman was Ken Schwaber. He decided he wanted to do something else. He wanted to make the alliance a revenue making machine…
> Ken came to me some time later, telling me he was going to make a class called Certified Scrum Master Class. I thought it was a dumb idea. But a dumb idea that works is not a dumb idea. People came and liked it. The more he charged, the more people came. He started giving out certificates, and he made a little organization off to the side – the Scrum Alliance. Lovely thing to happen.
Spot on. Bringing the stakeholder to the squad (just for a daily meeting, for example) is a great Agile insight which doesn't need Scrum at all. I highly recommend it.
I don't have much interview experience so I am wondering how you do this: "It is literally one of the first questions I ask in an interview about their processes and excuse myself from the process if I see if they follow it"
Do you abruptly cut the interview short or do you just make a mental note and continue?
Do you abruptly cut the interview short or do you just make a mental note and continue?
I don't get up and leave. Usually in most interviews at the end companies ask if you have any questions. I usually try to understand their processes and ways of working.
Usually after this, I take some time just to 'calm down' and think about it, and I usually shoot them an email saying that I appreciate the time and opportunity, but I don't think it will be a good match and wish them luck finding a better suited candidate. I had a few replies thanking me, most just don't reply and I had one (only one) insulting me and my experience and saying they only interviewed me out of pity as my experience wasn't good enough (I had more years (8) of experience in the tech stack they used than the number of years the company existed!:)) Was from a Who's Hiring thread here actually :)
Usually after this, I take some time just to 'calm down' and think about it, and I usually shoot them an email saying that I appreciate the time and opportunity, but I don't think it will be a good match and wish them luck finding a better suited candidate. I had a few replies thanking me, most just don't reply and I had one (only one) insulting me and my experience and saying they only interviewed me out of pity as my experience wasn't good enough (I had more years (8) of experience in the tech stack they used than the number of years the company existed!:)) Was from a Who's Hiring thread here actually :)
> Usually after this, I take some time just to 'calm down' and think about it, and I usually shoot them an email saying that I appreciate the time and opportunity, but I don't think it will be a good match and wish them luck finding a better suited candidate.
I LOVE sending letters like this. It's the politest middle finger you can give to a douchey hiring manager or organization.
I LOVE sending letters like this. It's the politest middle finger you can give to a douchey hiring manager or organization.
I think the value of calming down is normally to not send impolite or passive aggressive communications.
I don't have so much experience interacting with recruiters/hiring managers. However, every time I've let some frustration show at work, in the moment I felt vindicated and righteous, only to feel like an ass about 24 hours later. Normally when I feel the need to vocalize a frustration, I try to write down or remember why I'm frustrated, but wait to actually action the communication until I'm calm. Goes a long way to focus on solving problems, without identifying people as the problem.
I don't have so much experience interacting with recruiters/hiring managers. However, every time I've let some frustration show at work, in the moment I felt vindicated and righteous, only to feel like an ass about 24 hours later. Normally when I feel the need to vocalize a frustration, I try to write down or remember why I'm frustrated, but wait to actually action the communication until I'm calm. Goes a long way to focus on solving problems, without identifying people as the problem.
I'm not the person you're responding to, but just make a mental note and continue. Personally I'd even continue the interview process, I'm a Scrum hater, but an interesting project, a smart team, a big paycheck? You might have to put up with scrum, it's widespread.
Typically you would just make a mental note and continue. Walking out mid interview is considered kind of rude and it's worthwhile in the long run to not be rude if you can avoid it.
In terms of stand ups and such, it really depends on how well they are done.
Typically, they just become another box to check. “This task is underway, blah, blah..” and everyone tunes out.
I’ve seen them done well and usually because they are focused on prioritization - “is this still important? No? Stop doing it”.
Typically, they just become another box to check. “This task is underway, blah, blah..” and everyone tunes out.
I’ve seen them done well and usually because they are focused on prioritization - “is this still important? No? Stop doing it”.
I personally wouldn't work at a place that didn't do it. Scrum ceremonies are there to get alignment. If you don't do them, you end up working on the wrong things. If these meetings take up more than 1-2 hours a week, then you're doing it wrong.
If it works for you great. But this 'you are doing it wrong' is at the core of scrum. When scrum doesn't work, is because you are doing it wrong, and never a problem with scrum itself. No true Scotsman and all that.
I have been a professional developer for close to 20 years, 10 more if you count my hobby/learning path as well. All teams I worked that implemented scrum were a hindrance to me and not a benefit. It may work for others and that is fine, but it isn't a silver bullet solution for 100% of the cases.
I have been a professional developer for close to 20 years, 10 more if you count my hobby/learning path as well. All teams I worked that implemented scrum were a hindrance to me and not a benefit. It may work for others and that is fine, but it isn't a silver bullet solution for 100% of the cases.
I feel like various Agile frameworks might be saying “You are doing it wrong” to people using Waterfall for software development. In that case, I would agree. 16 years ago I talked to a project manager who had done PM for a nuclear plant and Waterfall is ok for that, but not usually for software where you learn more from users about what should be done and tweaked as you go along. Perhaps you are just seeing Scrum in places where they are doing Scrum wrong, e.g. adding to it and making it heavy-handed and overbearing.
If you’re on a team of more than a couple people and you have stakeholders feeding requirements to the project, what do you do that’s so different from the simple process of Scrum? It’s just set up to say, hey, we’re going to work on these items for the next week or two, and please don’t constantly come interrupt me in the middle to ask me to fit in a bunch more things than what we agreed to work on in this short time period. Then we’ll show you how it’s working and you can decide what we do next.
If you’re on a team of more than a couple people and you have stakeholders feeding requirements to the project, what do you do that’s so different from the simple process of Scrum? It’s just set up to say, hey, we’re going to work on these items for the next week or two, and please don’t constantly come interrupt me in the middle to ask me to fit in a bunch more things than what we agreed to work on in this short time period. Then we’ll show you how it’s working and you can decide what we do next.
> people using Waterfall for software development.
Is anyone really doing Waterfall now? Maybe earlier some industries used a Waterfall like process. But actual descriptions of Waterfall seem to go back 50 years to Royce's paper, Managing the Development of Large Software Systems. That model was explicitly described as bad. I don't fully agree with that paper, but his suggested improvements are more iterative. Personally it seems like now Waterfall is mostly used as a strawman.
> but not usually for software where you learn more from users about what should be done and tweaked as you go along
I agree with that. I wonder if Agile is highly influenced by it's leaders being closely involved with consulting.
Is anyone really doing Waterfall now? Maybe earlier some industries used a Waterfall like process. But actual descriptions of Waterfall seem to go back 50 years to Royce's paper, Managing the Development of Large Software Systems. That model was explicitly described as bad. I don't fully agree with that paper, but his suggested improvements are more iterative. Personally it seems like now Waterfall is mostly used as a strawman.
> but not usually for software where you learn more from users about what should be done and tweaked as you go along
I agree with that. I wonder if Agile is highly influenced by it's leaders being closely involved with consulting.
"Hindrance to me" is the wrong attitude unless you run the company. Scrum is not for the team to work faster. It's for the teams work to be visible, understood and correctly allocated. I find a lot of devs who dislike scrum dislike being told they have to work on company priorities instead of giving open ended estimates and then doing whatever they want.
What a sad and nihilistic view. Experienced devs are smart people. If you communicate the company targets, priorities and deadlines clearly, they will naturally find a way to self-organize to achieve those goals. Devs think it's micromanagement when they feel like they are not trusted to execute the communicated plans, but are instead required to report every hour worked to some slavemaster who might at any moment "allocate" them to a different task.
Not in my experience. In my experience, if you give the devs leeway, they'll come up with some totally overengineered architecture with the latest tech in it (which is great for their CVs) and will spend a lot of the time bikesheding over nonsense (e.g. killing each other PRs because "too functional" or "not functional enough"). The developers don't care about the company goals, but they care about their CVs and personal preferences regarding languages, tooling etc.
Also, if they team does not deliver, at the end of the day it's their manager who gets the blame, not them - so why should they care? Basically, smart devs are repaying the psychopathy of the typical company owners with a 100% selfish behavior of their own. That's the what I've seen in the wild, not the positive scenario you're describing. Perhaps it's "late stage capitalism" in the flesh.
Also, if they team does not deliver, at the end of the day it's their manager who gets the blame, not them - so why should they care? Basically, smart devs are repaying the psychopathy of the typical company owners with a 100% selfish behavior of their own. That's the what I've seen in the wild, not the positive scenario you're describing. Perhaps it's "late stage capitalism" in the flesh.
Well I suggest you stop working with colleagues you describe as psychopaths ASAP for the sake of your own mental health. I could never work with a developer who sacrifices the company's / team's business goals for a line in their own CV.
But it's indeed first and foremost the managers failing not recognizing these attributes in their team members, and not working to fix their attitude (which clearly is the underlying problem here). Imposing more process will not fix the team not caring about the product / business.
If you are not up to changing jobs, I'd suggest you try openly bringing up your concerns in a retro. Unless, you actually don't care about the product yourself either?
But it's indeed first and foremost the managers failing not recognizing these attributes in their team members, and not working to fix their attitude (which clearly is the underlying problem here). Imposing more process will not fix the team not caring about the product / business.
If you are not up to changing jobs, I'd suggest you try openly bringing up your concerns in a retro. Unless, you actually don't care about the product yourself either?
The colleagues in question are all gone now - they got better jobs thanks to the mess they've created in my project...
Psychopaty is perhaps too strong a word - they're just taking care of their interests. Perhaps in the olden times they were aligned with the interest of the employer, but currently they're clearly not (my employer has just announced that they'll lay off a couple hundred of IT people are replace them with an Indian outsourcing company, purely to cut costs...).
I don't care about the project either, but as a tech lead, I'm actually paid very well by the company to take care of its interests - incl. killing off any wild ideas that the devs might have. This (staying on old and boring tech that works well, but is not what will help me get the next well-paid job) will hurt my career in the long run, but my plan is to actually go FIRE within the current job, so it's not a problem. Most people don't have such plans though and hence they don't benefit from toiling for an ok wage with boring tech that gets the job done.
The underlying systemic problem is of course the fact that the whole industry (at least here in Europe) is crazy about following the latest tech trends for trends sake, and thus running along on the tech treadmill is the best way to get highest compensation. In the US I believe it's different, because there joining a FAANG gets you the most money, and they mostly use custom tech anyway, so they don't care about the latest open source hits (of course, you have to leetcode instead, so it comes with its own set of problems).
Psychopaty is perhaps too strong a word - they're just taking care of their interests. Perhaps in the olden times they were aligned with the interest of the employer, but currently they're clearly not (my employer has just announced that they'll lay off a couple hundred of IT people are replace them with an Indian outsourcing company, purely to cut costs...).
I don't care about the project either, but as a tech lead, I'm actually paid very well by the company to take care of its interests - incl. killing off any wild ideas that the devs might have. This (staying on old and boring tech that works well, but is not what will help me get the next well-paid job) will hurt my career in the long run, but my plan is to actually go FIRE within the current job, so it's not a problem. Most people don't have such plans though and hence they don't benefit from toiling for an ok wage with boring tech that gets the job done.
The underlying systemic problem is of course the fact that the whole industry (at least here in Europe) is crazy about following the latest tech trends for trends sake, and thus running along on the tech treadmill is the best way to get highest compensation. In the US I believe it's different, because there joining a FAANG gets you the most money, and they mostly use custom tech anyway, so they don't care about the latest open source hits (of course, you have to leetcode instead, so it comes with its own set of problems).
> my employer has just announced that they'll lay off a couple hundred of IT people are replace them with an Indian outsourcing company, purely to cut costs
Not one large-sized Nordic bank by any chance? ;)
The flipside of using latest tech is you should have easier time hiring new people to replace the ones who left. But I am certainly not denying that hiring devs who are willing to commit to the business is a really hard problem. Companies should maybe focus this more in their hiring practices over just the technical skill profile. Good developers will learn the tech stack in the job, if they care.
Also, people retention / satisfaction is pivotal in keeping the commited people on board. Doing massive outsourcings to India is certainly not a good signal to send to those who feel their skills and commitment could be appreciated elsewhere as well.
Not one large-sized Nordic bank by any chance? ;)
The flipside of using latest tech is you should have easier time hiring new people to replace the ones who left. But I am certainly not denying that hiring devs who are willing to commit to the business is a really hard problem. Companies should maybe focus this more in their hiring practices over just the technical skill profile. Good developers will learn the tech stack in the job, if they care.
Also, people retention / satisfaction is pivotal in keeping the commited people on board. Doing massive outsourcings to India is certainly not a good signal to send to those who feel their skills and commitment could be appreciated elsewhere as well.
> Not one large-sized Nordic bank by any chance? ;)
I will say no more ;)
> The flipside of using latest tech is you should have easier time hiring new people to replace the ones who left.
I've heard this argument before and it's basically a non sequitur for me. For example, there are fewer people who know the latest and greatest Scala libraries than those who know for example Java 8. The people who have learned Java 8 have not died or retired yet - they are still in industry, in large numbers, and hence it's easier and cheaper to hire them. Whereas you have to fight for the bleeding edge guys - usually by offering them high-paying contracts (which are the reason half of these guys are following the bleeding edge trends in the first place...).
I will say no more ;)
> The flipside of using latest tech is you should have easier time hiring new people to replace the ones who left.
I've heard this argument before and it's basically a non sequitur for me. For example, there are fewer people who know the latest and greatest Scala libraries than those who know for example Java 8. The people who have learned Java 8 have not died or retired yet - they are still in industry, in large numbers, and hence it's easier and cheaper to hire them. Whereas you have to fight for the bleeding edge guys - usually by offering them high-paying contracts (which are the reason half of these guys are following the bleeding edge trends in the first place...).
the problem exists too in the US due to large amounts of venture capital lying around. Ask yourself why many startups run on K8's yet they don't have the SRE requirements google has. Too much resume padding.
Good luck, if you're a engineer trying to make things work without too much ceremony. everything is about chasing the latest and the greatest, whether it makes sense for the problem at hand or not.
Good luck, if you're a engineer trying to make things work without too much ceremony. everything is about chasing the latest and the greatest, whether it makes sense for the problem at hand or not.
> I find a lot of devs who dislike scrum dislike being told they have to work on company priorities instead of giving open ended estimates
No, what I dislike is being told to go work on feature X, when I know that we’re going to run into issues with feature Y in a matter of weeks, and then having to spend nights and weekends fixing it when it eventually does break, because nobody trusted me to know what was good for the product.
Scrum gives people who have no clue what they’re doing the illusion that they do. The process is literally their only handhold to avoid feeling swept away. Like, I’m doing nothing else right, but at least we are following _the process_.
No, what I dislike is being told to go work on feature X, when I know that we’re going to run into issues with feature Y in a matter of weeks, and then having to spend nights and weekends fixing it when it eventually does break, because nobody trusted me to know what was good for the product.
Scrum gives people who have no clue what they’re doing the illusion that they do. The process is literally their only handhold to avoid feeling swept away. Like, I’m doing nothing else right, but at least we are following _the process_.
In Scrum the PO state what value they would like to see in the next sprint. Then the team start to pull in issues supporting that value. If you know that feature Y is going to result in none working software any PO pulling his/her weight will listen to you. After all, working software is more important that a new feature.
Scrum is one way transparency and those that recognize that are occasionally put off by the fact.
Again and again I've gone into the details of people's criticisms of scrum, and again and again it's turned out that they were just not actually doing it. Actually doing scrum does work 100% of the time as far as I can tell.
And on the other hand, you have a lot of testimonies here that say the only places they saw scrum work was when it was adapted to the team, and the ones that followed it to the letter failed.
It can't be both things at the same time. (out of curiosity, you say 100% of the time, how many companies you worked for that did scrum perfectly and had 100% good results?)
It can't be both things at the same time. (out of curiosity, you say 100% of the time, how many companies you worked for that did scrum perfectly and had 100% good results?)
Only two that I'd call perfect, but I also saw a direct correlation between how much a company broke the rules and how bad the results were.
I don't think that's a fair assessment. There are definitions of scrum methodologies. I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't actually follow one of them. All of them "compromised" with other business interests, and typically the compromise was on the "hard to follow" parts -- the core tenets of scrum! Some of them were 100% waterfall, but with scheduled meetings bearing titles that mimicked scrum processes. These aren't "people doing scrum wrong", these are people in a cargo cult.
I have only worked with a single team that fully followed a scrum methodology, but it was very eye opening and successful.
How many of your bad experiences with scrum bent more than a couple of these rules? How many were always followed? : https://en.wikipedia.org/wiki/Scrum_%28software_development%...
Some big things I've learned are:
* Sprint planning has to be mutual. Management cannot plan a sprint on their own, they do not have enough information to accurately plan for order or operations or effort required. Furthermore, participants need to understand the direction and priorities of the project in order to do their job properly.
* You cannot change a sprint that is in progress. Mitigating switching costs are a huge part of the benefit scrum provides. Compromising on this defeats the point of the process. It's hard to tell management "no", but you have to do it. If fire-drills are unavoidable, then you must to account for this time when you plan a sprint.
* All stakeholders must attend backlog groomings and sprint reviews. If the inputs to the process are guesses, then the outputs will be guesses. This is just as important when prioritizing work items as it is when giving feedback on completed items. It must be first-hand. Documentation and/or status updates simply do not even come even 10% close to the power that a live demo does.
I have only worked with a single team that fully followed a scrum methodology, but it was very eye opening and successful.
How many of your bad experiences with scrum bent more than a couple of these rules? How many were always followed? : https://en.wikipedia.org/wiki/Scrum_%28software_development%...
Some big things I've learned are:
* Sprint planning has to be mutual. Management cannot plan a sprint on their own, they do not have enough information to accurately plan for order or operations or effort required. Furthermore, participants need to understand the direction and priorities of the project in order to do their job properly.
* You cannot change a sprint that is in progress. Mitigating switching costs are a huge part of the benefit scrum provides. Compromising on this defeats the point of the process. It's hard to tell management "no", but you have to do it. If fire-drills are unavoidable, then you must to account for this time when you plan a sprint.
* All stakeholders must attend backlog groomings and sprint reviews. If the inputs to the process are guesses, then the outputs will be guesses. This is just as important when prioritizing work items as it is when giving feedback on completed items. It must be first-hand. Documentation and/or status updates simply do not even come even 10% close to the power that a live demo does.
> I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't actually follow one of them
To me that approach goes against the original principles for agile, especially "Individuals and Interactions over Processes and Tools". I'm not a huge fan of highly structured Agile and scrum processes. But I think the best agile implementations come when teams have ownership over their own agile processes.
And if the team truly has ownership they are responsible for their success or failure. Sure, their process may be objectively bad, but that doesn't mean a better process should be imposed from outside of the team. The team should have some level of trust to fix it.
I also disagree with your three points being hard requirements. They may be really good suggestions for teams doing scrum, especially in lower trust environments. All three are specifically for scrum, for instance they lose meaning if you aren't doing sprints. But that's just arguing semantics. Fixing compromised scrum isn't strictly necessary if the team can be successful by dropping scrum.
To me that approach goes against the original principles for agile, especially "Individuals and Interactions over Processes and Tools". I'm not a huge fan of highly structured Agile and scrum processes. But I think the best agile implementations come when teams have ownership over their own agile processes.
And if the team truly has ownership they are responsible for their success or failure. Sure, their process may be objectively bad, but that doesn't mean a better process should be imposed from outside of the team. The team should have some level of trust to fix it.
I also disagree with your three points being hard requirements. They may be really good suggestions for teams doing scrum, especially in lower trust environments. All three are specifically for scrum, for instance they lose meaning if you aren't doing sprints. But that's just arguing semantics. Fixing compromised scrum isn't strictly necessary if the team can be successful by dropping scrum.
Bear in mind I was speaking specifically about following scrum. While agile is flexible and open ended, scrum is a specific way to implement agile, and it has a process.
If, for instance, you’re not doing time-bounded sprints, you are objectively not doing scrum. Scrum has an implementation guide that outlines this.
https://scrumguides.org/scrum-guide.html
> While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Many people borrow ideas from scrum for use in their homegrown agile solution, and that’s ok. But it’s not scrum.
If, for instance, you’re not doing time-bounded sprints, you are objectively not doing scrum. Scrum has an implementation guide that outlines this.
https://scrumguides.org/scrum-guide.html
> While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Many people borrow ideas from scrum for use in their homegrown agile solution, and that’s ok. But it’s not scrum.
I spend more the 1-2 hours a day in "ceremonies". Today we had a meeting to discuss the pervasiveness of meetings. The irony was palpable.
If you're working on the wrong things just because you don't do scrum ceremonies then there's a more fundamental issue with your team.
Define "the wrong things." I see a year or two of productive work before I'd have to reach for anything with genuine doubts about business value. I might not read my stakeholders' minds exactly, or hit their preferred ordering, but I know they'd be consistently happy with the changes.
Ownership and vision are kind of the point of midlevel and senior roles. If you'd fall off the track in a matter of weeks, something is seriously wrong.
Ownership and vision are kind of the point of midlevel and senior roles. If you'd fall off the track in a matter of weeks, something is seriously wrong.
Do you think that’s representative of most work in most businesses, that you could work for months and years and finish things sort of in whatever order you want? Most of my experience has been that the planning and priorities of the business are much more strict and immediate, and you need constant interaction between them and the technical people to deliver the right things in the right order, and hopefully at approximately the right time. Business goals come frome outside the technical teams, they’re seldon determined by the devs, no matter how senior.
I think that’s more or less what it means to work in a tech company, as opposed to an IT department. “The business” is not some external thing. Each org is responsible for some part of the business, and contains all the specialties needed to take care of it. Junior people may work only within their specialties, but senior people are expected to have close partnerships and shared understanding with their cross-functional counterparts. We talk with each other frequently, but few of those exchanges contain anything new or surprising. Usually just an agreement to do the obvious next steps relative to what we did last time.
> then you're doing it wrong
What do you call it if everyone is doing it wrong?
What do you call it if everyone is doing it wrong?
Agile/scrum is not about software development. It's about business agility, managing uncertainty, and being able to adopt what you're doing to new information and new market situations.
You can't design, review and test new product designs in a word document. You need to be able to iterate, learn, adopt. PDCA: Plan, Do, Check, Act.
Scrum is just a framework that implements this. Main benefit for the business is that you don't have long periods where you can't change where you're going. And if you change your mind, you don't want to have to throw away a lot of useless investment. So you only plan short sprints, you deliver quickly, generate ROI, and improve your plan where you're heading.
Just a way to manage uncertainty.
You can't design, review and test new product designs in a word document. You need to be able to iterate, learn, adopt. PDCA: Plan, Do, Check, Act.
Scrum is just a framework that implements this. Main benefit for the business is that you don't have long periods where you can't change where you're going. And if you change your mind, you don't want to have to throw away a lot of useless investment. So you only plan short sprints, you deliver quickly, generate ROI, and improve your plan where you're heading.
Just a way to manage uncertainty.
Er... the scrum specific ceremonies are supposed to be a starting point for a team. The point of retros is to adapt your process to the team's needs as you go. So if your experience of standups, plannings, retros etc is bad it is by definition because they were doing bullshit scrum and not adapting.
Scrum and all agile processes are owned by the development team (including the PO). If they're imposing a cost and not bringing value to the developers, you're supposed to change them.
Scrum and all agile processes are owned by the development team (including the PO). If they're imposing a cost and not bringing value to the developers, you're supposed to change them.
> If they're imposing a cost and not bringing value to the developers, you're supposed to change them.
And then, based on the comments seeing here, you are doing it wrong because
>if your experience of standups, plannings, retros etc is bad it is by definition because they were doing bullshit scrum and not adapting.
And then, based on the comments seeing here, you are doing it wrong because
>if your experience of standups, plannings, retros etc is bad it is by definition because they were doing bullshit scrum and not adapting.
I've never felt like a stand-up with your manager-type-person present is ever net helpful. Stand-ups just implicitly become "what did you do yesterday that justified 10% of your biweekly paycheck" at some level, and people end up talking to the manager rather than to each other.
I'm sure some super special orgs out there can counteract this with their incredible non-toxic culture and such. Most cannot. Ones that explicitly think they can almost certainly actually cannot.
If it's solely the IC's, I think that's where it can be good. People feel a lot more free to not say anything if they don't have any blockers and don't need to put anything to the team. It's much easier to get in-and-out and have a high-bandwidth discussion.
I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next. And we had an open-door policy (not literally/physically of course) if you ever needed to discuss blockers or put things to the team. "Standups" happened naturally, about once or twice as week, where people would accrete into a standup in the middle of our pod discussing something that was so interesting/relevant that it naturally drew us out of our offices.
Maybe that was just the only time where we finally had the team and the process mesh on a natural level, and it doesn't prescribe this as "the way to do it" for anyone else. But damn did it work for us, for at least two years, before the org changed enough that our team didn't really exist as the same team anymore.
One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible". That and everything related to it was awful.
I'm sure some super special orgs out there can counteract this with their incredible non-toxic culture and such. Most cannot. Ones that explicitly think they can almost certainly actually cannot.
If it's solely the IC's, I think that's where it can be good. People feel a lot more free to not say anything if they don't have any blockers and don't need to put anything to the team. It's much easier to get in-and-out and have a high-bandwidth discussion.
I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next. And we had an open-door policy (not literally/physically of course) if you ever needed to discuss blockers or put things to the team. "Standups" happened naturally, about once or twice as week, where people would accrete into a standup in the middle of our pod discussing something that was so interesting/relevant that it naturally drew us out of our offices.
Maybe that was just the only time where we finally had the team and the process mesh on a natural level, and it doesn't prescribe this as "the way to do it" for anyone else. But damn did it work for us, for at least two years, before the org changed enough that our team didn't really exist as the same team anymore.
One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible". That and everything related to it was awful.
A good team can make any process work, just like a bad manager/team can destroy the best process.
I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career. I've also been fortunate enough to have good team members and technical management (prior to being management).
I have always found them helpful, particularly when people get stuck. Of course someone can always shout I'm stuck and hope the right person hears, but I've lost count of the times someone in the standup that likely would not have seen this person's problem says 'oh, I've seen that - do this'. And that includes possible management. Also, many people don't want to say they are stuck or don't know something. While not automatic, this does provide a scheduled block of time to speak up.
I've worked with many great engineer people who had tendencies to go down rabbit holes. A daily check-in made micromanagement unnecessary because it forced someone to think about what they accomplished and where was it headed.
Finally, it's ok to say nothing was accomplished yesterday. Shit happens, we all know it.
I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career. I've also been fortunate enough to have good team members and technical management (prior to being management).
I have always found them helpful, particularly when people get stuck. Of course someone can always shout I'm stuck and hope the right person hears, but I've lost count of the times someone in the standup that likely would not have seen this person's problem says 'oh, I've seen that - do this'. And that includes possible management. Also, many people don't want to say they are stuck or don't know something. While not automatic, this does provide a scheduled block of time to speak up.
I've worked with many great engineer people who had tendencies to go down rabbit holes. A daily check-in made micromanagement unnecessary because it forced someone to think about what they accomplished and where was it headed.
Finally, it's ok to say nothing was accomplished yesterday. Shit happens, we all know it.
>>> I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career.
I'm curious how bigs were your teams? and if you were all local in the same office?
There was one place were we did daily check-in and it was okay. It wasn't formals stand-ups but an informal check-in in the morning, asking each other what's up, when we got to our shared office, right after breakfast. We were just three in the team and it was quite informal. The majority of the time there weren't the three of us in office so this really wasn't a meeting at all.
I'm curious how bigs were your teams? and if you were all local in the same office?
There was one place were we did daily check-in and it was okay. It wasn't formals stand-ups but an informal check-in in the morning, asking each other what's up, when we got to our shared office, right after breakfast. We were just three in the team and it was quite informal. The majority of the time there weren't the three of us in office so this really wasn't a meeting at all.
10 or less people, mixed in office and remote. Mine have almost always been fairly informal, and early on (I'm in my 40s) pre-agile it was just a what's up type thing. So while there was a scheduled time, it was a very free form meeting. We would talk a bit about work, last nights video game, etc... If people were already deep into some work, it was fine to miss.
Agile/Scrum is great if done properly.
Most of the industry is doing it wrong/cargo-culting the wrong think. Non-technical managers, or worse, CS grads whose goal was to stop coding 4 years into their careers, took the parts of Agile they liked and made it into a micro-management strategy to justify their work.
Agile was written at a resort by 10x engineers for 10x engineers. Flat organization and high ownership (meaning these guys have a stake in the company). Trying to blindly copy it to highly hierarchical cost-center software shops is a recipe for disaster where the only ones making money are the agile consultants.
Most of the industry is doing it wrong/cargo-culting the wrong think. Non-technical managers, or worse, CS grads whose goal was to stop coding 4 years into their careers, took the parts of Agile they liked and made it into a micro-management strategy to justify their work.
Agile was written at a resort by 10x engineers for 10x engineers. Flat organization and high ownership (meaning these guys have a stake in the company). Trying to blindly copy it to highly hierarchical cost-center software shops is a recipe for disaster where the only ones making money are the agile consultants.
> Agile/Scrum is great if done properly.
and, I'd like to point out, Agile/Scrum is great IF applied on suitable organizations/projects.
Some projects are too big by nature and, regardless of how much resources are available, there are not enough 10x engineers to be hired and trained to deliver the project within a feasible time.
Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile.
Don't get me wrong, I like Agile and favor it over other method families whenever I can, but I have a different point of view when it comes to organizations "not well-suited to Agile". I don't necessarily see them as limited solely based on how well software projects can be carried within their structures.
It's indeed advantageous to possess a software project-friendly environment. That would provide them a good edge over competition.
But there are so many other things beyond that, and so many organizations being successful on their main goals despite being Agile-hostile, that I'm more inclined to look for ways to cope with their shortcomings.
I'm not implying you wanted to say that, but I see many Agile enthusiasts classifying those organizations as "not prepared to Agile" and I think this is so wrong. I see that simply as a natural incompatibility and, if I had to elect a culprit (which I don't think to be the case), then Agile would be the party which is in debt.
and, I'd like to point out, Agile/Scrum is great IF applied on suitable organizations/projects.
Some projects are too big by nature and, regardless of how much resources are available, there are not enough 10x engineers to be hired and trained to deliver the project within a feasible time.
Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile.
Don't get me wrong, I like Agile and favor it over other method families whenever I can, but I have a different point of view when it comes to organizations "not well-suited to Agile". I don't necessarily see them as limited solely based on how well software projects can be carried within their structures.
It's indeed advantageous to possess a software project-friendly environment. That would provide them a good edge over competition.
But there are so many other things beyond that, and so many organizations being successful on their main goals despite being Agile-hostile, that I'm more inclined to look for ways to cope with their shortcomings.
I'm not implying you wanted to say that, but I see many Agile enthusiasts classifying those organizations as "not prepared to Agile" and I think this is so wrong. I see that simply as a natural incompatibility and, if I had to elect a culprit (which I don't think to be the case), then Agile would be the party which is in debt.
> Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile.
These two issues can be solved by isolating the software folks from the rest of the organization. Think of a company within a company. That and fixing the hiring pipeline can fix ownership: bringing a culture of stock based compensation typically attracts high achievers and make it important for the engineers to truly own the product.
These two issues can be solved by isolating the software folks from the rest of the organization. Think of a company within a company. That and fixing the hiring pipeline can fix ownership: bringing a culture of stock based compensation typically attracts high achievers and make it important for the engineers to truly own the product.
How so?
You could structure your IT department as a flat organization (and I think it's indeed a good idea), but how would you fully adopt agile principles when they consider users as part of the team? How would you favor interactions over processes while stakeholders from the other side manifest low ownership levels or even sabotage the project (if they see the project putting their jobs at risk or when their managers don't give the project a proper level of priority)?
In theory it makes sense, but experience shows it's impractical to apply Agile principles on such environments without some adaptation.
I've already worked under such arrange (scrum + flat IT department inside hierarchical organization). It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
You could structure your IT department as a flat organization (and I think it's indeed a good idea), but how would you fully adopt agile principles when they consider users as part of the team? How would you favor interactions over processes while stakeholders from the other side manifest low ownership levels or even sabotage the project (if they see the project putting their jobs at risk or when their managers don't give the project a proper level of priority)?
In theory it makes sense, but experience shows it's impractical to apply Agile principles on such environments without some adaptation.
I've already worked under such arrange (scrum + flat IT department inside hierarchical organization). It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
> your IT department
If software engineers are working as the "IT" department, it's already a red flag. Especially if it's treated as a cost-center.
> It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
Some users, especially internals, don't want any changes. when that happens, the only thing left to do is pretty much switch project sadly. With a stock compensation, you don't want to waste your time building something that won't be used: that doesn't create any value.
If software engineers are working as the "IT" department, it's already a red flag. Especially if it's treated as a cost-center.
> It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
Some users, especially internals, don't want any changes. when that happens, the only thing left to do is pretty much switch project sadly. With a stock compensation, you don't want to waste your time building something that won't be used: that doesn't create any value.
> Agile was written at a resort by 10x engineers for 10x engineers.
Do these 10x engineers need Scrum ? I don’t think flat/high ownership organization have a strong need to be told how to do things, or import some cookie cutter framework in their day to day operation.
Getting inspired ? sure, but a lot of the ceremony parts of Scrum don’t make sense if people already communicate fluently and organize seemlessly.
Do these 10x engineers need Scrum ? I don’t think flat/high ownership organization have a strong need to be told how to do things, or import some cookie cutter framework in their day to day operation.
Getting inspired ? sure, but a lot of the ceremony parts of Scrum don’t make sense if people already communicate fluently and organize seemlessly.
> Agile was written at a resort by 10x engineers for 10x engineers.
Do these 10x engineers need Scrum ?
Not to beat a dead horse one more time, but "Agile <> Scrum"
Scrum is just one, out of many methodologies that claim some association with the core ideas behind the Agile Manifesto. It's totally possible to be "Agile" and not do a single thing that's in Scrum.
And just to add one more note: there's a lot of "stuff" that gets lumped in with Scrum in a lot of these criticism heavy threads, that isn't actually part of Scrum per-se. Often times idiot would-be Scrum masters cobble together bits and piece of ideas here and there and make some goofy hodge-podge and then call it Scrum. I'd encourage anybody contemplating Scrum for whatever reason to go read the Scrum Guide and see how different it is from the "Scrum" their organization practices. Same for the Agile Manifesto.
And if you encounter an organization that claims to be doing SAFE (Scaled Agile Framework) turn and run away as fast as you can, IMO.
Not to beat a dead horse one more time, but "Agile <> Scrum"
Scrum is just one, out of many methodologies that claim some association with the core ideas behind the Agile Manifesto. It's totally possible to be "Agile" and not do a single thing that's in Scrum.
And just to add one more note: there's a lot of "stuff" that gets lumped in with Scrum in a lot of these criticism heavy threads, that isn't actually part of Scrum per-se. Often times idiot would-be Scrum masters cobble together bits and piece of ideas here and there and make some goofy hodge-podge and then call it Scrum. I'd encourage anybody contemplating Scrum for whatever reason to go read the Scrum Guide and see how different it is from the "Scrum" their organization practices. Same for the Agile Manifesto.
And if you encounter an organization that claims to be doing SAFE (Scaled Agile Framework) turn and run away as fast as you can, IMO.
One of the details of the manifesto is that it does not tell you how to do things, and in fact discourages the prioritization of "processes and tools" over "individuals and interactions" (doesn't remove processes and tools, but it deprioritizes them). The manifesto was as much for the developers as for their managers and customers. It established the priorities of their work and relationship with each other.
And people can only communicate fluently and organize seamlessly because of their understanding. There's no quickfix solution to making sure you hired the right people.
Nobody does the full Scrum.
It's more of a set of ideas that can can be applied to a project (or not) and ways of thinking about the software engineering process itself. It's not a magic recipe, just like no programming language or framework will make RandomCo. a unicorn.
It's more of a set of ideas that can can be applied to a project (or not) and ways of thinking about the software engineering process itself. It's not a magic recipe, just like no programming language or framework will make RandomCo. a unicorn.
The only time I’ve seen it done properly was a team I worked in before the Agile manifesto was written.
Honestly I feel like a team that communicates healthily in channels on slack kinda defeats the entire purpose of stand ups. At my current job, we even have the customers for my team in slack channels and they are highly communicative, so honestly it makes the whole scrum model seem just a waste of time when I can start a question/thread right in slack with the product owners/customers
We have a #daily-updates channel where we can just drop status and blockers. We roll it up into a weekly summary.
According to Scrum, the manager should not even be present during the daily stand-up.
(More precisely, in Scrum there is actually no such thing as a manager. But often the manager is a replacement for product owner. However, the product owner should not be present during the daily stand-up. It should only be developers talking to developers, with scrum master acting as a moderator, essentially reminding everyone to keep it short.)
> I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next.
In Scrum, this is called retrospective, and is considered the only non-optional part. Ironically, in most companies this is the only part of Scrum that gets removed as a "waste of time".
> One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible".
This is what Scrum is explicitly against. The big boss should not even be involved; the developers should be talking to the customer directly. The customer decides what is the highest priority, but the developers decide how long it will take. The entire purpose of planning is to negotiate this; like the customer says "I want X and Y", the developers say "we can't do both in one month, but either of them is doable alone, which one is more urgent for you", the customer says "in that case, I want X", and the developers say "okay, let's meet in a month, you will have X, and we will show you a demo".
(More precisely, in Scrum there is actually no such thing as a manager. But often the manager is a replacement for product owner. However, the product owner should not be present during the daily stand-up. It should only be developers talking to developers, with scrum master acting as a moderator, essentially reminding everyone to keep it short.)
> I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next.
In Scrum, this is called retrospective, and is considered the only non-optional part. Ironically, in most companies this is the only part of Scrum that gets removed as a "waste of time".
> One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible".
This is what Scrum is explicitly against. The big boss should not even be involved; the developers should be talking to the customer directly. The customer decides what is the highest priority, but the developers decide how long it will take. The entire purpose of planning is to negotiate this; like the customer says "I want X and Y", the developers say "we can't do both in one month, but either of them is doable alone, which one is more urgent for you", the customer says "in that case, I want X", and the developers say "okay, let's meet in a month, you will have X, and we will show you a demo".
I thought this way when I started working, but I'm grudgingly coming around. It's easiest to keep a house clean out of respect for the people you live with. It's easiest to consistently dress and groom well when you're meeting people whose opinions you value. It's easiest to stick to exercise when it's an appointment with other people. You will cook and eat best in social and family meals.
A little bit of social exposure helps everyone to be their best selves. Mad respect to people who truly don't need this. But it makes sense that the workplace is adapted for those who do.
A little bit of social exposure helps everyone to be their best selves. Mad respect to people who truly don't need this. But it makes sense that the workplace is adapted for those who do.
At my last full-time position in the corporate world we were doing Scrum well. The daily scrum was short and not for any manager - team members shared quick updates and blockers with each other. Before we had Scrum enforced, all the dev teams suffered from chaos caused by product owners constantly changing priorities mid-sprint or adding “just one more feature” several times during the sprint, so once the product owners agreed to stick to Scrum the team was able to enjoy some sanity in their work.
You need to understand the mechanism and purpose behind agile. If you don't, then it is just a cargo cult thing. Software development, and product development is one of the hardest things to do right now. You need many independent people working together with "deep unplanned collaboration". How do you do that?
I'm old and I worked at Ingres when they decided to write a new release and everyone went off and worked on it for a year. It was right on schedule. Then they got together to release the product and found that each team had developed a component that failed completely to interoperate with any other components. Have you ever heard of Ingres?
The key to their failure was that they never put the pieces together.
So agile is a bunch of techniques to let people work together on exceedingly complex projects. Calling it agile is indeed just marketing. It is basically a messaging bus. The idea is that those Ingres people could have had some meetings to talk about how their components worked and things would have been better. Maybe not great, but better.
And if those people understood that their goal was to give others insight into how they were doing things, that would have been even better.
But think about this - what if from the very first day they just ran the whole project with all the components? Even if all the functionality was stubbed out, at least they would know that it worked together. We do that now, or we should - continuous integration or whatever.
I knew a person who was a great person and great programmer who had worked in the industry for eight years. And not once had the product they worked been used by another person. Think of all that waste.
So yeah, ignore scrum and agile and all that if you have something better. Its not a religion, its just one way of working together. :-)
I'm old and I worked at Ingres when they decided to write a new release and everyone went off and worked on it for a year. It was right on schedule. Then they got together to release the product and found that each team had developed a component that failed completely to interoperate with any other components. Have you ever heard of Ingres?
The key to their failure was that they never put the pieces together.
So agile is a bunch of techniques to let people work together on exceedingly complex projects. Calling it agile is indeed just marketing. It is basically a messaging bus. The idea is that those Ingres people could have had some meetings to talk about how their components worked and things would have been better. Maybe not great, but better.
And if those people understood that their goal was to give others insight into how they were doing things, that would have been even better.
But think about this - what if from the very first day they just ran the whole project with all the components? Even if all the functionality was stubbed out, at least they would know that it worked together. We do that now, or we should - continuous integration or whatever.
I knew a person who was a great person and great programmer who had worked in the industry for eight years. And not once had the product they worked been used by another person. Think of all that waste.
So yeah, ignore scrum and agile and all that if you have something better. Its not a religion, its just one way of working together. :-)
> The key to their failure was that they never put the pieces together.
> So agile is a bunch of techniques to let people work together
Never integrating the parts until the end has nothing to do with not having used "agile". It's just terrible engineering.
Quality engineering work has been getting done for decades before the agile cargo cult of daily status meetings aka "agile".
> So agile is a bunch of techniques to let people work together
Never integrating the parts until the end has nothing to do with not having used "agile". It's just terrible engineering.
Quality engineering work has been getting done for decades before the agile cargo cult of daily status meetings aka "agile".
> Never integrating the parts until the end has nothing to do with not having used "agile". It's just terrible engineering.
I don't disagree with this exactly, but agile is/can be a useful tool to keep engineering on the rails. It's not like if you do agile, you can forget about engineering practices because you've got agile instead. It just reinforces why good engineering is important, and acts as a stick to keep engineering teams on track. A bit like how with good tests, you just can't get away with sloppy code, because having tests necessitates following best practices.
I don't disagree with this exactly, but agile is/can be a useful tool to keep engineering on the rails. It's not like if you do agile, you can forget about engineering practices because you've got agile instead. It just reinforces why good engineering is important, and acts as a stick to keep engineering teams on track. A bit like how with good tests, you just can't get away with sloppy code, because having tests necessitates following best practices.
Yes, true. But this points at the annoying thing about how the agile cult attempts to take over credit for the good engineering practices that all existed before agile became a thing. All agile adds on top is the annoying parts (relentless status meetings, treating developers as faceless interchangeable "resources") that make life worse than it was before.
I am no defender of agile as I have seen it implemented as a cargo cult. So yes, quality engineering can happen without it. However, the communication that can/should/could be provided by agile is required by quality engineering.
My first experience with seeing how effective this communication can be was before agile when a manager held short, goofy meetings once a week and we engineers somehow managed to ship, ship on time, and ship reasonable products.
My first experience with seeing how effective this communication can be was before agile when a manager held short, goofy meetings once a week and we engineers somehow managed to ship, ship on time, and ship reasonable products.
> Have you ever heard of Ingres?
Only because of HN comments talking about the history of Postgres!
Only because of HN comments talking about the history of Postgres!
What’s so funny to me is what you’re describing is the nightmare that’s become scrum as opposed to actual agility. Agile is about ditching managers, bureaucracy, and estimates in favor of empowering the team itself.
Agility is just what it says: a philosophy of flexibility and adaptiveness.
Heirarchies, heavy processes, etc are by definition inflexible. They are not agile. You do not do agile. You are agile. You are agile because your company has a culture that is agile and you cannot achieve that unless the company is structured to be flexible.
I think actual agility is really, really a great way to build software efficiently... but unfortunately most programmers will only experience the cargo cult forced upon them by certified scrum masters... and this is just as bad, perhaps worse, than old fashioned waterfall.
More than anything, working in an agile environment is a very pleasant thing to do from a human standpoint. But most companies are incapable of the kind of equality and empowerment necessary to achieve agility, so they will force the terrible cargo cult version upon us.
Agility is just what it says: a philosophy of flexibility and adaptiveness.
Heirarchies, heavy processes, etc are by definition inflexible. They are not agile. You do not do agile. You are agile. You are agile because your company has a culture that is agile and you cannot achieve that unless the company is structured to be flexible.
I think actual agility is really, really a great way to build software efficiently... but unfortunately most programmers will only experience the cargo cult forced upon them by certified scrum masters... and this is just as bad, perhaps worse, than old fashioned waterfall.
More than anything, working in an agile environment is a very pleasant thing to do from a human standpoint. But most companies are incapable of the kind of equality and empowerment necessary to achieve agility, so they will force the terrible cargo cult version upon us.
Couldn't agree more. Just quit my job of last six years the previous week. I really liked the team and the product. We had a very informal development process - we all agreed it was agile but not through following any formal process (Scrum or such).
We still had retros and dailies. Planning was done by managers explaining a feature they'd like us to do, and the team then doing the planning, design and implementation. More processes and e.g. recurring meetings were erected and torn down based on the team's actual needs alone. If someone wanted an estimate, we'd give it, but we were not doing continuos estimation just for the sake of estimation itself, like in Scrum. Felt like the process served us, rather than us serving a process. If you'd taken a look at the Agile manifesto, we were ticking pretty much all the boxes: https://agilemanifesto.org/principles.html
Then 1.5 years ago, company decided to roll out whole IT department wide SAFe, which is basically Scrum but on a whole organization level, and hence even more bureaucratic and with one additional level of mega-iterations added on top of Scrum's sprints.
Suddenly, our team is assigned a Scrum master and we no longer even get to speak directly with the managers who previously negotiated new features with us. Instead, everything has to go through multiple levels of prioritization and broken telephones of new SAFe intermediaries. We started attending 2-3 new mandatory processes / recurring meetings, meaning time spent in inefficient boring meetings went up significantly. We had to also start a much more stringent ticketing system regime, including having to estimate ALL work. Despite multiple requests from Scrum master and managers, nobody was ever able to explain why estimating absolutely everything - even when nobody had even asked for an estimate - helped with anything. It was seemingly taken as a religious thesis that it was just the right thing to do.
Soon, the team was paralyzed. Even simple features became harder and harder to develop. Despite the massive effort spent on estimating even the most trivial of tasks, the big picture was forgotten about because larger feature-level ballpark estimates were no longer acceptable, and hence unimportant. On a company level, the business managers that previously talked directly to us just basically quit working with the IT department because the SAFe process was such a beast to contend. It was easiest for them to just stop asking for new digital product features, and focus on non-IT projects instead.
I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way - Scrum consultants love to gloat when some metric improves, but if things go south the org has only itself to blame for failing to correctly convert to their favorite flavor of True Agile System™.
My experience was however seeing an Agile team (as expressed by the Agile manifesto) turn into a Monty Python parody of agile software development just by being forced to submit to these "fake agile" heavy processes and hierarchies.
We still had retros and dailies. Planning was done by managers explaining a feature they'd like us to do, and the team then doing the planning, design and implementation. More processes and e.g. recurring meetings were erected and torn down based on the team's actual needs alone. If someone wanted an estimate, we'd give it, but we were not doing continuos estimation just for the sake of estimation itself, like in Scrum. Felt like the process served us, rather than us serving a process. If you'd taken a look at the Agile manifesto, we were ticking pretty much all the boxes: https://agilemanifesto.org/principles.html
Then 1.5 years ago, company decided to roll out whole IT department wide SAFe, which is basically Scrum but on a whole organization level, and hence even more bureaucratic and with one additional level of mega-iterations added on top of Scrum's sprints.
Suddenly, our team is assigned a Scrum master and we no longer even get to speak directly with the managers who previously negotiated new features with us. Instead, everything has to go through multiple levels of prioritization and broken telephones of new SAFe intermediaries. We started attending 2-3 new mandatory processes / recurring meetings, meaning time spent in inefficient boring meetings went up significantly. We had to also start a much more stringent ticketing system regime, including having to estimate ALL work. Despite multiple requests from Scrum master and managers, nobody was ever able to explain why estimating absolutely everything - even when nobody had even asked for an estimate - helped with anything. It was seemingly taken as a religious thesis that it was just the right thing to do.
Soon, the team was paralyzed. Even simple features became harder and harder to develop. Despite the massive effort spent on estimating even the most trivial of tasks, the big picture was forgotten about because larger feature-level ballpark estimates were no longer acceptable, and hence unimportant. On a company level, the business managers that previously talked directly to us just basically quit working with the IT department because the SAFe process was such a beast to contend. It was easiest for them to just stop asking for new digital product features, and focus on non-IT projects instead.
I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way - Scrum consultants love to gloat when some metric improves, but if things go south the org has only itself to blame for failing to correctly convert to their favorite flavor of True Agile System™.
My experience was however seeing an Agile team (as expressed by the Agile manifesto) turn into a Monty Python parody of agile software development just by being forced to submit to these "fake agile" heavy processes and hierarchies.
We’re in the midst of a ‘SAFe transformation’ from having been running in a fairly lightweight scrum-style manner for year.
There are a set of ‘good things’ that I can see from SAFe, and if you read the book and do the course there is loads about how you /should/ adapt it to work for you.
Amongst the issues is that SAFe, by its very nature, has stakeholders outside the local team and that mandates some sort of process.
Interestingly the size that Scaled Agile talk about is pretty big - a small Agile Release Train was discussed as ~100 people across ~5 teams. The full Portfolio SAFe is for multiple release trains e.g. 500+ people.
If you’re trying to enforce SAFe on something much smaller then I think you’re probably doing it wrong.
Also, if the “IT Department is trying to implement SAFe” rather than the “Company is undergoing a SAFe transformation” it has already gone wrong. You need to have your stakeholders throughout the organisation on board, and it is something of a top down thing.
There are a set of ‘good things’ that I can see from SAFe, and if you read the book and do the course there is loads about how you /should/ adapt it to work for you.
Amongst the issues is that SAFe, by its very nature, has stakeholders outside the local team and that mandates some sort of process.
Interestingly the size that Scaled Agile talk about is pretty big - a small Agile Release Train was discussed as ~100 people across ~5 teams. The full Portfolio SAFe is for multiple release trains e.g. 500+ people.
If you’re trying to enforce SAFe on something much smaller then I think you’re probably doing it wrong.
Also, if the “IT Department is trying to implement SAFe” rather than the “Company is undergoing a SAFe transformation” it has already gone wrong. You need to have your stakeholders throughout the organisation on board, and it is something of a top down thing.
> there is loads about how you /should/ adapt it to work for you
Is this really happeninig in your org when adopting SAFe? At least for us - we went to all the trainings but it was essentially a two-day heavy course of a SAFe consultant telling us how to run dailies, groomings, plannings, PI plannings, retros, demos etc. etc. ALL of these were mandatory and our team was assigned a Scrum master to make sure we were actually doing them (granted, he took responsibility of organizing also the retros, which was previously a full workday for me every two months.)
I even remember reading from the SAFe book that teams are only afforded a limited autonomy of deciding on the implementation technologies of the features that are assigned. No word of having any autonomy over the process, since I understod the uniform process being a requirement for the inter-team coordination to work.
Is this really happeninig in your org when adopting SAFe? At least for us - we went to all the trainings but it was essentially a two-day heavy course of a SAFe consultant telling us how to run dailies, groomings, plannings, PI plannings, retros, demos etc. etc. ALL of these were mandatory and our team was assigned a Scrum master to make sure we were actually doing them (granted, he took responsibility of organizing also the retros, which was previously a full workday for me every two months.)
I even remember reading from the SAFe book that teams are only afforded a limited autonomy of deciding on the implementation technologies of the features that are assigned. No word of having any autonomy over the process, since I understod the uniform process being a requirement for the inter-team coordination to work.
>If you’re trying to enforce SAFe on something much smaller then I think you’re probably doing it wrong.
the comment you are answering was on point
>I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way
the comment you are answering was on point
>I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way
Sometimes you actually are doing something wrong though. Preemptively stating that you know someone will tell it to you doesn’t necessarily mean that it isn’t true.
If you want to lose weight, a diet where you can eat as much McDonald’s as you want is probably doing it wrong. Applying SAFe to a small team is probably wrong.
If you want to lose weight, a diet where you can eat as much McDonald’s as you want is probably doing it wrong. Applying SAFe to a small team is probably wrong.
My bad, not ‘doing it wrong’, just trying to use the wrong methodology for your problem :)
sledgehammer to crack a nut.
sledgehammer to crack a nut.
This particular company was in fact seriously in need of a corporation-wide business development methodology, so sledgehammer was called for – and I can see the appeal they saw in SAFe. But completely replacing autonomous agile teams' existing self-organized processes with a new top-down forced SAFe variety of Scrum with the same swing of the hammer -- not really called for, but mandated anyway in name of SAFe having to be an "organization wide" effort.
Reality is of course that the dev teams are the only ones ever trained in the new process, and must suffer the chaos while rest of the org just don't care or hate it just as much – apart of course from the new middle managers who were hired to "help with the SAFe transformation".
My prediction: max two years from now senior management announce "the end of the SAFe experiment", and go back to some ad-hoc version of the preceding organization model "with lessons learned" etc. Rinse and repeat every four-five years.
Reality is of course that the dev teams are the only ones ever trained in the new process, and must suffer the chaos while rest of the org just don't care or hate it just as much – apart of course from the new middle managers who were hired to "help with the SAFe transformation".
My prediction: max two years from now senior management announce "the end of the SAFe experiment", and go back to some ad-hoc version of the preceding organization model "with lessons learned" etc. Rinse and repeat every four-five years.
> I know Scrum / SAFe proponents will say we were doing it wrong.
I guess you just weren't Agileing and Scruming hard enough!
I guess you just weren't Agileing and Scruming hard enough!
> Agile is about ditching managers, bureaucracy, and estimates in favor of empowering the team itself.
Scrum (as intended, not as actually done in most companies) is in essence a set of rules to prevent things from falling apart after you have ditched the managers:
* know what you want to achieve during this month -- planning for longer time is unrealistic, weekly planning is micromanagement;
* at the end of the month, make a demo of new features -- make sure that all pieces fit together, and get feedback whether this is actually what the customer wanted;
* reflect on what happened during this month and why -- this is the moment to speak freely, complain, and propose changes (for example, this is the occassion when the developers could collectively decide to stop using Jira);
* decide where to go during the next month -- together with the customer: the customer decides "what first", developers decide "how fast";
* make sure your colleagues know what you do and whether you need help -- this shouldn't take more than 3 minutes a day.
If your sprints are weekly, you are doing it wrong. If you don't make a demo, you are doing it wrong. First, with continuous integration, deploying the demo should be trivial. Second, if you don't show the demo to the customer, who is giving you feedback on your progress? (Nobody? Management?) If you skip the retrospective, or if you don't feel free to speak openly during the retrospective, you are doing it wrong. If you don't have an idea what to do next, and what is important for the customer, you are doing it wrong. If management gives you deadline, you are doing it wrong. If your daily standup takes more than three minutes, you are doing it wrong. (For anything that requires more time, you should arrange a separate meeting, for only the people involved, not the whole team. Note that the "separate meeting" could still be like five or ten minutes long.)
So much for the dream. Now here is what actually happens: in your company, the managers have the power, and they are not going to fire themselves. So instead, they will impose on you some kind of management-driven pseudo-Scrum, which looks like this:
The sprints are short, because that gives the managers greater feeling of control. You don't talk to the the actual customer, and the customer doesn't see your product before it is officially delivered; the managers acting as middlemen is how they justify their jobs. There is no retrospective, because this is the first and the last time in history when management decides that something is a waste of time. You have sprint planning, but you also have deadlines, so your choices are often limited to "do X this sprint and Y next sprint, or do Y this sprint and X next sprint". The daily, instead of team members synchronizing with each other, becomes team members reporting to the manager. You get Jira, which is set up according to the manager's wishes.
This is not a coincidence. The managers insist it needs to be done this way, because they want to protect their jobs. The same thing would happen with any other methodology.
Scrum (as intended, not as actually done in most companies) is in essence a set of rules to prevent things from falling apart after you have ditched the managers:
* know what you want to achieve during this month -- planning for longer time is unrealistic, weekly planning is micromanagement;
* at the end of the month, make a demo of new features -- make sure that all pieces fit together, and get feedback whether this is actually what the customer wanted;
* reflect on what happened during this month and why -- this is the moment to speak freely, complain, and propose changes (for example, this is the occassion when the developers could collectively decide to stop using Jira);
* decide where to go during the next month -- together with the customer: the customer decides "what first", developers decide "how fast";
* make sure your colleagues know what you do and whether you need help -- this shouldn't take more than 3 minutes a day.
If your sprints are weekly, you are doing it wrong. If you don't make a demo, you are doing it wrong. First, with continuous integration, deploying the demo should be trivial. Second, if you don't show the demo to the customer, who is giving you feedback on your progress? (Nobody? Management?) If you skip the retrospective, or if you don't feel free to speak openly during the retrospective, you are doing it wrong. If you don't have an idea what to do next, and what is important for the customer, you are doing it wrong. If management gives you deadline, you are doing it wrong. If your daily standup takes more than three minutes, you are doing it wrong. (For anything that requires more time, you should arrange a separate meeting, for only the people involved, not the whole team. Note that the "separate meeting" could still be like five or ten minutes long.)
So much for the dream. Now here is what actually happens: in your company, the managers have the power, and they are not going to fire themselves. So instead, they will impose on you some kind of management-driven pseudo-Scrum, which looks like this:
The sprints are short, because that gives the managers greater feeling of control. You don't talk to the the actual customer, and the customer doesn't see your product before it is officially delivered; the managers acting as middlemen is how they justify their jobs. There is no retrospective, because this is the first and the last time in history when management decides that something is a waste of time. You have sprint planning, but you also have deadlines, so your choices are often limited to "do X this sprint and Y next sprint, or do Y this sprint and X next sprint". The daily, instead of team members synchronizing with each other, becomes team members reporting to the manager. You get Jira, which is set up according to the manager's wishes.
This is not a coincidence. The managers insist it needs to be done this way, because they want to protect their jobs. The same thing would happen with any other methodology.
> for example, this is the occassion when the developers could collectively decide to stop using Jira
That's the gold standard! You know you are doing fake agile when the team is not allowed to decide stop using Jira.
In all seriousness, thanks - very valued insights! I did not even know those were the original purposes of the Scrum ceremonies, having only ever worked witn almost exactly the kind of pseudo-Scrum you describe.
That's the gold standard! You know you are doing fake agile when the team is not allowed to decide stop using Jira.
In all seriousness, thanks - very valued insights! I did not even know those were the original purposes of the Scrum ceremonies, having only ever worked witn almost exactly the kind of pseudo-Scrum you describe.
Perfect litmus test indeed! I worked in one place where scrum master - the person explicitly assigned to protect the team - was the one who most loudly imposed that the company configured Jira shall be used. Despite this being brought up as a PITA every retrospective.
This is the moment you know you are doing fake Agile and your scrummaster is just the managers puppet in disguise to spy on the team.
This is the moment you know you are doing fake Agile and your scrummaster is just the managers puppet in disguise to spy on the team.
It is difficult for the Scrum Master to be impartial in a situation where the management ultimately decides who will be the Scrum Master and whether Scrum will be used at all.
I am not sure what would be the right solution. One possibility is to fire the management, or never even hire them at first place -- if you want to have a software company that uses Scrum, do it from start. Another possibility is to have a Scrum Master with strong political skils... which more or less means, it cannot be a former developer.
Probably the fatal mistake is having too many managers in the company. At that moment, it is practically guaranteed that they will try to interfere with everything. They have to, because that is how they protect their own jobs. And they will hire more managers, because that is one way to get higher on the company ladder (hire more people into positions below you). And at that moment, everything is doomed, because now the company serves the managers instead of the other way round.
I guess this means that Scrum can work as intended only in small companies. Where the Scrum Master is not below several layers of management, but on the same level as the few managers, right below the company owner.
I am not sure what would be the right solution. One possibility is to fire the management, or never even hire them at first place -- if you want to have a software company that uses Scrum, do it from start. Another possibility is to have a Scrum Master with strong political skils... which more or less means, it cannot be a former developer.
Probably the fatal mistake is having too many managers in the company. At that moment, it is practically guaranteed that they will try to interfere with everything. They have to, because that is how they protect their own jobs. And they will hire more managers, because that is one way to get higher on the company ladder (hire more people into positions below you). And at that moment, everything is doomed, because now the company serves the managers instead of the other way round.
I guess this means that Scrum can work as intended only in small companies. Where the Scrum Master is not below several layers of management, but on the same level as the few managers, right below the company owner.
This is spot on. I think the biggest indication that you are in cargo cult psuedo scrum is Sprint with deadlines, the road to burnout.
> But most companies are incapable of the kind of equality and empowerment necessary to achieve agility, so they will force the terrible cargo cult version upon us.
I would argue that most companies cannot afford to give that kind of "empowerment" to most developers, especially if these companies rely heavily on masses of junior/inexperienced developers. So they figure a strong management layer is necessary to properly direct the project's goals.
Now I'm not saying that's how it should be, but that's the reality of the software talent market today.
I would argue that most companies cannot afford to give that kind of "empowerment" to most developers, especially if these companies rely heavily on masses of junior/inexperienced developers. So they figure a strong management layer is necessary to properly direct the project's goals.
Now I'm not saying that's how it should be, but that's the reality of the software talent market today.
I've heard this before but it strikes me as a fundamentally condescending view. I've found that most people, including junior developers, more than rise to the occasion as long as they're given trust, a real understanding of where the team is moving collectively and an environment where asking for help (or even direction!) feels comfortable and natural.
The problem is that this means you need leaders—managers or not—who are comfortable without an illusion of control or visibility and who understand how to lead and communicate effectively. And you really need this all the way up the chain. If you manage this, though, you'll be amazed at how productive even heavily junior teams can be.
The problem is that this means you need leaders—managers or not—who are comfortable without an illusion of control or visibility and who understand how to lead and communicate effectively. And you really need this all the way up the chain. If you manage this, though, you'll be amazed at how productive even heavily junior teams can be.
The illusion of control via rituals, status meetings, spreadsheets,JIRA, etc is a plague throughout the industry. Cargo cult and “making someone happy”. We do far too many thing simply because if you say you do it, your CTO / VP will be happy.
> these companies rely heavily on masses of junior/inexperienced developers. So they figure a strong management layer is necessary to properly direct the project's goals.
Development isn’t an assembly line process—and cannot possibly be. It’s about theory building and mental models. It requires experience.
It’s fine to have juniors, but they need to lean heavily on experienced colleagues. No amount of management and no management process can change that. A team where the juniors outnumber the seniors 3-to-1 is going to cost more money in the long run.
What you’re describing is exactly what I’m talking about when I say companies are unable to achieve this. Hire 3 senior people instead of 12 junior. You’ll get more done. Reduce your collaboration costs. But, as a manager, you get paid more if you manage more people, or if the people below you manage more people, so there’s a perverse incentive to build as much bureaucracy as possible and staff the lowest layers with the cheapest possible hires.
Development isn’t an assembly line process—and cannot possibly be. It’s about theory building and mental models. It requires experience.
It’s fine to have juniors, but they need to lean heavily on experienced colleagues. No amount of management and no management process can change that. A team where the juniors outnumber the seniors 3-to-1 is going to cost more money in the long run.
What you’re describing is exactly what I’m talking about when I say companies are unable to achieve this. Hire 3 senior people instead of 12 junior. You’ll get more done. Reduce your collaboration costs. But, as a manager, you get paid more if you manage more people, or if the people below you manage more people, so there’s a perverse incentive to build as much bureaucracy as possible and staff the lowest layers with the cheapest possible hires.
Well, yes, but that's also why most traditional companies are left for dead by the newer ones who are not doing that. The threat is existential and should be treated as such by the highest levels of management. The idea that they "can't" do it is just short-term thinking. A re-org is a big move and will upset the apple cart for a while, but not re-orging is often slow death.
Personally I'd almost always rather hire a single senior engineer and pay them what two juniors make. I suspect I won't get double the JIRA throughput, but will get more than double the actual effect on the product.
Personally I'd almost always rather hire a single senior engineer and pay them what two juniors make. I suspect I won't get double the JIRA throughput, but will get more than double the actual effect on the product.
Exactly. Notice scrum has no managers. There is no manager role in scrum. Yet companies still have managers? why? Makes no sense if you are really doing scrum right. How many companies actually implemented scrum and got rid of their managers?
Individuals and interactions over processes and tools
Anyone who says the Agile Manifesto and Scrum are not directly at odds is trying to sell you something.
Anyone who says the Agile Manifesto and Scrum are not directly at odds is trying to sell you something.
A lot of people misunderstand it, but what agile says is basically that "you should talk to each other more often" and "you should make smaller steps". So it's a YES from me.
If you never seen this, you should read this ASAP: https://agilemanifesto.org/
Because that's all there is to know about Agile. Obviously it takes a bit more time to really grasp how can you translate that to lines of code or building a deployment pipeline or shipping features, but if you understand these couple of lines, you already know enough about agile development.
If you never seen this, you should read this ASAP: https://agilemanifesto.org/
Because that's all there is to know about Agile. Obviously it takes a bit more time to really grasp how can you translate that to lines of code or building a deployment pipeline or shipping features, but if you understand these couple of lines, you already know enough about agile development.
I think Agile is best learnt by first failing a 1-million dollars Waterfall project.
“Kids today don’t know” what it feels like, explaining lawyers how you didn’t feel the wind turning after spending 9 months delivering layer 1 and 2 and crossing your fingers that layer 3 will be a wrap-up. Once you have seen that, the “less paperwork, more interactions”, the “add value not layers” become a relief ;)
“Kids today don’t know” what it feels like, explaining lawyers how you didn’t feel the wind turning after spending 9 months delivering layer 1 and 2 and crossing your fingers that layer 3 will be a wrap-up. Once you have seen that, the “less paperwork, more interactions”, the “add value not layers” become a relief ;)
I know what it feels like to fail a 2 million dollar agile project. Where do I go from there?
In today's culture, you should be a billionaire now.
But more seriously, "agile", what does it even mean? I almost posted this on another comment.
There is no, singular, agile beyond the manifesto. Everything else is a variation either attempting to push the goals and ideas of the manifesto or attempting to capitalize on fads.
Scrum is borderline fad (I'm ok on the concept, but I think employees should be paid not to go to most Scrum classes; most implementations are incredibly badly done like they deliberately misread the guide). SAFe is bullshit (the gov't bought into it though, how's that F-35 coming along again?).
XP had (has?) some seriously dogmatic advocates, but most people have learned it's a toolkit and not a thing to do without consideration.
Lean has always been presented as a philosophy and toolkit, at least as far as everything I've ever been able to find on it. I think there are some moronic certifications out there, skip them.
DevOps is Theory of Constraints for IT. Which is not a set of ceremonies to perform, but a way of viewing and trying to improve the system. Though, like with Lean, many people are apparently illiterate and fuck it up.
So the question becomes: what version of "agile" were you using? And did you do one of the most important thing that, as I noted in another comment, seems to be the most crucial common element of most of these (except SAFe, fuck SAFe): Did you actively set about to improve the way you worked as you worked? Did you frequently ask questions like: Is this working for us? Is this working for our customers? Is this the right process? Are these the right tools? Are we holding it right or should we try something different?
If introspection and reflection and periodic adjustments to not just the product but also the team (structure and dynamics) and processes aren't in play, then it's probably a ritualized version of agile which is only barely better than Waterfall.
But more seriously, "agile", what does it even mean? I almost posted this on another comment.
There is no, singular, agile beyond the manifesto. Everything else is a variation either attempting to push the goals and ideas of the manifesto or attempting to capitalize on fads.
Scrum is borderline fad (I'm ok on the concept, but I think employees should be paid not to go to most Scrum classes; most implementations are incredibly badly done like they deliberately misread the guide). SAFe is bullshit (the gov't bought into it though, how's that F-35 coming along again?).
XP had (has?) some seriously dogmatic advocates, but most people have learned it's a toolkit and not a thing to do without consideration.
Lean has always been presented as a philosophy and toolkit, at least as far as everything I've ever been able to find on it. I think there are some moronic certifications out there, skip them.
DevOps is Theory of Constraints for IT. Which is not a set of ceremonies to perform, but a way of viewing and trying to improve the system. Though, like with Lean, many people are apparently illiterate and fuck it up.
So the question becomes: what version of "agile" were you using? And did you do one of the most important thing that, as I noted in another comment, seems to be the most crucial common element of most of these (except SAFe, fuck SAFe): Did you actively set about to improve the way you worked as you worked? Did you frequently ask questions like: Is this working for us? Is this working for our customers? Is this the right process? Are these the right tools? Are we holding it right or should we try something different?
If introspection and reflection and periodic adjustments to not just the product but also the team (structure and dynamics) and processes aren't in play, then it's probably a ritualized version of agile which is only barely better than Waterfall.
Exactly. It's not agile until the process is one of the knobs you're willing to adjust. "Let us be agile according to this rigorously defined, unchangeable process" is self-contradictory.
Stop messing around and go waste 100 times that at on a federal project at Deloitte.
> I think Agile is best learnt by first failing a 1-million dollars Waterfall project.
Very high quality engineering work has been getting done ages before "agile" status-reporting was invented and it was often not waterfall (I've been around the industry since the 80s and have never done "waterfall" - the false dichotomy of agile vs. waterfall is a myth).
Very high quality engineering work has been getting done ages before "agile" status-reporting was invented and it was often not waterfall (I've been around the industry since the 80s and have never done "waterfall" - the false dichotomy of agile vs. waterfall is a myth).
I love how "Individuals and interactions over processes and tools" turned into "inscrutable processes and tools that take over individuals and interactions".
You can take anything and do it poorly. That's not the fault of the people who created it.
That site is horrendously dated. Here's a modern version of the same content: https://www.agilesoftwaremanifesto.com/
And here's a website describing how you're likely to see Agile implemented in The Real World (TM): https://www.halfarsedagilemanifesto.org/
Most of the problems seem to be not enough Agile!
Agile, as it’s practiced today is Jira driven disorganized waterfall, and has nothing to do with the OG agile principles.
Much like TDD, which works great when it’s dev driven, agile works great when it’s driven by dev team.
The problem happens when the PMs get involved and they have to schedule meetings to get basic status updates and have to implement their voodoo rituals to make it look like PMs are adding to project velocity. Planning Poker, lol.
It gets much worse on larger scope projects and many devs and PMs are inexperienced.
Much like TDD, which works great when it’s dev driven, agile works great when it’s driven by dev team.
The problem happens when the PMs get involved and they have to schedule meetings to get basic status updates and have to implement their voodoo rituals to make it look like PMs are adding to project velocity. Planning Poker, lol.
It gets much worse on larger scope projects and many devs and PMs are inexperienced.
Oh, man, you haven't seen Jira driven disorganized waterfall until you've seen SAFe -- Scaled Agile Framework. Basically Agile with cement shoes, for organizations that are scared to do anything without getting it countersigned in triplicate.
I love how there is an ongoing war between "the old guards" of agile and SAFe. Look up some of the rants, it's a great read. Certificate peddlers flaming each other.
SAFe has a great, telling name though - it's designed to be safe for corporate control freaks. They might not know waterfall, they just live it in their guts.
Easy to identify, they believe in being a "visionary leader" and "inspiring the lower rank".
SAFe has a great, telling name though - it's designed to be safe for corporate control freaks. They might not know waterfall, they just live it in their guts.
Easy to identify, they believe in being a "visionary leader" and "inspiring the lower rank".
The dev team can absolutely never drive a business process. Developers don't work with customers, don't measure revenue, don't do marketing. Scrum exists to facilitate clear communication about requirements in the smallest deliverable increments. Devs should be fully bought in and involved in decision making but product mangers have to be there to do discovery and set priorities. PMs are there to facilitate and measure progress which can mostly be done just by keeping tickets up to date.
If you have an inexperienced team, any process you adopt is going to suck.
If you have an inexperienced team, any process you adopt is going to suck.
As a dev I have spoken directly with customers in multiple projects, but based on mentioning revenue/marketing it seems you're coming from a consumer focus and not b2b implementations? It seems to be a common perspective on this site but it's not the only one.
Talking with a customer was great when we could, usually it's been when I worked in a small team (1-3 developers), speaking with either internal or external customers. We talk through what is needed then the BA/PM documents it in the updated job brief, rather than the other way around which leads to so much back and forth. It gets to the root of any uncertainty about what they want much quicker.
This is not any official brand of Agile. It's just our natural inclination when left alone. Talk, iterate, deliver.
Talking with a customer was great when we could, usually it's been when I worked in a small team (1-3 developers), speaking with either internal or external customers. We talk through what is needed then the BA/PM documents it in the updated job brief, rather than the other way around which leads to so much back and forth. It gets to the root of any uncertainty about what they want much quicker.
This is not any official brand of Agile. It's just our natural inclination when left alone. Talk, iterate, deliver.
I agree with everything you say. Part of the problem is PMs and the scrum masters with certificates and no technical experience run the show and play presenter/jira manager. Most of the time they have no idea what's going on and are glorified backwatchers.
I'd rather have multiple Sr. Devs be half time management, and half time dev. Or increase Sr. Dev pay by 20-30% and have them pick up management on top of their duties.
I'd rather have multiple Sr. Devs be half time management, and half time dev. Or increase Sr. Dev pay by 20-30% and have them pick up management on top of their duties.
I hate the term sprints. The idea is good but the term is horribly inaccurate. Sprint makes it seem like its a quick dash to the finish line and then its over. But the work is never over. One sprint ends and the next one starts immediately after. Work is not a sprint, its a marathon.
Sprints conceptually make sense. We have 3 features we want to develop. Lets aim to complete them in the next 2-3 weeks. I like them so long as the goals are extremly well defined and managed. Too many teams though forget the agile aspect of agile development. If there's a change to the priorities, its often poorly communicated or just added to the sprint without removing anything.
Daily Standups, as practiced by most teams, are a waste of time. They become status updates for the Project Manager or Team Leader.
What would be better is for engineers to use the time to review ideas, issues that have cropped up and ask questions about the codebase or specific issues. This is probably what a standup is supposed to be but when its mixed in with the context of status updates, it always takes a back seat.
Pointing is a complete waste of time. I have no idea how long a ticket is going to take until I start working on it. Estimations are usually wrong anyway. If anything, tickets should be pointed once the work is complete to track a teams acutal performance and velocity (output).
Having the team review tickets for the next sprint (sprint planning) is useful for inital discovery (so long as it doesn't involve pointing). One person on your team might know how to solve a bug ticket or know if a feature ticket is deceptively difficult. That discovery process can be extremely valuable.
Overall agile ideas I think do help more than they hurt but not always and not by much.
Sprints conceptually make sense. We have 3 features we want to develop. Lets aim to complete them in the next 2-3 weeks. I like them so long as the goals are extremly well defined and managed. Too many teams though forget the agile aspect of agile development. If there's a change to the priorities, its often poorly communicated or just added to the sprint without removing anything.
Daily Standups, as practiced by most teams, are a waste of time. They become status updates for the Project Manager or Team Leader.
What would be better is for engineers to use the time to review ideas, issues that have cropped up and ask questions about the codebase or specific issues. This is probably what a standup is supposed to be but when its mixed in with the context of status updates, it always takes a back seat.
Pointing is a complete waste of time. I have no idea how long a ticket is going to take until I start working on it. Estimations are usually wrong anyway. If anything, tickets should be pointed once the work is complete to track a teams acutal performance and velocity (output).
Having the team review tickets for the next sprint (sprint planning) is useful for inital discovery (so long as it doesn't involve pointing). One person on your team might know how to solve a bug ticket or know if a feature ticket is deceptively difficult. That discovery process can be extremely valuable.
Overall agile ideas I think do help more than they hurt but not always and not by much.
> Pointing is a complete waste of time. I have no idea how long a ticket is going to take until I start working on it. Estimations are usually wrong anyway. If anything, tickets should be pointed once the work is complete to track a teams acutal performance and velocity (output).
It's a complete waste of time for developers, but unfortunately the rest of the company might need to have an idea how long something might take because they need to sell products or services, and get return on investment.
It's really hard to sell people on "we will do these features/this project, but we have no idea how long it will take so just pay us until it's done". It's much easier to work on your estimations until they always get a little over-estimated, and then sell those estimations to the people paying the bills.
It's a complete waste of time for developers, but unfortunately the rest of the company might need to have an idea how long something might take because they need to sell products or services, and get return on investment.
It's really hard to sell people on "we will do these features/this project, but we have no idea how long it will take so just pay us until it's done". It's much easier to work on your estimations until they always get a little over-estimated, and then sell those estimations to the people paying the bills.
I disagree. Most tickets my team points (using fibonacci) end up as a 5 or an 8. Sometimes we have something that's a 2 (like a config update or a one liner) but the majority of the time its a 5 or an 8. In fact, we often say if something is above a 13, it needs to be split into more tickets where each would likely be a 5 or an 8.
What would be far better is if in sprint planning, tickets were properly split into blockers and improvements (effectively the same as needs vs wants).
Its up to you and your team to help the PM understand what is likely to be completed in a given sprint between the needs and wants and what will rollover to the next (maybe some of those needs are actually wants, and some of those wants are actually needs - this is part of what sprint planning should involve). Part of that is also the PM communicating what needs to get done (and vice versa). Pointing is just a more arbitrary and lengthy means of having that conversation.
Sprint planning is useful, pointing does nothing. If a blocker ticket is in the current sprint there should be a good faith assumption that it will be taken care of. If something happens putting that deliverable at risk, that's where the line 'people over processes' matters more and you have to communicate what issues are preventing the team from completing the blocker.
I guess I'm trying to say. Pointing as a process is a waste of time and the information it conveys can be conveyed more efficiently with good communication with your PM and team and a decent amount of trust between engineering and external teams.
What would be far better is if in sprint planning, tickets were properly split into blockers and improvements (effectively the same as needs vs wants).
Its up to you and your team to help the PM understand what is likely to be completed in a given sprint between the needs and wants and what will rollover to the next (maybe some of those needs are actually wants, and some of those wants are actually needs - this is part of what sprint planning should involve). Part of that is also the PM communicating what needs to get done (and vice versa). Pointing is just a more arbitrary and lengthy means of having that conversation.
Sprint planning is useful, pointing does nothing. If a blocker ticket is in the current sprint there should be a good faith assumption that it will be taken care of. If something happens putting that deliverable at risk, that's where the line 'people over processes' matters more and you have to communicate what issues are preventing the team from completing the blocker.
I guess I'm trying to say. Pointing as a process is a waste of time and the information it conveys can be conveyed more efficiently with good communication with your PM and team and a decent amount of trust between engineering and external teams.
You say that pointing is a waste of time, but also say that you don’t want something bigger than a 13. If you don’t do the pointing when do you realise the ticket is too big?
The points are purely to get an indicative size of the work, so it is clear work will be done in the next iteration (e.g. 3 weeks).
If other teams within your organisation need to know when an item is likely to be completed then accurate estimation is useful.
The points are purely to get an indicative size of the work, so it is clear work will be done in the next iteration (e.g. 3 weeks).
If other teams within your organisation need to know when an item is likely to be completed then accurate estimation is useful.
I just don’t understand using Fibonacci... seems like they arbitrarily picked a “tech” sequence with a cool name to seem more legit or something. But 1-10 would do just as well in my book, with 10 being roughly the amount of effort and the number of days in the sprint... so the things should add up to 10 for a full sprints work.
There are many things about the Scaled Agile Framework(Safe) I don't like, but rebranding sprints to iterations is something that I really like. It's not about being faster, it's just about time-boxing development activities and making planning, communication, demoing and retrospection a routine part of your team activities within that time-box.
Totally agree, the goal is to timebox features and tickets.
If the feature or task takes longer than the allotted time, you get to be agile and reevaluate if you should continue on the feature (does it need just a bit more work) or if its something to come back to in the next cycle.
Just like you say. If something takes longer than expected in the sprint, the retro is the time to call it out, review what happened that made the ticket take longer than expected and share your learnings with the team so everyone is aware of that particular aspect and knows to look out for it next time (maybe it was waiting on another team that blocked you, an unseen complexity, a changing requirement etc).
If the feature or task takes longer than the allotted time, you get to be agile and reevaluate if you should continue on the feature (does it need just a bit more work) or if its something to come back to in the next cycle.
Just like you say. If something takes longer than expected in the sprint, the retro is the time to call it out, review what happened that made the ticket take longer than expected and share your learnings with the team so everyone is aware of that particular aspect and knows to look out for it next time (maybe it was waiting on another team that blocked you, an unseen complexity, a changing requirement etc).
> We have 3 features we want to develop. Lets aim to complete them in the next 2-3 weeks.
I never actually saw it that way. It's more like we know the velocity of the team is about 25 to 30 points based on past estimations. The team has estimated the following stories and the product owner decides which stories he'd like to see implemented. So he picks a few stories totaling 30 points with the knowledge that it may not get done. And that's supposed to be OK. The more and longer you estimate with the same people, the closer the estimations come to reality. So he has 3 stories totaling 30 points, he definitely wants 2 of them to be finished so he puts them at the top - if the third one doesn't finish then that's too bad but it should be close to done at least.
I've never worked nights just because a PO decided he needed a feature in the sprint. But I'm also the type of developer to say something like alright you want this feature in the sprint that's going on? Sure pick one that's going out or I can assure you it's not going to be finished. I'm not trying to be a dick, but just communicating and managing expectations.
I never actually saw it that way. It's more like we know the velocity of the team is about 25 to 30 points based on past estimations. The team has estimated the following stories and the product owner decides which stories he'd like to see implemented. So he picks a few stories totaling 30 points with the knowledge that it may not get done. And that's supposed to be OK. The more and longer you estimate with the same people, the closer the estimations come to reality. So he has 3 stories totaling 30 points, he definitely wants 2 of them to be finished so he puts them at the top - if the third one doesn't finish then that's too bad but it should be close to done at least.
I've never worked nights just because a PO decided he needed a feature in the sprint. But I'm also the type of developer to say something like alright you want this feature in the sprint that's going on? Sure pick one that's going out or I can assure you it's not going to be finished. I'm not trying to be a dick, but just communicating and managing expectations.
Start calling each sprint "the stroll".
I love this haha, maybe I'll propose it to my team tomrrow
We had weekly sprints one time, the amount of overhead was insane. Even the manifesto says to integrate your working software anywhere from a couple of weeks to months, depending on your situation.
Eh? Integration of software in scrum is the one thing that's really dated these days.
We integrate software every commit.
We integrate software every commit.
We had daily builds but they tended to be broken. This is life in many places :)
They did proper integration point releases between teams at various phases, it was more an issue with 1 week sprints to close off tasks resulting in so much overhead that I felt like I was just building momentum and had to stop and gather my thoughts for the retro and planning. We'd essentially lose one work day out of every five.
They did proper integration point releases between teams at various phases, it was more an issue with 1 week sprints to close off tasks resulting in so much overhead that I felt like I was just building momentum and had to stop and gather my thoughts for the retro and planning. We'd essentially lose one work day out of every five.
I’m a little less zealous in my dislike of it. It’s not that the process itself is “bad”, the ideals behind it make sense. In practice (my own experience) it easily degrades into what I call “fake work”— you feel like you’re doing lots of productive measurement and estimation by drawing nice little boxes around projects, but projects rarely ever work this way. The one thing I see constantly is moving on to the next project because we checked off all the agile boxes, without giving much care to maintenance. There is always maintenance work, and it’s very easy to turn a blind eye to.
Something I consider maintenance work is refactoring of systems as new projects are planned/implemented. Everyone knows it’s a bad idea to just bolt on more and more “feature” work without thinking systemically, then we all point at “systemic” issues in retrospective meetings.
Again though, I’m not losing any sleep over this it’s just an observation from 9 years of experience as a web developer working for mostly SV tech companies large and small. It won’t be everyone’s experience, and in general the best advice I can give is try to come up with solutions using your own experience and opinions over those people implicitly/explicitly tell you to follow because they are “good”.
Something I consider maintenance work is refactoring of systems as new projects are planned/implemented. Everyone knows it’s a bad idea to just bolt on more and more “feature” work without thinking systemically, then we all point at “systemic” issues in retrospective meetings.
Again though, I’m not losing any sleep over this it’s just an observation from 9 years of experience as a web developer working for mostly SV tech companies large and small. It won’t be everyone’s experience, and in general the best advice I can give is try to come up with solutions using your own experience and opinions over those people implicitly/explicitly tell you to follow because they are “good”.
> Something I consider maintenance work is refactoring of systems as new projects are planned/implemented. Everyone knows it’s a bad idea to just bolt on more and more “feature” work without thinking systemically, then we all point at “systemic” issues in retrospective meetings.
When the great CPU architect Stephen Keller was on Lex Fridman's podcast, he made a comment that architectures should be refactored every 5 years and I thought to myself, "Good luck with that in Enterprise" as I looked over at the 10+ year old legacy infrastructure holding back org-level velocity at work
When the great CPU architect Stephen Keller was on Lex Fridman's podcast, he made a comment that architectures should be refactored every 5 years and I thought to myself, "Good luck with that in Enterprise" as I looked over at the 10+ year old legacy infrastructure holding back org-level velocity at work
oof every FIVE years is an eternity in software years. Maybe I have been working alone for too long while between jobs, but it just feels so much better to listen to all of your hunches about it being refactor time than to ignore them for the sake of functionality. It's just not possible to act on the hunch later when you have lost that important deep context and hastily added twelve other things too.
Tbf he was specifically thinking of CPU archs but at "Enterprise Scale" might as well be talking 10 years. Personally, from your comment, I'm learning to just stop giving a fuck and apply the (obvious, cause, you know, you've been looking at it for 5 years at least) re-factor regardless
I was a big believer 15 years ago, then became heavily disillusioned, and now have a pretty pragmatic view of it. It can help, if you don't know what you're doing at all it's a good framework to start. I feel like the Kanban approach where the team takes ownership of their process is a good one. There's a lot of great stuff in there about communicating as a team, and thinking about the customer.
Too often though in practice it devolves into a kind of cargo cult and the apologists lean way too hard into the "if it isn't working, you must not have believed in it hard enough" defense which is a bit too easy in my opinion. It short circuits any actual reflection and learning.
Basically, the agile manifesto is great.. the stuff agile coaches try to sell you is hot garbage. Everything else is somewhere in the middle, but Kanban is the closest because it preserves the "we are uncovering" part of the manifesto.
Too often though in practice it devolves into a kind of cargo cult and the apologists lean way too hard into the "if it isn't working, you must not have believed in it hard enough" defense which is a bit too easy in my opinion. It short circuits any actual reflection and learning.
Basically, the agile manifesto is great.. the stuff agile coaches try to sell you is hot garbage. Everything else is somewhere in the middle, but Kanban is the closest because it preserves the "we are uncovering" part of the manifesto.
If you think agile/scrum is bureaucratic try this thing called "SAFe".
But in all seriousness - scrum as it is practiced today is not beneficial. It's mostly used for "accountability" rather than the "collaborative/communication" mechanism that it was supposed to be. Add into that situations where product/program management questions every little estimation decision (e.g. do you really need those system guarantees? can we leave automated testing out of the MVP to reduce story points).
Agile has been corporatized (if such a word exists) and is no longer "agile".
But in all seriousness - scrum as it is practiced today is not beneficial. It's mostly used for "accountability" rather than the "collaborative/communication" mechanism that it was supposed to be. Add into that situations where product/program management questions every little estimation decision (e.g. do you really need those system guarantees? can we leave automated testing out of the MVP to reduce story points).
Agile has been corporatized (if such a word exists) and is no longer "agile".
SAFe always makes me laugh with its diagram for "lean" enterprises.
https://www.scaledagileframework.com/wp-content/uploads/2021...
https://www.scaledagileframework.com/wp-content/uploads/2021...
Oh my goodness. The actual people doing the work are not labeled on that diagram. It's just an anonymous icon of heads. If that doesn't tell you everything...
that is the most confusing diagram I've seen in a long time, thanks for sharing.
The process isn't a silver bullet. I've worked on scrum agile projects for 5 years at a consultancy, for a variety of projects and clients, so I've seen it work and I've seen it not work.
Scrum agile works when...
- People keep standup updates short and sweet, so standups take 15 minutes or less.
- Your team has a single product owner who speaks to customers and is empowered to make decisions.
- Team members invest time and energy into backlog grooming/refinement, ensuring stories are thorough and have good requirements.
- The team retros regularly to address issues.
- The team communicates often outside of the regular ceremonies, so that meetings stay focused.
Scrum works poorly when...
- Standups turn into 30 minute to 1 hour "status" meetings where everyone brings up every question they have.
- The product owner isn't empowered to make decisions, or your team has multiple product owners who decide by committee.
- Team members are disengaged or not even consulted during backlog refinement, and stories are missing critical requirements that you have to deal with in the middle of the sprint.
- Retros get cut because "there's not enough time".
- Nobody talks outside of the regular ceremonies, so meetings drag on forever.
Scrum agile doesn't work for every organization and every project. Sometimes company culture is too hard to change. Sometimes the work you're doing can't really be done in an agile way. Sometimes the organizational structure makes it hard for a scrum team to work without consulting multiple layers of bureaucracy. (That's my project right now, and it is NOT fun.) When that happens, you have to either relax the rules of scrum (being careful to avoid the pitfalls I mentioned above), or adopt a different process altogether.
Scrum agile works when...
- People keep standup updates short and sweet, so standups take 15 minutes or less.
- Your team has a single product owner who speaks to customers and is empowered to make decisions.
- Team members invest time and energy into backlog grooming/refinement, ensuring stories are thorough and have good requirements.
- The team retros regularly to address issues.
- The team communicates often outside of the regular ceremonies, so that meetings stay focused.
Scrum works poorly when...
- Standups turn into 30 minute to 1 hour "status" meetings where everyone brings up every question they have.
- The product owner isn't empowered to make decisions, or your team has multiple product owners who decide by committee.
- Team members are disengaged or not even consulted during backlog refinement, and stories are missing critical requirements that you have to deal with in the middle of the sprint.
- Retros get cut because "there's not enough time".
- Nobody talks outside of the regular ceremonies, so meetings drag on forever.
Scrum agile doesn't work for every organization and every project. Sometimes company culture is too hard to change. Sometimes the work you're doing can't really be done in an agile way. Sometimes the organizational structure makes it hard for a scrum team to work without consulting multiple layers of bureaucracy. (That's my project right now, and it is NOT fun.) When that happens, you have to either relax the rules of scrum (being careful to avoid the pitfalls I mentioned above), or adopt a different process altogether.
I had to scroll down quite a lot to find a comment that matches with my experience of scrum (the part where you describe when it works).
Good points!
Definitely my biggest gripe is story points + estimations. It's just completely flawed. We should be thinking more probabilistic (i.e. there's an 80% chance we'll get this done in 2 weeks). We should be doing that by running actual models on past work rather than gut feelings.
If you want to listen to a couple of guys I used to work with who really know what they are talking about, check out this series: https://www.youtube.com/channel/UC758reHaPAeEixmCjWIbsOA/vid...
If you want to listen to a couple of guys I used to work with who really know what they are talking about, check out this series: https://www.youtube.com/channel/UC758reHaPAeEixmCjWIbsOA/vid...
I remember noticing this on my first frontend job 5 years ago. How are in hell are they accurately measuring any kind of performance? I'm sure it can actually be done but enterprise half-asses even that, likely because keeping it all slightly arbitrary allows for more ambiguity to leverage against workers (keeps them paranoid rather than certain, elites don't like safety amongst workers).
> How are in hell are they accurately measuring any kind of performance?
You aren't, and that's the grift.
I force developers to do something they are bad at. They get better, but they're never 'great' at it. So I can withhold raises they deserve because I'm punishing them for what they're not good at instead of rewarding them for what they are great at.
You aren't, and that's the grift.
I force developers to do something they are bad at. They get better, but they're never 'great' at it. So I can withhold raises they deserve because I'm punishing them for what they're not good at instead of rewarding them for what they are great at.
It’s not a measurement tool though - it’s tool for self-calibration. If anyone outside the software team sees those estimates then the process is broken. Doubly so if they’re tied to any performance evaluation.
Well, but that's what actually happens everywhere. The estimates are not for the team itself, but used for managers and the company. Even in the comments here it was justified as "the company needs to know that to sell it to customers".
So reality trumps ideals.
So reality trumps ideals.
> It’s not a measurement tool though - it’s tool for self-calibration.
This was my complaint of the term “velocity” because it sounds objective and absolute when it’s really much more arbitrary and not even comparable to the same team from year to year.
This was my complaint of the term “velocity” because it sounds objective and absolute when it’s really much more arbitrary and not even comparable to the same team from year to year.
Exactly, and since there's no human whose job is to figure out the ontology of dev work...
I've wondered how well it would work to just have everyone on the team anonymously estimate what percentage of the project (or sprint, etc) is complete.
But I think that would get thrown out at the first sign of trouble. In many companies if the anonymous survey showed we were behind schedule the fix would be to stop doing the anonymous surveys.
But I think that would get thrown out at the first sign of trouble. In many companies if the anonymous survey showed we were behind schedule the fix would be to stop doing the anonymous surveys.
That's why Kanban with throughput/cycle-time makes so much more sense.
https://owenmccall.com/high-performance-role-process-vs-outc...
This article gave me clarity between the two philosophies. Kanban is about perfecting the process and trusting that results will naturally come as a result of that process. Agile is about attaining the outcomes and then focusing on what works for those outcomes.
I agree that Kanban makes more sense but Agile allows managers to point the finger at devs instead of having to point the finger at themselves.
This article gave me clarity between the two philosophies. Kanban is about perfecting the process and trusting that results will naturally come as a result of that process. Agile is about attaining the outcomes and then focusing on what works for those outcomes.
I agree that Kanban makes more sense but Agile allows managers to point the finger at devs instead of having to point the finger at themselves.
I understand your gripe but in a business setting you need some estimate of cost, even if it's on the order of hours, days, weeks etc. In my experience it's often cheaper to just get stuck in rather than trying to accurately predict the effort, since a single developer prototyping some solution for 10 hours goes further than 10 developers in a meeting for an hour. I'd say call a spade a spade, and put time estimates on these tasks, and admit that velocity is a measure of your bias (if you correctly estimate it will always be 1).
What really gets me about story points are the Agile folks who say "story points are a measure of complexity not effort/time". As if adding more complexity in the same amount of time were a good thing...
What really gets me about story points are the Agile folks who say "story points are a measure of complexity not effort/time". As if adding more complexity in the same amount of time were a good thing...
Probabilities would be estimates of costs too, they are just less naive ones.
Big surprise to most people: The purpose of estimating is not to come up with an estimate.
In a team of five, we might get 2,5,8,8,20. The value of the estimation was in discovering that someone thinks it's a 20, while someone else thinks it's a 2. They tell the rest of the team why, and we estimate again. Another useful signal is ?,?,?,?,? or (50,50,50,50,50). And of course, 5,5,5,8,8 (or other general agreement) suggests that this is low risk.
You certainly wont hear that from a scrum consultant.
In a team of five, we might get 2,5,8,8,20. The value of the estimation was in discovering that someone thinks it's a 20, while someone else thinks it's a 2. They tell the rest of the team why, and we estimate again. Another useful signal is ?,?,?,?,? or (50,50,50,50,50). And of course, 5,5,5,8,8 (or other general agreement) suggests that this is low risk.
You certainly wont hear that from a scrum consultant.
> Definitely my biggest gripe is story points + estimations. It's just completely flawed. We should be thinking more probabilistic (i.e. there's an 80% chance we'll get this done in 2 weeks). We should be doing that by running actual models on past work rather than gut feelings.
Why? If you made those more detailed estimates and models (which I'm sure would have a significant time cost), what would you do differently based on the results of them?
You need a rough sense of how relatively costly different tasks are, so that you can prioritise - if you ask the business/product side to prioritise completely blind, you'll end up not doing small things that could have brought a lot of value because they assume those things are hard, and you'll spend far too long doing things that they thought would be easy but are actually hard. So you want developers to do just enough estimation to allow the business to prioritise. Which means giving a low-detail estimate and giving developers assurance that it won't be used as a deadline. Story points are the most effective version I've seen.
(I don't watch videos, I'd be happy to read text articles)
Why? If you made those more detailed estimates and models (which I'm sure would have a significant time cost), what would you do differently based on the results of them?
You need a rough sense of how relatively costly different tasks are, so that you can prioritise - if you ask the business/product side to prioritise completely blind, you'll end up not doing small things that could have brought a lot of value because they assume those things are hard, and you'll spend far too long doing things that they thought would be easy but are actually hard. So you want developers to do just enough estimation to allow the business to prioritise. Which means giving a low-detail estimate and giving developers assurance that it won't be used as a deadline. Story points are the most effective version I've seen.
(I don't watch videos, I'd be happy to read text articles)
I wonder how much more accurate estimations would be if we had engineers actually draw probability curves that are then aggregated and analyzed. As it stands now, having had some experience getting burned, I always give my estimate that's really at the tail end, and I have become exceedingly efficient at explaining why that estimate is how long it will "really take."
Estimates somehow magically become commitments. Like, if you don't make it in the estimated time, it's your fault, you should have estimated bettter.
Okay, so suppose my best guess is that there is a 10% chance something could be done in a day, 80% chance it would take two or three days, and 10% chance it would take five days. What is supposed to be my "estimate"?
If I keep giving the longest time interval, I will seem like lazy and incompetent, because why am I always saying "five days" to tasks that everyone knows usually take only two or three days. But if I say "three days", then in those 10% when it actually takes five days, I have estimated wrongly.
In a long sprint, this will usually average out somehow; one "three-day" task will take five days, another "three-day" task will take one day. In a short spring, things are less predictable.
(yeah, technically it's not days, it's story points, but the idea is still that "medium complexity" only means "medium complexity unless something unexpected happens" and the unexpected things sometimes do happen, you can't simply commit to unexpected things never happening.)
Okay, so suppose my best guess is that there is a 10% chance something could be done in a day, 80% chance it would take two or three days, and 10% chance it would take five days. What is supposed to be my "estimate"?
If I keep giving the longest time interval, I will seem like lazy and incompetent, because why am I always saying "five days" to tasks that everyone knows usually take only two or three days. But if I say "three days", then in those 10% when it actually takes five days, I have estimated wrongly.
In a long sprint, this will usually average out somehow; one "three-day" task will take five days, another "three-day" task will take one day. In a short spring, things are less predictable.
(yeah, technically it's not days, it's story points, but the idea is still that "medium complexity" only means "medium complexity unless something unexpected happens" and the unexpected things sometimes do happen, you can't simply commit to unexpected things never happening.)
Estimating a single task is only really important to keep your cycle time in check and have the conversation about "should this task be broken down?"
Estimations from engineers shouldn't be used to forecast when a feature will really be done. That's where the model comes in and probabilities comes in.
Estimations from engineers shouldn't be used to forecast when a feature will really be done. That's where the model comes in and probabilities comes in.
Interestingly, the Manifesto for Agile Software Development never mentions estimation. Yet it is a big part of Scrum. Measuring accuracy in estimation is a big part of tooling for Agile project management. But should it be?
I think this is suspicious. It smuggles things from the Old Ways into Agile. Estimation sucked, to a fatal extent, when trying to do critical path analysis of software projects. Why should it suck less in Scrum?
The manifesto mentions retrospectives. Retrospectives have hard reliable data. You can learn from retrospectives. Estimation is unreliable. Would project outcomes actually differ with less emphasis on estimation? Would they improve with more emphasis on retrospectives?
I think this is suspicious. It smuggles things from the Old Ways into Agile. Estimation sucked, to a fatal extent, when trying to do critical path analysis of software projects. Why should it suck less in Scrum?
The manifesto mentions retrospectives. Retrospectives have hard reliable data. You can learn from retrospectives. Estimation is unreliable. Would project outcomes actually differ with less emphasis on estimation? Would they improve with more emphasis on retrospectives?
Yes, exactly.
The Mythical Man Month was written 45 years ago.
And since then we have gone from bad to worse.
Story points are even worse than man-months at measuring work.
Because in scrum not only is the assumption that the estimate for a task holds not matter who and how many works on it, but dependencies are also not handled well for either tasks or backlog items. To some extent a team can try to handle it in a sprint, but it is not part of the estimation.
For example it can be a lot faster if the same developers can work on corresponding frontend and backend jobs. If they are split in different sprints or if the developers also have to work on other tasks, it could take a lot longer.
And the whole story points, fibonacci, etc is just nonsense. If an experienced developer estimates that a given job would take somewhere between 10 days and two months, depending if they can reuse X and the Y algorithms performs if he and developer Z works on it, then that is the best estimate you will get.
The only thing that makes scrum estimates more precise, is that once you have broken everything into 100 tiny tasks, you have added about 20 hours of writing commit messages, updating JIRA, and preparing for the next task.
Story points are even worse than man-months at measuring work.
Because in scrum not only is the assumption that the estimate for a task holds not matter who and how many works on it, but dependencies are also not handled well for either tasks or backlog items. To some extent a team can try to handle it in a sprint, but it is not part of the estimation.
For example it can be a lot faster if the same developers can work on corresponding frontend and backend jobs. If they are split in different sprints or if the developers also have to work on other tasks, it could take a lot longer.
And the whole story points, fibonacci, etc is just nonsense. If an experienced developer estimates that a given job would take somewhere between 10 days and two months, depending if they can reuse X and the Y algorithms performs if he and developer Z works on it, then that is the best estimate you will get.
The only thing that makes scrum estimates more precise, is that once you have broken everything into 100 tiny tasks, you have added about 20 hours of writing commit messages, updating JIRA, and preparing for the next task.
I see probabilistic accounting for unknowns. An 80% chance would have some a small amount of unknown, so if the task was 3 points, I would bump it to a 5 to account for the known. And, since points are not linear, the larger task automatically grows proportionally, i.e. 8 -> 13.
Points are flawed. Whether you have them grow linear, exponentially, or fibonacci doesn't make a difference. The fundamentals are flawed. They cover it in their videos and in more depth their talks/books.
Monte Carlo estimations and probabilistic estimates take longer to do.
I don't know how they do it, but you used to have to group stories to stories of similar effort done in the past in order for the simulation to take into account story size. Otherwise your model will be effected by things like stories in different components taking more effort to do.
Putting stories into rough size pots is essentially what pointing is.
I don't know how they do it, but you used to have to group stories to stories of similar effort done in the past in order for the simulation to take into account story size. Otherwise your model will be effected by things like stories in different components taking more effort to do.
Putting stories into rough size pots is essentially what pointing is.
> Besides being a dream for micromanagers
I really don't get how people come to this conclusion about scrum. The alternative to scrum is the Project manager dictator regime, the literal micromanagers dream, where the pm can at any time jump by your desk and say "drop everything you are doing, and do this thing for me right now", and where the estimates are just whatever the PM decides to communicate, but when you fail to deliver a fully functional product in the 2 months the PM pulled out of thin air, it's somehow your fault.
In Scrum, the PO should be prevented from micromanaging, since he's not telling anyone what to do. There's a product backlog which the PO can prioritize sure, but that's the level of interaction. The team pulls work into the iteration backlog, so nothing should be picked up that the team doesn't agree to do. And each individual team member picks tasks from the iteration backlog, so nothing should be forced upon you. As for the daily stand-ups there should be no management in that meeting, it's a 15 minut maximum meeting between only those who have items in the spring back-log, which most often should not include the PO. If it's turning into a day-by-day status meeting you need your Scrum Master to step in. The board and iteration deliveries should be enough status to go by.
I really don't get how people come to this conclusion about scrum. The alternative to scrum is the Project manager dictator regime, the literal micromanagers dream, where the pm can at any time jump by your desk and say "drop everything you are doing, and do this thing for me right now", and where the estimates are just whatever the PM decides to communicate, but when you fail to deliver a fully functional product in the 2 months the PM pulled out of thin air, it's somehow your fault.
In Scrum, the PO should be prevented from micromanaging, since he's not telling anyone what to do. There's a product backlog which the PO can prioritize sure, but that's the level of interaction. The team pulls work into the iteration backlog, so nothing should be picked up that the team doesn't agree to do. And each individual team member picks tasks from the iteration backlog, so nothing should be forced upon you. As for the daily stand-ups there should be no management in that meeting, it's a 15 minut maximum meeting between only those who have items in the spring back-log, which most often should not include the PO. If it's turning into a day-by-day status meeting you need your Scrum Master to step in. The board and iteration deliveries should be enough status to go by.
I guess one reason why some people think this is because there are so many ways to still basically have the project manager dictator regime, as you called it, but just call it scrum/agile. E.g. everything is p0.
Daily standup could be a good idea if it was strictly bounded in time (15 min) and planned about noon when productivity usually drops and it is less likely to disrupt everyone's work.
As for sprints: for a few months I have been in a team where there are strictly applied. There is so much time lost: basically the sprint is either too short or too long. After a few "failed" sprints time estimations will become very conservative giving a lot of slack. Personally I am not comfortable with so much slack, it undermines my motivation.
In my experience anyway, as pressure increases sprints are less strictly enforced, for the sake of efficiency. Also approaching delivery the software has become quite complex and bugs tend to be complex has well, hard to estimate precisely. The fact that sprints do not hold under pressure is an indication they are not suitable for SW development.
There is also much time lost in the 2-3 days preparing for the next sprint, because we just cannot spend full days on meetings, for both human and material reasons. Those days are only "half worked".
As for sprints: for a few months I have been in a team where there are strictly applied. There is so much time lost: basically the sprint is either too short or too long. After a few "failed" sprints time estimations will become very conservative giving a lot of slack. Personally I am not comfortable with so much slack, it undermines my motivation.
In my experience anyway, as pressure increases sprints are less strictly enforced, for the sake of efficiency. Also approaching delivery the software has become quite complex and bugs tend to be complex has well, hard to estimate precisely. The fact that sprints do not hold under pressure is an indication they are not suitable for SW development.
There is also much time lost in the 2-3 days preparing for the next sprint, because we just cannot spend full days on meetings, for both human and material reasons. Those days are only "half worked".
> Daily standup could be a good idea if it was strictly bounded in time (15 min)
I'd say this is almost necessary, unless you have a small team that have been working together for a good amount of time, understand the project, and have lots of agile experience. Otherwise, it goes from a status update, to a drawn-out meeting where everyone's got a different agenda, nobody's paying attention to anyone but themselves (count the number of times you hear "sorry, I didn't catch that" when someone's asked a question directly during your next "stand up").
I also find it's really useful to use your kanban/sprint board to direct standup, instead of having each develop take a turn at talking. Going from right-to-left, asking what's changed with each ticket since yesterday, and if there's anything that's blocking progress today.
I'd say this is almost necessary, unless you have a small team that have been working together for a good amount of time, understand the project, and have lots of agile experience. Otherwise, it goes from a status update, to a drawn-out meeting where everyone's got a different agenda, nobody's paying attention to anyone but themselves (count the number of times you hear "sorry, I didn't catch that" when someone's asked a question directly during your next "stand up").
I also find it's really useful to use your kanban/sprint board to direct standup, instead of having each develop take a turn at talking. Going from right-to-left, asking what's changed with each ticket since yesterday, and if there's anything that's blocking progress today.
For most of my career I did well with no daily meeting. Team meeting was 1-2 hours weekly and I quite liked that rhythm. When I was blocked or short of work I would talk to coworkers or my manager. So maybe stand-ups are targeted at less autonomous people, but overall I find this a bit childish.
Of course there is once in a while a "wait wait wait I have already encountered this issue" and someone can help another, but it is rather rare and half the time it is a false alarm because as you said people do not pay much attention.
Of course there is once in a while a "wait wait wait I have already encountered this issue" and someone can help another, but it is rather rare and half the time it is a false alarm because as you said people do not pay much attention.
The topic is kind of broad but to focus on standups, I have a couple of firm beliefs:
- Standups don't need to be daily - it's too much. Twice a week is okay (this can be adjusted depending on team/product dynamics).
- They shouldn't consist of everyone telling everyone else what they're working on. This practice is boring and useless to anyone who is present. (If you want to check what I'm working on, log into the issue tracking system and look at the tickets against my name.) Instead, standups should focus on pieces of work that need to be delivered or that need to change status.
- Standups don't need to be daily - it's too much. Twice a week is okay (this can be adjusted depending on team/product dynamics).
- They shouldn't consist of everyone telling everyone else what they're working on. This practice is boring and useless to anyone who is present. (If you want to check what I'm working on, log into the issue tracking system and look at the tickets against my name.) Instead, standups should focus on pieces of work that need to be delivered or that need to change status.
I've been at jobs now for ~7 years and subjected to this. Everyone has to list what they're working on, everyone else ignores what is being listed/talked about until it is their turn and I feel like I'm repeating myself 10x a day. It sucks.
This is the most common example of the Cargo Cult version of Agile/Scrum.
I've seen project managers lead cross-functional scrum/agile teams, making people listen to eachother so that each team is in sync and productive.
But this was their personal understanding, and was then removed to pave way for the mandated certified "Agile" methodologies and rituals (=WaterScrumFall). So whatever was learned, gets lost in the next turn of the wheel, inevitably.
What people miss in their accounts is that any success or learning is temporary, and in the organisational space, change is inevitable rendering all and any accomplishments transient.
But this was their personal understanding, and was then removed to pave way for the mandated certified "Agile" methodologies and rituals (=WaterScrumFall). So whatever was learned, gets lost in the next turn of the wheel, inevitably.
What people miss in their accounts is that any success or learning is temporary, and in the organisational space, change is inevitable rendering all and any accomplishments transient.
> They shouldn't consist of everyone telling everyone else what they're working on.
It's a common habit people fall into when transitioning to scrum. An experienced scrum master should never let this happen though.
It's a common habit people fall into when transitioning to scrum. An experienced scrum master should never let this happen though.
While its goal is to "empower" developers to build usable things quickly, Agile/Scrum is often used by management to give themselves insight into development progress. And because its not a "fixed" process and is inherently malleable, the way it gets implemented is usually to serve management first and developers second.
A perfect example of this is the misuse of things like story points. It's supposed to be a reference as to how complicated a task is to complete. Ideally, over time, management gets a sense of how many "story points" a team can complete in a sprint. In practice however, development teams basically get brow-beat into treating story points as shorthand for how long they think something will take. So for example, something that involves a bunch of basic drudgery that has no real impact on the system gets scored high. Whereas some minor change deep in the bowels of the system that breaks a cascade of tests and causes massive regressions gets scored low because hey its only 5 lines of code!
A perfect example of this is the misuse of things like story points. It's supposed to be a reference as to how complicated a task is to complete. Ideally, over time, management gets a sense of how many "story points" a team can complete in a sprint. In practice however, development teams basically get brow-beat into treating story points as shorthand for how long they think something will take. So for example, something that involves a bunch of basic drudgery that has no real impact on the system gets scored high. Whereas some minor change deep in the bowels of the system that breaks a cascade of tests and causes massive regressions gets scored low because hey its only 5 lines of code!
If "Agile" results in extra layers of bureaucracy and more meetings, that's a great sign that agile is being done terribly wrong. Which, to be fair, is very very common.
Remember the manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Remember the manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
My thought to every line quoted is "why?" What are the actual principles involved, and why don't we just jump straight to those when making process decisions? Manifestos do more harm then good because their vagueness enables reinterpretation.
> Manifestos do more harm then good because their vagueness enables reinterpretation.
That totally relates to my experience.
I've seen this scene repeated over and over:
- project begins
- something happens and delays the project (arrival of new team members who need some time to learn about the code base, for instance; it's not even an issue, it's just a natural consequence which makes the project go different than planned and put certain kinds of managers in distress)
- project start to get behind of the schedule or whatever tool in use to track progress
- "you are not a true Agilist"
I just can't understand why is it so easy to blame the old methods while it's so hard to identify weaknesses in the current ones.
Besides, the room they left for interpretation leads to a good amount of bike-shedding and witch hunting as soon as something goes wrong in the project -- if one assumes the method is perfect, the only possible explanation for a failure is that the method has been misfollowed.
That totally relates to my experience.
I've seen this scene repeated over and over:
- project begins
- something happens and delays the project (arrival of new team members who need some time to learn about the code base, for instance; it's not even an issue, it's just a natural consequence which makes the project go different than planned and put certain kinds of managers in distress)
- project start to get behind of the schedule or whatever tool in use to track progress
- "you are not a true Agilist"
I just can't understand why is it so easy to blame the old methods while it's so hard to identify weaknesses in the current ones.
Besides, the room they left for interpretation leads to a good amount of bike-shedding and witch hunting as soon as something goes wrong in the project -- if one assumes the method is perfect, the only possible explanation for a failure is that the method has been misfollowed.
Adding more people to a project makes it later.
A manifesto is a set of principles. Principles tend to be vague.
I think when Agile is finally replaced by something else it will be because of:
Scaling developers vertically requires having support tools, processes, and people to get past the things that trip them up and back to forward progress. They don't have to be big tools, or big processes. In fact it's much more important that they be reliable than that they have huge feature sets.
But Agile without tools and processes? Show me anyone who is pulling that off, and I'll show you someone who has mislabeled a bunch of things as 'not-tool' and 'not-process'.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Scaling developers vertically requires having support tools, processes, and people to get past the things that trip them up and back to forward progress. They don't have to be big tools, or big processes. In fact it's much more important that they be reliable than that they have huge feature sets.
But Agile without tools and processes? Show me anyone who is pulling that off, and I'll show you someone who has mislabeled a bunch of things as 'not-tool' and 'not-process'.
I left out the last line, which I probably shouldn't have:
"That is, while there is value in the items on the right, we value the items on the left more."
Agile doesn't mean no documentation and no tools - it just means they should not be the focus.
"That is, while there is value in the items on the right, we value the items on the left more."
Agile doesn't mean no documentation and no tools - it just means they should not be the focus.
Yes and I think I disagree with that line.
The difference is one of intent. Having tools or processes to have processes is a bureaucratic mess which they Agile folks rightfully wanted to cut with a scythe. Sword. Scary sharp thing of your choice.
There's a difference between building tools and process, and building a culture of toolsmiths and process tweakers. The latter, I think, follows the spirit of Agile but not the letter of it. And lean is just... throw the baby out with the bathwater. It's bureaucracy as written by a minimalist.
The difference is one of intent. Having tools or processes to have processes is a bureaucratic mess which they Agile folks rightfully wanted to cut with a scythe. Sword. Scary sharp thing of your choice.
There's a difference between building tools and process, and building a culture of toolsmiths and process tweakers. The latter, I think, follows the spirit of Agile but not the letter of it. And lean is just... throw the baby out with the bathwater. It's bureaucracy as written by a minimalist.
> Agile doesn't mean no documentation and no tools - it just means they should not be the focus.
Except for Jira, of course. /s
Except for Jira, of course. /s
> “If "Agile" results in extra layers of bureaucracy and more meetings, that's a great sign that agile is being done terribly wrong. Which, to be fair, is very very common.”
It’s so common that it’s been branded: SAFe, and it’s a complete abomination.
It’s so common that it’s been branded: SAFe, and it’s a complete abomination.
Agile: maybe, depends on definition and execution
Scrum: nope
Daily standups: awesome, do them, if it works for you and your team. Don't let anyone fool you into doing something called one that isn't. Actually stand up (if you're able). Actually demand everyone (who's able) does too. The end of the discussion is when someone's uncomfortable. If that cuts the discussion too short, tailor future ones to accommodate them. Repeat until unnecessary.
Real agile (and real things that are actually used in agile) are not micromanageable, they're the antithesis. I highly recommend a read/refresher on the actual Agile Manifesto. All of the things described here that sound nasty are just what agile was challenging, in agile clothing.
Edit: oh how did I miss my favorite target?
Sprints: definitely not for me. They're the Trojan Horse that lets all the fake agile stuff in. I prefer Kanban, but whatever flexible, adaptive, communicative system your team chooses go for it.
Scrum: nope
Daily standups: awesome, do them, if it works for you and your team. Don't let anyone fool you into doing something called one that isn't. Actually stand up (if you're able). Actually demand everyone (who's able) does too. The end of the discussion is when someone's uncomfortable. If that cuts the discussion too short, tailor future ones to accommodate them. Repeat until unnecessary.
Real agile (and real things that are actually used in agile) are not micromanageable, they're the antithesis. I highly recommend a read/refresher on the actual Agile Manifesto. All of the things described here that sound nasty are just what agile was challenging, in agile clothing.
Edit: oh how did I miss my favorite target?
Sprints: definitely not for me. They're the Trojan Horse that lets all the fake agile stuff in. I prefer Kanban, but whatever flexible, adaptive, communicative system your team chooses go for it.
I manage managers and managers of managers, so have years of seeing this play out over dozens of teams. At this point, I prefer my engineering teams to "locally optimize" their process. I tell them that I care about the following 4 things:
1. There is a clear way for stakeholders to provide you with their requirements and discuss them.
2. There is a clear decision made about what is going to be worked on.
3. There is a way to check on progress without asking individual engineers.
4. After work is complete, stakeholders get clear communication about what actually happened.
I strongly suggest that they accomplish this by using "sprints", because then it means that they only have to manage the communication before and after sprints instead of ongoing. I also have never seen my #3 really done well because getting developers to keep issues up to date has always been difficult.
Almost every team ends up doing daily stand ups, and when they don't it is usually because of timezone issues, so they find a substitute. This seems to be something that many engineers fall into as a habit to help keep each other unblocked.
The one thing that is problematic for my approach is predictability. If teams don't have an inherent value of completing sprint goals, then work carries over from sprint to sprint, and stakeholders can't predict when things are going to be delivered.
I strongly suggest that they accomplish this by using "sprints", because then it means that they only have to manage the communication before and after sprints instead of ongoing. I also have never seen my #3 really done well because getting developers to keep issues up to date has always been difficult.
Almost every team ends up doing daily stand ups, and when they don't it is usually because of timezone issues, so they find a substitute. This seems to be something that many engineers fall into as a habit to help keep each other unblocked.
The one thing that is problematic for my approach is predictability. If teams don't have an inherent value of completing sprint goals, then work carries over from sprint to sprint, and stakeholders can't predict when things are going to be delivered.
> I also have never seen my #3 really done well because getting developers to keep issues up to date has always been difficult.
This is where CI/CD integration of tickets and good commit hygiene comes in, in my opinion. If your pipeline updates the state of the ticket as it progresses and commits are both sensible (describing the work completed rather than 'WIP: did stuff') and viewable from the ticket's history, that /should/ be sufficient to gauge progress when viewed alongside the work spec.
This is where CI/CD integration of tickets and good commit hygiene comes in, in my opinion. If your pipeline updates the state of the ticket as it progresses and commits are both sensible (describing the work completed rather than 'WIP: did stuff') and viewable from the ticket's history, that /should/ be sufficient to gauge progress when viewed alongside the work spec.
This is a good point. If someone is willing to look at the git history of an issue, they can glean a lot of information about the progress.
Before you judge it, I implore you to ask whether your organization is actually doing Agile/Scrum correctly. I doubt most orgs are and I suspect most negative opinions come from doing it incorrectly/ineffectively. I think the core principles of agile are well-intended. It's the desired state we want to achieve. However, most of us are still trying to reconcile with our current state.
There are many pitfalls. For example, giving product owner and even manager roles to the lead engineer or architect, daily standups devolving into telling people what ticket number they have in progress as opposed to blockers they are seeing or actually working on, product owners not showing up to backlog grooming sessions leaving engineering to make their own priorities, product managers being the engineering manager and leading retrospectives making everyone biased to say what went well but not things to improve on, agile release trains having teams that don't really interact with each other leaving engineering teams tuned out during system level PI planning and demos. The list goes on.
The current state of an org implementing agile/scrum can easily lead to what David Graeber calls Bull*hit jobs: https://www.youtube.com/watch?v=kikzjTfos0s. The onus is on the organization's leaders to take everyone to the desired state. However, all too often the actual leaders of an organization are the engineers themselves and would much rather get work done than to micromanage.
There are many pitfalls. For example, giving product owner and even manager roles to the lead engineer or architect, daily standups devolving into telling people what ticket number they have in progress as opposed to blockers they are seeing or actually working on, product owners not showing up to backlog grooming sessions leaving engineering to make their own priorities, product managers being the engineering manager and leading retrospectives making everyone biased to say what went well but not things to improve on, agile release trains having teams that don't really interact with each other leaving engineering teams tuned out during system level PI planning and demos. The list goes on.
The current state of an org implementing agile/scrum can easily lead to what David Graeber calls Bull*hit jobs: https://www.youtube.com/watch?v=kikzjTfos0s. The onus is on the organization's leaders to take everyone to the desired state. However, all too often the actual leaders of an organization are the engineers themselves and would much rather get work done than to micromanage.
Agile the stuff in the manifesto is pretty much spot on.
Agile the stuff people make you do in work is often pretty anti-thetical.
Scrum as a process is basically poison.
Agile the stuff people make you do in work is often pretty anti-thetical.
Scrum as a process is basically poison.
Upvoted (although I'm not sure I agree with the last point, but the top 2 are definitely spot-on)
The agile manifesto is tiny and a scrum guide like this one: https://scrumguides.org/scrum-guide.html is readable in a couple of hours. But the version of "scrum" forced on many people is a far cry from that.
The agile manifesto is tiny and a scrum guide like this one: https://scrumguides.org/scrum-guide.html is readable in a couple of hours. But the version of "scrum" forced on many people is a far cry from that.
For the last one, basically if a process is essentially never implemented in a way that respects the principles it’s designed around something is very wrong.
Yes, I agree. But I'm not sure what you do about that though. Stronger "dictacts" from an international "scrum committee" putting out material telling you what is "correct" scrum and what is not?
The problem as ever is people and expecting that process will fix them. Individuals and interactions over processes and tools.
A dysfunctional team won’t be fixed by a new process to follow. It’ll just warp to the dysfunctions.
A dysfunctional team won’t be fixed by a new process to follow. It’ll just warp to the dysfunctions.
Emphasize the principles more.
The one thing I've consistently seen absent in many Scrum attempts is the sprint retrospective. When this is included and is permitted to include not just code/product issues but also process issues, it has worked very well even when they skimped out on other elements of Scrum. But most often the retrospective is absent or the process is not permitted to be included in it. This makes you fundamentally anti-Agile as you literally have a rigid, static process.
The one consistent element that I have found across nearly every reading of Agile I've done and my experiences over the past (now almost 20 professional) years has been that the critical element of agile is its responsiveness and introspectiveness. Lacking those two things you do not have anything that can be called Agile, at best it's an imitation, at worst it's SAFe and you should run fast.
DevOps, Lean, Scrum, Theory of Constraints (realized in software, at least in part, as DevOps) to the extent that they have defined processes they are not the same. But the consistent element is introspection and responsiveness leading to adaptation to the team, organization, customers, and systems being developed/maintained.
This is the critical element missing from many organizations and teams at the time of the manifesto. See Waterfall, any CMMI office. They become static, they delay their feedback loops to extraordinary time frames. Waterfall (may it die a fiery death), in some spectacular failures I've witnessed, had 5 years from start to delivery for customer test, not deployment. CMMI has a strong association with Waterfall (unjust in my opinion), but it still promotes a static process that is only reviewed when it's time for your next appraisal (technically it promotes continuous monitoring and improvement, but like with Scrum everyone ignores it).
It's still a crucial element missing from many organizations who have cargo culted their way into Agile or adopted "Agile" processes (like SAFe, may it suffer the same fate as Waterfall). If your processors ever become truly static, you either found The One True Process (for your team and situation) or you're failing to recognize and adapt to your circumstances.
The one thing I've consistently seen absent in many Scrum attempts is the sprint retrospective. When this is included and is permitted to include not just code/product issues but also process issues, it has worked very well even when they skimped out on other elements of Scrum. But most often the retrospective is absent or the process is not permitted to be included in it. This makes you fundamentally anti-Agile as you literally have a rigid, static process.
The one consistent element that I have found across nearly every reading of Agile I've done and my experiences over the past (now almost 20 professional) years has been that the critical element of agile is its responsiveness and introspectiveness. Lacking those two things you do not have anything that can be called Agile, at best it's an imitation, at worst it's SAFe and you should run fast.
DevOps, Lean, Scrum, Theory of Constraints (realized in software, at least in part, as DevOps) to the extent that they have defined processes they are not the same. But the consistent element is introspection and responsiveness leading to adaptation to the team, organization, customers, and systems being developed/maintained.
This is the critical element missing from many organizations and teams at the time of the manifesto. See Waterfall, any CMMI office. They become static, they delay their feedback loops to extraordinary time frames. Waterfall (may it die a fiery death), in some spectacular failures I've witnessed, had 5 years from start to delivery for customer test, not deployment. CMMI has a strong association with Waterfall (unjust in my opinion), but it still promotes a static process that is only reviewed when it's time for your next appraisal (technically it promotes continuous monitoring and improvement, but like with Scrum everyone ignores it).
It's still a crucial element missing from many organizations who have cargo culted their way into Agile or adopted "Agile" processes (like SAFe, may it suffer the same fate as Waterfall). If your processors ever become truly static, you either found The One True Process (for your team and situation) or you're failing to recognize and adapt to your circumstances.
> The one thing I've consistently seen absent in many Scrum attempts is the sprint retrospective.
This is explicitly forbidden in Scrum. Retrospective is the only part that cannot be removed.
But I agree, most companies prefer to allow as little feedback as possible.
This is explicitly forbidden in Scrum. Retrospective is the only part that cannot be removed.
But I agree, most companies prefer to allow as little feedback as possible.
I find retrospectives demoralizing. I don't want to reherse what we messed up the last 3 weeks every three weeks we allready know that. The constant pressure to "improve" makes you feel bad even though things are going OK.
Most painpoints are external to our team anyways (otherwise it would have been fixed) so why discuss it sprint after sprint.
Most painpoints are external to our team anyways (otherwise it would have been fixed) so why discuss it sprint after sprint.
I suppose there are good and bad ways to do retrospective. I have seen good ones. I admit I haven't seen many bad ones, mostly because most companies I worked at simply do not have retrospectives at all.
The good ones kinda resemble what the developers would tell each other if they had a beer together after work. They probably wouldn't press each other to "improve". Well, maybe they would, if there was one exceptional slacker. But even then, it probably wouldn't be like "work faster! faster! even faster!" but rather something like "run the unit tests on your machine before you commit the code, dummy, and stop using one-character names for variables, who is supposed to read that?". Which would optimally result in introducing policies to prevent that, such as running the tests automatically in continuous integration, adopting code standards and doing code reviews, etc.
The good ones kinda resemble what the developers would tell each other if they had a beer together after work. They probably wouldn't press each other to "improve". Well, maybe they would, if there was one exceptional slacker. But even then, it probably wouldn't be like "work faster! faster! even faster!" but rather something like "run the unit tests on your machine before you commit the code, dummy, and stop using one-character names for variables, who is supposed to read that?". Which would optimally result in introducing policies to prevent that, such as running the tests automatically in continuous integration, adopting code standards and doing code reviews, etc.
I think the thing is to go back to the point of the retrospective which is to improve how you're working. You can do that with a regular meeting but that's not the only way to approach things.
I have not had good luck with organized agile. I like the manifesto, and the pedigree of its authors. I just have been unable to be satisfied with its actual implementation. Probably my fault (or my company’s).
Nowadays, because folks don’t like to work with older devs, I’m forced to work alone. Although this limits the scope of what I can do, it has allowed me free rein to formalize a manner of programming that has very good results.
I call it “Evolutionary Development”[0]-[2]. It requires a great deal of experience (not intelligence or education). Thankfully, that’s a resource I have in abundance.
[0] https://littlegreenviper.com/miscellany/evolutionary-design-...
[1] https://littlegreenviper.com/miscellany/forensic-design-docu...
[2] https://littlegreenviper.com/various/concrete-galoshes/
Nowadays, because folks don’t like to work with older devs, I’m forced to work alone. Although this limits the scope of what I can do, it has allowed me free rein to formalize a manner of programming that has very good results.
I call it “Evolutionary Development”[0]-[2]. It requires a great deal of experience (not intelligence or education). Thankfully, that’s a resource I have in abundance.
[0] https://littlegreenviper.com/miscellany/evolutionary-design-...
[1] https://littlegreenviper.com/miscellany/forensic-design-docu...
[2] https://littlegreenviper.com/various/concrete-galoshes/
> I just have been unable to be satisfied with its actual implementation
You have not been satisfied with implementations you've experienced.
You have not been satisfied with implementations you've experienced.
Exactly. That’s why I phrased it that way. But the way I do things now, would give a lot of agile folks fits.
If I’m skating on thin ice; I might as well dance.
EDIT: It looks like you got dinged for that comment. I'm sorry. It was a bit challenging, but completely fair, done in a respectful manner, and I respect it. I expect and support that kind of challenge on HN.
If I’m skating on thin ice; I might as well dance.
EDIT: It looks like you got dinged for that comment. I'm sorry. It was a bit challenging, but completely fair, done in a respectful manner, and I respect it. I expect and support that kind of challenge on HN.
The true agile practitioners would be happy you've found a process that works :)
I like the idea of Kanban and 3x weekly standups/status.
VS
Sprints and daily standups.
---
Daily standups are too often, not enough updates, and it feels more like pressure than utility for the engineers.
Sprints, while helping keep multiple teams working on a single "epic" or "feature" in sync, also feel like an arbitrary slice of time vs. letting people work on things at the pace they are comfortable at. Finish early? Careful taking new work in, it will look bad to bring new things into the sprint and not finish.
Take an extra day on a story due to some complications? That's fine if it's middle of sprint. But rollover into new sprint? Oh gosh, what will that do to our sprint report?
Time estimations, maintaining backlogs of work and prioritizing, and documenting work done are all great. But some of it has too much ritual to it.
VS
Sprints and daily standups.
---
Daily standups are too often, not enough updates, and it feels more like pressure than utility for the engineers.
Sprints, while helping keep multiple teams working on a single "epic" or "feature" in sync, also feel like an arbitrary slice of time vs. letting people work on things at the pace they are comfortable at. Finish early? Careful taking new work in, it will look bad to bring new things into the sprint and not finish.
Take an extra day on a story due to some complications? That's fine if it's middle of sprint. But rollover into new sprint? Oh gosh, what will that do to our sprint report?
Time estimations, maintaining backlogs of work and prioritizing, and documenting work done are all great. But some of it has too much ritual to it.
> Careful taking new work in, it will look bad to bring new things into the sprint and not finish
yep. Furthermore, there are many other perverse incentives that I noticed, but one stands out: the incentive not to take on risky or difficult stories out of fear that if it is not finished by the "committed" date (end of sprint), you will be tarred and shamed during the sprint review.
yep. Furthermore, there are many other perverse incentives that I noticed, but one stands out: the incentive not to take on risky or difficult stories out of fear that if it is not finished by the "committed" date (end of sprint), you will be tarred and shamed during the sprint review.
I've used both Scrum and Kanban. Kanban, for me, is by far the superior method. There are no artificial sprint deadlines, no ticket sizing, far fewer ceremonies, gives a lot of flexibility, but still provides enough structure to place emphasis on tracking and completing work.
If you've never worked in a Kanban environment, I highly suggest you research it and encourage your employer to experiment with it.
If you've never worked in a Kanban environment, I highly suggest you research it and encourage your employer to experiment with it.
Note that Kanban requires a certain maturity and self-discipline from the development team and the stakeholders. If that's a given, Kanban can work very well.
Scrum was really invented for situations where management is constantly asking "when do we get X?" and the development always says "we aren't done yet".
In this scenario, the sprint is meant to reassure management that they'll get at least *something (even if not a full X) in a predictable time, and forces the development team to put something out in a given time frame even if not yet perfect / finished / whatever.
If that's not a problem, Kanban can be indeed be a much better fit, and come with far less overhead.
Scrum was really invented for situations where management is constantly asking "when do we get X?" and the development always says "we aren't done yet".
In this scenario, the sprint is meant to reassure management that they'll get at least *something (even if not a full X) in a predictable time, and forces the development team to put something out in a given time frame even if not yet perfect / finished / whatever.
If that's not a problem, Kanban can be indeed be a much better fit, and come with far less overhead.
> the sprint is meant to reassure management that they'll get at least *something (even if not a full X) in a predictable time
I would rephrase it as "sprint is meant to make management to believe that they'll get at least something in a predictable time".
I also notice that lots of comments seem to be coming from front-end or customer-based companies. For backend and b2b, 2 weeks sprint for some new functionality is funny.
I would rephrase it as "sprint is meant to make management to believe that they'll get at least something in a predictable time".
I also notice that lots of comments seem to be coming from front-end or customer-based companies. For backend and b2b, 2 weeks sprint for some new functionality is funny.
> I also notice that lots of comments seem to be coming from front-end or customer-based companies. For backend and b2b, 2 weeks sprint for some new functionality is funny.
I develop internal tooling for a b2b company, and we ship features multiple times a week. Much of that is backend.
Often not huge features, but still features that make life easier for colleagues.
I develop internal tooling for a b2b company, and we ship features multiple times a week. Much of that is backend.
Often not huge features, but still features that make life easier for colleagues.
A team commitment based on the learning from the last sprints to scope the next one, so that you can predict the delivery scope, is an artificial deadline?
Yes. Either "commitments" are ignored and tickets casually spill over into next sprint, or they are enforced leading to inflated estimates by the team so you dont have to work overtime the next sprints. See also the commitments-vs-forecast discussion further above.
Kanban still has estimates and you can still do bi-weekly demos of whatever has been done since last demo. Management can still get a sense of when they will get stories by judging how far down the backlog they are. Team is still protected from interruptions by their WIP-limit but PO can still swap out highest prio item not currently in progress, win-win.
Kanban still has estimates and you can still do bi-weekly demos of whatever has been done since last demo. Management can still get a sense of when they will get stories by judging how far down the backlog they are. Team is still protected from interruptions by their WIP-limit but PO can still swap out highest prio item not currently in progress, win-win.
It can be beneficial if done right - but most places just don't do it right at all.
I've even seen officially certified scrum masters using it in ways that go completely against the ideas that are behind it.
The main idea of Scrum is, to empower the entire team to decide on their own processes through finding consensus, and to get rid of annoyances that slow things down.
If Scrum itself becomes that annoyance that slows you down - then according to Scrum you absolutely need to get rid of it.
All the different parts of scrum should be considered an all-you-can-eat buffet. You are not supposed to eat all of it - you are supposed to just pick out the things you like the most.
The only core principle is to regularly meet up and discuss how to improve things. That cycle between two such discussions is typically called "sprint" - and that meetup where you discuss improvements is typically called "retrospective". Nothing else about scrum is a requirement. It's just a list of things that worked for some other teams - doesn't mean it will work for you.
I've even seen officially certified scrum masters using it in ways that go completely against the ideas that are behind it.
The main idea of Scrum is, to empower the entire team to decide on their own processes through finding consensus, and to get rid of annoyances that slow things down.
If Scrum itself becomes that annoyance that slows you down - then according to Scrum you absolutely need to get rid of it.
All the different parts of scrum should be considered an all-you-can-eat buffet. You are not supposed to eat all of it - you are supposed to just pick out the things you like the most.
The only core principle is to regularly meet up and discuss how to improve things. That cycle between two such discussions is typically called "sprint" - and that meetup where you discuss improvements is typically called "retrospective". Nothing else about scrum is a requirement. It's just a list of things that worked for some other teams - doesn't mean it will work for you.
> Nothing else about scrum is a requirement
From the perspective of Scrum this is incorrect. It is specifically stated that:
> Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless. [1]
Eg. If you don't follow the framework, you're not doing Scrum
[1] https://scrumguides.org/scrum-guide.html
From the perspective of Scrum this is incorrect. It is specifically stated that:
> Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless. [1]
Eg. If you don't follow the framework, you're not doing Scrum
[1] https://scrumguides.org/scrum-guide.html
I politely disagree.
I've read the book "Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland and J.J. Sutherland which goes into the history of how Scrum was invented, and the ideas and philosophy behind it - and neither that quote of yours, nor anything similar to it, is represented in that book.
I've also read "Essential Scrum" by Kenneth S. Rubin, which many consider the best book to read on Scrum, and that does not endorse anything like your quote either. That book definitely is more on the "all-you-can-eat buffet" side of things.
Both books clearly state in some form or other, that ALL processes cause overhead - and that does include the processes suggested/recommended by Scrum. And that's why you should always use as little processes as possible. Sadly you can't work without any processes at all - if you try that, some informal processes will just emerge on their own. It just doesn't work without - unless you are a tiny team of friends.
Scrum has become a big commercial enterprise, that wants to sell courses and trainings and scrum master certificates. They have a financial incentive to churn out rules to follow, because that's how they earn money. But that's surely not what is best for teams and work motivation. I really don't think that Scrum originally was about rules at all - it was (and should be) about what is best for teams and work motivation. Just my 2 cents.
I've read the book "Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland and J.J. Sutherland which goes into the history of how Scrum was invented, and the ideas and philosophy behind it - and neither that quote of yours, nor anything similar to it, is represented in that book.
I've also read "Essential Scrum" by Kenneth S. Rubin, which many consider the best book to read on Scrum, and that does not endorse anything like your quote either. That book definitely is more on the "all-you-can-eat buffet" side of things.
Both books clearly state in some form or other, that ALL processes cause overhead - and that does include the processes suggested/recommended by Scrum. And that's why you should always use as little processes as possible. Sadly you can't work without any processes at all - if you try that, some informal processes will just emerge on their own. It just doesn't work without - unless you are a tiny team of friends.
Scrum has become a big commercial enterprise, that wants to sell courses and trainings and scrum master certificates. They have a financial incentive to churn out rules to follow, because that's how they earn money. But that's surely not what is best for teams and work motivation. I really don't think that Scrum originally was about rules at all - it was (and should be) about what is best for teams and work motivation. Just my 2 cents.
I appreciate the politeness :D
The quote comes from the official Scrum guide. I'd say that is an authoritative source (just like yours, mind). I was just pointing out that according to 'the bible' you have to incorporate the framework as a whole, or not call what you're doing Scrum (Scrumbut perhaps?).
I agree with you on the commercialism surrounding Scrum and the financial incentive.
The quote comes from the official Scrum guide. I'd say that is an authoritative source (just like yours, mind). I was just pointing out that according to 'the bible' you have to incorporate the framework as a whole, or not call what you're doing Scrum (Scrumbut perhaps?).
I agree with you on the commercialism surrounding Scrum and the financial incentive.
Well, I guess I'm better off keeping a good distance form that NuScrum stuff - I'll be sticking with the original Scrum ;)
And yeah, I'll keep calling the old one just "Scrum", as it always was called, whether or not "the bible" allows me to :P
And yeah, I'll keep calling the old one just "Scrum", as it always was called, whether or not "the bible" allows me to :P
Fundamentally, it's about discipline. The problem is that people don't know how to balance.
Management needs tools to detect (1) slippage, (2) true cost, (3) emerging issues.
Engineers need to not silo, work together, make progress, and share status.
Amazon would do it at 11am, and it would last no more than 10 minutes for a small team. Every two weeks, management and engineers get in a room to holistically determine where things are at, and then they go and report status up.
What I would tell teams that I bootstrap is that the process itself doesn't matter, but the team needs a shared discipline to be effective. Their team has desired outcomes and everyone needs to be accountable for making progress.
Management needs tools to detect (1) slippage, (2) true cost, (3) emerging issues.
Engineers need to not silo, work together, make progress, and share status.
Amazon would do it at 11am, and it would last no more than 10 minutes for a small team. Every two weeks, management and engineers get in a room to holistically determine where things are at, and then they go and report status up.
What I would tell teams that I bootstrap is that the process itself doesn't matter, but the team needs a shared discipline to be effective. Their team has desired outcomes and everyone needs to be accountable for making progress.
I've always been a fan of a light agile process - every few weeks you sit down and come up with a target for the subsequent interval - 2 weeks is a good start, shouldn't be more than 6-8 weeks. Within that, you define what you want to work on - could be a particular milestone within the project. Could also be user stories, doesn't really matter as long as everyone has a good sense of what the next milestone is.
Then you check in as a group on a weekly, or maybe twice-weekly basis, with an explicit goal of identifying risks and uncertainties that have arisen during that timeframe.
The goal here is not to micromanage, but to give a sense of progress towards a goal - whether a metric shift, a release, a roadmap commitment, etc. If you don't hit your interval milestones a few intervals in a row, your high-level thinking about timing is wrong, and you need to adapt the project or the timing.
Then you check in as a group on a weekly, or maybe twice-weekly basis, with an explicit goal of identifying risks and uncertainties that have arisen during that timeframe.
The goal here is not to micromanage, but to give a sense of progress towards a goal - whether a metric shift, a release, a roadmap commitment, etc. If you don't hit your interval milestones a few intervals in a row, your high-level thinking about timing is wrong, and you need to adapt the project or the timing.
From my experience as a scrum master, if there is any micro-managing going on, it's being done wrong. The standup should literally be no more than a minute per person. Each person gets 2-3 sentences: "I did this yesterday. Today I'm working on this. I could use some help with X. (if applicable)"
It's meant to help keep the team aligned on what everyone is doing at a higher level, not for any details at all. After the standup, the team can address any requests for help that came up as needed. But that falls outside of the standup.
Agile is meant to help empower teams and improve their velocity, and that requires people to own their own stuff. So the standup should be a purely informative, high-level overview of where the team is so everyone is aligned. If it's anything more, it will become a cumbersome, painful exercise in micro-management and tangential discussions.
It's meant to help keep the team aligned on what everyone is doing at a higher level, not for any details at all. After the standup, the team can address any requests for help that came up as needed. But that falls outside of the standup.
Agile is meant to help empower teams and improve their velocity, and that requires people to own their own stuff. So the standup should be a purely informative, high-level overview of where the team is so everyone is aligned. If it's anything more, it will become a cumbersome, painful exercise in micro-management and tangential discussions.
In my experience with old companies adopting agile, is I equate it to a company wants to evolve it's culture, but in doing so they start doing what they think the companies they want to emulate do to succeed. I'd equate it to doing a cargo cult.
Doesn't mean there isn't value to companies that have succeeded with it, or created a value culture around this coordination. But my experience was a bunch of people sitting around talking about what color paper should be used for a particular work item on the sticky board, which I struggle to see the value of.
Doesn't mean there isn't value to companies that have succeeded with it, or created a value culture around this coordination. But my experience was a bunch of people sitting around talking about what color paper should be used for a particular work item on the sticky board, which I struggle to see the value of.
Compared to what?
My experiance of traditional project managment is we used to have milestones, write daily progress reports, requirement anaysis meetings with BA's etc
In my mind scrum has less bureaucracy than that.
Scrum Meetings are best used as a way to come together as a team to work how to make progress today.
For example:
I want to deploy this change to prod today, but one of the tests is failing and I don't know why. Ok lets get a couple of people to mob on the test to figure out whats going on after scrum etc
That's a good scrum meeting.
Bad scrum meeting. Person 1: I did x yesterday. Person 2: I did x yesterday etc Person 3: I tried to get x done yesterday, but I got stuck i'll try again today.
No value whatsoever.
The emphasis should be on problem solving as a team, and focusing the team on pain points to get work across the finish line.
To that end i find "walking the board" far more valuable, than status updates from each memeber.
In my mind scrum has less bureaucracy than that.
Scrum Meetings are best used as a way to come together as a team to work how to make progress today.
For example:
I want to deploy this change to prod today, but one of the tests is failing and I don't know why. Ok lets get a couple of people to mob on the test to figure out whats going on after scrum etc
That's a good scrum meeting.
Bad scrum meeting. Person 1: I did x yesterday. Person 2: I did x yesterday etc Person 3: I tried to get x done yesterday, but I got stuck i'll try again today.
No value whatsoever.
The emphasis should be on problem solving as a team, and focusing the team on pain points to get work across the finish line.
To that end i find "walking the board" far more valuable, than status updates from each memeber.
Calling out my potential bias[es] up front: I am a former certified scrum master. I let it expire intentionally. I don't necessarily dislike Agile/scrum but I think it has a lot of weaknesses that aren't addressed, and it gets applied as a panacea in instances that might be better served with waterfall or some hybrid.
> Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
Agile is one of those things that seems like a dream for micromanagers, and if the extent of your company's Agile implementation is saying that you "do Agile" then yeah it's going to be a nightmare. But Agile teams are supposed to be largely self-organized and self-managing. I don't want to No True Scotsman this but if you're doing Agile right there's very little room for some external micromanager to impose their will upon you, but there's certainly room for one to crop up internally.
An old coworker used to say that Agile was created by someone who was sexually attracted to meetings. We don't do a lot of them, or we do them with a subset (on our team of ~11 including the manager and analysts, backlog grooming is 2-3 people for example).
> Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
Agile is one of those things that seems like a dream for micromanagers, and if the extent of your company's Agile implementation is saying that you "do Agile" then yeah it's going to be a nightmare. But Agile teams are supposed to be largely self-organized and self-managing. I don't want to No True Scotsman this but if you're doing Agile right there's very little room for some external micromanager to impose their will upon you, but there's certainly room for one to crop up internally.
An old coworker used to say that Agile was created by someone who was sexually attracted to meetings. We don't do a lot of them, or we do them with a subset (on our team of ~11 including the manager and analysts, backlog grooming is 2-3 people for example).
>I am a former certified scrum master.
What is the minimum number of weekends that are needed to earn that?
Without moving any goalposts, still less than one, correct?
Not meaning to single you out, just curious since you would be in a position to know.
Kudos for letting it expire.
Not that I don’t like agile or scrum, just the certification thing kind of gets in my craw since it’s so little effort and used as if it’s a big deal.
What is the minimum number of weekends that are needed to earn that?
Without moving any goalposts, still less than one, correct?
Not meaning to single you out, just curious since you would be in a position to know.
Kudos for letting it expire.
Not that I don’t like agile or scrum, just the certification thing kind of gets in my craw since it’s so little effort and used as if it’s a big deal.
>just the certification thing kind of gets in my craw since it’s so little effort and used as if it’s a big deal.
Correctly pointed out! I have come to dismiss these folks out of hand without losing anything.
Correctly pointed out! I have come to dismiss these folks out of hand without losing anything.
I think scrum is a tool for middle management that invented ceremony to give their role "meaning". At the same time it allows them to avoid the difficult questions of product management (e.g. "is this really an orthogonal feature or does it interfere somewhere?") It also tends to be awfully childish sometimes (this management style was allegedly invented by pedagogists).
Regardless, several techniques are actually worthwhile: Retrospectives for things that happen regularly (they aren't useful for things that happen very seldom). Daily standup as a sync for developers that collaborate the same task.
Regardless, several techniques are actually worthwhile: Retrospectives for things that happen regularly (they aren't useful for things that happen very seldom). Daily standup as a sync for developers that collaborate the same task.
It works well when the team take ownership of the process and treat it as tricks for forcing the sorts of communication that needs to happen but usually doesn't just happen.
Estimation? It's about communication. Standups? Communication. Grooming? It's communication. Retrospectives? Communication.
All the bits are intended to foster communicating different issues that ought to be discussed.
Estimation? It's about communication. Standups? Communication. Grooming? It's communication. Retrospectives? Communication.
All the bits are intended to foster communicating different issues that ought to be discussed.
This is a really good way to sum it up. Even Story Points are supposed to be about adding communication to estimation. It is supposed to be collaborative, but people take it wrong and I have seen SCRUM master doing it :D
Planning poker is the best thing in the whole world. Nit because it gives accurate estimations. Because the conversation that comes out of a 1 vs 8 are so revealing!
I personally find the cycle of planning => sprint => retrospective to be great for teamwork, but scrum in itself is not really something I would care about. Pick the concepts you like and forget about the rest, there is no need for the full package. For example doing some estimation work during planning to be sure that tasks are clear and simple enough (in the sense of “low complexities”) for everybody in the team is great. But you don’t need to actually assign a “complexity value” or whatever as they create confusion and false expectations.
What works for my teams in the past was to just pick a process then regularly ask ourselves if it’s slowing us down or is missing something, and change it slightly when necessary. You may need a few weeks to get used to a working routine that works for everyone, and it’s likely that will evolve over time depending on the people and projects. Better to keep processes to a minimum and make it easy to change it in cases something doesn’t work.
What works for my teams in the past was to just pick a process then regularly ask ourselves if it’s slowing us down or is missing something, and change it slightly when necessary. You may need a few weeks to get used to a working routine that works for everyone, and it’s likely that will evolve over time depending on the people and projects. Better to keep processes to a minimum and make it easy to change it in cases something doesn’t work.
Exactly! Scrum is just another tool in a project managers toolbox.
I like the process based aproach of PMBOK, which is a set of processes that can be applied or left out, deoending on the project context.
Unfortunately I see a lot of Scrum managers, and certified project managers constantly applying all processes they learned about and furthermore annoying those who do the actual work.
I like the process based aproach of PMBOK, which is a set of processes that can be applied or left out, deoending on the project context.
Unfortunately I see a lot of Scrum managers, and certified project managers constantly applying all processes they learned about and furthermore annoying those who do the actual work.
I literally lost my last job because I dislike the scrum methodologies and said I haven't ever seen it working good. The team was a mess, the manager a micro-manager claiming empowering people.. I get the idea but I've never seen it working productively.
Dailies are the most stupid invention ever. Even if its just 15 minutes, its either blocks your "agilitiy" if its on a time-slot that you prefer not to work, or it steals almost an hour because you get out of the tunnel, wait for the meeting, have to get into working mode again.
Dailies are the most stupid invention ever. Even if its just 15 minutes, its either blocks your "agilitiy" if its on a time-slot that you prefer not to work, or it steals almost an hour because you get out of the tunnel, wait for the meeting, have to get into working mode again.
Sprints are nonsense unless they have gaps bewtween them, noone can sprint indefinitely
Standups are good for small teams all working on the same thing, and only if no managers are present. Unless the manager is writing code too .
Kanban seems ok but i havent used it for any period of time.
The various tools are nice for remembering what needs to be done and making shared checklists.
Standups are good for small teams all working on the same thing, and only if no managers are present. Unless the manager is writing code too .
Kanban seems ok but i havent used it for any period of time.
The various tools are nice for remembering what needs to be done and making shared checklists.
> Sprints are nonsense unless they have gaps bewtween them, noone can sprint indefinitely
This is the crux of the nonsense. A high-level engineer can work around this but for the mass of ticket punchers, it just encourages non-thinking, risk aversion, and a lack of trust between themselves do the pressure of velocity charts, which translates into buggy code, mounting legacy blockers.
I know frontend engineers who didn't know what a finite state machine was, nevermind how it was implicit in their business code. For the mass of mediocre engineeers, sprints kill incentive to learn and become a better engineer; no is rewarding you.
Product doesn't care cause they're incentive structure is advesarial to Engineering push-back on tech debt, refactoring, etc. Sprints allow them to make sure their bonus is on time. Then Product people quit when BS mounts, another round of Product management shows up, and rinse, repeat.
I've seen this cycle happen three times in one org in just 5 years, the org where I started as a Junior.
And don't let DevOps also be working against sprints in a mediocre org
Sprints have, for most of the industry, not the Top 10% employers and what not, frankly regressed the industry.
Everyone stops working for the organization and starts trying to figure out how to make the organization work for them, from engineering to product to devops, etc. Good hiring is also a factor in what you'll get out of your employers, but sprints don't get you more at either rate.
This is the crux of the nonsense. A high-level engineer can work around this but for the mass of ticket punchers, it just encourages non-thinking, risk aversion, and a lack of trust between themselves do the pressure of velocity charts, which translates into buggy code, mounting legacy blockers.
I know frontend engineers who didn't know what a finite state machine was, nevermind how it was implicit in their business code. For the mass of mediocre engineeers, sprints kill incentive to learn and become a better engineer; no is rewarding you.
Product doesn't care cause they're incentive structure is advesarial to Engineering push-back on tech debt, refactoring, etc. Sprints allow them to make sure their bonus is on time. Then Product people quit when BS mounts, another round of Product management shows up, and rinse, repeat.
I've seen this cycle happen three times in one org in just 5 years, the org where I started as a Junior.
And don't let DevOps also be working against sprints in a mediocre org
Sprints have, for most of the industry, not the Top 10% employers and what not, frankly regressed the industry.
Everyone stops working for the organization and starts trying to figure out how to make the organization work for them, from engineering to product to devops, etc. Good hiring is also a factor in what you'll get out of your employers, but sprints don't get you more at either rate.
'Sprint' does not mean you have to push yourself to code as fast as you can, nor does it mean that you have to start coding straight away. In fact part of the work may not involve coding at all (e.g. studies and architecture work) and these activities can also be part of a sprint.
Sprints are just time-bounded units to plan and execute the work with the stated aim of having working software at the end of each sprint. You can do that indefinitely in the same way you can follow another software development methodology indefinitely.
Sprints are just time-bounded units to plan and execute the work with the stated aim of having working software at the end of each sprint. You can do that indefinitely in the same way you can follow another software development methodology indefinitely.
> 'Sprint' does not mean you have to push yourself to code as fast as you can, nor does it mean that you have to start coding straight away. In fact part of the work may not involve coding at all (e.g. studies and architecture work) and these activities can also be part of a sprint.
I agree with this statement. However, I believe the term is poorly chosen and, in my experience with managers, frequently misunderstood.
There are two issues I have with the term. First, sprints, as a physical activity, are about short, very hard, bursts of work which are fundamentally unsustainable. Even an athlete competing in sprints takes a good break between each one. Second, "sprint" conveys a sense that the focus is on speed because that's how we judge sprinters.
The first point suggests that Scrum needs a different kind of interval than just a sprint. It needs something like a rest period. Not a "sit down and do nothing" period, but analogous to the "active recovery" that athletes often take part in between exertions. Something productive, supportive, but secondary to the principle objective (a runner isn't at the race to stretch, but they stretch so they can continue to race).
That second point is important, managers hear sprint and they think speed. Any kind of slow down or delay makes them think that the team is just dicking around. The idea that a sprint could be spent on anything bringing indirect value (rather than direct) like test and deployment automation, refactoring and cleanup, or training is antithetical to this perception. Consequently you cannot, easily, put those activities into sprints, or you have to disguise them or mete them out over a series of sprints so that enough "real" value is being created from the management perspective.
Finally, "agile" is about responsiveness. The term was chosen for the manifesto deliberately. We don't look at Usain Bolt on race day and say, "Wow, that man is agile". But you would talk about the agility of a football player who loses speed dodging, avoiding, and leaping around a field to get a 100 yard touchdown. The agile player is responsive to opposition and present conditions. They do need to be fast, but their ultimate speed isn't just from raw speed but from their ability to maintain progress despite adverse conditions. A faster but less agile player could get lucky, but more often will get blocked. The use of the term "sprint" in Scrum conveys no real sense that adaptation and responsiveness are important.
I agree with this statement. However, I believe the term is poorly chosen and, in my experience with managers, frequently misunderstood.
There are two issues I have with the term. First, sprints, as a physical activity, are about short, very hard, bursts of work which are fundamentally unsustainable. Even an athlete competing in sprints takes a good break between each one. Second, "sprint" conveys a sense that the focus is on speed because that's how we judge sprinters.
The first point suggests that Scrum needs a different kind of interval than just a sprint. It needs something like a rest period. Not a "sit down and do nothing" period, but analogous to the "active recovery" that athletes often take part in between exertions. Something productive, supportive, but secondary to the principle objective (a runner isn't at the race to stretch, but they stretch so they can continue to race).
That second point is important, managers hear sprint and they think speed. Any kind of slow down or delay makes them think that the team is just dicking around. The idea that a sprint could be spent on anything bringing indirect value (rather than direct) like test and deployment automation, refactoring and cleanup, or training is antithetical to this perception. Consequently you cannot, easily, put those activities into sprints, or you have to disguise them or mete them out over a series of sprints so that enough "real" value is being created from the management perspective.
Finally, "agile" is about responsiveness. The term was chosen for the manifesto deliberately. We don't look at Usain Bolt on race day and say, "Wow, that man is agile". But you would talk about the agility of a football player who loses speed dodging, avoiding, and leaping around a field to get a 100 yard touchdown. The agile player is responsive to opposition and present conditions. They do need to be fast, but their ultimate speed isn't just from raw speed but from their ability to maintain progress despite adverse conditions. A faster but less agile player could get lucky, but more often will get blocked. The use of the term "sprint" in Scrum conveys no real sense that adaptation and responsiveness are important.
In my experience sprints just represent artificial constructs that in the long run serve no real purpose. We end up saying strange things like "I won't be finished with X until next sprint", or "we took in 15 points this sprint". I've seen people become more interested in what I call "Jira ticket engineering" than the actual work.
In my experience sprints just represent artificial constructs that in the long run serve no real purpose
This is exactly what I meant by calling them nonsense. Calling them rounds or periods would have made much more sense. Especially since a coding sprint was already a thing, and meant lets ignore everything else and just write code for a few days.
I've seen people become more interested in what I call "Jira ticket engineering" than the actual work.
We use Rally, but I have seen the same thing. There is hope among some that switching to Jira will solve that problem.
This is exactly what I meant by calling them nonsense. Calling them rounds or periods would have made much more sense. Especially since a coding sprint was already a thing, and meant lets ignore everything else and just write code for a few days.
I've seen people become more interested in what I call "Jira ticket engineering" than the actual work.
We use Rally, but I have seen the same thing. There is hope among some that switching to Jira will solve that problem.
How about just using January, February ... etc instead of making up new words like sprint.
I don't understand. The impression I got from this thread is that the sentiment towards Scrum is mostly negative.
So why is Scrum so prominent in the software industry today? My guess it that, although bad, Scrum is not bad enough to actually completely destroy the productive of a team. Developers are still able to produce output despite the process. OTOH, mid-level managers are able to use Scrum to produce numbers/metrics to make the upper level happy, get promoted, move onto other companies, and make Scrum spread.
Is my view somewhat accurate? Is there anything we as developers can do to help improve our work environment? In the end, are we powerless against the wrath of the management?
So why is Scrum so prominent in the software industry today? My guess it that, although bad, Scrum is not bad enough to actually completely destroy the productive of a team. Developers are still able to produce output despite the process. OTOH, mid-level managers are able to use Scrum to produce numbers/metrics to make the upper level happy, get promoted, move onto other companies, and make Scrum spread.
Is my view somewhat accurate? Is there anything we as developers can do to help improve our work environment? In the end, are we powerless against the wrath of the management?
Agile/Scrum in limited doses to aspects of Software Development is basically common sense. Applying it mechanically to the entire Product/Project Development life cycle is dumb.
The "Agile Manifesto" is just well known platitudes.
Agile!: The Good, the Hype and the Ugly by Bertrand Meyer is a must read.
Summary: https://medium.com/@knL/i-just-read-agile-the-good-the-hype-...
Webcast: https://www.youtube.com/watch?v=ffkIQrq-m34
The "Agile Manifesto" is just well known platitudes.
Agile!: The Good, the Hype and the Ugly by Bertrand Meyer is a must read.
Summary: https://medium.com/@knL/i-just-read-agile-the-good-the-hype-...
Webcast: https://www.youtube.com/watch?v=ffkIQrq-m34
Honestly, what is the purpose of this post? Is HN really the place for clickbait? You would get the same reaction with something like "Do you think functional programming is beneficial for software delivery?" or "Do you think Christopher Alexander was a mediocre architect who just happened to be a mediocre computer scientist?" Please tell me that the person behind this is harvesting the names from this Op-Ed comment thread to build a feedbag for their mech turk. I can't wait to get my exclusive offer for all-natural, water-based, non-toxic lube.
Besides being a micromanager's dream, the whole concept of "blockers" in agile/scrum is just a way for companies to blame developers for the company's lack of resources and poor strategy (i.e. the team is too small for the amount and complexity of tasks, so there is no time to properly define and break down tasks, focus is on quantity/output instead of things actually working, management encourages a lone wolf mentality, etc.).
If you don't care about delivering broken software and having high engineer turnover, scrum is just fine.
If you don't care about delivering broken software and having high engineer turnover, scrum is just fine.
In my experience, when you see scrum, you will see an over-bureaucratic company with way more managers that engineers and, usually, those managers (call them product owners, project managers whatever) are the ones calling the shots which leads to all sorts of problems due to their general lack of technical knowledge and overfocus on "deliverables and customers needs".
And don't get me wrong: customer needs are the priority in every company that sells software or provides SW services. But one thing is what customer needs, and another is how to provide it to them.
More times than not, in those places, we ended up redesigning a feature in the middle of the development because it was designed by POs and other ilk only looking at customer needs, so that design didn't fit the system.
And don't get me wrong: customer needs are the priority in every company that sells software or provides SW services. But one thing is what customer needs, and another is how to provide it to them.
More times than not, in those places, we ended up redesigning a feature in the middle of the development because it was designed by POs and other ilk only looking at customer needs, so that design didn't fit the system.
The definition is just too loose and what we seem to wind up with in many cases is a Cargo Cult version of Agile/Scrum.
As an example, I have never had a PM/Team practice Agile/Scrum in a manner where the total amount of Work-in-Progress is something that gets paid attention to.
In my opinion this is a very serious error.
As an example, I have never had a PM/Team practice Agile/Scrum in a manner where the total amount of Work-in-Progress is something that gets paid attention to.
In my opinion this is a very serious error.
I've always seen it like a religion. The message is good, but some priests lose sight of it and focus too much on the ceremonies. When that fails, and the promise fails to manifest itself, they blame people for not following not following the ceremonies with sufficient zeal.
Yet if you look at the original scriptures, you don't find any ceremonies, just a message, and it's more like a guideline than a rule.
I like the message, but I don't like religious enforcement of the ceremonies. Some work, some don't. It depends on your team.
Yet if you look at the original scriptures, you don't find any ceremonies, just a message, and it's more like a guideline than a rule.
I like the message, but I don't like religious enforcement of the ceremonies. Some work, some don't. It depends on your team.
My biggest irritations with Scrum center around point assignment and the 'emergent architecture' on green-field projects.
In those areas, I think that simply following the Scrum ritual is not necessarily harmful, however it is almost surely _not enough_. At least one person needs to have read through the scattered stories, built a mental model of the project's function, and have enough experience to start forming a notion of how things will work given the resources available. Better yet, if everyone has done that and can collaborate on a sketch of the architecture. Without this, all of the points poker is just Ouija board voodoo for the non-tech stake holders because nobody could possibly know how much effort it will be to build that 'Implement a button to do-complicated-reporting-process' down in the backlog.
However, I have witnessed several teams where conversation around architecture and data model simply doesn't happen. On sprint one, everyone gets some stories, and goes off to do their thing. What you get is a minimally-coherent-to-satisfy-the-story data model and massive duplication of effort and code.
That problem should be taken care of with story grooming and the regular, deliberate, refactoring and tech-debt pay down but I don't see that happen very often in practice. Everyone is in too much of a hurry to stop and say 'wait, this code is demonstrably garbage and we're doing it wrong'. They just build around the weird, wrong, or inefficient parts and get their stories finished.
In those areas, I think that simply following the Scrum ritual is not necessarily harmful, however it is almost surely _not enough_. At least one person needs to have read through the scattered stories, built a mental model of the project's function, and have enough experience to start forming a notion of how things will work given the resources available. Better yet, if everyone has done that and can collaborate on a sketch of the architecture. Without this, all of the points poker is just Ouija board voodoo for the non-tech stake holders because nobody could possibly know how much effort it will be to build that 'Implement a button to do-complicated-reporting-process' down in the backlog.
However, I have witnessed several teams where conversation around architecture and data model simply doesn't happen. On sprint one, everyone gets some stories, and goes off to do their thing. What you get is a minimally-coherent-to-satisfy-the-story data model and massive duplication of effort and code.
That problem should be taken care of with story grooming and the regular, deliberate, refactoring and tech-debt pay down but I don't see that happen very often in practice. Everyone is in too much of a hurry to stop and say 'wait, this code is demonstrably garbage and we're doing it wrong'. They just build around the weird, wrong, or inefficient parts and get their stories finished.
I'm an IC and can't stand scrum. However I regularly work with teams that are steeped in it. It's not really an issue because I always choose my level of participation when working with one of the scrum teams.
If I think the level of process and granularity is overbearing I say "no thanks" and pull the "Individuals and interactions over process and tools". If there is one thing that I wish I would have learned earlier in my career is that it's really ok to say "no thanks".
If I think the level of process and granularity is overbearing I say "no thanks" and pull the "Individuals and interactions over process and tools". If there is one thing that I wish I would have learned earlier in my career is that it's really ok to say "no thanks".
"Agile" and related are terrible more often than not, in my experience, but they can be very good. I've seen a lot of different pathologies in them, but one quick diagnostic tool I'd suggest:
Can the team decide they don't need dedicated standups, and stop doing them until they decide they want them again?
If not—if management mandates them, if some single in-charge person (who may or may not also do some programming on the team) would, all on their own, be able to veto that change even if every single other person didn't want them, and even if offered alternatives to suit whatever needs they actually have, or if you'd feel uncomfortable even bringing it up even after you're pretty familiar with everyone there, or if you're not even sure when such a discussion might occur ("pretty much any time" is the best answer, but "during a retro, and only then" is... OK) then very probably the agile you're in is bad.
If that's something that could, plausibly, happen, then there's a decent chance it's the good kind.
One way to get a sense of this if you're new (even during an interview) at a place that actually claims to "do agile" and has done it for any length of time, would be to ask what they've changed about their process since starting. "Nothing", especially if accompanied by seeming baffled by the question, is such a bad sign I'm tempted to name it as sufficient evidence per se for a "run far away, very fast" reaction. Citing deliberate abandonment of or modification to any major agile "ritual", arrived at only after initially trying it the normal way and not just because some manager said to change it, but because the team wanted to, is a very good sign, though just because they haven't done that isn't necessarily bad. The point is: is agile a straight-jacket for the team, or just another tool to use as they like.
There are lots of other bad signs one might see (multiple teams in a standup, standups becoming perform-for-the-manager prove-you-did-work describe-every-little-detail-of-your-"struggles" garbage-micro-management-meetings ruining every single work-day, et c.) but that's an easy one that can be checked for even in the absence of other obvious problems.
Can the team decide they don't need dedicated standups, and stop doing them until they decide they want them again?
If not—if management mandates them, if some single in-charge person (who may or may not also do some programming on the team) would, all on their own, be able to veto that change even if every single other person didn't want them, and even if offered alternatives to suit whatever needs they actually have, or if you'd feel uncomfortable even bringing it up even after you're pretty familiar with everyone there, or if you're not even sure when such a discussion might occur ("pretty much any time" is the best answer, but "during a retro, and only then" is... OK) then very probably the agile you're in is bad.
If that's something that could, plausibly, happen, then there's a decent chance it's the good kind.
One way to get a sense of this if you're new (even during an interview) at a place that actually claims to "do agile" and has done it for any length of time, would be to ask what they've changed about their process since starting. "Nothing", especially if accompanied by seeming baffled by the question, is such a bad sign I'm tempted to name it as sufficient evidence per se for a "run far away, very fast" reaction. Citing deliberate abandonment of or modification to any major agile "ritual", arrived at only after initially trying it the normal way and not just because some manager said to change it, but because the team wanted to, is a very good sign, though just because they haven't done that isn't necessarily bad. The point is: is agile a straight-jacket for the team, or just another tool to use as they like.
There are lots of other bad signs one might see (multiple teams in a standup, standups becoming perform-for-the-manager prove-you-did-work describe-every-little-detail-of-your-"struggles" garbage-micro-management-meetings ruining every single work-day, et c.) but that's an easy one that can be checked for even in the absence of other obvious problems.
First of all: one thing is Agile, another thing is Scrum. Scrum is for people that need to be introduced with clear steps to Agile. Imho the best way to do Agile is Kanban but you need mature teams.
In my experience only one company of the six I worked for was doing real Agile. Really short stories, the entire team (inclusing devs) talking to the customer, meetings reduced to a minimum, xp practices all over the place. High value produced, happy customers.
What I noticed about it was that: - every single member of the team believed in it, so no protests - management believed in IT and paid for both agile and xp coaches - hiring was being done right, hr on the first call already clarified what we expected so zero false positives in the hiring phase, new hirings didn't need convincing - slow hiring. The majority of devs hates agile, scrum, pair programming, testing and talking to customers
I left after 5 years to try something new, I still don't find something as good as what I described above.
I then worked for both startups and corp but when they do it, they do it wrong: focused on the process and not on the outcome. People were told "scrum is mandatory because we are doing the digital transformation" or whatever. No measures of the outcome.
Anyway, I firmly believe in Agile, I saw it working in a product company that made billions.
Unfortunately the movement got polluted with consultants that need to sell their service so I personally think you need to get lucky to find a proper place to do it.
In my experience only one company of the six I worked for was doing real Agile. Really short stories, the entire team (inclusing devs) talking to the customer, meetings reduced to a minimum, xp practices all over the place. High value produced, happy customers.
What I noticed about it was that: - every single member of the team believed in it, so no protests - management believed in IT and paid for both agile and xp coaches - hiring was being done right, hr on the first call already clarified what we expected so zero false positives in the hiring phase, new hirings didn't need convincing - slow hiring. The majority of devs hates agile, scrum, pair programming, testing and talking to customers
I left after 5 years to try something new, I still don't find something as good as what I described above.
I then worked for both startups and corp but when they do it, they do it wrong: focused on the process and not on the outcome. People were told "scrum is mandatory because we are doing the digital transformation" or whatever. No measures of the outcome.
Anyway, I firmly believe in Agile, I saw it working in a product company that made billions.
Unfortunately the movement got polluted with consultants that need to sell their service so I personally think you need to get lucky to find a proper place to do it.
I was working on a few projects where SCRUM was used. All those projects - with only one exception - were screwed. On one project Daily Standups were always more than an hour (of the most valuable and most productive morning time) where we/they would talk mostly about topics I wasn't involved in. Reviews were 3 to 5 hours every second week... On another project estimates were in "story points" and projects manager had to "recalculate" them into man-days in order to be able to communicate with customers... And so on... Not a help for developers and for customers either... But on my current project - it is working! It is lightweight (most standups are finished in 5 minutes, Sprint Reviews are mostly finished in 30 to 75 minutes every third week), Sprint Plannings are short because we have regular Groomings (twice a week). Sprint Retro is also short (30 minutes). Groomings may be time consuming, but they are needed in order to understand what needs to be done in details. We estimate in man-days and break all tasks larger than 8 or 12 man-days into smaller one. Everybody must be able to pickup any task. If one finished his work, he must take the task with highest priority from the list (for current sprint). Sprints are 3 weeks long. I have to say this is the first time it is working for me as a developer. And business ("non-technical") people are satisfied, because they have much more insight into development and understand better how everything works. All new wishes and requests flow into Backlog and are prioritized and then groomed and estimated. So we spend in average weekly 30 minutes for ALL standups and 3 hours for grooming (which is actually part of planning). It is VERY lightweight and I like it the first time in my life. We are doing it in this way for 2 years now and nobody has any plans to change it.
They do bring value, but that value can greatly depend on how it’s implemented and what your team does. Personally I have found agile to be great the closer you are to the customer.
Agile at its core is about a few things: committing as a team to work (shared accountability), creating reasonable expectations of what can actually be delivered (as opposed to how much the boss wants to get done), creating a cadence of delivery that is aligned with value to the business, and continuous improvement (through metrics and retros). It’s not perfect, but an agile process run well creates consistency, which over the long run is very important.
Scrum is a way to force communication, create awareness, and adjust prioritization. A lot of people think this is a waste of time, but a high performing team requires excellent communication and this is one way to achieve that. If your team is not getting value out of it, that might mean people are too silo’d.
Having said all this, it’s all about how the team works together. These processes are meant to focus a team on delivering business value. If a team uses another process and performs well, there’s no reason to be dogmatic.
Agile at its core is about a few things: committing as a team to work (shared accountability), creating reasonable expectations of what can actually be delivered (as opposed to how much the boss wants to get done), creating a cadence of delivery that is aligned with value to the business, and continuous improvement (through metrics and retros). It’s not perfect, but an agile process run well creates consistency, which over the long run is very important.
Scrum is a way to force communication, create awareness, and adjust prioritization. A lot of people think this is a waste of time, but a high performing team requires excellent communication and this is one way to achieve that. If your team is not getting value out of it, that might mean people are too silo’d.
Having said all this, it’s all about how the team works together. These processes are meant to focus a team on delivering business value. If a team uses another process and performs well, there’s no reason to be dogmatic.
>but a high performing team requires excellent communication and this is one way to achieve that.
This is the problem: that sentence is backwards, as it is scrum. A high performance team HAVE excellent communication. So Scrum tries to force this hoping it will create a high performance team. Effect before the cause. Maybe if you are lucky, it would work... maybe.
This is the problem: that sentence is backwards, as it is scrum. A high performance team HAVE excellent communication. So Scrum tries to force this hoping it will create a high performance team. Effect before the cause. Maybe if you are lucky, it would work... maybe.
> what are the pros and cons of sprints
From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorities.
From the team/developer's POV, I personally feel like it gives me more freedom (I get to choose the tasks I want to work on, obviously in the limit of the sprint backlog) and a good ratio between work variety (I have the opportunity to work on something different every 2 weeks) and work stability/visibility (once the sprint planning is done, the sprint backlog normally won't change for 2 weeks).
> what are the pros and cons of daily standups
Ensure that everyone in the team is on the same boat. Encourage communication between developers<->developers and developers<->product manager.
I often read on HN that daily standups is micromanagement, but I've never felt it that way (in 10 years of doing agile/scrum in different companies, from the developer's POV as well as from the manager's POV). I guess it can vary from company to company and team to team tho.
From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorities.
From the team/developer's POV, I personally feel like it gives me more freedom (I get to choose the tasks I want to work on, obviously in the limit of the sprint backlog) and a good ratio between work variety (I have the opportunity to work on something different every 2 weeks) and work stability/visibility (once the sprint planning is done, the sprint backlog normally won't change for 2 weeks).
> what are the pros and cons of daily standups
Ensure that everyone in the team is on the same boat. Encourage communication between developers<->developers and developers<->product manager.
I often read on HN that daily standups is micromanagement, but I've never felt it that way (in 10 years of doing agile/scrum in different companies, from the developer's POV as well as from the manager's POV). I guess it can vary from company to company and team to team tho.
>> what are the pros and cons of sprints
> From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorities.
Or rather, from the team's PoV — to NOT change priorities for 2 weeks, to not have side channel communications, or random diversions from email or chats, and being able to focus for 2 weeks without getting carried away.
I've been in too many companies with an "inverted" org structure, dozens of managers trying to push stuff into a lone programmer (inverted pyramid). Being able to lock down the backlog, focus for 2 weeks, close the door on background requests (perfect reason "we're in the middle of the sprint"), and leave those managers to fight between themselves in the background on how to prioritize the next 2 weeks — it's a good thing.
> From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorities.
Or rather, from the team's PoV — to NOT change priorities for 2 weeks, to not have side channel communications, or random diversions from email or chats, and being able to focus for 2 weeks without getting carried away.
I've been in too many companies with an "inverted" org structure, dozens of managers trying to push stuff into a lone programmer (inverted pyramid). Being able to lock down the backlog, focus for 2 weeks, close the door on background requests (perfect reason "we're in the middle of the sprint"), and leave those managers to fight between themselves in the background on how to prioritize the next 2 weeks — it's a good thing.
> I get to choose the tasks I want to work on, obviously in the limit of the sprint backlog
This part always interests me because I've never worked on a team where it actually worked that way, or even made sense to work that way. You get a few people together, a cryptography expert, somebody who knows eMMC really well, everybody kinda knows USB, and one person with much stronger EE skills. And I do go fix a simple bug in the eMMC stack, but for new features its like, well this will take me 10x longer because I'll have to read some long spec. I have no relationship with the hardware folks who I might need to collaborate with. And during this time I guess the EE is having fun, but out of their element implementing Elliptic curve cryptography while the crypto person sits on their hands because they're only still on the team on the assurance that they'd never have to touch their hated SATA driver again?
It's not that I don't believe it works, I just wonder how it would work for me.
This part always interests me because I've never worked on a team where it actually worked that way, or even made sense to work that way. You get a few people together, a cryptography expert, somebody who knows eMMC really well, everybody kinda knows USB, and one person with much stronger EE skills. And I do go fix a simple bug in the eMMC stack, but for new features its like, well this will take me 10x longer because I'll have to read some long spec. I have no relationship with the hardware folks who I might need to collaborate with. And during this time I guess the EE is having fun, but out of their element implementing Elliptic curve cryptography while the crypto person sits on their hands because they're only still on the team on the assurance that they'd never have to touch their hated SATA driver again?
It's not that I don't believe it works, I just wonder how it would work for me.
Not sure how it could work in your case. I think the main use case for SCRUM is applications development (web, desktop, mobile, whatever). In that context you have a mixed team of backend and frontend developers, or even better (in my opinion) a team of full stack developers. And so, tasks are not gatekeeped behind domain expertise and everyone in the team is able to pick whatever they want. Some developers usually have more experience with some parts of the codebase, but it's a good opportunity for the other developers to get comfortable with it too (which is, by the way, highly encouraged from the company's POV, in case if the only developer who knows that part of the codebase leaves the company).
I think maybe it has to do with having "product teams." There is no worry that we'd collapse if our EE or crypto experts left, we've got many more, just not on this team. And having one product per team is not typical except for specific "products" I happen to be involved in, for both practical (this software is written much differently than anything else for many reasons) and historical (this team at one point worked on a similar in some ways, completely different in others, product in the past, that was in a different business unit, with a different target platform and a different customer, and when that whole class of products stopped existing, they were moved over here).
The daily stand-up is about communication and fostering quick information sharing and quick problem resolution.
That's also the reason they advocate that ideally the team should sit all together. In that ideal work the daily stand-up lasts only 5-10 minutes, it's not meant to be a dreaded status meeting where you talk for 5 minutes then try not to fall sleep for an hour...
That's also the reason they advocate that ideally the team should sit all together. In that ideal work the daily stand-up lasts only 5-10 minutes, it's not meant to be a dreaded status meeting where you talk for 5 minutes then try not to fall sleep for an hour...
at the stand-up everyone should sit together?
Yes. If by Agile you mean development practices like continuous integration (periodically integrating changes into a single environment so that the system can be tested) and creating short feedback loops like devs testing their code; and by Scrum you mean creating team routines for reviewing assumptions and the team talking directly to customers; and periodic reflection to improve processes, then yes, I do.
Daily Standups are supposed to be Daily Planning Sessions for the Team. But the common implementation has devolved into status update meetings.
So the con is that, more likely than not, it will be a status update meeting, in which case, a waste of most people's time.
If it's a Daily Planning Session, there are no cons, only pros.
The pro is team alignment, with each other and with project objectives and goals, with only a maximum of 24 hours for possible misalignment.
Misalignment is ALWAYS the problem. Daily Planning Sessions help mitigate that ineveitability.
Daily Standups are supposed to be Daily Planning Sessions for the Team. But the common implementation has devolved into status update meetings.
So the con is that, more likely than not, it will be a status update meeting, in which case, a waste of most people's time.
If it's a Daily Planning Session, there are no cons, only pros.
The pro is team alignment, with each other and with project objectives and goals, with only a maximum of 24 hours for possible misalignment.
Misalignment is ALWAYS the problem. Daily Planning Sessions help mitigate that ineveitability.
[deleted]
It depends. I would think of SCRUM as Getting Things Done for teams?
I.e. a popular set of productivity tools with a cottage industry of people trying to teach it behind it.
If you look at it as a set of tools, you can make something really tailor-made for your team and on occasion it lead to creating a truly bespoe process that fits our team needs and doesn't have anything to do with scrum anymore :-)
With things like standups, backlog refinements, storypoint estimation, based on my experience this works for team of 3 to 10 people, with a clear responsibility that work together on a project for at least 6 sprints (usually 2 weeks/sprint), where new work can wait for new sprint to start.
It helped us focus, storypoints started to work for estimating stuff after ~3 sprints, our managers got used to "no, we won't start working on it right away, put it in the backlog, you will join for prioritization anyway".
I.e. a popular set of productivity tools with a cottage industry of people trying to teach it behind it.
If you look at it as a set of tools, you can make something really tailor-made for your team and on occasion it lead to creating a truly bespoe process that fits our team needs and doesn't have anything to do with scrum anymore :-)
With things like standups, backlog refinements, storypoint estimation, based on my experience this works for team of 3 to 10 people, with a clear responsibility that work together on a project for at least 6 sprints (usually 2 weeks/sprint), where new work can wait for new sprint to start.
It helped us focus, storypoints started to work for estimating stuff after ~3 sprints, our managers got used to "no, we won't start working on it right away, put it in the backlog, you will join for prioritization anyway".
Now I want to be devils advocate and give you the "corporate" perspective -
You say Agile disrupts your "flow", makes you deliver buggy code and just work to close tickets like a drone?
Good! Who said code needs to be perfect and bug-free? remember Lean? Just get it out there! we can always fix things later.
From a business perspective - we are spending money to develop functionality, not our peoples skills. Tickets and tasks should result in adding value to the business, not to our codebase.
This is a cruel and unsustainable way of thinking, which will have your best developers leaving the company very quickly. But if you're an enterprise corp - you see them as interchangable "resources" anyway, and Agile helps you accomodate to them leaving by splitting the work to small bits and having no single owner.
This is also a way of looking at things...
You say Agile disrupts your "flow", makes you deliver buggy code and just work to close tickets like a drone?
Good! Who said code needs to be perfect and bug-free? remember Lean? Just get it out there! we can always fix things later.
From a business perspective - we are spending money to develop functionality, not our peoples skills. Tickets and tasks should result in adding value to the business, not to our codebase.
This is a cruel and unsustainable way of thinking, which will have your best developers leaving the company very quickly. But if you're an enterprise corp - you see them as interchangable "resources" anyway, and Agile helps you accomodate to them leaving by splitting the work to small bits and having no single owner.
This is also a way of looking at things...
> Tickets and tasks should result in adding value to the business
I mean, they should but its not always a direct path. Resolving tech debt should speed up delivery of future products and features. Do businesses actually understand that reasoning... not really from my experience. This is really just a lack of understanding or appreciation of nuance for how software is developed by non tech companies that have been forced to hire engineers and create engineering departments.
> Agile helps you accomodate to them leaving by splitting the work to small bits and having no single owner.
This only holds true if you have a team structure and organization that prevents specialists and keeps everyone as a generalist. I don't believe that's actually possible...
Instiutional knowledge is massive, and I feel its often vastly undervalued by companies when engineers decide to leave.
I mean, they should but its not always a direct path. Resolving tech debt should speed up delivery of future products and features. Do businesses actually understand that reasoning... not really from my experience. This is really just a lack of understanding or appreciation of nuance for how software is developed by non tech companies that have been forced to hire engineers and create engineering departments.
> Agile helps you accomodate to them leaving by splitting the work to small bits and having no single owner.
This only holds true if you have a team structure and organization that prevents specialists and keeps everyone as a generalist. I don't believe that's actually possible...
Instiutional knowledge is massive, and I feel its often vastly undervalued by companies when engineers decide to leave.
Anecdotal, but your experience seems to match well with my understanding of the dark side of scrum/standup.
Holding all else constant I hope to have a job where I am not on the spot for making some unknown amount of tangible progress every 24 hrs. Deep work cannot take place in short, consistent staccato steps. Sometimes big moves forward happen in a day. More often it’s a day better spent thinking hard, rather than thrashing around for quick answers.
Moreover, if I have to ask for extra help to make progress quickly and consistently, I miss out on the learning that trying things myself would provide.
In addition to being very unfulfilling, this means that I do not grow to properly understand the codebase in a timely fashion. This means I will under achieve over the long haul. All the better to judge me inferior I suppose. It can be quite toxic.
Holding all else constant I hope to have a job where I am not on the spot for making some unknown amount of tangible progress every 24 hrs. Deep work cannot take place in short, consistent staccato steps. Sometimes big moves forward happen in a day. More often it’s a day better spent thinking hard, rather than thrashing around for quick answers.
Moreover, if I have to ask for extra help to make progress quickly and consistently, I miss out on the learning that trying things myself would provide.
In addition to being very unfulfilling, this means that I do not grow to properly understand the codebase in a timely fashion. This means I will under achieve over the long haul. All the better to judge me inferior I suppose. It can be quite toxic.
No. Scrum is a horrible way of working that disempowers developers, silos them away from stakeholders and customers, and prioritises middle management over product designers. Its only selling point is the juxtaposition against the straw man “Waterfall”.
Scrum is incompatible with Agile principles.
Scrum is incompatible with Agile principles.
I wouldn't say Scrum is incompatible but it's very often done in a way which is antithetical to Agile principles.
Regarding Waterfall, it's not a strawman. I've witnessed many Waterfall projects over the years at my offices. Two of the most spectacular were planned on the order of 5 years, one failing spectacular, the other only "succeeding" because the follow-on project was started 2 years into it and still had 2 years remaining, so they deployed the completed one.
They really did follow the moronic linear flow Royce said doesn't work (at scale). The spectacular failure was billions of dollars worth of work wasted as it turned out they didn't build what was needed. Another project was started to replace it before they even finished testing and deployment.
Regarding Waterfall, it's not a strawman. I've witnessed many Waterfall projects over the years at my offices. Two of the most spectacular were planned on the order of 5 years, one failing spectacular, the other only "succeeding" because the follow-on project was started 2 years into it and still had 2 years remaining, so they deployed the completed one.
They really did follow the moronic linear flow Royce said doesn't work (at scale). The spectacular failure was billions of dollars worth of work wasted as it turned out they didn't build what was needed. Another project was started to replace it before they even finished testing and deployment.
Agile is there for the convenience of managers. The language of its manifesto has been essentially weaponised, in my opinion. The idea was to give more power to expert programmers that cared for the user without the constraints of bureaucratic procurements. And instead, what we got is something remarkably similar to Jeremy Bentham's Panopticon.
It has backfired, because most organizations cherrypick what they want about Agile, and discard what doesn't adjust to the "way we do things here".
In case this resonates with someone, I wrote more about it here: https://alvaroduran.com/essays/against-agile/
It has backfired, because most organizations cherrypick what they want about Agile, and discard what doesn't adjust to the "way we do things here".
In case this resonates with someone, I wrote more about it here: https://alvaroduran.com/essays/against-agile/
At most of the teams that have done this sort of thing IME, it has been a disaster.
However, I spent some time working with contractors at Pivotal and I met an EM at one employer, and these people seem to take this stuff super seriously and get good results. The difference is that they do not just have standups and backlog grooming and retrospective. They do EXTREME PROGRAMMING. I am not sure if this is suitable for all kinds of work, but it was highly productive in my experience.
In that case though, the answer to your question is still "no," because there is no extra bureaucracy and because the points exist to serve the team rather than management.
However, I spent some time working with contractors at Pivotal and I met an EM at one employer, and these people seem to take this stuff super seriously and get good results. The difference is that they do not just have standups and backlog grooming and retrospective. They do EXTREME PROGRAMMING. I am not sure if this is suitable for all kinds of work, but it was highly productive in my experience.
In that case though, the answer to your question is still "no," because there is no extra bureaucracy and because the points exist to serve the team rather than management.
I worked for Pivotal and it's pretty much the place that got it right. But the process isn't just a process. A lot of the magic was in careful hiring and deeply thoughtful, caring leadership.
Agile, yes. Very much so. I remember developing pre-Agile and the endless Gantt charts and delivery milestones that never happened.
Being able to throw all of that in the bin and just say "we're Agile, so it'll be ready when we all agree it's ready, and we'll direct effort where we think it's most needed as we go" is awesome.
I've never worked with Scrum, but I have solid negative opinions on it (so hopefully I never have to). One of the core parts of the Agile Manifesto is "people before process" and Scrum is all process, so I'm always confused as to how the two became synonymous.
Being able to throw all of that in the bin and just say "we're Agile, so it'll be ready when we all agree it's ready, and we'll direct effort where we think it's most needed as we go" is awesome.
I've never worked with Scrum, but I have solid negative opinions on it (so hopefully I never have to). One of the core parts of the Agile Manifesto is "people before process" and Scrum is all process, so I'm always confused as to how the two became synonymous.
Agile/Scrum is nothing more than a product that Martin Fowler and Thoughtworks publicized for their own good (money wise). Outside of that it is just another buzzword driven development which gets nothing done.
I see mostly pros in agile, especially compared to the waterfall methods it replaced. Of course there is no methodology that cannot be wrecked by stupidity and pretense. Done well I have seen the following benefits from sprints and standups:
* Sprints - Instill a sense of urgency - Reduce scope to a manageable set - Allow for short-term planning and reflection (and short term is the only term that works) - Align the team
* Daily Standups - Provide a relatively cheap and high-bandwidth way to disseminate information. - Keep the team bonded and allow for early course corrections.
* Sprints - Instill a sense of urgency - Reduce scope to a manageable set - Allow for short-term planning and reflection (and short term is the only term that works) - Align the team
* Daily Standups - Provide a relatively cheap and high-bandwidth way to disseminate information. - Keep the team bonded and allow for early course corrections.
Software projects fail because some non-technical folks want to hit a timeline, linearly chunk tasks and flog team to "giet-it-done" until it is "done-done". So what does the developer do? 1. Get whatever it takes to ship the product - 5millisecond or 500 millisecond latency does not matter, most of the algos that could be constatnt are not...Gee wonder why Zoom is 91B and Cisco is 191B, assuming Webex is identical to Zoom.And oh, the churn....The scrum is designed to stretch the system to its breaking point and keep it there...
One approach I want to try one day is described here in the Shape up book. It's free and takes around 2-3 hours to read cover to cover. The idea I liked the most is that it made me shift from "How much effort and time we need to solve the problem" to "How much effort we are willing to spend on solving the problem, then find a solution that matches that 'hunger', 'willingness'". It makes simplifications of solutions viable.
But the books is full of gems, so my two sentence overview doesn't do it justice. Read it here https://basecamp.com/shapeup
With that said, I don't expect any manager to allow us to try out. People love that they can hear people every day that they are all very busy.
My current Scrum experience is from a large retail company. Our mobile app team of ~8 devs tries to keep up with the web team of ~50 devs (or even more, I just started and we work remote, I have no clue about the exact numbers).
The schedule, roadmap is mapped out for at least the next year.
Then, the Scrum doesn't make any sense. We can't decide what's important for the user. We can't work on bugs (that makes the lives of our users miserable) because we work on big feature launch X, and if we don't finish, it will jeopardize big migration Y in 2 months, and then it'll make big relaunch in Country Z impossible in 4 months.
It's waterfall with two-week crunch times and daily standups. And our ratings in the app store are constantly declining. But hey, at least we are on time, no matter how terrible our app is, in Jira it says it's shipped so don't whine about software and product quality.
During my whole career (about 5-ish years), I didn't find a place where a standup every day made sense. I think two or three sync-sessions per week would be perfect. Daily standups just made anxious, nobody listens to the others, you either say too little or too much, and the original promise of standups just didn't match my every day experience: we never found blockers we wouldn't have found otherwise, etc... In my opinion, pair/group programming (2-3 ppl) is thousand times better.
But the books is full of gems, so my two sentence overview doesn't do it justice. Read it here https://basecamp.com/shapeup
With that said, I don't expect any manager to allow us to try out. People love that they can hear people every day that they are all very busy.
My current Scrum experience is from a large retail company. Our mobile app team of ~8 devs tries to keep up with the web team of ~50 devs (or even more, I just started and we work remote, I have no clue about the exact numbers).
The schedule, roadmap is mapped out for at least the next year.
Then, the Scrum doesn't make any sense. We can't decide what's important for the user. We can't work on bugs (that makes the lives of our users miserable) because we work on big feature launch X, and if we don't finish, it will jeopardize big migration Y in 2 months, and then it'll make big relaunch in Country Z impossible in 4 months.
It's waterfall with two-week crunch times and daily standups. And our ratings in the app store are constantly declining. But hey, at least we are on time, no matter how terrible our app is, in Jira it says it's shipped so don't whine about software and product quality.
During my whole career (about 5-ish years), I didn't find a place where a standup every day made sense. I think two or three sync-sessions per week would be perfect. Daily standups just made anxious, nobody listens to the others, you either say too little or too much, and the original promise of standups just didn't match my every day experience: we never found blockers we wouldn't have found otherwise, etc... In my opinion, pair/group programming (2-3 ppl) is thousand times better.
Alistair Cockburn used to talk a lot about the contextual aspects of agile and how you need different levels of process rigour and ceremony at different levels of scale (number of project members) and different levels of criticality (e.g. are you building a sign-up form for the Christmas party or the control system for a surgical robot).
Whether people say it is good or bad, it is useful to understand the context, scale and criticalilty where they came to that conclusion. Otherwise it is very difficult to compare answers.
Whether people say it is good or bad, it is useful to understand the context, scale and criticalilty where they came to that conclusion. Otherwise it is very difficult to compare answers.
In my personal experience, sprints are mostly a waste of time. They're maybe useful when you really need regular updates about the status of a project with clear milestones, but I think the software world (or some corners of it, anyway) are coming around to the "It's ready when it's ready" mentality rather than crunching for arbitrary deadlines. So I personally prefer something more like Kanban. I use that both professionally and personally.
I also don't like points generally. To some degree you need some kind of estimate, but estimations are notoriously inaccurate, so just embrace that and stick a "days/weeks/months" label on something and call it a day (though if it is weeks or months, it should probably be broken down, but I do that on-the-fly as I arrive at those bigger tasks and develop an understanding of what's involved).
I actually do find standups useful in my experience, because in my team we have a couple individual contributors working largely independently on independent components of an overall software suite. Some of them are new and so might try reinventing wheels we've already solved in other compartments. By having a dedicated time for people to just talk about what they're doing, more senior developers can catch when wheel-invention is happening and steer the more junior developers towards existing solutions.
But above all, don't cargo-cult any practice. Find what works for a specific team and run with it, because different teams have different needs. That's the real essence of Agile.
I also don't like points generally. To some degree you need some kind of estimate, but estimations are notoriously inaccurate, so just embrace that and stick a "days/weeks/months" label on something and call it a day (though if it is weeks or months, it should probably be broken down, but I do that on-the-fly as I arrive at those bigger tasks and develop an understanding of what's involved).
I actually do find standups useful in my experience, because in my team we have a couple individual contributors working largely independently on independent components of an overall software suite. Some of them are new and so might try reinventing wheels we've already solved in other compartments. By having a dedicated time for people to just talk about what they're doing, more senior developers can catch when wheel-invention is happening and steer the more junior developers towards existing solutions.
But above all, don't cargo-cult any practice. Find what works for a specific team and run with it, because different teams have different needs. That's the real essence of Agile.
I've seen it work, and work really well, on a team with all "A" players, and with a guy (just one of the team, not a "scrum master" or anything) who really understood how to run an agile team.
And then I've seen it fall apart, in the exact same place, because upper management wasn't getting progress reports in terms they understood.
It can work, and work well. But it's far less automatic than people think, and far more likely to turn into cargo cult agile.
And then I've seen it fall apart, in the exact same place, because upper management wasn't getting progress reports in terms they understood.
It can work, and work well. But it's far less automatic than people think, and far more likely to turn into cargo cult agile.
This is the problem with all fads. They are usually great ideas pulled from smart and capable teams, but, then the soulless "how many flair do you have?" companies try to replicate it. They eventually take over the fad, and instead of becoming smart and capable themselves, they make the fad soulless and "how many flair do you have?" This is exactly what happened to Agile.
For me, scrum is really about splitting code development into 2 week chunks called "sprints". And I like that.
So instead of, on hand, having constant daily storm of thing, or, on the other hand, having tasks that take forever and never end, you have time-boxed 2 weeks sprints that you plan beforehand and do them. It's not overly planned for the next year, it's also not no planning, it's "just right". Management is happy that they see what is going on, developers are happy that they are not micromanaged.
Daily meetup is just to check up how things are going. It's good, but it needs to be really checked by someone to not exceed some time and not be yet-another 1 hour meeting.
All the other things can be safely ignored; all those managers and owners and masters, they would exist with or without scrum and they effectively don't matter all that much.
What I do hate is "story points" and "velocity", because they at the same time don't mean anything and do mean something. In my head I convert them to "mandays". I don't know why people don't call them "mandays". "But they are not mandays" you say... well they mostly are, let's call them that.
I never had experience with all the other weird rituals like the cards.
So instead of, on hand, having constant daily storm of thing, or, on the other hand, having tasks that take forever and never end, you have time-boxed 2 weeks sprints that you plan beforehand and do them. It's not overly planned for the next year, it's also not no planning, it's "just right". Management is happy that they see what is going on, developers are happy that they are not micromanaged.
Daily meetup is just to check up how things are going. It's good, but it needs to be really checked by someone to not exceed some time and not be yet-another 1 hour meeting.
All the other things can be safely ignored; all those managers and owners and masters, they would exist with or without scrum and they effectively don't matter all that much.
What I do hate is "story points" and "velocity", because they at the same time don't mean anything and do mean something. In my head I convert them to "mandays". I don't know why people don't call them "mandays". "But they are not mandays" you say... well they mostly are, let's call them that.
I never had experience with all the other weird rituals like the cards.
I personally find the ritual boring but it's not without its value. Below are a few points I've found useful to me personally.
1. I get to see the progress of the project as a whole on a daily basis. Without the stand ups, I probably would have no idea how and what we are doing as a team and I'll just be doing my own thing.
2. There were times I mentioned an issue I ran into and others chipped in with helpful ideas (sometimes even the solution) saving me time. If it weren't for the stand up, I would have just solved it on my own anyway but could have taken more time. In a way, this opens up a helpline.
3. If you are a team lead, this can help make things more predictable. There's an understanding what everyone is expected to do in a regular meeting than scheduling meetings when you think is needed but others may not have the same motivation for a meeting and can end up same few people talking every time.
I hate meetings in general, but I hate surprises even more. So, seeing meetings pop up suddenly on my calendar is something I really dislike. Agile and the stand ups at least make things predictable like short 20 minute meetings every day. After I get through that, I know I'm not gonna be bothered again for the day :)
1. I get to see the progress of the project as a whole on a daily basis. Without the stand ups, I probably would have no idea how and what we are doing as a team and I'll just be doing my own thing.
2. There were times I mentioned an issue I ran into and others chipped in with helpful ideas (sometimes even the solution) saving me time. If it weren't for the stand up, I would have just solved it on my own anyway but could have taken more time. In a way, this opens up a helpline.
3. If you are a team lead, this can help make things more predictable. There's an understanding what everyone is expected to do in a regular meeting than scheduling meetings when you think is needed but others may not have the same motivation for a meeting and can end up same few people talking every time.
I hate meetings in general, but I hate surprises even more. So, seeing meetings pop up suddenly on my calendar is something I really dislike. Agile and the stand ups at least make things predictable like short 20 minute meetings every day. After I get through that, I know I'm not gonna be bothered again for the day :)
As someone who has worked in Project Management of Bridges, Enterprise ERP transformations and everything in between, there are definitely benefits in certain use cases. It really comes down to the type of "thing" being delivered and how to deal with the inherent risk.
Agile works best in environments where the scope or execution methodology can not be discerned up-front or where it is crucial you need assurance that expectations are aligned. Your risk profile is much higher due to the number of unknowns, so a lot of time is spent doing work "around" the design and delivery of said thing to mitigate all that risk. As such, it works well for mostly corporeal endeavors such as building new software, or things that . This helps operationalize a feedback loop of try, test, re-align, try, test... etc. across stakeholder groups to help make small rapid course corrections until you get to where you need to go or abandon at an optimum time without marching like lemmings to a cliff.
It also works well in technical environments where there is a lot of collaboration and interfacing between different specialized groups. Forcing everyone to come together and be accountable for their dependencies to each other reduces those instances where blockers, compounding delays and finger pointing send things off the rails.
Estimating, assigning, controlling and monitoring, what you would typically term "earned value", in a project management sense is extremely difficult for these types of things. If the scale of work is large things naturally land on amounts that aggregate up to something useful
The two things I often see in agile projects/organizations that are often done poorly and lead to failure are:
- Maintaining a proper understanding and separation of the delivery risk (risk associated with building, creating) and the delivered risk (the risk you've baked into the "thing" by aspects of its design)
- Not allowing for or tracking risk mitigation, or how residual risk is trending
- Thinking because every project is unique that they are unique and therefore need a unique way of managing the project (i.e. re-inventing basic project management methods)
- Thinking your business is unique (it's not, less than 10% at most) and that therefore everything you do, including how you execute projects is unique (you don't).
Agile works best in environments where the scope or execution methodology can not be discerned up-front or where it is crucial you need assurance that expectations are aligned. Your risk profile is much higher due to the number of unknowns, so a lot of time is spent doing work "around" the design and delivery of said thing to mitigate all that risk. As such, it works well for mostly corporeal endeavors such as building new software, or things that . This helps operationalize a feedback loop of try, test, re-align, try, test... etc. across stakeholder groups to help make small rapid course corrections until you get to where you need to go or abandon at an optimum time without marching like lemmings to a cliff.
It also works well in technical environments where there is a lot of collaboration and interfacing between different specialized groups. Forcing everyone to come together and be accountable for their dependencies to each other reduces those instances where blockers, compounding delays and finger pointing send things off the rails.
Estimating, assigning, controlling and monitoring, what you would typically term "earned value", in a project management sense is extremely difficult for these types of things. If the scale of work is large things naturally land on amounts that aggregate up to something useful
The two things I often see in agile projects/organizations that are often done poorly and lead to failure are:
- Maintaining a proper understanding and separation of the delivery risk (risk associated with building, creating) and the delivered risk (the risk you've baked into the "thing" by aspects of its design)
- Not allowing for or tracking risk mitigation, or how residual risk is trending
- Thinking because every project is unique that they are unique and therefore need a unique way of managing the project (i.e. re-inventing basic project management methods)
- Thinking your business is unique (it's not, less than 10% at most) and that therefore everything you do, including how you execute projects is unique (you don't).
The daily standup is not part of agile.
Agile is defined here: http://agilemanifesto.org/
Agile is defined here: http://agilemanifesto.org/
The manifesto lists principles. Principles must be implemented and turned into processes in order to actually produce software. Scrum's daily stand-up is a process, a tool, to implement the following principle:
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
And it also contributes to this one:
"The best architectures, requirements, and designs emerge from self-organizing teams."
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
And it also contributes to this one:
"The best architectures, requirements, and designs emerge from self-organizing teams."
I believe the daily standup is part of XP (http://www.extremeprogramming.org) which is an Agile Method.
It's part of Scrum, which itself is also an agile method.
"Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress"
Agile is for quick feedback on made progress, to compare it to expected progress and to be able to report your progress and forecast to business people to let them know how far behind the schedule you are as quickly as possible.
Let's say it's January and you need to deliver a product with a 200 use cases on July. After just a few first iterations you will be able to tell if you can deliver all use cases on July or quickly give feedback to business people that you won't be able to. From there you have options: close the project and stop investing time and money in it, add people to the project because you got your info very quickly that you won't be able to make the deadline in 6 months.
Uncle Bob talks about it in depth in one of his lectures here: https://youtu.be/SVRiktFlWxI https://youtu.be/qnq9syXUuFE
And in his book Clean Agile: Back to basics.
Let's say it's January and you need to deliver a product with a 200 use cases on July. After just a few first iterations you will be able to tell if you can deliver all use cases on July or quickly give feedback to business people that you won't be able to. From there you have options: close the project and stop investing time and money in it, add people to the project because you got your info very quickly that you won't be able to make the deadline in 6 months.
Uncle Bob talks about it in depth in one of his lectures here: https://youtu.be/SVRiktFlWxI https://youtu.be/qnq9syXUuFE
And in his book Clean Agile: Back to basics.
"Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress"
Agile is for quick feedback on made progress, to compare it to expected progress and to be able to report your progress and forecast to business people to let them know how far behind the schedule you are as quickly as possible.
Let's say it's January and you need to deliver a product with a 200 use cases on July. After just a few first iterations you will be able to tell if you can deliver all use cases on July or quickly give feedback to business people that you won't be able to. From there you have options: close the project and stop investing time and money in it, add people to the project because you got your info very quickly that you won't be able to make the deadline in 6 months.
Uncle Bob talks about it in depth in one of his lectures here:
https://youtu.be/SVRiktFlWxI?t=1807
https://youtu.be/qnq9syXUuFE?t=3400
And in his book Clean Agile: Back to basics.
Agile is for quick feedback on made progress, to compare it to expected progress and to be able to report your progress and forecast to business people to let them know how far behind the schedule you are as quickly as possible.
Let's say it's January and you need to deliver a product with a 200 use cases on July. After just a few first iterations you will be able to tell if you can deliver all use cases on July or quickly give feedback to business people that you won't be able to. From there you have options: close the project and stop investing time and money in it, add people to the project because you got your info very quickly that you won't be able to make the deadline in 6 months.
Uncle Bob talks about it in depth in one of his lectures here:
https://youtu.be/SVRiktFlWxI?t=1807
https://youtu.be/qnq9syXUuFE?t=3400
And in his book Clean Agile: Back to basics.
Below is not just my experience, but also from other teams I have worked with over the past 10 years in an agile / scrum setting.
Sprints:
- pros
Helps to avoid continuous changing direction at request of stakeholders. 2 week sprint feel really good as planning horizon: not too long, not too short. Teams do not commit to anything beyond that timeline. Any roadmap commitments are based on stats and product owner responsibility. Team is not accountable for any missed deadlines.
- Cons:
It can feel like wash-rinse-repeat sometimes. Can be a killer for flow and feel inflexible when you are nearly there (getting it done) and the sprint review interrupts the flow. If the balance is bad you should probably look at kanban.
Daily’s:
- Pros
Excellent way to find out if team members need help or some syncing is needed. If done well team will “feel” if your getting closer to getting everything done. With work from home good to see everyone on the team at least once a day.
-Cons:
Hard to get right. Should be about inspection by the team to help adapt the plan and get to your goal, but this is often forgotten. Might become a way to “control” the team and put pressure on people and check for performance of individuals.
As for micromanagement: this is not exclusively found in agile / scrum. A micromanager will find a way to abuse any method to “control” their world. If you let go, set a clear purpose and direction, start helping team members to get more autonomous you will find that performance goes beyond what micromanagement can achieve.
Scrum (as defined in the scrum guide) can work, when it doesn’t: adapt and try again.
Sprints:
- pros
Helps to avoid continuous changing direction at request of stakeholders. 2 week sprint feel really good as planning horizon: not too long, not too short. Teams do not commit to anything beyond that timeline. Any roadmap commitments are based on stats and product owner responsibility. Team is not accountable for any missed deadlines.
- Cons:
It can feel like wash-rinse-repeat sometimes. Can be a killer for flow and feel inflexible when you are nearly there (getting it done) and the sprint review interrupts the flow. If the balance is bad you should probably look at kanban.
Daily’s:
- Pros
Excellent way to find out if team members need help or some syncing is needed. If done well team will “feel” if your getting closer to getting everything done. With work from home good to see everyone on the team at least once a day.
-Cons:
Hard to get right. Should be about inspection by the team to help adapt the plan and get to your goal, but this is often forgotten. Might become a way to “control” the team and put pressure on people and check for performance of individuals.
As for micromanagement: this is not exclusively found in agile / scrum. A micromanager will find a way to abuse any method to “control” their world. If you let go, set a clear purpose and direction, start helping team members to get more autonomous you will find that performance goes beyond what micromanagement can achieve.
Scrum (as defined in the scrum guide) can work, when it doesn’t: adapt and try again.
Sounds like you are not doing scrum. And I only know of the term 'daily' being prt of the scrum process.
So. If you're not doing scrum you are not leveraging it's potential and even more important, its rules.
The rules of a daily is non-disputable. It has a formula. If you're not following the formula, it's not scrum.
A daily is not about progress. It's about communication. You communicate what you did since the last daily, and what you expect to do before the next.
But you're not being measured on what you communicated. You are merely sharing what you' re doing.
If there is discussion in a daily, it's not a daily. If you're not using a board for the baseline for communicating, you're fucked.
The role of a scrum master is to take note of what is going on and help out if she hears anything that sounds off. A good scrum master is a bit like a dictator. Focused, on top of things, helpful and listens to what is going on and does not bend to outsiders.
Good scrum masters are hard to come by. That's most often imo, why scrum had a bad rep in some places.
Also remember, agile is something that must happen on a top level, otherwise it will not work very well.
So. If you're not doing scrum you are not leveraging it's potential and even more important, its rules.
The rules of a daily is non-disputable. It has a formula. If you're not following the formula, it's not scrum.
A daily is not about progress. It's about communication. You communicate what you did since the last daily, and what you expect to do before the next.
But you're not being measured on what you communicated. You are merely sharing what you' re doing.
If there is discussion in a daily, it's not a daily. If you're not using a board for the baseline for communicating, you're fucked.
The role of a scrum master is to take note of what is going on and help out if she hears anything that sounds off. A good scrum master is a bit like a dictator. Focused, on top of things, helpful and listens to what is going on and does not bend to outsiders.
Good scrum masters are hard to come by. That's most often imo, why scrum had a bad rep in some places.
Also remember, agile is something that must happen on a top level, otherwise it will not work very well.
"But you're not being measured on what you communicated. You are merely sharing what you' re doing."
This is never true. Its a daily confession of what you did. Its micromanagement.
This is never true. Its a daily confession of what you did. Its micromanagement.
The way you talk about this makes it sound like you are in a very bureaucratic world. The original idea of agile/scrum was to cut down this bureaucracy and only keep what is actually useful. But in most practical cases one still needs some degree of structured communication. The degree of structured communication could then perhaps be the famous scrum ceremonies. However, the way you talk about it, it sounds like the scrum ceremonies come in addition to the already existing bureaucracy. To me that sounds like putting the cart in front of the horse. A more agile way of looking at it would be to look to some bureaucratic procedures that seem burdensome and replace them with something lighter. The famous scrum ceremonies could be taken as suggestions if you like.
It also sounds like there is not very much trust between team members. You immediately go to 'signalling progress vs. actually making progress'.... The scrum ceremonies are actually meant to support an environment where developers trust each other and one developer helps another when s/he could use it.
It also sounds like there is not very much trust between team members. You immediately go to 'signalling progress vs. actually making progress'.... The scrum ceremonies are actually meant to support an environment where developers trust each other and one developer helps another when s/he could use it.
I think that it takes freedoms and responsibilities away from developers, chops work into chunks that are too small, forces constant arbitrary deadlines and a lack of a relaxed pace (they are not called "sprints" for nothing), and incentivizes under-estimation to "fit things in", resulting in overloading or overruns. It also treats developers as fungible which is very much not the case if specialist skills are not evenly distributed. The constant "scrum meetings" serve as an unwelcome goad and very rarely convey information that anyone except micromanagers care about.
Editing to add: learning is an important part of being a programmer. Experimenting, reading the manual, trying it out, these are all things that get managed out, when you have to beg for "spike" time to do them, and somebody else doesn't see the importance.
The upsides are that it does make it somewhat easier to pivot or to shelve-and-resume when you know which of the bitty pieces are still to do, and it makes long term estimates slightly less arbitrary.
Editing to add: learning is an important part of being a programmer. Experimenting, reading the manual, trying it out, these are all things that get managed out, when you have to beg for "spike" time to do them, and somebody else doesn't see the importance.
The upsides are that it does make it somewhat easier to pivot or to shelve-and-resume when you know which of the bitty pieces are still to do, and it makes long term estimates slightly less arbitrary.
I still think it's wrong to conflate the two, at the very least.
Agile gives you principles as to how to envision developing software. Scrum is just one implementation that tries to follow these principles.
I'm not a fan of Scrum, although I can understand why some of its components could be attractive. Velocity for example is interesting, as it's an attempt to empirically measure how "fast" a team can develop, and base estimations on that instead of just throwing a bunch of hours/days as an estimate when in fact it's hard to do that. I still think it doesn't work well to solve this, but to be fair I don't think there's a single method that solves it.
In the end, I think Agile is beneficial (in my experience!) but more importantly that you need to use and tailor a software development methods to your own needs and context, and stop blindly following existing models but instead see them just as what they are: tools.
As another example since you mentioned it: daily standups can be good, or terrible, it depends what you make of these. I've worked in a company where it was basically a "scheduled waste of time", but I moved to a place where we mixed it with basically a "hey good morning" type of coffee break and it worked rather well in a casual way, chatting up what was coming and that's it. And we keep in mind that if some kind of "ritual" becomes useless, then we skip it altogether as soon as we agree there's no value in it.
That last part feels important to me because that's ultimately where a key aspect lie: when you say it's a "micromanagers' dream", I think it just shows that the software development method can always be twisted and hijacked by some people given enough power/representation/influence.
Agile gives you principles as to how to envision developing software. Scrum is just one implementation that tries to follow these principles.
I'm not a fan of Scrum, although I can understand why some of its components could be attractive. Velocity for example is interesting, as it's an attempt to empirically measure how "fast" a team can develop, and base estimations on that instead of just throwing a bunch of hours/days as an estimate when in fact it's hard to do that. I still think it doesn't work well to solve this, but to be fair I don't think there's a single method that solves it.
In the end, I think Agile is beneficial (in my experience!) but more importantly that you need to use and tailor a software development methods to your own needs and context, and stop blindly following existing models but instead see them just as what they are: tools.
As another example since you mentioned it: daily standups can be good, or terrible, it depends what you make of these. I've worked in a company where it was basically a "scheduled waste of time", but I moved to a place where we mixed it with basically a "hey good morning" type of coffee break and it worked rather well in a casual way, chatting up what was coming and that's it. And we keep in mind that if some kind of "ritual" becomes useless, then we skip it altogether as soon as we agree there's no value in it.
That last part feels important to me because that's ultimately where a key aspect lie: when you say it's a "micromanagers' dream", I think it just shows that the software development method can always be twisted and hijacked by some people given enough power/representation/influence.
> Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
There are about a million discussions about how broken Agile is, most of which discuss some abomination of a process with very superficial similarities to Agile. It's not like having a standup is some sort of magically good thing on its own if people just use it to do things the way they've always done them.
Cue the inevitable "If everybody is doing Agile wrong, maybe there's something wrong with Agile?" response, to which I would simply say that I've seen Agile work in at least two completely different workplaces, and I've seen how terrible non-Agile processes are in at least another two.
The pros and cons are typically thought of as intrinsic properties of Agile in general. But they are not.
Agile has a number of assumptions regarding organizational culture and the people involved on the project. Those assumptions are usually not discussed very often, which is bad, since I believe they are typically related to those many cases of failed Agile implementations that end up getting different explanations depending on how one likes/dislikes Agile.
To summarize what I'd like to answer about your question:
Pros:
- They are great tools to break larger projects into smaller chunks and to keep track of their progresses. Experience shows that it's easier to reach success on smaller projects, and sprints and daily meetings are ways of emulate such sort of project even when working on larger ones.
- There's an opportunity of catching and fixing schedule slippages, requirements misunderstandings and other sorts of deviations before they get too expensive to fix.
Cons:
- You need a bigger deal of maturity and commitment of people involved. As IT professionals, we usually complain about users being unprepared for working on Agile projects, but we have to admit that many professionals show a significant decrease in performance when they are not under a certain level of healthy pressure.
- When you favor people over processes and communication over documentation, a higher level of mutual trust is required. You can't find that everywhere, for a number of reasons. Some say that such organizations are not prepared to work under Agile rules. Some are more pragmatic and adapt. I stick with the latter. Agile talks a great deal about embracing change on requirements, and I don't see what is the point of being a purist and refusing to adapt the method to deal with risks.
Agile has a number of assumptions regarding organizational culture and the people involved on the project. Those assumptions are usually not discussed very often, which is bad, since I believe they are typically related to those many cases of failed Agile implementations that end up getting different explanations depending on how one likes/dislikes Agile.
To summarize what I'd like to answer about your question:
Pros:
- They are great tools to break larger projects into smaller chunks and to keep track of their progresses. Experience shows that it's easier to reach success on smaller projects, and sprints and daily meetings are ways of emulate such sort of project even when working on larger ones.
- There's an opportunity of catching and fixing schedule slippages, requirements misunderstandings and other sorts of deviations before they get too expensive to fix.
Cons:
- You need a bigger deal of maturity and commitment of people involved. As IT professionals, we usually complain about users being unprepared for working on Agile projects, but we have to admit that many professionals show a significant decrease in performance when they are not under a certain level of healthy pressure.
- When you favor people over processes and communication over documentation, a higher level of mutual trust is required. You can't find that everywhere, for a number of reasons. Some say that such organizations are not prepared to work under Agile rules. Some are more pragmatic and adapt. I stick with the latter. Agile talks a great deal about embracing change on requirements, and I don't see what is the point of being a purist and refusing to adapt the method to deal with risks.
I think scrum functions as an engineering accounting system. It’s worked really well in my experiences and has allowed me to forecast capacity which helps
Materialize timelines.
https://on-systems.tech/109-toward-predictable-engineering-v...
https://on-systems.tech/109-toward-predictable-engineering-v...
With respect to all involved, I've so far worked on two projects using scrum, and hated it both times. The biggest problem for me is something I haven't seen too many people mention here - scrum apparently goes hand-in-hand with feature-driven development. Some list of requirements is divided up into small vertical slices through the software, which are drip-fed to the team via the backlog; the end result is akin to building a house in vertical slices. It's possible to work like this but very difficult and without near-prescient levels of foresight on the part of the team leads to large amounts of otherwise unnecessary rework, especially when the requirements inevitably change, which is supposed to be where 'agility' comes into its own. That's not agile, it's clumsy and wasteful.
Far better in my experience to spend time analysing the requirements as a whole, to distil the essence of what's being developed, and design a set of components that express that essential nature in a flexible way, such that the features arise out of the combination of those components rather than being developed in isolation and then mashed together as the project progresses. Accept as a given that intial requirements are just a best guess, and design accordingly - to cram piles of poorly-thought-through code through reams of unit tests is to fight this reality, not to embrace it (note that this is not to rag on unit testing itself, which, like any good tool, is extremely useful when deployed appropriately).
Doing this kind of analysis up front and then developing the components using scrum - that would probably be OK, but I've yet to see or hear of anyone doing that.
As for the process side of scrum: stand-ups are fine if they are kept very short and simply used to express and work through problems, but this appears to require active policing to prevent people rambling, and the retrospectives again are potentially useful, but in my experience turn into long awkward sessions of scratching around to find items for the 'things that went well/went wrong/would change' lists - and more often than not 'things that went well' could be summed up as "we all did our jobs". Celebrate genuinely awesome results, sure, but as a software developer, I don't need or want a pat on the back just for developing software successfully. Overall I would say that the principles of scrum sound nice but when they meet real people the results are somewhere between mediocre and painful.
Far better in my experience to spend time analysing the requirements as a whole, to distil the essence of what's being developed, and design a set of components that express that essential nature in a flexible way, such that the features arise out of the combination of those components rather than being developed in isolation and then mashed together as the project progresses. Accept as a given that intial requirements are just a best guess, and design accordingly - to cram piles of poorly-thought-through code through reams of unit tests is to fight this reality, not to embrace it (note that this is not to rag on unit testing itself, which, like any good tool, is extremely useful when deployed appropriately).
Doing this kind of analysis up front and then developing the components using scrum - that would probably be OK, but I've yet to see or hear of anyone doing that.
As for the process side of scrum: stand-ups are fine if they are kept very short and simply used to express and work through problems, but this appears to require active policing to prevent people rambling, and the retrospectives again are potentially useful, but in my experience turn into long awkward sessions of scratching around to find items for the 'things that went well/went wrong/would change' lists - and more often than not 'things that went well' could be summed up as "we all did our jobs". Celebrate genuinely awesome results, sure, but as a software developer, I don't need or want a pat on the back just for developing software successfully. Overall I would say that the principles of scrum sound nice but when they meet real people the results are somewhere between mediocre and painful.
Daily stand-up has the pro from a management perspective that people feel pressure to perform. It does make sure people focus on the things they should be focusing on. The associated con is that not everyone performs under pressure.
The pro of having a sprint is that the team knows what they can do in advance. I don't need to ask my boss for a new task, I just pick the topmost of the board that's not been worked on. The con is sometimes added pressure to finish a sprint (beyond normal pressure and without real-world cause) and a lot of time wasted in team wide meetings to plan a new sprint.
'refinement' meetings as far as I understand are unfortunately usually a waste of time.
Estimations in terms of 'effort' points are a recipe for failure because ultimately they will be converted into man-hour units yet were not supposed to think of them as time but 'complexity'. As a result velocity and burn down tools are just a cause for strife. I'd recommend using a normal time unit instead. Skip the conversion.
The other way these things can possibly be made useful is if the most important metric is not velocity but reliability (which most teams don't use but is used in at least one team in my org).
Retrospectives have the potential to be a cause of strife for obvious reasons. Usually they are pointless because people understand it's a powder keg so you never learn anything.
Personally I don't like agile/scrum but if I'd have to do it myself I would keep at least some elements, like the board you can take tasks from. Standups I would like to see alternatives for. Estimations I would try to do myself or maybe have a tech lead do. I wouldn't even bother communicating it with the rest. Ultimately I never learned anything besides agile scrum so I'd have to adopt at least parts of it no matter that I dislike it.
The pro of having a sprint is that the team knows what they can do in advance. I don't need to ask my boss for a new task, I just pick the topmost of the board that's not been worked on. The con is sometimes added pressure to finish a sprint (beyond normal pressure and without real-world cause) and a lot of time wasted in team wide meetings to plan a new sprint.
'refinement' meetings as far as I understand are unfortunately usually a waste of time.
Estimations in terms of 'effort' points are a recipe for failure because ultimately they will be converted into man-hour units yet were not supposed to think of them as time but 'complexity'. As a result velocity and burn down tools are just a cause for strife. I'd recommend using a normal time unit instead. Skip the conversion.
The other way these things can possibly be made useful is if the most important metric is not velocity but reliability (which most teams don't use but is used in at least one team in my org).
Retrospectives have the potential to be a cause of strife for obvious reasons. Usually they are pointless because people understand it's a powder keg so you never learn anything.
Personally I don't like agile/scrum but if I'd have to do it myself I would keep at least some elements, like the board you can take tasks from. Standups I would like to see alternatives for. Estimations I would try to do myself or maybe have a tech lead do. I wouldn't even bother communicating it with the rest. Ultimately I never learned anything besides agile scrum so I'd have to adopt at least parts of it no matter that I dislike it.
Well, if you don't communicate, don't plan or don't do any retrospectives then those omissions will have a high probability to cause problems.
In that sense scrum is like "training wheels for self organizing teams". Once you understand the benefits, a small team should be capable of modifying the system.
If we look at productized processes Kanban is much better at getting the essential framework in place.
Scrum is not the worst process that could be applied to software production for large orgs. Worse examples include for example a no-process, hardware companies shoehorning software development into hardware development framework and so on.
IMO as a junior dev over a decade ago it was nice to have scrum when I started at a company since that framework made it very explicit what the rules of the process were. A no-process would have been much worse and stressful.
But high performing teams tend to realize there is no one shoe fits all solutions to complex processes and then evolve their own system.
In that sense scrum is like "training wheels for self organizing teams". Once you understand the benefits, a small team should be capable of modifying the system.
If we look at productized processes Kanban is much better at getting the essential framework in place.
Scrum is not the worst process that could be applied to software production for large orgs. Worse examples include for example a no-process, hardware companies shoehorning software development into hardware development framework and so on.
IMO as a junior dev over a decade ago it was nice to have scrum when I started at a company since that framework made it very explicit what the rules of the process were. A no-process would have been much worse and stressful.
But high performing teams tend to realize there is no one shoe fits all solutions to complex processes and then evolve their own system.
For me, agile is synonymous with a common sense approach: take small steps to your goal, and don't be alarmed if you need to pivot your strategy along the way, as no one has a crystal ball.
Having said that, I've seen a lot of agile projects fail, because people are too busy worrying about being "agile", while forgetting to apply common sense.
Having said that, I've seen a lot of agile projects fail, because people are too busy worrying about being "agile", while forgetting to apply common sense.
You are describing cargo-cult scrum, or consulting-driven scrum. At this point, I think scrum is a lost cause, because, at best, people go through the motions, but more likely, managers use it for the opposite of its intended purpose.
I did my first scrum training with Ken Schwaber. Ten years later I did it again with a "Scrum Consultant". Same "processes", but utterly different reasons, utterly different outcomes.
And there's no hope for it. Managers can't be convinced by me that Ken Schwaber didn't mean whatever bullshit their high-priced consultant is saying. Even without the consultant, there are far too many ambiguous things, that Ken gets into specifically, that don't come across when discussing Scrum. Scrum will result in the manager doing none of their responsibilities (e.g. proper planning), while micromanaging the engineers.
If I ever start another company, we will do Scrum. But otherwise, I won't go near it.
I did my first scrum training with Ken Schwaber. Ten years later I did it again with a "Scrum Consultant". Same "processes", but utterly different reasons, utterly different outcomes.
And there's no hope for it. Managers can't be convinced by me that Ken Schwaber didn't mean whatever bullshit their high-priced consultant is saying. Even without the consultant, there are far too many ambiguous things, that Ken gets into specifically, that don't come across when discussing Scrum. Scrum will result in the manager doing none of their responsibilities (e.g. proper planning), while micromanaging the engineers.
If I ever start another company, we will do Scrum. But otherwise, I won't go near it.
Following any process to the letter by some text book is problematic.
If you consider things in the Agile Manifesto and the spirit of being agile, the pros are things like you don't waste time building stuff nobody uses. Why gather requirements, design, develop, test, deploy of features that have minimal or no usage. I've seen many cases that by the time a feature gets out there, its not needed/wanted any more. There are charts and stuff on this regarding Lean Software Development. Another pro is barriers are identified quickly and can be problem-solved quickly. Figure out your unknowns really early and you can adjust what you're building.
Over the last year with everything going on there were days where at standup people said "got distracted" and that is perfectly fine. I took that to mean they didn't get anything done during the last day. There were some major life distractions this past year. Those meetings aren't for management to keep tallies on people for some fictitious scoreboard, they are there for the team to identify barriers, ask questions, etc. so the work can get done. Agile comes from lean principles from manufacturing, its about eliminating wasteful steps in a process.
Some cons would be with the wrong culture you get micro-managers, people measuring stuff that doesn't matter (ticket size, velocity, whatever) and possibly people gaming whatever nonsense you are measuring. If there is bad culture the project management process being used doesn't matter really, its not going to be pleasant working in that.
If there is high risk in what you are delivering, like if you're building software for controlling a nuclear power plant, ICU medical devices, etc. you may need a lot tighter controls around the project process because software bugs can result in really bad things. Maybe a waterfall process works better in those situations, otherwise use agile that fits the people and organization.
If you consider things in the Agile Manifesto and the spirit of being agile, the pros are things like you don't waste time building stuff nobody uses. Why gather requirements, design, develop, test, deploy of features that have minimal or no usage. I've seen many cases that by the time a feature gets out there, its not needed/wanted any more. There are charts and stuff on this regarding Lean Software Development. Another pro is barriers are identified quickly and can be problem-solved quickly. Figure out your unknowns really early and you can adjust what you're building.
Over the last year with everything going on there were days where at standup people said "got distracted" and that is perfectly fine. I took that to mean they didn't get anything done during the last day. There were some major life distractions this past year. Those meetings aren't for management to keep tallies on people for some fictitious scoreboard, they are there for the team to identify barriers, ask questions, etc. so the work can get done. Agile comes from lean principles from manufacturing, its about eliminating wasteful steps in a process.
Some cons would be with the wrong culture you get micro-managers, people measuring stuff that doesn't matter (ticket size, velocity, whatever) and possibly people gaming whatever nonsense you are measuring. If there is bad culture the project management process being used doesn't matter really, its not going to be pleasant working in that.
If there is high risk in what you are delivering, like if you're building software for controlling a nuclear power plant, ICU medical devices, etc. you may need a lot tighter controls around the project process because software bugs can result in really bad things. Maybe a waterfall process works better in those situations, otherwise use agile that fits the people and organization.
Quick story: I worked for a Japanese company. A really good one.
Anyone familiar with Japanese business/engineering process knows that the principal engineering project management fuel is meetings. Highly organized and structured meetings. Our headquarters building in Shinagawa had two entire floors, dedicated to conference rooms, and every floor had at least 4 conference rooms, along with "ad hoc" conference rooms, made up of file cabinets, set up like a grade-schooler's home "fort."
We had to book conference rooms six months in advance, for a half-hour meeting. Once, we were ten minutes late for a meeting, and the booking system automatically knocked us out, and assigned our room to another team. We went out to the coffee shop, but couldn't "talk shop" outside the headquarters building.
Yeah...they take meetings seriously over there.
So my team (based in the US, but run from Japan) hired a really sharp guy to be our process/infrastructure person. He was loved and valued throughout his six-year tenure, and we cried for years, after he moved on to greener pastures (this story might illustrate the appeal of said "greener pastures"). He was a fairly new Agile proponent, and proposed a daily standup.
So, anyway, the spirit of a daily standup, is to be informal and fast. Start of day, 15 minutes, no chairs, lightning talks, very brief Q&A, What I did, What I Want to Do, the Challenges I Anticipate, etc.
So, our Japanese liaison member (the person responsible for learning our process and representing Tokyo's interests to us) takes a liking to these, because...meeting GOOD. You get the picture.
So our "standups" ended up becoming hour-long daily pre-lunchtime events, with a booked conference room, seats, a fixed agenda, and a daily report to Tokyo.
Be careful what you wish for.
Anyone familiar with Japanese business/engineering process knows that the principal engineering project management fuel is meetings. Highly organized and structured meetings. Our headquarters building in Shinagawa had two entire floors, dedicated to conference rooms, and every floor had at least 4 conference rooms, along with "ad hoc" conference rooms, made up of file cabinets, set up like a grade-schooler's home "fort."
We had to book conference rooms six months in advance, for a half-hour meeting. Once, we were ten minutes late for a meeting, and the booking system automatically knocked us out, and assigned our room to another team. We went out to the coffee shop, but couldn't "talk shop" outside the headquarters building.
Yeah...they take meetings seriously over there.
So my team (based in the US, but run from Japan) hired a really sharp guy to be our process/infrastructure person. He was loved and valued throughout his six-year tenure, and we cried for years, after he moved on to greener pastures (this story might illustrate the appeal of said "greener pastures"). He was a fairly new Agile proponent, and proposed a daily standup.
So, anyway, the spirit of a daily standup, is to be informal and fast. Start of day, 15 minutes, no chairs, lightning talks, very brief Q&A, What I did, What I Want to Do, the Challenges I Anticipate, etc.
So, our Japanese liaison member (the person responsible for learning our process and representing Tokyo's interests to us) takes a liking to these, because...meeting GOOD. You get the picture.
So our "standups" ended up becoming hour-long daily pre-lunchtime events, with a booked conference room, seats, a fixed agenda, and a daily report to Tokyo.
Be careful what you wish for.
I hate it.
The place I work at is doing it wrong in my opinion: sprint points are directly mapped to time (instead of complexity), meaning that each day = 2 points per developer. Stand ups are really just status updates to our product manager - developers don't actually chat to each other about issues, we just report to the pm. If the pm is in another meeting, then standup doesn't occur at all.
The worst thing about it: There is no end in sight. There is no natural endpoint. It's just ticket after ticket after ticket, with the almighty burn down chart looking down on us. It just never ends. In a way we are assembly line workers. We cannot take slightly longer than what the ticket says, then you are forced to explain where you are stuck, even if you aren't stuck, so people thumb suck reasons.
(With something like carpentry, you build something, apply finishes, enjoy the product, AND IT IS DONE. With software development + scrum = infinite treadmill. You get deprived of ever getting a sense of accomplishment.)
During sprint planning we also assign the ticket upfront to specific people, so we have hectic issues with knowledge silo's.
On the sprint point side, we basically either have tickets that are 3, 5 or 8 and nobody dare picks another number. Using their system of 2 points = 1 developer day, some tickets should be 20 points, simply because it will take the person at least the whole 2 weeks to do. Some tasks are inherently complex or tedious and will take longer, but at this company we basically have to rush everything. Nobody ever has downtime and time to think.
I'm kind of over the company and over scrum. Looking back after 10 years, the only place where scrum did work for me was at one company (that sadly closed down (infighting between directors)) where we didn't take it serious at all - it was all for fun, no drama/seriousness, no care about mapping points to time, retro's was super funny (and not a moan fest) - basically nobody took it seriously and our productivity was crazy good.
Another place I briefly worked used old school Gantt charts which worked surprisingly well even though I didn't like it in the beginning (it was a more waterfall-like approach, loads of planning upfront). We would spend a WEEK planning and then code for like a month and release basically near perfect code to production. It did feel a bit boring in a way because there was very little wiggle room - everyone just followed the plan.
The place I work at is doing it wrong in my opinion: sprint points are directly mapped to time (instead of complexity), meaning that each day = 2 points per developer. Stand ups are really just status updates to our product manager - developers don't actually chat to each other about issues, we just report to the pm. If the pm is in another meeting, then standup doesn't occur at all.
The worst thing about it: There is no end in sight. There is no natural endpoint. It's just ticket after ticket after ticket, with the almighty burn down chart looking down on us. It just never ends. In a way we are assembly line workers. We cannot take slightly longer than what the ticket says, then you are forced to explain where you are stuck, even if you aren't stuck, so people thumb suck reasons.
(With something like carpentry, you build something, apply finishes, enjoy the product, AND IT IS DONE. With software development + scrum = infinite treadmill. You get deprived of ever getting a sense of accomplishment.)
During sprint planning we also assign the ticket upfront to specific people, so we have hectic issues with knowledge silo's.
On the sprint point side, we basically either have tickets that are 3, 5 or 8 and nobody dare picks another number. Using their system of 2 points = 1 developer day, some tickets should be 20 points, simply because it will take the person at least the whole 2 weeks to do. Some tasks are inherently complex or tedious and will take longer, but at this company we basically have to rush everything. Nobody ever has downtime and time to think.
I'm kind of over the company and over scrum. Looking back after 10 years, the only place where scrum did work for me was at one company (that sadly closed down (infighting between directors)) where we didn't take it serious at all - it was all for fun, no drama/seriousness, no care about mapping points to time, retro's was super funny (and not a moan fest) - basically nobody took it seriously and our productivity was crazy good.
Another place I briefly worked used old school Gantt charts which worked surprisingly well even though I didn't like it in the beginning (it was a more waterfall-like approach, loads of planning upfront). We would spend a WEEK planning and then code for like a month and release basically near perfect code to production. It did feel a bit boring in a way because there was very little wiggle room - everyone just followed the plan.
Scrum, and "certified" (or not) Product Owners, Project Managers, Product Managers, Scrum Masters, Technical leads, architects, engineering managers, and QA that don't come with years of code slinging under their belt have no place in software development.
Kanban makes so much more sense when that kind of garbage is in your work environment.
Kanban makes so much more sense when that kind of garbage is in your work environment.
Yes, if done properly. I have had great luck with an Agile/Scrum methodology, to the point where I actively advocate for it over other management/time structure styles.
There are a few points that are important to it working well though:
* Team size should be small, but not pathologically so. 3-8 is about the range it is ideal.
* Strong ownership and trust between engineer and product owners, both way.
* Engineers should have broad, or at least T-shaped competencies, not narrow, exclusive focuses
* Meetings should feel useful to all participants, at all times. Specifically, standups should be useful to the POs because they get a rough idea of how things are going across the team, but it is also useful to the engineers to ensure that engineers are actually working together, not simply siloing themselves.
* Engineers should be competent, in general. They don't need to all be 10x engineers, but a team comprised mostly of leaderless junior engineers will fail, even more so with Scrum/Agile
There are a few points that are important to it working well though:
* Team size should be small, but not pathologically so. 3-8 is about the range it is ideal.
* Strong ownership and trust between engineer and product owners, both way.
* Engineers should have broad, or at least T-shaped competencies, not narrow, exclusive focuses
* Meetings should feel useful to all participants, at all times. Specifically, standups should be useful to the POs because they get a rough idea of how things are going across the team, but it is also useful to the engineers to ensure that engineers are actually working together, not simply siloing themselves.
* Engineers should be competent, in general. They don't need to all be 10x engineers, but a team comprised mostly of leaderless junior engineers will fail, even more so with Scrum/Agile
The biggest problem with Scrum/Agile is that it is easy to do wrong, but hard to do right. Then again, every team that I've seen doing Agile wrong does any other system wrong too, it's just pointing to systemic problems that no amount of management techniques can paper over.
> Strong ownership and trust between engineer and product owners, both way.
Trust has to be the most important ingredient for a successful project regardless of the project management process, if you have trust any process can work well.
Agree about Team Size, less people less communication is needed which results in less misunderstandings == more productivity.
Trust has to be the most important ingredient for a successful project regardless of the project management process, if you have trust any process can work well.
Agree about Team Size, less people less communication is needed which results in less misunderstandings == more productivity.
Yes, it's working for us, but not without cost.
It's a good way to set expectations for what will be/is to be delivered in a Sprint, and limits going off-piste in too many directions while not delivering functionality (which is a problem for creative/broad-skillset developers at times).
It also limits the impact/waste in case the requirements change - you only worked two weeks in the wrong direction. (and they say changing requirements is the biggest problem in software projects since ever)
However, I find that it often reduces developers to mindless drones, just trying to satisfy acceptance criteria without thinking about the big picture. (You know you're there when Refinement meetings are very quiet and the Architect does most of the talking).
As for estimation/scoring - I find that estimating "complexity" is nonsense. Treating points as "days" is more realistic and leads to better time management from everyone.
It's a good way to set expectations for what will be/is to be delivered in a Sprint, and limits going off-piste in too many directions while not delivering functionality (which is a problem for creative/broad-skillset developers at times).
It also limits the impact/waste in case the requirements change - you only worked two weeks in the wrong direction. (and they say changing requirements is the biggest problem in software projects since ever)
However, I find that it often reduces developers to mindless drones, just trying to satisfy acceptance criteria without thinking about the big picture. (You know you're there when Refinement meetings are very quiet and the Architect does most of the talking).
As for estimation/scoring - I find that estimating "complexity" is nonsense. Treating points as "days" is more realistic and leads to better time management from everyone.
Oh and standups are not that bad!
We keep it small, team level (6 people), and they last 15 minutes.
No pressure to describe anything - you can say "I'm still working on that thing" and that's that..
Honestly it's more of a social thing, especially while remoting, and a chance to share thoughts and offer assistane.
We keep it small, team level (6 people), and they last 15 minutes.
No pressure to describe anything - you can say "I'm still working on that thing" and that's that..
Honestly it's more of a social thing, especially while remoting, and a chance to share thoughts and offer assistane.
I'm a manager who (I think) does agile right, and will now defend it because I think it's brilliant (when done right).
On standups: first, I rarely speak in standup; if some other manager uses it to micromanage, well, that's on them, not on the general concept of daily checkins. Second, it's very difficult to "signal progress vs. actually making it" with your teammates. That's part of the point: intra-team accountability. If you're making no progress, you might fool me with generic excuses and you can certainly fool a business analyst or a project manager, but you can't fool another programmer who works on the same code and sits next to you.
On agile having a lot of bureaucracy layers: compared to what? The agile "bureaucracy" my teams endure is: standup, refinement, and retro. That's less than two hours per week. What methodology involves less bureaucracy than that, other than anarchy?
On points: OK I will kind of give you this one, but only because they don't bring value to you. Story points aren't for you, the dev, they're for PM and execs. What do execs want, in terms of estimates? They want to know exactly when a feature is going to ship, to the day, even if it's years away. What do devs want, in terms of estimates? To not give one, ever, for anything. Story points are the compromise. And pointing a story takes maybe 30 seconds, so it's hard to understand how anyone can see it as onerous.
So in summary, I think agile is very good when done right, and in places where it seems bad it is usually because one of the basic ingredients (a team empowered to change their own process) is missing. That, to me, is the core of agile: a team that iterates on their own process. If your team is not willing to or allowed to do that, IMHO they're not actually agile. And if they are, well, take your objections, bring them up in retro, and propose something better.
On standups: first, I rarely speak in standup; if some other manager uses it to micromanage, well, that's on them, not on the general concept of daily checkins. Second, it's very difficult to "signal progress vs. actually making it" with your teammates. That's part of the point: intra-team accountability. If you're making no progress, you might fool me with generic excuses and you can certainly fool a business analyst or a project manager, but you can't fool another programmer who works on the same code and sits next to you.
On agile having a lot of bureaucracy layers: compared to what? The agile "bureaucracy" my teams endure is: standup, refinement, and retro. That's less than two hours per week. What methodology involves less bureaucracy than that, other than anarchy?
On points: OK I will kind of give you this one, but only because they don't bring value to you. Story points aren't for you, the dev, they're for PM and execs. What do execs want, in terms of estimates? They want to know exactly when a feature is going to ship, to the day, even if it's years away. What do devs want, in terms of estimates? To not give one, ever, for anything. Story points are the compromise. And pointing a story takes maybe 30 seconds, so it's hard to understand how anyone can see it as onerous.
So in summary, I think agile is very good when done right, and in places where it seems bad it is usually because one of the basic ingredients (a team empowered to change their own process) is missing. That, to me, is the core of agile: a team that iterates on their own process. If your team is not willing to or allowed to do that, IMHO they're not actually agile. And if they are, well, take your objections, bring them up in retro, and propose something better.
I just remembered I had this book above my desk. In Sterman's Business Dynamics, chapter 1, he has two diagrams of the "learning loop" (pages 16 and 19).
In my mind, the benefit of agile is that it encourages a movement towards the double-loop learning model (pg 19), which is a struggle for many people and most organizations, from a single-loop learning model (pg 16) (assuming there is even a learning loop present at all).
The single-loop learning model:
The double-loop learning model (another ASCII art attempt) closes the loop and brings the feedback back to the mental models (using abbreviations to shrink it a bit):
In my mind, the benefit of agile is that it encourages a movement towards the double-loop learning model (pg 19), which is a struggle for many people and most organizations, from a single-loop learning model (pg 16) (assuming there is even a learning loop present at all).
The single-loop learning model:
Mental Models of Real World
|
v
Strategy, Structure, Decisions Rules
|
v
Decisions <------------+
| |
v |
Real World |
| |
v |
Information Feedback --+
The double-loop learning model (another ASCII art attempt) closes the loop and brings the feedback back to the mental models (using abbreviations to shrink it a bit):
MM ------> SSDR
^| |
|v v
IF------->Decisions
^ |
| |
+--- RW <---+
> Sterman's Business Dynamics
I actually just bought this book - is it any good? :)
I actually just bought this book - is it any good? :)
Honestly I only got a few chapters in before life took over. But I have liked what I read. It’s my sisters copy from a grad school class and she and her classmates liked it but I don’t know how much of that was the class versus the book.
Great thanks, I'm considering applying to grad school as well. This book is a big part of their core curriculum, so I was curious to see if it was any good.
[deleted]
> Do these extra bureaucracy layers, meetings, checkmarks and vague "man-points" estimates actually bring any value.
Seems like your company is doing it wrong;) Agile is supposed to 1. remove bureaucracy, not add some; 2. adapt to the situation. Before Agile, you would read specs and implement them, and those specs had been carefully written by a team of analysts (8 people for a year). Any change to specs had to circle around the analysts and customers. Agile should first be an improvement on top of that.
But if Agile is still getting in your way, seek to remove that too, and your managers will be happy. Agile should be about adapting. Anything that does not bring features is unnecessary.
Last note for humor: “The wrong way to do Agile” depicts how things actually happened in Waterfall: https://youtu.be/l1yWusiaLCM
Seems like your company is doing it wrong;) Agile is supposed to 1. remove bureaucracy, not add some; 2. adapt to the situation. Before Agile, you would read specs and implement them, and those specs had been carefully written by a team of analysts (8 people for a year). Any change to specs had to circle around the analysts and customers. Agile should first be an improvement on top of that.
But if Agile is still getting in your way, seek to remove that too, and your managers will be happy. Agile should be about adapting. Anything that does not bring features is unnecessary.
Last note for humor: “The wrong way to do Agile” depicts how things actually happened in Waterfall: https://youtu.be/l1yWusiaLCM
From my perspective of being on scrum/agile teams for many years I have learned to love it when it’s done well, though it took a while to get over the shock of the daily standups and weekly events. The feeling I get is one of accountability from each member of the team that we are working as one toward the same goal. Once in a while when someone’s stuck, if everyone feels empowered and the psychological safety of the group has been set by management and the group itself, issues and problems get raised quickly and are also quickly put to bed. If a team has one 10x engineer, they are able to support múltiple 1x engineers and all are productive and moving the ball forward. When the PO is on top of the ball and the backlog is up to date and communication with the stakeholders is ongoing and the grooming meetings are run with input from the whole team and the stories and tasks and spikes are discussed at length so everyone has the best understanding they can, it is a pleasure to behold and be a part of. I just attended an Agile training today and one of the most critical paths are to try to keep team turnover to a minimum, thus reducing the ramp up time of new members. While not always possible, when the team is able to find their stride with the estimation and all agree on what the appropriate estimation should be things move smoothly. Sometimes there will be wildly divergent estimations; that’s ok, it just means more discussion is needed to understand the task at hand. This does require lots of patience for the existing members as once the code is known we skew our estimation based on our own ability and familiarity with the code. I’ve seen some estimations within one team, one one story, post discussion go from 1 to 8 on a Fibonacci estimation. We discussed and turned out we divided the story into 3 and got 2 points of estimation for each story showing we were closer to the 8 point estimation rather than the 1 point. My point in all of this is the dev team in my opinion has their fingers on the pulse of what’s going on as well as the PO when all work together toward the common goal.
In my opinion it's seen (at least where I've worked) as better for the following reasons:
1. Better visibility of progress and blocking issues - this is a big plus to senior mgmt and if you're technical it will help you alot that they understand you're making progress rather than being a blackbox that they hope delivers something in 6 months time
2. More adaptable to change - every project changes, the lnger it runs the less suitable it is at the end. Agile/Scrum theoretically allows you to change course better (not that you couldn't do it under waterfall..)
You do make a good point that it can be a dream for micro managers if you're unlucky enough to work for one, there are many potential faults but it depends on who's in the team frankly. The standups can become mundane and useless if people can't be honest about blockers or where they need help as well.
1. Better visibility of progress and blocking issues - this is a big plus to senior mgmt and if you're technical it will help you alot that they understand you're making progress rather than being a blackbox that they hope delivers something in 6 months time
2. More adaptable to change - every project changes, the lnger it runs the less suitable it is at the end. Agile/Scrum theoretically allows you to change course better (not that you couldn't do it under waterfall..)
You do make a good point that it can be a dream for micro managers if you're unlucky enough to work for one, there are many potential faults but it depends on who's in the team frankly. The standups can become mundane and useless if people can't be honest about blockers or where they need help as well.
Separate agile from scrum. Scrum is usually terrible, badly implemented and often still includes sprint commitments even though they were changed to forecasts 10 years ago.
SAFe for larger orgs or Kanban for smaller teams are excellent approaches to agile.
The book 2nd Generation Lean Product Development really gets into the weeds on what works and why.
SAFe for larger orgs or Kanban for smaller teams are excellent approaches to agile.
The book 2nd Generation Lean Product Development really gets into the weeds on what works and why.
Agreed, Scrum has been crap everywhere that I've worked that used it. Nothing like a 1 hour standup every morning to hinder productivity.
1 HOUR?
I think it all depends on what kind of software you are making / supporting.
The game industry is a famous example where scrum just does not work. There are to many pipelines and to many disciplines, and everything depends on shipping.
So in the game / VFX industry there is most of the time a strict waterfall structure that does not help you to do scrum. If the hours a team is spening on a sprint is not the same every time then you are just using postid notes to track the progress. (crunch hours are unfortunately very common in the game industry)
So in general I would say, Scrum/Agile is definitely beneficial if you are shipping multiple versions of a product. But if its all about shipping 1 final product or if the time team members are going to work on it is not specified then you are just using it to track you progress and it is therefor not any better then good communication.
The game industry is a famous example where scrum just does not work. There are to many pipelines and to many disciplines, and everything depends on shipping.
So in the game / VFX industry there is most of the time a strict waterfall structure that does not help you to do scrum. If the hours a team is spening on a sprint is not the same every time then you are just using postid notes to track the progress. (crunch hours are unfortunately very common in the game industry)
So in general I would say, Scrum/Agile is definitely beneficial if you are shipping multiple versions of a product. But if its all about shipping 1 final product or if the time team members are going to work on it is not specified then you are just using it to track you progress and it is therefor not any better then good communication.
"Agile is a Adjective not a Noun". It was supposed to empower devs but has been hijacked by management to enforce standards.
from Pragmatic Dave Thomas: Agile is Dead https://www.youtube.com/watch?v=a-BOSpxYJ9M
from Pragmatic Dave Thomas: Agile is Dead https://www.youtube.com/watch?v=a-BOSpxYJ9M
Pros: if done properly it makes software delivery actually predictable
Cons: everything else :-)
I enjoy the non-scrum world, but every time I try it, I realize how bad it actually is for everyone involved, especially if there are timelines. But also I think unless you're sufficiently experienced, Scrum is micromanagement hell indeed.
Cons: everything else :-)
I enjoy the non-scrum world, but every time I try it, I realize how bad it actually is for everyone involved, especially if there are timelines. But also I think unless you're sufficiently experienced, Scrum is micromanagement hell indeed.
In my org dailies are mostly helpful and not a reporting tool. We work in project teams for our customers and are about 300 people.
Also our agile approaches mostly work out well, but our whole organization is structured in a way that facilitates this.
We have only 2 levels of hierarchy and crossfunctional groups for arbitrary topics like "wage transparency", "consulting" or "technology". Anyone interested can take part in those and they get some budget too.
Every few weeks there are townhalls where economic development is reported by the executives to the rest of the company and anyone can ask questions. Since covid we do this via google meet with great success.
All in all agile approaches only truly work if acceptance from the higher ups is high. If agile is just used to get tighter deadlines out of devs it is actively harmful.
Also our agile approaches mostly work out well, but our whole organization is structured in a way that facilitates this.
We have only 2 levels of hierarchy and crossfunctional groups for arbitrary topics like "wage transparency", "consulting" or "technology". Anyone interested can take part in those and they get some budget too.
Every few weeks there are townhalls where economic development is reported by the executives to the rest of the company and anyone can ask questions. Since covid we do this via google meet with great success.
All in all agile approaches only truly work if acceptance from the higher ups is high. If agile is just used to get tighter deadlines out of devs it is actively harmful.
No. It's never worked anywhere I've seen or heard of. There is always resistance, missed deadlines, managers that start treating their teams like children because burndown charts aren't being adhered to, etc.
You can't streamline software development. I don't know why people keep trying.
You can't streamline software development. I don't know why people keep trying.
Well, there is no mention of estimates in the manifesto. It's just people want to know if the thing they buy might cost them one million dollars or 100000 dollars. So giving estimates has nothing to do with agile per se. You probably needed to tell your customer or your boss how much time/money you think something will cost before, didn't you? If you didn't, I don't see why you should now.
Daily meetings are not to micromanage and show off that you've done so much work yesterday, but to identify issues that need to be resolved and a good place to ask the team for help if you're stuck.
Unfortunately, agile nowadays is mostly scrum, following some non sensical plan taught by some agile coach and too much management, whereas agile was invented solely by and for developers (not managers).
Daily meetings are not to micromanage and show off that you've done so much work yesterday, but to identify issues that need to be resolved and a good place to ask the team for help if you're stuck.
Unfortunately, agile nowadays is mostly scrum, following some non sensical plan taught by some agile coach and too much management, whereas agile was invented solely by and for developers (not managers).
The challenge with agile is how it is run. Agile/scrum is an opportunity for micromanagement. Agile/scrum is an opportunity for greater freedom to developers. I think that this reveals that company culture is more important than any methodology. If the company culture does not fit agile/scrum, then it will not work. Another important factor is the experience-level of the team. For novice developers, scrum/agile seems like unnecessary process. For a small team of experienced developers, it may not be necessary because they may already be following its best practices. From my experience, scrum/agile is best done when it fits company culture, has buy-in from the most experienced developers, and is used with a team of mixed experience.
The incentives have changed. Now I just work to say something at the standup, and standups are like 30 minutes long because people keep turning it into classical waterfall style discussion meetings between two people while everyone else listens. I hate it and the fossils that perpetuate this.
> Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
If by "micromanagers" you mean, "just managers who like to understand how time is being spent", then yes that is what Scrum/KANBAN are for, among other things.
Story time...
I remember working at a startup in the UK around 2013/2014. We had guy working for us who did the UI for the portal our customers used to interact with our service. We had another developer doing the back end in Ruby on Rails.
At this point in time we didn't do Scrum so as a result we didn't do daily stand ups. We also didn't do any form of TDD, BDD or any testing at the code/module/lib level at all.
Fast forward a few months and another programmer joined the team. Really great programmer and big on testing and Scrum. He convinced the CTO to try Scrum and go with daily stand-ups, planning meetings and retrospectives. That was all he was asking. The CTO agreed.
The UI was fired a week later. Turns out he had spent two weeks allowing the side menu slide in and out from the left of the web page. He did this from scratch.
The new guy then convinced the CTO that TDD was important for at least the critical paths through our application. He wasn't asking for 100% code coverage, nor would he (because he's smarter than that.) The CTO agreed.
The back end guy upped and left two months later. Turns out he didn't like doing testing of any kind, so instead of writing useful, meaningful tests, he wrote tests that simply returned "true".
The lesson from this is: Scrum can, like systems, highlight problems inside of an organisation. By implementing Scrum were got a daily snapshot of what everyone was doing, keeping people accountable for their actions, and knocking down blockers sooner rather than later. There is no "micromanagement" here.
These simple systems, like TDD, Scrum, OKRs, and so on, are excellent when used correctly.
If by "micromanagers" you mean, "just managers who like to understand how time is being spent", then yes that is what Scrum/KANBAN are for, among other things.
Story time...
I remember working at a startup in the UK around 2013/2014. We had guy working for us who did the UI for the portal our customers used to interact with our service. We had another developer doing the back end in Ruby on Rails.
At this point in time we didn't do Scrum so as a result we didn't do daily stand ups. We also didn't do any form of TDD, BDD or any testing at the code/module/lib level at all.
Fast forward a few months and another programmer joined the team. Really great programmer and big on testing and Scrum. He convinced the CTO to try Scrum and go with daily stand-ups, planning meetings and retrospectives. That was all he was asking. The CTO agreed.
The UI was fired a week later. Turns out he had spent two weeks allowing the side menu slide in and out from the left of the web page. He did this from scratch.
The new guy then convinced the CTO that TDD was important for at least the critical paths through our application. He wasn't asking for 100% code coverage, nor would he (because he's smarter than that.) The CTO agreed.
The back end guy upped and left two months later. Turns out he didn't like doing testing of any kind, so instead of writing useful, meaningful tests, he wrote tests that simply returned "true".
The lesson from this is: Scrum can, like systems, highlight problems inside of an organisation. By implementing Scrum were got a daily snapshot of what everyone was doing, keeping people accountable for their actions, and knocking down blockers sooner rather than later. There is no "micromanagement" here.
These simple systems, like TDD, Scrum, OKRs, and so on, are excellent when used correctly.
"Agile" or scrum is one of the worst idea in software development that can happen to a company.
I've only seen it kill creativity in lieu of "productivity" (which really is a code word for reporting to management/downwards micromanagement)
It is a mistake to adopt any agile process when the management does not have what they call the agile mindset. Both the words "downwards" and "micromanagement" are already warning signs that the company will do better with a different process.
I have never had a good experience with Scrum, sprints, standups, retros. I mean you can fucking take what I worked on, what I'm working on from JIRA. Why should I waste my time reporting that on a meeting?
Like others said above, Scrum did reduced the time we between when we finish a feature and when it hits production. I like the idea of quick feedback cycle and fast iteration.
But most companies abuse scrum and see sprints as a way to squeeze more out of dev teams. I've been working in a scrum team (leading the tech team as a tech lead, not product owner) for 3 years and I'm burned out now. Trying to get to a different place soon enough.
It is good for the product/managers, but for dev teams it can be bad if not done well.
Like others said above, Scrum did reduced the time we between when we finish a feature and when it hits production. I like the idea of quick feedback cycle and fast iteration.
But most companies abuse scrum and see sprints as a way to squeeze more out of dev teams. I've been working in a scrum team (leading the tech team as a tech lead, not product owner) for 3 years and I'm burned out now. Trying to get to a different place soon enough.
It is good for the product/managers, but for dev teams it can be bad if not done well.
Scrum is great because it encourages hyper-communication through ceremonies but there needs to be some acknowledgement of its purpose, right now it has been hijacked by consultancies so they can save money on BAs and analysis, so it always works out badly in practice.
I think scrum is very useful if executed properly, especially when something new is being developed. Small-scale attainable and clear goals, the daily sync/unblock, having clarity for 2 weeks (no randomization beyond livesite because all work goes into the backlog), and having a ready set of tasks to work on if you run out of work is great.
However scrum can really suck if executed poorly, especially the daily syncs. One of the keys I think is taking things offline and not ratholing, enforcing the time limit (15min), and if there's any manager or PM present not doing engineering work they cannot speak unless spoken to, or perhaps once at the end with any short updates/concerns w.r.t. backlog.
However scrum can really suck if executed poorly, especially the daily syncs. One of the keys I think is taking things offline and not ratholing, enforcing the time limit (15min), and if there's any manager or PM present not doing engineering work they cannot speak unless spoken to, or perhaps once at the end with any short updates/concerns w.r.t. backlog.
The agile idea is not bad and some ideas from scrum are not bad, but I have never seen an environment where the dev team thought daily (sometimes twice...) standups were a great idea. That could be my experience of course, but I'm almost always an outsider (coming into teams to help them implement our products) and asking around; in most places I get to, standups are seen as a show off session and so, automatically, as a 'punch the weaklings in the face' session. Fill up the time with rattling off blockers (aka blaming others) and allow for just enough success for the bosses to see you are a 1000x'er.
Communication is important (vitally so), just the format is entirely wrong imho.
Communication is important (vitally so), just the format is entirely wrong imho.
Every company fails in some respect with at least rate limiting. The last thing you should do in software dev is introduce more meetings, but that's how managers interpret agile. If I didn't get anything done, or only a trivial part of a bigger picture, the last hing I want to talk about or hear from anyone else for 30 minutes first thing in the morning is that. Likewise with only being able to the fastest things done in two weeks, or small parts of them if the sprint schedule isn't adapted to the team very well.
In most circumstances, one or two updates a week would be fine, preferably followed by the rest of update meetings so more contiguous hours of problem solving can happen.
In most circumstances, one or two updates a week would be fine, preferably followed by the rest of update meetings so more contiguous hours of problem solving can happen.
Some things I like:
* Frequent feedback from stakeholders and customers
* Retrospectives
* Standups
These can be annoying but they help make sure that the right thing is developed.
Things I don't like:
* Things get rushed to get them done before the sprint ends (even if there is no deadline pressure)
* On the other hand, everything takes at least two weeks to get done
I feel that this turns the output of a very high-performing developer into that of a mediocre developer. I'm not a 10x developer, so I can cope. ;)
Things I don't like but don't blame on Scrum:
* Jira
* Storypoints
* Estimating: All estimates beyond the current sprint are completely unreliable. Still, people use storypoints to derive release dates and worse, measure the productivity of employees using them.
FWIW, until I learn of better processes, I prefer Scrum without "buts" and with continuous deployment.
* Frequent feedback from stakeholders and customers
* Retrospectives
* Standups
These can be annoying but they help make sure that the right thing is developed.
Things I don't like:
* Things get rushed to get them done before the sprint ends (even if there is no deadline pressure)
* On the other hand, everything takes at least two weeks to get done
I feel that this turns the output of a very high-performing developer into that of a mediocre developer. I'm not a 10x developer, so I can cope. ;)
Things I don't like but don't blame on Scrum:
* Jira
* Storypoints
* Estimating: All estimates beyond the current sprint are completely unreliable. Still, people use storypoints to derive release dates and worse, measure the productivity of employees using them.
FWIW, until I learn of better processes, I prefer Scrum without "buts" and with continuous deployment.
I think it is, up until politics and managers come into play. If you leave to the team level, and you have some good senior people in a team that can also help and guide junior developers, you can do great.
In the end it depends on the people, and the biggest thing that can make or break this is the product owner. We had someone as a product owner who had absolutely no political play in the game, he was a designer that stepped in and understood the product. All he did was explain some quirks and come in to help if there are questions or things that are not clear. On the other hand, when the product owner tires to be a manager of the team and the processes, it all goes extremely wrong.
In the end it depends on the people, and the biggest thing that can make or break this is the product owner. We had someone as a product owner who had absolutely no political play in the game, he was a designer that stepped in and understood the product. All he did was explain some quirks and come in to help if there are questions or things that are not clear. On the other hand, when the product owner tires to be a manager of the team and the processes, it all goes extremely wrong.
We just nuked our daily stand-up.
The idea that we could have a call at a fixed time each day to figure out and reorient active development priorities is a manager's fantasy.
Some developers need a whole week to get momentum on very difficult tasks. Breaking their time up into discrete 24 hour chunks where they have to constantly report ambiguous progress can create incredible amounts of unnecessary stress over time.
We are now operating 100% async. I worked with our implementation group to ensure we have a buffer of priority issues so that developers always have a way to grab the next task, even if it's 3am on Saturday. Some people get inspired at weird times and that's totally fine.
The idea that we could have a call at a fixed time each day to figure out and reorient active development priorities is a manager's fantasy.
Some developers need a whole week to get momentum on very difficult tasks. Breaking their time up into discrete 24 hour chunks where they have to constantly report ambiguous progress can create incredible amounts of unnecessary stress over time.
We are now operating 100% async. I worked with our implementation group to ensure we have a buffer of priority issues so that developers always have a way to grab the next task, even if it's 3am on Saturday. Some people get inspired at weird times and that's totally fine.
My dad and grandfather were both doctors, and I somehow ended up in Startups as a programmer. Sometimes, in the middle of retrospectives, I start to daydream about what operating rooms would look like if managed by Agile(®)...
`Dr. Andrew's has certainly given his opinion about what we should do next with the patient, but what does Fred think? Fred says masks are pointless. Dr. Andrew, we're all equals here, you shouldn't let your emotions take over. We'd like you to perform this surgery without a mask...`
Luckily, it's just a software management technique, and generally speaking there are enough adults in the room that it moves forward regardless...
`Dr. Andrew's has certainly given his opinion about what we should do next with the patient, but what does Fred think? Fred says masks are pointless. Dr. Andrew, we're all equals here, you shouldn't let your emotions take over. We'd like you to perform this surgery without a mask...`
Luckily, it's just a software management technique, and generally speaking there are enough adults in the room that it moves forward regardless...
In a perfect world? Yes. On paper it is very good. And making people accountable for their work is a good thing. So is organizing work to be sure it gets done. I'm not a developer, but my department is developing a product for internal consumption, and using the Agile method is good for this purpose. I'm a terribly disorganized person so I like the structure it brings.
Beyond that, it's just a way of doing things, much like an OS. It doesn't matter if you're running W10, MacOS, or some flavor of Linux. If it's the right tool for the job, then it's the right tool for the job. But if it's not, then why is it in use?
Beyond that, it's just a way of doing things, much like an OS. It doesn't matter if you're running W10, MacOS, or some flavor of Linux. If it's the right tool for the job, then it's the right tool for the job. But if it's not, then why is it in use?
No.
Agile/xp started at Chrysler as a way to push back on management on give engineers a chance to pace/structure/set expectations for their work
Modern agile is just a management framework used as an excuse to micro manage the shit out of your work force.
Agile/xp started at Chrysler as a way to push back on management on give engineers a chance to pace/structure/set expectations for their work
Modern agile is just a management framework used as an excuse to micro manage the shit out of your work force.
Yeah, it's not complicated. What's crazy is the way lots of engineers rationalize all this instead of just being empirical. I think software selects for authoritarian personalities to a degree, who are quite comfortable pretending to be avatars of rule of law (they are merely messagers who can also disavow merely being a messenger) rather than looking at what's actually happening in front of their eyes, like the adversarial nature of most Product teams in most mediocre orgs.
I'll explain my experience, from starting as a newcomer in a business and ending as a Team Lead / Scrum Manager.
When I first started, we operated on textbook Waterfall standards - I'd be handed an issue from my manager, I'd spend an unspecified amount of time trying to fix it or implement it, and repeat. I had no context about what my other colleagues were doing, or about the greater scope of the project. We had several projects going on at once, which frequently missed deadlines or changed scope halfway through. I might spend a day on an issue, or two weeks - there was no assessment of how complex an issue was. Due to the age of the codebase, various parts of it had no unit tests or documentation.
Some of my other colleagues proposed using Scrum to organise a new project they were working on. Issues were organised, broken down as small as possible, and progress was delivered in Sprints. They estimated their issues, estimated a delivery date for each phase, and met it. They also implemented unit tests and completed documentation for the code.
Over time this method was expanded out to all new projects, with my colleagues organised into teams who focused on one project at a time (while handling maintenance of the older system).
I've found that pairing Scrum with other modern development techniques like unit testing and MVC architecture has made the projects much more maintainable and has given the teams more investment in driving the projects.
We use three parts of Scrum - standups, weekly sizings, reviews. While retrospectives were important early on, mostly everyone is happy with the level of Scrum we practice. A key thing is to not let these meetings overrun - that seems to be everyone's main complaint about Scrum is not letting it distract from actual work, but using the time to better plan it out. My managers can see the progress of a project in rea-time as well, between reviews and looking at the team burn-down mid-Sprint. We can better track issues that people are struggling with on a day-to-day basis.
I've now found it a lot easier to deliver projects on time, and to better justify why delays occur because of the increased amount of planning. My team members are now better invested in the project and morale is much higher. I see Scrum as enabling picking up other good practices as well, but it's not worth doing if you're not also pairing it with these other techniques, or it's just a way for management to hold lots of meetings. It really requires a team-based focus, which is why I think a lot of lone wolf programmers bounce off it.
When I first started, we operated on textbook Waterfall standards - I'd be handed an issue from my manager, I'd spend an unspecified amount of time trying to fix it or implement it, and repeat. I had no context about what my other colleagues were doing, or about the greater scope of the project. We had several projects going on at once, which frequently missed deadlines or changed scope halfway through. I might spend a day on an issue, or two weeks - there was no assessment of how complex an issue was. Due to the age of the codebase, various parts of it had no unit tests or documentation.
Some of my other colleagues proposed using Scrum to organise a new project they were working on. Issues were organised, broken down as small as possible, and progress was delivered in Sprints. They estimated their issues, estimated a delivery date for each phase, and met it. They also implemented unit tests and completed documentation for the code.
Over time this method was expanded out to all new projects, with my colleagues organised into teams who focused on one project at a time (while handling maintenance of the older system).
I've found that pairing Scrum with other modern development techniques like unit testing and MVC architecture has made the projects much more maintainable and has given the teams more investment in driving the projects.
We use three parts of Scrum - standups, weekly sizings, reviews. While retrospectives were important early on, mostly everyone is happy with the level of Scrum we practice. A key thing is to not let these meetings overrun - that seems to be everyone's main complaint about Scrum is not letting it distract from actual work, but using the time to better plan it out. My managers can see the progress of a project in rea-time as well, between reviews and looking at the team burn-down mid-Sprint. We can better track issues that people are struggling with on a day-to-day basis.
I've now found it a lot easier to deliver projects on time, and to better justify why delays occur because of the increased amount of planning. My team members are now better invested in the project and morale is much higher. I see Scrum as enabling picking up other good practices as well, but it's not worth doing if you're not also pairing it with these other techniques, or it's just a way for management to hold lots of meetings. It really requires a team-based focus, which is why I think a lot of lone wolf programmers bounce off it.
What we think shouldn't matter, instead we should look at the evidence to judge if Agile is beneficial for software delivery.
The problem is that research into software engineering sucks. The silver lining is that some people have done small scale studies on this subject.
The studies I've read range from no impact to a significant improvement of using Agile methodologies over, say, waterfall processes. This large variability is a hint of how inconsistent these studies are, but I've seen more evidence piling up in the "good" side of the scale.
However, from your loaded comment seems clear you aren't really interested in data anyway.
The problem is that research into software engineering sucks. The silver lining is that some people have done small scale studies on this subject.
The studies I've read range from no impact to a significant improvement of using Agile methodologies over, say, waterfall processes. This large variability is a hint of how inconsistent these studies are, but I've seen more evidence piling up in the "good" side of the scale.
However, from your loaded comment seems clear you aren't really interested in data anyway.
I have worked in projects where agile/scrum worked really well and on other projects that it did not work well. Since the process is so variable, I think it is bad for software delivery.
The parts I didn't think worked:
* Retrospectives which had no actions as an outcome
* Daily stand ups that were led by a project manager who discussed each persons work 1 to 1 within the group
* Bugs not really fitting into the flow of work
* A poor planning session can set up a bad sprint
* Sprints often ending without any working software
* Team members working in silos
* Outside dependencies blocking work
* Estimating turning into 'how many hours will this take?'
* People reporting working on two or three things every standup
* and the worst imo, work not on the sprint board that must be done
The parts I didn't think worked:
* Retrospectives which had no actions as an outcome
* Daily stand ups that were led by a project manager who discussed each persons work 1 to 1 within the group
* Bugs not really fitting into the flow of work
* A poor planning session can set up a bad sprint
* Sprints often ending without any working software
* Team members working in silos
* Outside dependencies blocking work
* Estimating turning into 'how many hours will this take?'
* People reporting working on two or three things every standup
* and the worst imo, work not on the sprint board that must be done
As many other have already said it all depends on how it is implemented, and most companies do it wrong. Scrum is hard, not because it is difficult to do it, but because in most companies it requires a change and changes are hard. In my company we implemented scrum in an iterative fashion, changing one practice at a time, till we got to (almost) full scrum, and I like it.
You need to take in consideration what scrum makes you do (stand up meeting,...) but also what it is meant to prevent and you shouldn't usually do (interruptions and working on requirements that change daily)
It's hard but when done properly it's great
You need to take in consideration what scrum makes you do (stand up meeting,...) but also what it is meant to prevent and you shouldn't usually do (interruptions and working on requirements that change daily)
It's hard but when done properly it's great
Unequivocally, NO. Please don't tell me I'm doing it wrong.
The cons are it's a huge waste of my time.
I much prefer a system where someone just tells me what they want/expect, and leaves me alone while I do it.
I have no idea how tracking should be done.
The cons are it's a huge waste of my time.
I much prefer a system where someone just tells me what they want/expect, and leaves me alone while I do it.
I have no idea how tracking should be done.
I do like the standup if it really is “stand up” (so short that it’s not worth sitting down).
What I’ve seen work best is just a quick “hey this is what I’m doing today/this week, will depend on yyy” so that anyone who depends on what you’re doing (or not doing) knows; alternatively, “wait, you’re depending on my project yyy?”, no discussion except, “hey, let’s talk directly after this”.
Not for any manager’s benefit, just for each others’. Like a code review there should be no judgement. If anybody wants discussion do it elsewhere so everybody else can get on with things.
What I’ve seen work best is just a quick “hey this is what I’m doing today/this week, will depend on yyy” so that anyone who depends on what you’re doing (or not doing) knows; alternatively, “wait, you’re depending on my project yyy?”, no discussion except, “hey, let’s talk directly after this”.
Not for any manager’s benefit, just for each others’. Like a code review there should be no judgement. If anybody wants discussion do it elsewhere so everybody else can get on with things.
If you want to grok Scrum you should read James Coplien's A Scrum Book or his related work on patterns.
Also, the bean counters have won. In most enterprise companies "Agile" is nothing more than top down micromanagement.
Also, the bean counters have won. In most enterprise companies "Agile" is nothing more than top down micromanagement.
Daily standups seem to work ok for operations teams like SRE.
I find it is the human equivalent of alerting and observability.
SCRUM/AGILE/whatever for development and product teams is a red flag for me. I find that bi-weekly demo days seem to set a better culture and pace for things without the constant oversight.
Sprinkle in some weekly "forums" across teams to chat, BS, and discuss issues. Invite people to bring their agenda questions, concerns, etc.
The biggest thing (especially in remote) is that all your humans have visibility to the other humans in a semi-consistent basis. The org-chart matters.
SCRUM/AGILE/whatever for development and product teams is a red flag for me. I find that bi-weekly demo days seem to set a better culture and pace for things without the constant oversight.
Sprinkle in some weekly "forums" across teams to chat, BS, and discuss issues. Invite people to bring their agenda questions, concerns, etc.
The biggest thing (especially in remote) is that all your humans have visibility to the other humans in a semi-consistent basis. The org-chart matters.
I see value of daily standups and planning next sprint e.g 2 weeks and I like them
but we dropped that bullshit like "story points" - you know, abstraction over abstraction of time/effort whatever it is.
we estimate stuff in man hours.
but we dropped that bullshit like "story points" - you know, abstraction over abstraction of time/effort whatever it is.
we estimate stuff in man hours.
I have found agile rituals like standups, retros, iteration planning meetings etc helpful because it gives multiple forums especially for junior developers to participate. These help break down information asymmetries that can creep up.
However, it is essential to keep in mind why these things are done and not just cargo cult them.
I have felt Scrum is cargo cult agile which helps non technical managers retain power post "agile transformation" in the form of "scrum master". Just that title changes the power balance in meetings and kills the spirit of what they are meant for.
However, it is essential to keep in mind why these things are done and not just cargo cult them.
I have felt Scrum is cargo cult agile which helps non technical managers retain power post "agile transformation" in the form of "scrum master". Just that title changes the power balance in meetings and kills the spirit of what they are meant for.
Hoo nelly! You’ve asked a question that can easily get HN to write 50+ pages. Hope you like reading!
To make a meeting matter, make a decision. You can make the daily stand up ritual into something meaningful to the participants, if you recast it as “let’s decide what we’re gonna do today.” If it is just a progress update, then it can be done better asynchronously.
But, the daily stand up actually does increase productivity as a status update, if the work is not planned out properly. So let me get into what that means: in theory, on any software project, there is a dependency graph of steps which have to be done in order to achieve the next release. This graph also has implicit dependencies just because we have finite resources and one person can't do everything at once. The steps also come with some time estimate, and then we know that there is uncertainty in that estimate so we add safety buffer. Whether the work is planned out properly comes down to whether this safety buffer is spent, or squandered. If the most important thing is not being worked on, if it is sitting waiting for review say, or if it is just an ugly messy task that nobody wants to pick up: then your safety buffer is getting spent but you're not getting much for it. And the easiest place that this happens is at the start of a new release when there seems to be so much abundant safety buffer that it is now time to play and relax and experiment with random ideas. In fact, give arbitrary amounts of safety buffer to a poorly planned software project, and it will overrun whatever buffer you give it, simply because of this lack of urgency at the start, it becomes even less urgent if it's not due in one quarter but is instead due in three quarters.
So that is where standup comes in and imposes an artificial urgency. And somebody randomly happens to work on the critical path and it starts moving forward. Until you run into a big ugly problem that nobody wants to solve on the critical path, then the project gets delayed until there are no other things to work on, someone has to slog through the pain. you still miss the deadline but not by nearly as much as you were. Lights a candle under everyone's ass. It's not the right approach, the right approach would light a bonfire under one person's ass, the exact right person's ass, until they passed the baton to the next person.
To make a meeting matter, make a decision. You can make the daily stand up ritual into something meaningful to the participants, if you recast it as “let’s decide what we’re gonna do today.” If it is just a progress update, then it can be done better asynchronously.
But, the daily stand up actually does increase productivity as a status update, if the work is not planned out properly. So let me get into what that means: in theory, on any software project, there is a dependency graph of steps which have to be done in order to achieve the next release. This graph also has implicit dependencies just because we have finite resources and one person can't do everything at once. The steps also come with some time estimate, and then we know that there is uncertainty in that estimate so we add safety buffer. Whether the work is planned out properly comes down to whether this safety buffer is spent, or squandered. If the most important thing is not being worked on, if it is sitting waiting for review say, or if it is just an ugly messy task that nobody wants to pick up: then your safety buffer is getting spent but you're not getting much for it. And the easiest place that this happens is at the start of a new release when there seems to be so much abundant safety buffer that it is now time to play and relax and experiment with random ideas. In fact, give arbitrary amounts of safety buffer to a poorly planned software project, and it will overrun whatever buffer you give it, simply because of this lack of urgency at the start, it becomes even less urgent if it's not due in one quarter but is instead due in three quarters.
So that is where standup comes in and imposes an artificial urgency. And somebody randomly happens to work on the critical path and it starts moving forward. Until you run into a big ugly problem that nobody wants to solve on the critical path, then the project gets delayed until there are no other things to work on, someone has to slog through the pain. you still miss the deadline but not by nearly as much as you were. Lights a candle under everyone's ass. It's not the right approach, the right approach would light a bonfire under one person's ass, the exact right person's ass, until they passed the baton to the next person.
I've got a pleasure to watch this Scrum thingy in action while consulting for one rather known company. To my eyes it was colossal waste of time and resources. I was an independent vendor so I did not really need to participate and only came to their offices every once in a while. Still out of curiosity went to few standups and that got me pretty depressed. In my eyes at least from what I saw the only "value" it brought was giving a job to a people who should not be let near software development process.
To me, Scrum is kind of like someone packaged cargo culting and started selling it as a product. All of the routines and processes that some successful team had at one point, with none of the underlying understanding. There is a kernel of Lean in there, somewhere, though. The most recent incarnation is probably the DevOps-movement. I think the principles behind Lean are pretty solid, and understanding them and then applying them in forming how your team works is a genuinely good idea. Scrum is not.
What matters is critical thought in optimizing whichever methodology you use for your team.
No methodology works right out of the box and it’s insane to think that any could. You have to look at your specific requirements and mold Agile around your team. Agile literally says to do this but most just ignore it.
The more thought you put into your methodology, the better it will work. I know most want Agile to replace critical thought because they don’t want to have a target on their back if things go wrong but there is no substitute.
No methodology works right out of the box and it’s insane to think that any could. You have to look at your specific requirements and mold Agile around your team. Agile literally says to do this but most just ignore it.
The more thought you put into your methodology, the better it will work. I know most want Agile to replace critical thought because they don’t want to have a target on their back if things go wrong but there is no substitute.
Agile is about being able to respond to change quickly by delivering value sooner.
Scrum is a gimmick invented to sell scrum courses. It's an easy-to-understand framework for convincing managers that their teams are agile, but I've never seen it work in practice.
Some of the scrum practices - such as daily strandups - can be extremely valuable for software teams. Standups, for example, are an opportunity for alignment, or more accurately, for correcting misalignment. And like all practices, they can be practiced badly.
Scrum is a gimmick invented to sell scrum courses. It's an easy-to-understand framework for convincing managers that their teams are agile, but I've never seen it work in practice.
Some of the scrum practices - such as daily strandups - can be extremely valuable for software teams. Standups, for example, are an opportunity for alignment, or more accurately, for correcting misalignment. And like all practices, they can be practiced badly.
I’ve found that the best value I’ve ever gotten from Sprints, was to manage upwards. We had a CEO that would request features daily, change priorities hourly, and get angry when nothing was delivered.
So by having each Sprint accounted for and signed off, whenever he barged in and demanded something new, the first question was asked - what would he like removed from the current Sprint. By him signing off that things were removed, he could no longer ask why it wasn’t completed as originally agreed to
So by having each Sprint accounted for and signed off, whenever he barged in and demanded something new, the first question was asked - what would he like removed from the current Sprint. By him signing off that things were removed, he could no longer ask why it wasn’t completed as originally agreed to
I've seen agile/scrum implemented very well exactly once. I could say some clichés about well-meshed gears. It was a great experience to work within. Was it just a well built team or did agile/scrum actually help? I think the latter based on the general ease and stability of our software releases.
I've subsequently seen agile/scrum very poorly several times within both large and small companies.
I like working within Agile/Scrum - when it's implemented well. But that's rare.
I've subsequently seen agile/scrum very poorly several times within both large and small companies.
I like working within Agile/Scrum - when it's implemented well. But that's rare.
There seems to be a lot of confusion in the comments over what agility means vs the bureaucratic cargo-culting safe/scrum nonsense that has been perpetuated by enterprises and “certification” providers.
The ideas behind agility in software development were all about reducing bureaucracy, focusing on small slices straight to the customer, strong focus on quality and testing practices and continually readjusting and improving. None of it was ever about stand ups, estimation, using Jira etc.
The ideas behind agility in software development were all about reducing bureaucracy, focusing on small slices straight to the customer, strong focus on quality and testing practices and continually readjusting and improving. None of it was ever about stand ups, estimation, using Jira etc.
In my team we took some agile practice and threw out some others.
We do:
- sprints
- retrospectives
- healthchecks (from Spotify squads)
- story points, and kinda compute our velocity. Well, we approximately know how many points we can do in a sprint
- say no. We routinely refuse to do stuff coming from the top of it doesn't align with our vision as engineers
We stopped:
- daily stand-ups. They're completely useless
- poker planning. We still evaluate tasks together but without the useless ceremonial, and autonomously reevaluate during the sprint if necessary. It's considered bad, we don't care, it works.
We do:
- sprints
- retrospectives
- healthchecks (from Spotify squads)
- story points, and kinda compute our velocity. Well, we approximately know how many points we can do in a sprint
- say no. We routinely refuse to do stuff coming from the top of it doesn't align with our vision as engineers
We stopped:
- daily stand-ups. They're completely useless
- poker planning. We still evaluate tasks together but without the useless ceremonial, and autonomously reevaluate during the sprint if necessary. It's considered bad, we don't care, it works.
"Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress."
Sounds you would like proof that scrum does not work. Instead, how about looking at the parts that could work for your team, and discuss if you should adopt?
When we need a bit more torque, we tend to adapt more process and when we have plenty of time to waste we abandon process and take it easy.
If you are lazy and dont want to work, you probably dont want processes that expose your slack.
Sounds you would like proof that scrum does not work. Instead, how about looking at the parts that could work for your team, and discuss if you should adopt?
When we need a bit more torque, we tend to adapt more process and when we have plenty of time to waste we abandon process and take it easy.
If you are lazy and dont want to work, you probably dont want processes that expose your slack.
The idea of the agile manifesto is great.
The implementation sucks.
As-is-done the value proposition of the management style is in the negative.
This negative value, aka cost, is then used to support extra roles nobody needs - scrum masters, agile consultants, etc.
From a, e.g., YC POV, agile is great, because you can sell useless cloud-worded services surrounding it.
From a dev POV, out of the trenches, it's an annoying fad - at best.
It depends on what you were doing previously.
And it also depends on how you implement it - doing it well relies on buy-in from anyone touching the dev team in any way.
So, yes it can offer benefits, for some companies, if done well.
Just renaming managers into product owners and renaming hour long meetings where you explain yourself to the manager "stand-up" is not going to get you anywhere. Doing it right involves significant change to process with no-one trying to circumvent it.
And it also depends on how you implement it - doing it well relies on buy-in from anyone touching the dev team in any way.
So, yes it can offer benefits, for some companies, if done well.
Just renaming managers into product owners and renaming hour long meetings where you explain yourself to the manager "stand-up" is not going to get you anywhere. Doing it right involves significant change to process with no-one trying to circumvent it.
[deleted]
Scrum and sprints is like placing an obstacle in front of a blind person, you trick the developers into thinking it's good for them, while you tricked them they work harder and harder and then you also trick them into OnCall so they also work at nights, give them laptops so they don't stop working from home, give them slack on their mobile so they are fully connected and here you have it .
Slightly off-topic but there should really be a "no-scrum"-hiring website, which displays companies that are NOT following scrum.
It depends on what you compare it to. It's supposed to be fewer meetings than the alternative.
Standups aren't supposed to be about managing, there is no manager present. Ours takes 5 to 10 minutes before lunch.
However Scrum has become so formalised, so focused on certifications and titles and the exact way to do it, that it's become the opposite of what Agile was trying to achieve.
Standups aren't supposed to be about managing, there is no manager present. Ours takes 5 to 10 minutes before lunch.
However Scrum has become so formalised, so focused on certifications and titles and the exact way to do it, that it's become the opposite of what Agile was trying to achieve.
The idea of Agile/Scrum is great.
The practice varies, if done correctly it's beneficial, if done poorly it's a nightmare like any poor software engineering practice. Can't tell you definitively about how beneficial it is to the software industry, but I believe it's a net positive since it has encouraged faster shipment over big bang releases.
The practice varies, if done correctly it's beneficial, if done poorly it's a nightmare like any poor software engineering practice. Can't tell you definitively about how beneficial it is to the software industry, but I believe it's a net positive since it has encouraged faster shipment over big bang releases.
I’ve been thinking a lot about this, but im on my phone so quick answer is I think we should file it on the “x is considered harmful” pile.
Most people aren’t doing agile, they’re doing a custom, lightweight version of it. This is a good practice though I still think it hurts projects; but not as much as quote unquote real agile.”
Can you make it a poll? That would be really interesting
Most people aren’t doing agile, they’re doing a custom, lightweight version of it. This is a good practice though I still think it hurts projects; but not as much as quote unquote real agile.”
Can you make it a poll? That would be really interesting
Define Agile/Scrum.
Oh, a few months passed?
Define Agile/Scrum again, because one of the key decision makers has moved to a different role, so we’re changing things. So what’s the new definition?
Oh, some more time passed?
More org changes! Time to change the definition of Agile/Scrum again.
Now, what was the question?
“Well if you’re doing it right, it should survive though changes of management.”
Oh ok, but tell me... when did that assumption ever hold?
Oh, a few months passed?
Define Agile/Scrum again, because one of the key decision makers has moved to a different role, so we’re changing things. So what’s the new definition?
Oh, some more time passed?
More org changes! Time to change the definition of Agile/Scrum again.
Now, what was the question?
“Well if you’re doing it right, it should survive though changes of management.”
Oh ok, but tell me... when did that assumption ever hold?
Standup is a thing you do in scrum but I don't think it's the most important thing. I think the most important thing is getting better at estimating work over time and leading to better ability to plan realistic chunks of work, and the mindset to respond to changing plans. It lets you impose a predictable rithym on unpredictable life.
When done right Agile as a process is beneficial to product development. In the framework Scrum, dailys facilitate communication, and increase productivity.
Cons of any product development process is not taking into account human interaction and assuming a perfect team.
Build a team first, choose process to get the best out of this team be it Agile/whatever.
Cons of any product development process is not taking into account human interaction and assuming a perfect team.
Build a team first, choose process to get the best out of this team be it Agile/whatever.
A good team will produce good software, regardless of methodology.
But a good agile team will be more responsive to changing customer needs.
But a good agile team will be more responsive to changing customer needs.
I think it is useful to rephrase your questions to make the intent of sprints and standups more explicit:
Sprints: What are the pros and cons of delivering working software incrementally at regular intervals?
Standups: What are the pros and cons of teams members spending 15 minutes together every day talking about their work and how they might help each other?
Sprints: What are the pros and cons of delivering working software incrementally at regular intervals?
Standups: What are the pros and cons of teams members spending 15 minutes together every day talking about their work and how they might help each other?
No.
That's what I want to believe anyways.
It would be interesting to see an actual study, though.
Team A does project 1 with Scrum.
Team B does project 1 without Scrum.
Let's say over 3 months.
Who wins?
We could look at time to finish, bugs, code quality/resilience, etc.
I know there is a 'study' out every other day from some Project Mgmt org saying, "500% of IT Projects are fail!", but obviously we need real studies.
That's what I want to believe anyways.
It would be interesting to see an actual study, though.
Team A does project 1 with Scrum.
Team B does project 1 without Scrum.
Let's say over 3 months.
Who wins?
We could look at time to finish, bugs, code quality/resilience, etc.
I know there is a 'study' out every other day from some Project Mgmt org saying, "500% of IT Projects are fail!", but obviously we need real studies.
"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan" -- Agile Manifesto
Whatever we do in agile/scrum of Today is anything but that.
I am curious to know if Teslas/SpaceXes/Googles/Stripes of the world practice Agile/Scrum?
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan" -- Agile Manifesto
Whatever we do in agile/scrum of Today is anything but that.
I am curious to know if Teslas/SpaceXes/Googles/Stripes of the world practice Agile/Scrum?
Can anyone name a well-known important software project (say linux, python, tensorflow, angular) that was delivered via Agile/Scum? And some of you may enjoy this linkblog https://againstscrum.tumblr.com/
Agile - yes, Scrum - no.
Like with any great idea there was someone who decided to monetize it. Thats how scrum was born.
I see that with every pragmatic solution good devs try to share:
- TDD
- Agile
- FP
Sooner or later some “hot-shot” shows up and decides to “teach” ppl for money “how to do things correct way”.
After that great ideas turn into crap, because too many people want profit from it instead of learning from it.
Like with any great idea there was someone who decided to monetize it. Thats how scrum was born.
I see that with every pragmatic solution good devs try to share:
- TDD
- Agile
- FP
Sooner or later some “hot-shot” shows up and decides to “teach” ppl for money “how to do things correct way”.
After that great ideas turn into crap, because too many people want profit from it instead of learning from it.
Extra bureaucracy do bring value but not for the operators. Rather, they benefit the learning of the organization at the cost of overhead to every operator.
Pros: helps team uncover and jump over costly roadblocks Cons: overhead
There’s probably a better system out there. Till someone invents it, Scrum works fine for my teams
Pros: helps team uncover and jump over costly roadblocks Cons: overhead
There’s probably a better system out there. Till someone invents it, Scrum works fine for my teams
Good waterfall is better than good agile. Bad agile is better than bad waterfall.
Many places also do agile badly. The ones that have stand ups without a (certified) scrum master are likely doing it wrong and can often be anti-productive.
Kanban is fine though, and a good low overhead technique for multiple people in a team.
Many places also do agile badly. The ones that have stand ups without a (certified) scrum master are likely doing it wrong and can often be anti-productive.
Kanban is fine though, and a good low overhead technique for multiple people in a team.
From what I’ve seen in the video game industry, scrum is pointless and often destructive.
I’ve often seen coders staring at the void during so-called standups, and very weak devs closing tickets while doing almost nothing useful for the project, because their managers cared only for this metric...
I’ve often seen coders staring at the void during so-called standups, and very weak devs closing tickets while doing almost nothing useful for the project, because their managers cared only for this metric...
The opponent is software complexity. The task is iterate design, to create a simple solution. Money will be made or lost depending on whether the solution is both simple and useful enough.
Scrum, management, meetings distract at best, crush at worst, this critical creative process.
Scrum, management, meetings distract at best, crush at worst, this critical creative process.
As it's done in reality? No.
If done properly (very rarely done properly) it works as described on the box.
Most people simple use Agile as a way to generate interactive Gantt Charts that management can change willy-nilly. It's very rarely done to empower teams or improve effectiveness.
If done properly (very rarely done properly) it works as described on the box.
Most people simple use Agile as a way to generate interactive Gantt Charts that management can change willy-nilly. It's very rarely done to empower teams or improve effectiveness.
Agile is the worst possible way to deliver software except for everything else we've tried.
I find value in part of it. Dailies I find very beneficial. You get to hear what other people are having problems with, and maybe you already faced something similar. Or the other way around, when you face it you remember that someone solved a similar issue.
Think of this as a plateau point in a new industrial revolution. Steam engines were great, and improved mines and factories - and then we had to redesign society around the effects (slums, poverty etc. Oh no wait, new housing, new cities, ... it took a while)
We are trying to build a new way of building value - this time using code as technology. My usual comparator is this is software literacy - and we need to look at the effects of the European literacy explosion of 1450's as a guide (renaissance Italy still kept glassblowers as virtual prisoners)
The things that are broken and I think in need of change
* Capital vs Management. Executives often capture too much value, and control too many of the allocation decisions. Huge corporations are inefficient - in a similar scale to centrally planned economies. (For example, I cannot imagine that Jeff Bezos spending billions on rockets is the most efficient means to produce value from those billions)
* command and control vs democracy. Again with the decisions best taken at small scale. How would your (big) company behave if instead of executives deciding which projects got what funding, it was voted upon by employees? It would be radically different. Would it be better? I imagine the discussion forums would look a lot like Linus' rants. How would we moderate that? Would hiring people be different? Would you hire someone politically different to you if they might vote against you? Would you even get a hiring decision?
* Project Management stops being about dates. This bugs me a lot - at some point all the nice agile - we need certain level of quality, story points are a measure of complexity not time, we discover as we go, all that falls apart and becomes a date in a plan at the board level. Mostly because the tools used at board level (and the mental models) cannot cope with ideas of alpha, beta, prod quality, or if this date slips all other dates slip too - cones of uncertainty are a good approach to this, as are other mapping functions about the relationships between features and capabiites. I dont have a good answer here either.
But there is a lot going on - its not a fad (ok Scrum might be, but this is not about scrum - or agile - its about how do we humans produce this new code thing at scale and change our society around it as we did in 1450 with words, or 1890 with cars.
If you have the skill to write code, then dismissing this as "management crap" means giving up an informed voice on one of humanities most important inflexion points since ... the last one.
We are trying to build a new way of building value - this time using code as technology. My usual comparator is this is software literacy - and we need to look at the effects of the European literacy explosion of 1450's as a guide (renaissance Italy still kept glassblowers as virtual prisoners)
The things that are broken and I think in need of change
* Capital vs Management. Executives often capture too much value, and control too many of the allocation decisions. Huge corporations are inefficient - in a similar scale to centrally planned economies. (For example, I cannot imagine that Jeff Bezos spending billions on rockets is the most efficient means to produce value from those billions)
* command and control vs democracy. Again with the decisions best taken at small scale. How would your (big) company behave if instead of executives deciding which projects got what funding, it was voted upon by employees? It would be radically different. Would it be better? I imagine the discussion forums would look a lot like Linus' rants. How would we moderate that? Would hiring people be different? Would you hire someone politically different to you if they might vote against you? Would you even get a hiring decision?
* Project Management stops being about dates. This bugs me a lot - at some point all the nice agile - we need certain level of quality, story points are a measure of complexity not time, we discover as we go, all that falls apart and becomes a date in a plan at the board level. Mostly because the tools used at board level (and the mental models) cannot cope with ideas of alpha, beta, prod quality, or if this date slips all other dates slip too - cones of uncertainty are a good approach to this, as are other mapping functions about the relationships between features and capabiites. I dont have a good answer here either.
But there is a lot going on - its not a fad (ok Scrum might be, but this is not about scrum - or agile - its about how do we humans produce this new code thing at scale and change our society around it as we did in 1450 with words, or 1890 with cars.
If you have the skill to write code, then dismissing this as "management crap" means giving up an informed voice on one of humanities most important inflexion points since ... the last one.
Daily stand-ups and scrum events work very well when used as a self organizing tool for the scrum team. Micromanagers are not invited. And neither are managers. (I am saying this as a manager myself.) This is what causes the process to breakdown.
Love all the comments to the effect of if agile/scrum/other buzzword isn't working, it's because you're not really doing it/you're not doing it enough/you're just cargo culting it bla bla bla
It’s great in theory and sometimes in practice. However it’s also a dangerous tar pit for rule followers.
Whatever you do, make sure you review all procedures to decide if they make sense for your team. Don’t follow them blindly.
Kanban is an approach with less ceremony.
Whatever you do, make sure you review all procedures to decide if they make sense for your team. Don’t follow them blindly.
Kanban is an approach with less ceremony.
Problem is that software, frontend in particular, attracts low-grade authoritarian personalities who are ok being vessels of the "rule-of-law" and so aren't aware enough to perceive something doesn't work after enough unsuccessful iterations
I think it depends on what the Scrum/Agile process looks like and what it is replacing. For example, I think its pretty useful to have an iterative forecast of achievable work rather than a huge BRD and a solid deadline.
There are no "pros". Agile was created by consultants to sell consulting, and the so-called "Agile Manifesto" is nothing but silly aphorisms unrelated to the task of developing and delivering software.
Did you even care to check who wrote the agile manifesto?
A good book about that might be clean agile by uncle Bob. It should will your view on the origin and history of agile.
Yeah, I was in the industry back then, I know exactly what kind of people created it and why. Citing "Uncle Bob" is hardly an endorsement.
Can be, but the last place I was in that tried to adopt agile ended up changing managers, and now have one guy assigning tickets and expecting people to show up to "his" stand-up meeting.
I wasn't the only person that left.
I wasn't the only person that left.
I recommend the “Agile is dead (long live agility)” talk by Dave Thomas, one of the creators of the Agile Manifesto.
https://youtu.be/vqz8ND-N1hc
https://youtu.be/vqz8ND-N1hc
It's all about cutting the time in standups down to a bare minimum. I don't care what you did yesterday, I want to know in one sentence what you're doing _today_ and if you're blocking anyone.
They're patronising, micro-management that might work on juniors, but are offensive to anyone else. I can't stand them, and have only seen them cause harm. Monotonous, tedious, theatrical speed bumps.
[deleted]
Have you heard about DarkScrum?
The Agile manifesto doesn't talk about roles or how the process should be, but Scrum does it.
Agile itself was introduced by bunch of software engineers came up with the Agile manifesto. It's simple, abstract, and effective. There are many successful tech companies that already have something more extensive than Agile. Agile manifesto is just a good starting point if you don't have anything in place.
But somehow Scrum became the recipe to implement Agile and we ended up with a job title called Scrum Master which has been increasingly taken by non technical people inside traditional organizations.
I've seen teams that implement Scrum by the book. They have a person called Scrum Master that facilitates all team meetings. It basically turns other team members into reactive players instead of proactive. But, do we really need a person to facilitate team meetings and ceremonies?
I talked with a few Scrum Masters, their job satisfaction is actually very low and even though they don't admit it to their own team, they don't believe they are adding real value. What they all have in common is that they all want to switch to a different role and they are looking for an opportunity.
I couldn’t find anything similar in other industries, and it's hard to find a successful development team that implements Scrum by the book. What you find most of the time is what is called "other Scrum flavors" and I think that's a problem in our industry. What many teams are doing isn't Scrum, but anything that has a short release cycle, a daily update in any form, and a retrospective is called Scrum.
The irony is that most of the Silicon Valley and successful tech companies don't use Scrum at all. In fact many of them don't even label what they have as Agile.
What is happening right now is many companies wasting lots of time trying to implement Scrum by the book until they fail and move on to something that they call a Scrum flavor. I think we should stop calling it Scrum so others don't have to repeat the same mistake again and again.
If a team fails, Scrum compares it to its book and says the team failed because they didn't implement Scrum properly. And when a team with one of those so-called "Scrum flavors" is successful, Scrum takes all the credit.
I personally think we should kill Scrum. We shouldn't advocate it and we shouldn't call any team with a daily update a Scrum team. Many successful tech companies don't use Scrum, but they aren't vocal about it.
The Agile manifesto doesn't talk about roles or how the process should be, but Scrum does it.
Agile itself was introduced by bunch of software engineers came up with the Agile manifesto. It's simple, abstract, and effective. There are many successful tech companies that already have something more extensive than Agile. Agile manifesto is just a good starting point if you don't have anything in place.
But somehow Scrum became the recipe to implement Agile and we ended up with a job title called Scrum Master which has been increasingly taken by non technical people inside traditional organizations.
I've seen teams that implement Scrum by the book. They have a person called Scrum Master that facilitates all team meetings. It basically turns other team members into reactive players instead of proactive. But, do we really need a person to facilitate team meetings and ceremonies?
I talked with a few Scrum Masters, their job satisfaction is actually very low and even though they don't admit it to their own team, they don't believe they are adding real value. What they all have in common is that they all want to switch to a different role and they are looking for an opportunity.
I couldn’t find anything similar in other industries, and it's hard to find a successful development team that implements Scrum by the book. What you find most of the time is what is called "other Scrum flavors" and I think that's a problem in our industry. What many teams are doing isn't Scrum, but anything that has a short release cycle, a daily update in any form, and a retrospective is called Scrum.
The irony is that most of the Silicon Valley and successful tech companies don't use Scrum at all. In fact many of them don't even label what they have as Agile.
What is happening right now is many companies wasting lots of time trying to implement Scrum by the book until they fail and move on to something that they call a Scrum flavor. I think we should stop calling it Scrum so others don't have to repeat the same mistake again and again.
If a team fails, Scrum compares it to its book and says the team failed because they didn't implement Scrum properly. And when a team with one of those so-called "Scrum flavors" is successful, Scrum takes all the credit.
I personally think we should kill Scrum. We shouldn't advocate it and we shouldn't call any team with a daily update a Scrum team. Many successful tech companies don't use Scrum, but they aren't vocal about it.
I cannnot say it is benifecial for delivery, but it is beneficial for engineers, cos' focusing on processing not the results.
A good agile process, make development work less stress.
A good agile process, make development work less stress.
Has anyone here used scrum for research oriented machine learning projects at a company? How well did it work and if it worked well, what tweaks did you make, if any?
Considering that “old-school non-agile” can mean many different things, it would be very surprising if Scrum were uniformly better or worse than all of them.
Depends what you build.
For experimental stuff, agile could be good.
For product stuff, Scrum could be good.
For commodity stuff, six sigma could be good.
Using one of these for something it isn't meant to do will lead to failure.
For experimental stuff, agile could be good.
For product stuff, Scrum could be good.
For commodity stuff, six sigma could be good.
Using one of these for something it isn't meant to do will lead to failure.
A lot of people misunderstand scrum. It doesn't slow you down but speeds you up. Why? It enpowers the team to cut out all the bullshit.
Standup is a status meeting? Who told you that? It's a planning meeting. You plan the day with your peers. If you do it right you don't have to talk to anyone the rest of the day and just flow.
Don't listen to the consultants. Learn about real scrum from here. https://sites.google.com/a/scrumplop.org/published-patterns/...
Standup is a status meeting? Who told you that? It's a planning meeting. You plan the day with your peers. If you do it right you don't have to talk to anyone the rest of the day and just flow.
Don't listen to the consultants. Learn about real scrum from here. https://sites.google.com/a/scrumplop.org/published-patterns/...
Scrum is a ridiculous waste of time today due to non-software savvy (as in aren't afraid of code) folks polluting project manager, product owner, product manager, and software manager positions.
Tickets come flying in, blockers get turned into a mountain from a mole hill, planning meetings are multi-hour time wasters, retrospectives cover the same things, and everybody is just nice to each other rather than raising their concerns. Deadlines are a fallacy, other than giving substance to these ritual meetings.
Kanban makes so much more sense. Allows estimation via cycle time
Tickets come flying in, blockers get turned into a mountain from a mole hill, planning meetings are multi-hour time wasters, retrospectives cover the same things, and everybody is just nice to each other rather than raising their concerns. Deadlines are a fallacy, other than giving substance to these ritual meetings.
Kanban makes so much more sense. Allows estimation via cycle time
Done right, I see scrum as a good way to get a team ease into an agile methodology.
What bothers me is that scrum masters are being groomed as the next-gen MBA.
What bothers me is that scrum masters are being groomed as the next-gen MBA.
out of many places i,ve worked which practiced agile, only one did it well. we spent entire day on planning, another entire day on retro. we broke down tasks to no more than three points. we did not try to squeeze out more than possible. our software turned out robust and reliable, and our estimates were spot on. everyone was happy. the key was the manager.
Yes, because the developers understand better what brings the money, so they invest their time and resources more efficiently.
no
too much chin wagging, not enough building too much synchronous communication
for being called agile you don't build software very quickly with it
too much chin wagging, not enough building too much synchronous communication
for being called agile you don't build software very quickly with it
Of course not. But it’s good for the manager industry. Slow the gears down enough and create more and more overhead.
I've never found any advantages from daily standups.
As you note, disadvantages include micromanagement and perverse incentives.
As you note, disadvantages include micromanagement and perverse incentives.
Yes. They make it easier to co-manage larger teams with people with drastically different philosophical opinions and can (if well-trained and practiced) help avoid burning out your team.
That is to say, in a lot of ways a small clever theologically-aligned team is going to be better. But if there’s a good reason you can’t have that, scrum can help you make the most of it.
That is to say, in a lot of ways a small clever theologically-aligned team is going to be better. But if there’s a good reason you can’t have that, scrum can help you make the most of it.
Scrum is not agile. You really should not write scrum/agile. That is just as bad c/c++ :-)
No, as generally practiced, it is not of any value aside from keeping project managers busy.
I think there are types of projects where Agile/Scrum works well and makes sense and that's mostly in web or direct customer facing applications and especially in those with either very quick or already setup infrastructure. There small changes can be presented quickly and iterations can be fast.
Unfortunately I've been working in backend data movement since college where the final product is very well defined in the old waterfall model. Our intermediate tables aren't any use to the internal customers and there's not really much iteration needed, they come to us with data that's somewhere other than where they need it and we bring it to where they do. Recently though our org has taken to Agile/Scrum and the results are a little painful especially with our projects that require significant infrastructure setup, all of which is owned by external teams often understaffed so their backlogs are weeks to months long and while we're waiting on provisioning or approval from governance we're stuck looking for stuff to do that will meaningfully move things forward.
Unfortunately I've been working in backend data movement since college where the final product is very well defined in the old waterfall model. Our intermediate tables aren't any use to the internal customers and there's not really much iteration needed, they come to us with data that's somewhere other than where they need it and we bring it to where they do. Recently though our org has taken to Agile/Scrum and the results are a little painful especially with our projects that require significant infrastructure setup, all of which is owned by external teams often understaffed so their backlogs are weeks to months long and while we're waiting on provisioning or approval from governance we're stuck looking for stuff to do that will meaningfully move things forward.
A fun game: try and guess who the ICs are in the replies and who the facilitators are
Is the goal to deliver software or to deliver value/solutions to the users?
For software delivery? Absolutely.
For engineering and software quality? Absolutely not.
For engineering and software quality? Absolutely not.
Instead of standup I think we should do more interteam meetings.
I am not even understand the purpose of manager in the team.
Part of the original Agile concepts make sense.
The rest is just a religion.
The rest is just a religion.
[deleted]
Neither of these is valuable in my experience
I worked in a couple shops that did XP ("extreme programming") in the early 2000s. At the time this was a kind of progressive movement, associated with empowering developers, came out of the Smalltalk world and other "odd" places, was associated with a rather more grassroots engineering culture. Prototype and iterate. Very different from "classic" engineering orthodoxy. At the time very new, and came along with a bunch of other stuff that promised more rapid development; heavy object oriented dev, dynamic languages, test first design, etc. etc.
I had mixed experiences with it but absorbed a lot of good lessons. While I can't speak to "scrum" that much (I've seen degraded forms of it a few times but not the actual "real" thing) I think many of those fundamentals have been lost in the intervening years... err.. decades (cry).
Two things key for me, that it seems that people don't care about anymore:
i. Developers doing their own estimates. Absolutely essential to managing scope. This one always goes out the window or gets ignored first. I have worked in so many "agile" teams that would choke on their own vomit before taking the power away from managers or "experts" on the team to decide how long something will take. If this is the case, there is no point in scoping in an "agile" process anymore. You'll just have to crunch to meet their deadline, and that's that. That's not "agile" that's "sweatshop." (Or, if you routinely blow out / pad the estimates too large to compensate... inefficient)
ii. Ship the minimal viable product, and then iterate on it. You ain't gonna need it, etc. Release frequently and often and in small chunks. Absolutely foreign concept to most of the recent UX and PMs I've worked with, especially at BigCo, who treat the design doc / mock / spec as the finished product, with the actual development just being a kind of "last mile." Want to know what changed between their last giant spec document and now? Read the whole 50 pager again. My wife was taking UX design courses and even there, while paying lip service to agile there was all this type of "produce a planning document" with big upfront information hierarchies and total project design. And yes, even working in embedded and other things not front facing, I found this to some degree. A fear of iteration, still. The act of forcing the customer or PM or whatever into a discipline of an incremental thought process honestly helps with frequent delivery, and keeps the process responsible to the user, the real final customer.
What is so often missed is that agile in the classic XP sense was an exchange, some compromises: I (the engineer) agree to work rapidly and ship frequently and to give you great visibility, but you (the customer) agree to be provide me with constant feedback and prioritization, to accept my estimates/scoping, and to think incrementally and practically about what you want now rather than what you think you might need 6 months from now.
Daily standups and iteration meetings and story cards? Handy. But these are just part of the mechanics and can easily devolve into theatre or pantomime of "agile" if the other pieces aren't there.
I had mixed experiences with it but absorbed a lot of good lessons. While I can't speak to "scrum" that much (I've seen degraded forms of it a few times but not the actual "real" thing) I think many of those fundamentals have been lost in the intervening years... err.. decades (cry).
Two things key for me, that it seems that people don't care about anymore:
i. Developers doing their own estimates. Absolutely essential to managing scope. This one always goes out the window or gets ignored first. I have worked in so many "agile" teams that would choke on their own vomit before taking the power away from managers or "experts" on the team to decide how long something will take. If this is the case, there is no point in scoping in an "agile" process anymore. You'll just have to crunch to meet their deadline, and that's that. That's not "agile" that's "sweatshop." (Or, if you routinely blow out / pad the estimates too large to compensate... inefficient)
ii. Ship the minimal viable product, and then iterate on it. You ain't gonna need it, etc. Release frequently and often and in small chunks. Absolutely foreign concept to most of the recent UX and PMs I've worked with, especially at BigCo, who treat the design doc / mock / spec as the finished product, with the actual development just being a kind of "last mile." Want to know what changed between their last giant spec document and now? Read the whole 50 pager again. My wife was taking UX design courses and even there, while paying lip service to agile there was all this type of "produce a planning document" with big upfront information hierarchies and total project design. And yes, even working in embedded and other things not front facing, I found this to some degree. A fear of iteration, still. The act of forcing the customer or PM or whatever into a discipline of an incremental thought process honestly helps with frequent delivery, and keeps the process responsible to the user, the real final customer.
What is so often missed is that agile in the classic XP sense was an exchange, some compromises: I (the engineer) agree to work rapidly and ship frequently and to give you great visibility, but you (the customer) agree to be provide me with constant feedback and prioritization, to accept my estimates/scoping, and to think incrementally and practically about what you want now rather than what you think you might need 6 months from now.
Daily standups and iteration meetings and story cards? Handy. But these are just part of the mechanics and can easily devolve into theatre or pantomime of "agile" if the other pieces aren't there.
My pithy quote about agile is how much it is like communism:
1. Both started with a manifesto.
2. Both are meant to deliver some downtrodden group (serfs or developers) from their lowly state but end up making it worse.
3. Any criticism of the obvious flaws in both systems will elicit wails of "it works, everyone else just did it wrong"
let me also ask you about timesheets...
Old school team management was always a disaster. No project manager in my 36 years of software development could ever accurately "estimate" the level of effort for developers. Asking us to estimate was never helpful either.
I've worked on scrum and other types of agile project management over the last ten years. In that time, I've seen many bad implementations and only one good one. At Redbox, they had it down to a science and it worked perfectly. They had meetings for developing stories run by business analysts. They had sprint planning meetings run by scrum masters that only involved fully vetted and story-pointed stories. They used Fibonacci numbers for voting and everyone had a vote, including the QA people. They had QA people! We only started a sprint if everyone agreed on the stories. We (the developers) selected stories. We were never assigned anything. Stand ups were very quick. What are you working on, what did you complete, do you have any blockers.
The entire point of agile/scrum is transparency and to focus on delivering incremental value. Over time, that value can be packaged and reported upward to show management what features are being added or improved. No one can hide. If you're not pulling your weight or invested in your work, everyone will know within a day or two. If you legitimately have issues with your assignment, you need to communicate that and the team will help you.
The issue that comes up over and over with agile/scrum is how management and budgeting interact with the backlog and prioritization. There is often zero trust from the people writing the checks on "incremental continuous delivery". They want feature X boxed and completed by an arbitrary date. In my experience this _always_ fails. What you end up seeing is "something" being delivered by that date, but with an "acceptable" number of "defects". Which is to say the entire feature isn't really complete and everyone has agreed to lie about that fact.
So continuous delivery via an agile process is the only way to do the work and make sure things stay on the rails. The harder problem is getting people in management circles to understand this process and embrace it and set aside their old school project success reporting techniques.
Like I said. In ten years I've only seen this done well once. And then a few places did it "okay". Most places do what everyone laughingly calls "fake agile", which is a mix of waterfall and agile.
Don't get me started on things like SAFe or Pivotal. Those are ways of putting process behind agile and that breaks one of the primary tenets of agile. People over Process. It's also clearly an attempt to monetize agile through testing and certification or by putting an app in front of it.
I've worked on scrum and other types of agile project management over the last ten years. In that time, I've seen many bad implementations and only one good one. At Redbox, they had it down to a science and it worked perfectly. They had meetings for developing stories run by business analysts. They had sprint planning meetings run by scrum masters that only involved fully vetted and story-pointed stories. They used Fibonacci numbers for voting and everyone had a vote, including the QA people. They had QA people! We only started a sprint if everyone agreed on the stories. We (the developers) selected stories. We were never assigned anything. Stand ups were very quick. What are you working on, what did you complete, do you have any blockers.
The entire point of agile/scrum is transparency and to focus on delivering incremental value. Over time, that value can be packaged and reported upward to show management what features are being added or improved. No one can hide. If you're not pulling your weight or invested in your work, everyone will know within a day or two. If you legitimately have issues with your assignment, you need to communicate that and the team will help you.
The issue that comes up over and over with agile/scrum is how management and budgeting interact with the backlog and prioritization. There is often zero trust from the people writing the checks on "incremental continuous delivery". They want feature X boxed and completed by an arbitrary date. In my experience this _always_ fails. What you end up seeing is "something" being delivered by that date, but with an "acceptable" number of "defects". Which is to say the entire feature isn't really complete and everyone has agreed to lie about that fact.
So continuous delivery via an agile process is the only way to do the work and make sure things stay on the rails. The harder problem is getting people in management circles to understand this process and embrace it and set aside their old school project success reporting techniques.
Like I said. In ten years I've only seen this done well once. And then a few places did it "okay". Most places do what everyone laughingly calls "fake agile", which is a mix of waterfall and agile.
Don't get me started on things like SAFe or Pivotal. Those are ways of putting process behind agile and that breaks one of the primary tenets of agile. People over Process. It's also clearly an attempt to monetize agile through testing and certification or by putting an app in front of it.
Pivotal never issued certifications of the kind you're suggesting and Pivotal Tracker was never the breadwinner for Pivotal. Most of the money came from Labs, data products like RabbitMQ or Greenplum and platform products based Cloud Foundry and Kubernetes. Today that remains largely true where Pivotal wound up at VMware.
Tracker was made because Pivotal Labs folks needed it and it was opened up to general use because clients asked for it. The idea that the rest of Pivotal's work was a plot to flog Tracker is risible. Ain't nobody gettin' rich selling complex software for $10 a month to the pickiest possible market.
Tracker was made because Pivotal Labs folks needed it and it was opened up to general use because clients asked for it. The idea that the rest of Pivotal's work was a plot to flog Tracker is risible. Ain't nobody gettin' rich selling complex software for $10 a month to the pickiest possible market.
My issue with Tracker was it's horrific spin on what agile is supposed to be and the two instances it was being pushed hard I found extremely problematic. And the cost of partnering with Pivotal overall was ridiculous. Doing things the "pivotal way". Companies were taken for a ride with the idea that they could "outsource" the management and implementation of their software development through their tools. People over Process.
> Companies were taken for a ride with the idea that they could "outsource" the management and implementation of their software development through their tools.
That was never the purpose. Never. I'm sorry you had a bad experience and I apologise for our role in it. But Pivotal was the real thing.
That was never the purpose. Never. I'm sorry you had a bad experience and I apologise for our role in it. But Pivotal was the real thing.
The concrete "how it's done" and the "culture" of the people involved - how they behave with each other - will influence your experience with them much more than the ideas behind these methodologies. I've had a very positive personal experience with them, and I can give you a point of view as to how they work and why they can be a positive way of working.
Regarding the "standups", for example, they are definitely not meant to be about "micro-managing", "signalling process" or any kind of "status report" (definitely not to a manager!). The idea behind these kind of agile methodologies is to allow teams to self-organize. The standups are meant to be a brief way for the team members to catch up with each other, and seek help if necessary. There's no need to say anything if you don't feel that you need to sync with your team members, and it's definitely a way for managers to control what you are doing. When done right, they are short, concise, helpful and positive. The same idea applies to the "retrospectives". Don't call them that if you don't want, but it helps to get together as a team and see what you want to change in the current "way of doing things" - and it's good to actually have the autonomy to change it!...
About the concept of "sprints". Dividing work in sprints is both about planning and, again, about self-organization. It's about fairness in a way: leaving developers the time to deliver something, in a way, "protected" from route changes and with a clear goal of something to deliver. But it's also about not setting up goals too far in the future. Because the goal is set up in (usually) a couple of weeks time, the results can be analyzed and the product, or whatever, developed incrementally, with management reviewing the progress bi-weekly. You wouldn't want to set a goal three months in advance and discover at the end of that period all the things that you assumed were one way that were actually not that way.
"Agile" touches several points and one of them is that during work it's important to talk face-to-face about requirements and how whatever you are building is meant to work. That is, as others have commented in this thread, that it's a good thing to have a conversation during development with whoever is the representative of the product side of things to solve doubts, instead of relying on a list of requirements.
That's, from my point of view, less bureaucratic than a formal process. The regular meetings are also meant to be lightweight and to the point. You don't have to have a highly formalized process to "point" tasks. The underlying idea is to try to allocate a reasonable amount of work to a certain period. That also does not mean that bugs or unexpected issues can't be fixed during the sprint - there are ways to make all that work.
You have to understand what all these practices are for, the ideas behind the whole thing, to do them right. And you have to work with people that behave in a certain way, that have a certain good will, that have a certain working culture, the righ experience, etc. The particular circumstances will make all the difference.
I think that seeing some of the answers in this thread it seems a little bit discouraging, but, in my humble opinion, one just have to be lucky, find the right company and the right people to work with. I hope that my personal perspective helps.
Regarding the "standups", for example, they are definitely not meant to be about "micro-managing", "signalling process" or any kind of "status report" (definitely not to a manager!). The idea behind these kind of agile methodologies is to allow teams to self-organize. The standups are meant to be a brief way for the team members to catch up with each other, and seek help if necessary. There's no need to say anything if you don't feel that you need to sync with your team members, and it's definitely a way for managers to control what you are doing. When done right, they are short, concise, helpful and positive. The same idea applies to the "retrospectives". Don't call them that if you don't want, but it helps to get together as a team and see what you want to change in the current "way of doing things" - and it's good to actually have the autonomy to change it!...
About the concept of "sprints". Dividing work in sprints is both about planning and, again, about self-organization. It's about fairness in a way: leaving developers the time to deliver something, in a way, "protected" from route changes and with a clear goal of something to deliver. But it's also about not setting up goals too far in the future. Because the goal is set up in (usually) a couple of weeks time, the results can be analyzed and the product, or whatever, developed incrementally, with management reviewing the progress bi-weekly. You wouldn't want to set a goal three months in advance and discover at the end of that period all the things that you assumed were one way that were actually not that way.
"Agile" touches several points and one of them is that during work it's important to talk face-to-face about requirements and how whatever you are building is meant to work. That is, as others have commented in this thread, that it's a good thing to have a conversation during development with whoever is the representative of the product side of things to solve doubts, instead of relying on a list of requirements.
That's, from my point of view, less bureaucratic than a formal process. The regular meetings are also meant to be lightweight and to the point. You don't have to have a highly formalized process to "point" tasks. The underlying idea is to try to allocate a reasonable amount of work to a certain period. That also does not mean that bugs or unexpected issues can't be fixed during the sprint - there are ways to make all that work.
You have to understand what all these practices are for, the ideas behind the whole thing, to do them right. And you have to work with people that behave in a certain way, that have a certain good will, that have a certain working culture, the righ experience, etc. The particular circumstances will make all the difference.
I think that seeing some of the answers in this thread it seems a little bit discouraging, but, in my humble opinion, one just have to be lucky, find the right company and the right people to work with. I hope that my personal perspective helps.
This one will be long ;)
First of all, I would like to address the "haters". They rant on and on about how Scrum does not work, how its slowing them, unnecessary meetings, etc. But if you look at what they say, it's always the same. They screw up, did not used it correctly. Its like when you want to cook a dinner, and burn yourself instead. Do you blame the fire? Or your stupid ass? :D
Scrum is not a silver bullet. It is not useful everywhere. For example for very small teams, who have like one, standalone responsibility, they know it well,... having Scrum is a waste. All they need is someone who will be able to give them (feature) request and they will do the job well. They are essentially self-organized.
However, for bigger teams, more complex product, more teams involved, this does not work anymore. One guys can THINK he is the owner because he coded that particular component, but there is another owner in second team and they clash. Often times people work like crazy, but the whole product does not work. All the pieces are there, but they cannot work together, gazillion ideas how to make it work, ego-driven heated discussion how we should use this library instead of this one. How everyone else is stupid because they do not integrate with us first, etc.
Scrum it is NOT a waste of time. Any fool that say a 3-4 hours during two weeks is great waste is total junior. That amount of time will never ever mean difference between "job well done" and "oh no, we fucked up again". If you are desperately thinking that the extra hour you spend coding instead of 4 daily standups (15 minute each) will save your product, then you already are on the edge of "crunch time" and doing something incredibly wrong.
Scrum - when implemented properly - provides many benefits:
1) Little to none micromanaging: The amount of micromanaging and reporting is lower, because your progress is visible without the need to actually report to the boss.
2) More option for your own time schedule: If the team evaluates that something is "hard" and give it huge number of storypoints (if you use SP), you are expected to work on it for some time and no-one will bother you like every half a day.
3) Predictability: business oriented people can easily "calculate" the time of delivery based on your predictions/estimates. You are shielded from that bullshit AND you are earning more trust every iteration, which means you have more option to do it your way.
4) Knowledge is shared: there are no silos, everyone potentially can work on anything within the competence area of the team. If someone gets sick, work just don't stop because the "owner" of the lib is out and we know nothing about it.
5) The power to stand up to the brass.
And others, I personally value those the most. And you can achieve some of those using different frameworks, but Scrum is proven to work the best all around. Also important note is that there are some basic rules for Scrum, but most of it is just recommendations. If you follow the book to the letter and do not adjust for your team, you are screwing yourselves.
First of all, I would like to address the "haters". They rant on and on about how Scrum does not work, how its slowing them, unnecessary meetings, etc. But if you look at what they say, it's always the same. They screw up, did not used it correctly. Its like when you want to cook a dinner, and burn yourself instead. Do you blame the fire? Or your stupid ass? :D
Scrum is not a silver bullet. It is not useful everywhere. For example for very small teams, who have like one, standalone responsibility, they know it well,... having Scrum is a waste. All they need is someone who will be able to give them (feature) request and they will do the job well. They are essentially self-organized.
However, for bigger teams, more complex product, more teams involved, this does not work anymore. One guys can THINK he is the owner because he coded that particular component, but there is another owner in second team and they clash. Often times people work like crazy, but the whole product does not work. All the pieces are there, but they cannot work together, gazillion ideas how to make it work, ego-driven heated discussion how we should use this library instead of this one. How everyone else is stupid because they do not integrate with us first, etc.
Scrum it is NOT a waste of time. Any fool that say a 3-4 hours during two weeks is great waste is total junior. That amount of time will never ever mean difference between "job well done" and "oh no, we fucked up again". If you are desperately thinking that the extra hour you spend coding instead of 4 daily standups (15 minute each) will save your product, then you already are on the edge of "crunch time" and doing something incredibly wrong.
Scrum - when implemented properly - provides many benefits:
1) Little to none micromanaging: The amount of micromanaging and reporting is lower, because your progress is visible without the need to actually report to the boss.
2) More option for your own time schedule: If the team evaluates that something is "hard" and give it huge number of storypoints (if you use SP), you are expected to work on it for some time and no-one will bother you like every half a day.
3) Predictability: business oriented people can easily "calculate" the time of delivery based on your predictions/estimates. You are shielded from that bullshit AND you are earning more trust every iteration, which means you have more option to do it your way.
4) Knowledge is shared: there are no silos, everyone potentially can work on anything within the competence area of the team. If someone gets sick, work just don't stop because the "owner" of the lib is out and we know nothing about it.
5) The power to stand up to the brass.
And others, I personally value those the most. And you can achieve some of those using different frameworks, but Scrum is proven to work the best all around. Also important note is that there are some basic rules for Scrum, but most of it is just recommendations. If you follow the book to the letter and do not adjust for your team, you are screwing yourselves.
Disclaimer: My job title is "LEAN architect", so I might be biased here.
The point is, "agile" emerged from accepting that building new things primarily deals with the uncertain. You plan something, and then there are the "unknown unknowns" where things will take orders of magnitude more time than planned. Additionally, more often than not it isn't even clear how the solution actually looks like or if the stakeholders even articulated what their real problem is. So the solution: just start with something and then establish a short feedback cycle to steer the next steps in the right direction, which wasn't obvious in the previous cycle. Therefore all the ceremony, like doing daily standups to resolve problems that arrive while iterating the problem space, or retro/review where progress gets presented and the next steps are agreed upon. The heart of the principle translates to "be flexible" in the face of uncertainity. This also implies that the team is trusted to decide on the spot.
In reality, "Agile" often comes in the form of something like "Scrum", which isn't agile at all. There is ceremony and cargo-culting how one should behave without any understanding _why_ to do things. Management gets sold the idea that they get a tight grip on all decisions (Micromanagement) and can closely "watch how workers perform" with a short feedback loop. Because "we cross the bridge when we come to it", all the "engineering" parts of software development are thrown out of the window and essential things like caring about sound architectures/maintainability/... are supressed. This gets even more emphasized with the usual mindset of "Velocity", translating to managers as "build more features faster, now!". This in turn leads to some early successes but mostly turns into swamps of unmaintainable glue code and after a while the voices wanting a "rewrite" become louder... back to square one. Oh, and do not forget that "Backlogs" (especially with months/years ahead planned and communicated with stakeholders) are just chunked Waterfall processes without any flexibility, ironically killing actual flexibility. Daily standups become just virtue signalling happenings where everyone agrees that they're "on schedule" or "things will take longer".
There ARE teams that deliver high-quality solutions without getting slower over time using Scrum, but know what? These teams would achieve the same with any process, including some internal Waterfall variations. Great/experienced people deliver great results, even more so if they can act autonomously.
So instead of some magical "Agile Processes" that everyone has to follow and great results will appear (in reality: they won't), my job is to increase the chances for actual success in the real world. How? by following some LEAN values (instead of processes). But here is the next catch: there are huge misunderstandings about LEAN when it comes to software development!
Classical "LEAN Production" comes from a world where physical things are manufactured in large numbers, basically doing the same thing again and again, and tries to optimize how to do this thing better/faster/cheaper. In software development the root problem is inversed: we are never actually doing the _same thing_ more than once (except cases of reinventing the wheel). All attempts to use classical LEAN Production techniques to software projects will fail miserably (except you have awesome people to begin with, see above).
Then there are the "Lean Startup" people which start with the actual problem space and cycle in "build measure learn". Makes absolute sense if you are a startup and have to find _something_ that sticks. The problem: teams that act like this are doing the job of actual business founders and require the trust to change the business itself. This doesn't work within a traditional company when you have executive teams and a management hierarchy.
So what could be done if these things don't work? Dig deeper and formulate _values_ everyone should follow. Examples:
- "decide as late as possible" -> do not lock yourself in hard technical dependencies (this will only run with MariaDB v123 on Google Cloud with Setup ABC) early on, or else you will have a hard time being flexible (like migrating to AWS Lambda because some compelling technical/business reasons). Yes this way is not able to leverage minute features of a ultra specialized solution, but chances are high something generic will do (like: we need a sql database)
- "build quality in" -> in many cases it does _not_ take significantly longer to build something that is well-tested, decoupled and documented than to hack something together, especially when you are building it right now and have all requirements in your head currently. In fact, most code that is designed with maintainability is more on the side of an asset (you can build on it) instead of a liability (should be replaced in the future/does not get used because noone understands it or its purpose/... bitrot.). So when your building blocks are actually solid, you may even become faster, which often shows in mere _weeks_ after a project starts.
- "Eliminate Waste" -> the posterchild value of LEAN... but the quintessence. Everything that prevents the team/individual to make relevant progress right now must be stopped. Relevant progress is anything that produces value for the customer (read: _not manager_!). Waiting hours for feedback if a code snippet works? Make it fast. Sitting in pointless meetings or ceremony processes? Cancel them. Deployments/Builds need mental energy to execute? Automate it. "Feature Ideas" from managers? Let them prove that it WILL bring customer value, ideally: how much. Can't stress this enough: do not build anything that does not clearly increase customer value, no matter who demands it internally, never follow the "what if..." rabbit hole or you end in feature creep and potentially dead code areas that still cost maintenance.
... and so on. You can google more infos about "LEAN Software principles: if you want. The main takeaway: act based on clearly defined values _enables_ actual agility, acting based on arbitrary processes (like Scrumfall) _decreases_ actual aglity.
But even this (my) approach has a big downside: success is measured in ... success. Whatever the Team does, they must show that there is a measurable business impact, or share why something failed (so that bad ideas will not get tried again later... and again...). This is a stark contrast to the "virtue ethics" approach many are happy with, where "trying with best (displayable) effort" is good enough and gets rewarded. I will just look at the outcome: what did you do, was it executed as good as possible within given constraints, and which impact did it have, followed by the question: what did you learn and therefore what is the next logical step?
Many people still prefer to work without the "pressure for success" for 8 hours per workday and go home, where working is just the thing one does for earning money. No issues with that, but chances are even LEAN will not work when you only have people with this mindset. Not disciminating, just my experience.
The point is, "agile" emerged from accepting that building new things primarily deals with the uncertain. You plan something, and then there are the "unknown unknowns" where things will take orders of magnitude more time than planned. Additionally, more often than not it isn't even clear how the solution actually looks like or if the stakeholders even articulated what their real problem is. So the solution: just start with something and then establish a short feedback cycle to steer the next steps in the right direction, which wasn't obvious in the previous cycle. Therefore all the ceremony, like doing daily standups to resolve problems that arrive while iterating the problem space, or retro/review where progress gets presented and the next steps are agreed upon. The heart of the principle translates to "be flexible" in the face of uncertainity. This also implies that the team is trusted to decide on the spot.
In reality, "Agile" often comes in the form of something like "Scrum", which isn't agile at all. There is ceremony and cargo-culting how one should behave without any understanding _why_ to do things. Management gets sold the idea that they get a tight grip on all decisions (Micromanagement) and can closely "watch how workers perform" with a short feedback loop. Because "we cross the bridge when we come to it", all the "engineering" parts of software development are thrown out of the window and essential things like caring about sound architectures/maintainability/... are supressed. This gets even more emphasized with the usual mindset of "Velocity", translating to managers as "build more features faster, now!". This in turn leads to some early successes but mostly turns into swamps of unmaintainable glue code and after a while the voices wanting a "rewrite" become louder... back to square one. Oh, and do not forget that "Backlogs" (especially with months/years ahead planned and communicated with stakeholders) are just chunked Waterfall processes without any flexibility, ironically killing actual flexibility. Daily standups become just virtue signalling happenings where everyone agrees that they're "on schedule" or "things will take longer".
There ARE teams that deliver high-quality solutions without getting slower over time using Scrum, but know what? These teams would achieve the same with any process, including some internal Waterfall variations. Great/experienced people deliver great results, even more so if they can act autonomously.
So instead of some magical "Agile Processes" that everyone has to follow and great results will appear (in reality: they won't), my job is to increase the chances for actual success in the real world. How? by following some LEAN values (instead of processes). But here is the next catch: there are huge misunderstandings about LEAN when it comes to software development!
Classical "LEAN Production" comes from a world where physical things are manufactured in large numbers, basically doing the same thing again and again, and tries to optimize how to do this thing better/faster/cheaper. In software development the root problem is inversed: we are never actually doing the _same thing_ more than once (except cases of reinventing the wheel). All attempts to use classical LEAN Production techniques to software projects will fail miserably (except you have awesome people to begin with, see above).
Then there are the "Lean Startup" people which start with the actual problem space and cycle in "build measure learn". Makes absolute sense if you are a startup and have to find _something_ that sticks. The problem: teams that act like this are doing the job of actual business founders and require the trust to change the business itself. This doesn't work within a traditional company when you have executive teams and a management hierarchy.
So what could be done if these things don't work? Dig deeper and formulate _values_ everyone should follow. Examples:
- "decide as late as possible" -> do not lock yourself in hard technical dependencies (this will only run with MariaDB v123 on Google Cloud with Setup ABC) early on, or else you will have a hard time being flexible (like migrating to AWS Lambda because some compelling technical/business reasons). Yes this way is not able to leverage minute features of a ultra specialized solution, but chances are high something generic will do (like: we need a sql database)
- "build quality in" -> in many cases it does _not_ take significantly longer to build something that is well-tested, decoupled and documented than to hack something together, especially when you are building it right now and have all requirements in your head currently. In fact, most code that is designed with maintainability is more on the side of an asset (you can build on it) instead of a liability (should be replaced in the future/does not get used because noone understands it or its purpose/... bitrot.). So when your building blocks are actually solid, you may even become faster, which often shows in mere _weeks_ after a project starts.
- "Eliminate Waste" -> the posterchild value of LEAN... but the quintessence. Everything that prevents the team/individual to make relevant progress right now must be stopped. Relevant progress is anything that produces value for the customer (read: _not manager_!). Waiting hours for feedback if a code snippet works? Make it fast. Sitting in pointless meetings or ceremony processes? Cancel them. Deployments/Builds need mental energy to execute? Automate it. "Feature Ideas" from managers? Let them prove that it WILL bring customer value, ideally: how much. Can't stress this enough: do not build anything that does not clearly increase customer value, no matter who demands it internally, never follow the "what if..." rabbit hole or you end in feature creep and potentially dead code areas that still cost maintenance.
... and so on. You can google more infos about "LEAN Software principles: if you want. The main takeaway: act based on clearly defined values _enables_ actual agility, acting based on arbitrary processes (like Scrumfall) _decreases_ actual aglity.
But even this (my) approach has a big downside: success is measured in ... success. Whatever the Team does, they must show that there is a measurable business impact, or share why something failed (so that bad ideas will not get tried again later... and again...). This is a stark contrast to the "virtue ethics" approach many are happy with, where "trying with best (displayable) effort" is good enough and gets rewarded. I will just look at the outcome: what did you do, was it executed as good as possible within given constraints, and which impact did it have, followed by the question: what did you learn and therefore what is the next logical step?
Many people still prefer to work without the "pressure for success" for 8 hours per workday and go home, where working is just the thing one does for earning money. No issues with that, but chances are even LEAN will not work when you only have people with this mindset. Not disciminating, just my experience.
After 14 years of trying and helping teams experiment, repeating what other have said, here is what we’re doing nowadays:
- don’t mix up Agile with Scrum...
- see Agile as aspirational (aka read an try very hard to go back to the manifesto to clear the clutter)
- see Scrum and XP as tools
- prefer XP to Scrum : yes, it’s better to have good software in the middle of a shitty process than a good process around a shitty software. believe me, good software, even in nightmarish organization can bring joy. don’t be the opposite. :-)
- be concerned about the internal well oiling of the team first and the the product: same than with the process, a good team can course-correct a bad product decision or a user backslash (to a point), the opposite is way harder...imaging trying to keep your users telling them your product is superb, it’s just that the software works half of the time...
For the’code part’
XP if you can/know, or just start with automation (basic ci/cd or cr, tests). Then raise collaboration by making it easier to ‘code together’, agree on ‘code expectations’ and communications expectations whatever that means for your lot. THEN everybody should approach their ‘quality standard threshold’. The way is just up from there: code coverage, TDD/BDD, code review, IaC, you’re already pretty ‘software agile’ at that point, but like a circus artist, reach for always more agile
Next the ‘product part’:
That’s where most Scrum consultant will hammer you with the dailys, the demos, the ceremonies and all. Back to the manifesto. Learn what your people like, what and when it makes them productive. Make it weird, unwieldy but a perfect-fit for you all.
If a consultant looked at it, it should say ‘oh, ok, that’s a weird way to do it, but I guess it could work’.
To put my money where my mouth is, here is what we do (but it’s full of our remote, bilingual, socially multi-diverse quirks).
We start and end at a demo to our C-level and business ‘patron’.
Just after the ‘last one’, we pick what we will try to demo next time. We talk about the value of it. To whom in our demo audience/user it should evoke excitement. What would be ‘minimum’ otherwise we dont show up. What would be ‘nice’ and what would be mind-blowing. We all agree what a user should see. We settle on it for the next weeks (yes, no prefixed date). In general there’s one or two ‘big things’ that would constitute ‘the meat’, we create one/two sufficiently descriptive stories with personas that should match what we discussed for the demo and Condition of Success in JIRA and put it as In Progress. Everything else, except production issues, is considered unimportant and optional. If one of us has time during build or waiting for a review, we tackle the ‘little things’.
The PO/Business DoppleGanger goes get what we need to do all that (wireframe, design, translation, legal wording, marketing spiel,...). He/She works directly with the devs that need it. We meet every Thu and Fri for 5/10 min (usualy, max 30) entirely to make sure sub-groups or individuals are not missing on what other will be doing and profit from it. We talk about what we’re working on next not the past (the past is done, stop wasting time talking about it!!! :-)). No task, no story bs, no past ‘blocker’ discussion lingering. If people want to track their stuff in github issues or JIRA, they do it on their own. But they better make sure it’s tidy and up to date cause we do not accept messy backlogs.
In between those ‘bi-weeklies’ if someone in the team need to discuss anything or are blocked, they shout on Slack and wait. If it’s an emergency, they send a mean Giphy. If they really need someone, they DM a lead. and so on. People own what/how/when they do 200% up until we approach the end of the 2 week threshold.
Then it’s about all that we achieved. The big question is asked ‘are we ready to demo’? If a majority don’t think we have enough to show, we wait another week and ask the same question. Then week 4, same. At that point we need to have a freaking good reason not to be showing something after 4 weeks. Even if it’s minimal. Even if it’s a bunch of HTTP calls and some JSON.
And we cycle.
In summary:
- 2 meeting of max 30 min (you can drop of after that)
- lots of behind the scene ‘ad-hoc’ interactions per need (that respect a ‘rule of engagement for collaboration’ the team agreed on, btw)
- 1 demo, tailor-made to the actual delivered value by the team (not the dreamt one) every 2, 3 or 4 weeks
Practice wise: IaC all the way (tks Pulumi and Google Cloud team), CI/CD (with real automated delivery not CR), code-review using PR and on-demand env, fully diamond-shaped code coverage, dependabots and automated CodeSec audits, conventional commits with semantic versioning, and we’re just starting.
-> No planning (except the 40 min discussing the next demo just after the current one).
-> No poker estimate. In fact no estimates.
-> No backlog burn downs and cycle time and resolution time...
-> No WIP (technically, yes, this is Scrumban-ish with a WIP of 2...).
We do one quarterly product vision discussion with everybody that feeds team growth and high level product roadmap (no precise estimates, in terms of Q or 2 month span).
That, I believe, can be called agile :-)
- don’t mix up Agile with Scrum...
- see Agile as aspirational (aka read an try very hard to go back to the manifesto to clear the clutter)
- see Scrum and XP as tools
- prefer XP to Scrum : yes, it’s better to have good software in the middle of a shitty process than a good process around a shitty software. believe me, good software, even in nightmarish organization can bring joy. don’t be the opposite. :-)
- be concerned about the internal well oiling of the team first and the the product: same than with the process, a good team can course-correct a bad product decision or a user backslash (to a point), the opposite is way harder...imaging trying to keep your users telling them your product is superb, it’s just that the software works half of the time...
For the’code part’
XP if you can/know, or just start with automation (basic ci/cd or cr, tests). Then raise collaboration by making it easier to ‘code together’, agree on ‘code expectations’ and communications expectations whatever that means for your lot. THEN everybody should approach their ‘quality standard threshold’. The way is just up from there: code coverage, TDD/BDD, code review, IaC, you’re already pretty ‘software agile’ at that point, but like a circus artist, reach for always more agile
Next the ‘product part’:
That’s where most Scrum consultant will hammer you with the dailys, the demos, the ceremonies and all. Back to the manifesto. Learn what your people like, what and when it makes them productive. Make it weird, unwieldy but a perfect-fit for you all.
If a consultant looked at it, it should say ‘oh, ok, that’s a weird way to do it, but I guess it could work’.
To put my money where my mouth is, here is what we do (but it’s full of our remote, bilingual, socially multi-diverse quirks).
We start and end at a demo to our C-level and business ‘patron’.
Just after the ‘last one’, we pick what we will try to demo next time. We talk about the value of it. To whom in our demo audience/user it should evoke excitement. What would be ‘minimum’ otherwise we dont show up. What would be ‘nice’ and what would be mind-blowing. We all agree what a user should see. We settle on it for the next weeks (yes, no prefixed date). In general there’s one or two ‘big things’ that would constitute ‘the meat’, we create one/two sufficiently descriptive stories with personas that should match what we discussed for the demo and Condition of Success in JIRA and put it as In Progress. Everything else, except production issues, is considered unimportant and optional. If one of us has time during build or waiting for a review, we tackle the ‘little things’.
The PO/Business DoppleGanger goes get what we need to do all that (wireframe, design, translation, legal wording, marketing spiel,...). He/She works directly with the devs that need it. We meet every Thu and Fri for 5/10 min (usualy, max 30) entirely to make sure sub-groups or individuals are not missing on what other will be doing and profit from it. We talk about what we’re working on next not the past (the past is done, stop wasting time talking about it!!! :-)). No task, no story bs, no past ‘blocker’ discussion lingering. If people want to track their stuff in github issues or JIRA, they do it on their own. But they better make sure it’s tidy and up to date cause we do not accept messy backlogs.
In between those ‘bi-weeklies’ if someone in the team need to discuss anything or are blocked, they shout on Slack and wait. If it’s an emergency, they send a mean Giphy. If they really need someone, they DM a lead. and so on. People own what/how/when they do 200% up until we approach the end of the 2 week threshold.
Then it’s about all that we achieved. The big question is asked ‘are we ready to demo’? If a majority don’t think we have enough to show, we wait another week and ask the same question. Then week 4, same. At that point we need to have a freaking good reason not to be showing something after 4 weeks. Even if it’s minimal. Even if it’s a bunch of HTTP calls and some JSON.
And we cycle.
In summary:
- 2 meeting of max 30 min (you can drop of after that)
- lots of behind the scene ‘ad-hoc’ interactions per need (that respect a ‘rule of engagement for collaboration’ the team agreed on, btw)
- 1 demo, tailor-made to the actual delivered value by the team (not the dreamt one) every 2, 3 or 4 weeks
Practice wise: IaC all the way (tks Pulumi and Google Cloud team), CI/CD (with real automated delivery not CR), code-review using PR and on-demand env, fully diamond-shaped code coverage, dependabots and automated CodeSec audits, conventional commits with semantic versioning, and we’re just starting.
-> No planning (except the 40 min discussing the next demo just after the current one).
-> No poker estimate. In fact no estimates.
-> No backlog burn downs and cycle time and resolution time...
-> No WIP (technically, yes, this is Scrumban-ish with a WIP of 2...).
We do one quarterly product vision discussion with everybody that feeds team growth and high level product roadmap (no precise estimates, in terms of Q or 2 month span).
That, I believe, can be called agile :-)
Scrum is like PowerPoint or C: I'm sure it's possible to use it mostly well, but its defaults actively push bad patterns so the vast majority of Scrum implementations are actively counter-productive.
In the most common case I've seen, Scrum quickly devolves into Scrum-flavored micromanagement by some combination of actual managers, business teams and "product owners". Short sprints, daily tracked tickets, process-based decision-making... all effective at taking away autonomy from the people doing the actual work.
Even if you avoid the worst sort of micromanagement, though, Scrum still has fundamental problems. The process is primarily team-oriented, which sounds great until you realize that it's creating strong psychological incentives through peer pressure—and they're the wrong incentives. Standups, Sprint Planning, velocity... etc all push people to hyper-focus on small tickets with tight deadlines without considering the broader context.
I've seen this create massive problems on teams:
1. People feel siloed on their "assigned" tickets. Having constant public deadlines means that everyone feels pressured to make visible progress on "their" work which actively stifles ad hoc collaboration. On Scrum teams, I see people guilty for asking their teammates for help!
2. For the same reasons as 1, people feel pressure not to work on anything that isn't "their" ticket. In my experience, the best way to maintain a quality codebase is for everyone to fix small problems as soon as they see them; while this is possible with some Scrum implementations, you're fighting the current. This also robs people of any ownership over their work or their code, which is another key component to quality software development.
3. Scrum incentivizes consistency above everything else, whether impact, progress or work quality. Teams get bogged down with technical debt that accumulates gradually enough for estimates to adjust, but they continue to look productive anyway. After all, slow, incremental progress is actually more consistent than fast bursty progress!
4. The nature of the processes pushes individuals away from understanding the broader context of their work, and encourages managers/product owners/etc to communicate at the wrong level of granularity. Instead of giving programmers the context they need to make effective tactical decisions, Scrum pushes for trying to adjust work through small, artificial tickets. Too much information flows from the team and not enough to the team. I've seen managers get annoyed that their programmers don't seem to care or understand the broader context of their work—where's the passion!?—but how is anyone going to understand or value context if they don't have the space to make any real decisions with it?
5. Constant public deadlines absolutely destroy psychological safety. The teams I've worked with using Scrum are consistently under more stress than other teams. It's no surprise—needing to show up to a standup every morning to say "I'm still working on X" is pretty depressing, no matter how much impact you may have in absolute terms. The process provides plenty of ways for programmers to feel like they're falling behind or letting the team down, and provides no real upside. There's little room for real creativity or agency within a heavily process- and ticket-driven system; the best you can hope for is doing your assignments faster. How can anyone really excel in that sort of setting?
I've been working in Target's AI/data science team for almost five years now, and I've worked on and with teams that were heavily into Scrum, teams that didn't treat it too seriously and teams that operated with minimal-to-nonexistant processes. Some Scrum teams did okay and some were complete trainwrecks. Much lower-process teams weren't always great themselves—there are a lot of ways to bog down software development!—but each of the most productive and innovative teams I worked with was on the low-process part of the spectrum, and people working on those teams were noticeably happier.
At this point I've spent enough time both observing and thinking about Scrum-style processes to have some strong conclusions:
1. Process imposed from the outside is usually awful. Scrum especially so.
2. Process legitimately adopted by a team can be okay—even Scrum—but still has a real chance of backfiring. Scrum especially so.
3. You don't need process for poor management, but the two seem to go hand-in-hand.
4. The best teams have leaders—formal or not—who effectively communicate context, motivation and direction then leave room for individuals to figure out how to get there and how to communicate up about it.
Now the challenge is how to help incubate environments like this myself, and how to judge whether future teams and companies have a culture like this or not.
In the most common case I've seen, Scrum quickly devolves into Scrum-flavored micromanagement by some combination of actual managers, business teams and "product owners". Short sprints, daily tracked tickets, process-based decision-making... all effective at taking away autonomy from the people doing the actual work.
Even if you avoid the worst sort of micromanagement, though, Scrum still has fundamental problems. The process is primarily team-oriented, which sounds great until you realize that it's creating strong psychological incentives through peer pressure—and they're the wrong incentives. Standups, Sprint Planning, velocity... etc all push people to hyper-focus on small tickets with tight deadlines without considering the broader context.
I've seen this create massive problems on teams:
1. People feel siloed on their "assigned" tickets. Having constant public deadlines means that everyone feels pressured to make visible progress on "their" work which actively stifles ad hoc collaboration. On Scrum teams, I see people guilty for asking their teammates for help!
2. For the same reasons as 1, people feel pressure not to work on anything that isn't "their" ticket. In my experience, the best way to maintain a quality codebase is for everyone to fix small problems as soon as they see them; while this is possible with some Scrum implementations, you're fighting the current. This also robs people of any ownership over their work or their code, which is another key component to quality software development.
3. Scrum incentivizes consistency above everything else, whether impact, progress or work quality. Teams get bogged down with technical debt that accumulates gradually enough for estimates to adjust, but they continue to look productive anyway. After all, slow, incremental progress is actually more consistent than fast bursty progress!
4. The nature of the processes pushes individuals away from understanding the broader context of their work, and encourages managers/product owners/etc to communicate at the wrong level of granularity. Instead of giving programmers the context they need to make effective tactical decisions, Scrum pushes for trying to adjust work through small, artificial tickets. Too much information flows from the team and not enough to the team. I've seen managers get annoyed that their programmers don't seem to care or understand the broader context of their work—where's the passion!?—but how is anyone going to understand or value context if they don't have the space to make any real decisions with it?
5. Constant public deadlines absolutely destroy psychological safety. The teams I've worked with using Scrum are consistently under more stress than other teams. It's no surprise—needing to show up to a standup every morning to say "I'm still working on X" is pretty depressing, no matter how much impact you may have in absolute terms. The process provides plenty of ways for programmers to feel like they're falling behind or letting the team down, and provides no real upside. There's little room for real creativity or agency within a heavily process- and ticket-driven system; the best you can hope for is doing your assignments faster. How can anyone really excel in that sort of setting?
I've been working in Target's AI/data science team for almost five years now, and I've worked on and with teams that were heavily into Scrum, teams that didn't treat it too seriously and teams that operated with minimal-to-nonexistant processes. Some Scrum teams did okay and some were complete trainwrecks. Much lower-process teams weren't always great themselves—there are a lot of ways to bog down software development!—but each of the most productive and innovative teams I worked with was on the low-process part of the spectrum, and people working on those teams were noticeably happier.
At this point I've spent enough time both observing and thinking about Scrum-style processes to have some strong conclusions:
1. Process imposed from the outside is usually awful. Scrum especially so.
2. Process legitimately adopted by a team can be okay—even Scrum—but still has a real chance of backfiring. Scrum especially so.
3. You don't need process for poor management, but the two seem to go hand-in-hand.
4. The best teams have leaders—formal or not—who effectively communicate context, motivation and direction then leave room for individuals to figure out how to get there and how to communicate up about it.
Now the challenge is how to help incubate environments like this myself, and how to judge whether future teams and companies have a culture like this or not.
Agile and Scrum are different things.
Agile is the recognition that that in the modern world, especially in digital products, we learn new information faster than we can act on new information, and so we benefit from structures and "processes" that allow us to discover and act on information as quickly as possible. "Processes" is in quotes there because this usually translates to a _lack_ of process. Formalized process slows things down and agile wants to act fast. Agile prefers for us to live and communicate in the moment rather than through some structured form. This is also why agile tends to be a bottom-up organizational structure, giving the most agency to the people doing the work rather than managers and middlemen.
Scrum is weird, and very, _very_ misunderstood. Scrum, at its heart, is trying compensate for one of agile's "weaknesses"--or at least, what many organizations might view as a weakness: disempowered management. Most organizations aren't willing to adopt the agile values that allow them to move fast because it means higher ups have less direct control and visibility into what's going on. Scrum tries to compensate for this by introducing an agile-flavored framework that isn't really agile, but can provide organizations that won't adopt agile values with structure that can still give them a bit of what they want (namely visibility) while providing some of agile's benefits.
Scrum's Achilles Heel, however, is a tragic one: Organizations that aren't willing to adopt agile's values aren't likely to adopt Scrum's values either. So despite all the effort and "restructuring" organizations put into place to "do Scrum", they end up with the same values and processes they were already using, but now with a Scrum-like vocabulary. This is why Scrum gets a pretty bad reputation: At its best, it's not as good as agile, and at its worst, it's twisted into a mask for the processes that were the original problem. You're usually better off either doing straight agile or not bothering with either.
As for the pros and cons of the concepts and meetings, let's clear up what each of them is about:
Standup - Often used as a daily check in. This not the intended usage and doesn't do the team much good. A well-used standup is simply an opportunity for team members to expose any blockers they're encountering so that others might jump in and help if they're so able. If the team has good communication habits already, a daily stand up won't bring them much benefit. That said, it's also serves as an opportunity for shy team members, or those who don't want to bother people, to regularly get a chance at communicating their problems, so it can be practical depending on the team's personalities.
The Sprint - Most teams think of the sprint as a unit of time around which they should plan work. This is incorrect; in fast paced environment, there's no such thing as planning work reliably enough that you can assign just enough for the sprint's duration. There are too many unknown unknowns for that to work.
A sprint is the maximum amount of time the team goes between syncs about the priorities, current problems, and what works needs to be done. Sprints aren't about planning out work and getting to it, they're about making sure the team regularly aligns itself on the important things. To accomplish this, we usually have two meetings per sprint:
Grooming - A session in which the team comes together and reviews all the upcoming work, changes, etc. The goal is for everyone on the team to be familiar with what's being worked on, how the product should behave, and that product definitions/specs are clear enough for work to begin.
Retro - A session in which the team can explore organizational or other obstacles getting in the way of productivity, and then collaborate on solutions to these problems.
Checkmarks, point systems, velocity tracking--these do not contribute to productivity and are not worth incorporating into your team. Usually, the people that benefit from these are not the people who benefit from productivity, but the people who want to have "data" they can use to prove to _their_ manager that they're doing a good job (and deserve a raise/promotion).
There's a lot of depth to agile, and done properly it can be a huge boost to fast-moving teams. But it's also very easy to get lost and go down a bad road that satisfies no one. Agile is worth pursuing, but only if you have a good guide that can keep you on the right path, and the full buy in of the organization, so they don't pull out on you halfway through.
Credentials: I'm a certified level 1 Scrum master.
Agile is the recognition that that in the modern world, especially in digital products, we learn new information faster than we can act on new information, and so we benefit from structures and "processes" that allow us to discover and act on information as quickly as possible. "Processes" is in quotes there because this usually translates to a _lack_ of process. Formalized process slows things down and agile wants to act fast. Agile prefers for us to live and communicate in the moment rather than through some structured form. This is also why agile tends to be a bottom-up organizational structure, giving the most agency to the people doing the work rather than managers and middlemen.
Scrum is weird, and very, _very_ misunderstood. Scrum, at its heart, is trying compensate for one of agile's "weaknesses"--or at least, what many organizations might view as a weakness: disempowered management. Most organizations aren't willing to adopt the agile values that allow them to move fast because it means higher ups have less direct control and visibility into what's going on. Scrum tries to compensate for this by introducing an agile-flavored framework that isn't really agile, but can provide organizations that won't adopt agile values with structure that can still give them a bit of what they want (namely visibility) while providing some of agile's benefits.
Scrum's Achilles Heel, however, is a tragic one: Organizations that aren't willing to adopt agile's values aren't likely to adopt Scrum's values either. So despite all the effort and "restructuring" organizations put into place to "do Scrum", they end up with the same values and processes they were already using, but now with a Scrum-like vocabulary. This is why Scrum gets a pretty bad reputation: At its best, it's not as good as agile, and at its worst, it's twisted into a mask for the processes that were the original problem. You're usually better off either doing straight agile or not bothering with either.
As for the pros and cons of the concepts and meetings, let's clear up what each of them is about:
Standup - Often used as a daily check in. This not the intended usage and doesn't do the team much good. A well-used standup is simply an opportunity for team members to expose any blockers they're encountering so that others might jump in and help if they're so able. If the team has good communication habits already, a daily stand up won't bring them much benefit. That said, it's also serves as an opportunity for shy team members, or those who don't want to bother people, to regularly get a chance at communicating their problems, so it can be practical depending on the team's personalities.
The Sprint - Most teams think of the sprint as a unit of time around which they should plan work. This is incorrect; in fast paced environment, there's no such thing as planning work reliably enough that you can assign just enough for the sprint's duration. There are too many unknown unknowns for that to work.
A sprint is the maximum amount of time the team goes between syncs about the priorities, current problems, and what works needs to be done. Sprints aren't about planning out work and getting to it, they're about making sure the team regularly aligns itself on the important things. To accomplish this, we usually have two meetings per sprint:
Grooming - A session in which the team comes together and reviews all the upcoming work, changes, etc. The goal is for everyone on the team to be familiar with what's being worked on, how the product should behave, and that product definitions/specs are clear enough for work to begin.
Retro - A session in which the team can explore organizational or other obstacles getting in the way of productivity, and then collaborate on solutions to these problems.
Checkmarks, point systems, velocity tracking--these do not contribute to productivity and are not worth incorporating into your team. Usually, the people that benefit from these are not the people who benefit from productivity, but the people who want to have "data" they can use to prove to _their_ manager that they're doing a good job (and deserve a raise/promotion).
There's a lot of depth to agile, and done properly it can be a huge boost to fast-moving teams. But it's also very easy to get lost and go down a bad road that satisfies no one. Agile is worth pursuing, but only if you have a good guide that can keep you on the right path, and the full buy in of the organization, so they don't pull out on you halfway through.
Credentials: I'm a certified level 1 Scrum master.
At the risk of being reductive - yes, it’s fine. Most of the complaints you see are a result of people basing their opinions on whatever broken processes they have at their broken company which are kind of semi-agile, and this applies to the caricature you paint as well.
You cannot fix bad management or ineffective teams by applying a methodology, and many companies have both broken management and broken teams. Sprinkling “Scrum” on top won’t fix that, and there’s a widespread failure to realise that the symptoms people see are not the result of Scrum or Agile or anything else, but would exist regardless of the development process being used.
So, for example of how I find this working well: total process overhead for my teams is about two hours a week, averaged over the two-week sprint. This incorporates all of the planning, reviews, and daily standups. Outside of rare or one-off events like project kickoffs, post-mortems, or long-term roadmap discussions there are no other process-related meetings.
Daily standups are very much a “good morning” meeting to say hello, discuss plans for the day, and make arrangements with anyone who wants to team up or get some input from others. 10 minutes maximum. Development team and product owner only.
Fortnightly review meetings are the chance for all of the teams to get together and briefly talk though what they’ve been working on, since they don’t necessarily interact with each other all the time. This is a good chance to highlight anything that might affect others or ask any questions. 30 minutes with all the teams, including business development, management etc.
The retrospective is a chance to flag up and discuss any general issues or ideas - maybe proposing spending some time on fixing a frustrating bug, calling attention to something you’ve found that works well, or proposing some process change. Also a chance to thank particular people or teams for stuff they’ve helped with. Another 30 minutes again with everyone.
And finally the planning meetings. Reviewing what was completed and not completed in the previous sprint, picking out the tickets (from the backlog of work) that we want to do for the next, and then running through them to make sure we have all the details required for each one. Maybe adding some additional tickets for anything that’s missing. Then a quick planning poker estimation of story points, agreeing on an estimate for each amongst the team, followed by comparing the total estimate with the previous sprint to see if it looks roughly in-line or we have tried to pack too much in. Usually 1 hour, developers and product team only.
The developers will also spend a bit of time over the course of a sprint documenting anything they want to do as a ticket and collecting the appropriate requirements. The product team will also file tickets for anything that has to be e.g. delivered to a customer, as well as long-term roadmap items that form the bulk of the work.
That’s basically it. There are no teams of bureaucracy, or micromanagement, or “progress signalling”, or reporting, or piles of useless meetings. Just regularly checking in with each other, and periodically reviewing and adjusting what we are doing.
The goal of any of these systems is to help produce quality work at a steady pace. Take the bits that work and drop the bits that don’t. We have small teams so I’m sure the nature of the process will change over time, but I’ve worked with far larger teams that were pretty much the same.
Honestly, at this point I find it hard to think of a method of development I would prefer.
You cannot fix bad management or ineffective teams by applying a methodology, and many companies have both broken management and broken teams. Sprinkling “Scrum” on top won’t fix that, and there’s a widespread failure to realise that the symptoms people see are not the result of Scrum or Agile or anything else, but would exist regardless of the development process being used.
So, for example of how I find this working well: total process overhead for my teams is about two hours a week, averaged over the two-week sprint. This incorporates all of the planning, reviews, and daily standups. Outside of rare or one-off events like project kickoffs, post-mortems, or long-term roadmap discussions there are no other process-related meetings.
Daily standups are very much a “good morning” meeting to say hello, discuss plans for the day, and make arrangements with anyone who wants to team up or get some input from others. 10 minutes maximum. Development team and product owner only.
Fortnightly review meetings are the chance for all of the teams to get together and briefly talk though what they’ve been working on, since they don’t necessarily interact with each other all the time. This is a good chance to highlight anything that might affect others or ask any questions. 30 minutes with all the teams, including business development, management etc.
The retrospective is a chance to flag up and discuss any general issues or ideas - maybe proposing spending some time on fixing a frustrating bug, calling attention to something you’ve found that works well, or proposing some process change. Also a chance to thank particular people or teams for stuff they’ve helped with. Another 30 minutes again with everyone.
And finally the planning meetings. Reviewing what was completed and not completed in the previous sprint, picking out the tickets (from the backlog of work) that we want to do for the next, and then running through them to make sure we have all the details required for each one. Maybe adding some additional tickets for anything that’s missing. Then a quick planning poker estimation of story points, agreeing on an estimate for each amongst the team, followed by comparing the total estimate with the previous sprint to see if it looks roughly in-line or we have tried to pack too much in. Usually 1 hour, developers and product team only.
The developers will also spend a bit of time over the course of a sprint documenting anything they want to do as a ticket and collecting the appropriate requirements. The product team will also file tickets for anything that has to be e.g. delivered to a customer, as well as long-term roadmap items that form the bulk of the work.
That’s basically it. There are no teams of bureaucracy, or micromanagement, or “progress signalling”, or reporting, or piles of useless meetings. Just regularly checking in with each other, and periodically reviewing and adjusting what we are doing.
The goal of any of these systems is to help produce quality work at a steady pace. Take the bits that work and drop the bits that don’t. We have small teams so I’m sure the nature of the process will change over time, but I’ve worked with far larger teams that were pretty much the same.
Honestly, at this point I find it hard to think of a method of development I would prefer.
Don't think, just do the job.
Supporters of Scrum remind me of the people who say Communism really works, it's just been implemented poorly.
no
Speaking as someone from the financial world who was shocked to learn about
daily standups, no, agile is complete * invented and promoted by non-technical
armchair lieutenants.
Mba-speak, translated:
Value prop = You don’t really need this
Data Science = Not a Real Science
I have it more or less working = It’s not working
I got it working = Please don’t ask me about this anymore
Does this make sense? = Are you even listening?
Let’s stop talking about talking about the issue = We’re halfway through this meeting
Please enter a jira estimate = I am or want to be your boss
Quick stand-up = I’m interrupting your flow
Daily stand-up = I’m interrupting your flow every day
PM = Tom Smykowski
Product = Paid Intern
Feature complete = See “I have it more or less working”
Deep dive = I have no intention of pursuing this
In-flight = I enjoy dramatizing the trivial (See “How Can We Land the Plane”)
This is not intended to offend anyone = This probably offends everyone
Mba-speak, translated:
Value prop = You don’t really need this
Data Science = Not a Real Science
I have it more or less working = It’s not working
I got it working = Please don’t ask me about this anymore
Does this make sense? = Are you even listening?
Let’s stop talking about talking about the issue = We’re halfway through this meeting
Please enter a jira estimate = I am or want to be your boss
Quick stand-up = I’m interrupting your flow
Daily stand-up = I’m interrupting your flow every day
PM = Tom Smykowski
Product = Paid Intern
Feature complete = See “I have it more or less working”
Deep dive = I have no intention of pursuing this
In-flight = I enjoy dramatizing the trivial (See “How Can We Land the Plane”)
This is not intended to offend anyone = This probably offends everyone
Let's take this offline = Well... It's complicated
Let's take this offline = I'm bored, go bother someone else
Artificial intelligence = I have no idea how this works
Big Data = an Excel spreadsheet
Decentralised = not our problem
Open-source = we didn't build it
No-code = I didn't want to pay a programmer
Big Data = an Excel spreadsheet
Decentralised = not our problem
Open-source = we didn't build it
No-code = I didn't want to pay a programmer
Done = I'm finished but haven't tested it
More-or-less working, emphasis on "less"
Barf. Some of these are too familiar.
All Truisms!
>Ask HN: Do you think Agile/Scrum is beneficial for software delivery?
Yes.
>Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
It is. Management being able to change direction every 1-2 weeks is fantastic for management but can be really bad for burnout.
Every day you have to talk about what you worked on and what you planned to work on like you're toddlers who can't be trusted to do work.
Every two weeks you have agonizing meetings where you're expected to analyze the past weeks, and come up with plans to improve them as a team. This sounds good on paper but after years of it, you mostly want to shoot yourself.
And that's assuming your team doesn't agree to a 1 week sprint, where the total meeting load can be 10% of the time spent working.
And that's at companies that are pretty good at it.
So yes, it's good for software delivery. But for something called agile/scrum, it's awfully process heavy, and it sucks as an engineer.
Yes.
>Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
It is. Management being able to change direction every 1-2 weeks is fantastic for management but can be really bad for burnout.
Every day you have to talk about what you worked on and what you planned to work on like you're toddlers who can't be trusted to do work.
Every two weeks you have agonizing meetings where you're expected to analyze the past weeks, and come up with plans to improve them as a team. This sounds good on paper but after years of it, you mostly want to shoot yourself.
And that's assuming your team doesn't agree to a 1 week sprint, where the total meeting load can be 10% of the time spent working.
And that's at companies that are pretty good at it.
So yes, it's good for software delivery. But for something called agile/scrum, it's awfully process heavy, and it sucks as an engineer.
Yes, Agile Scrum is definitely beneficial for software delivery in my experience, but only when actually practiced. I see far too many teams doing stand-ups and using Jira and thinking this constitutes Agile Scrum...
I read a few books on Agile-Scrum, and still can get what the hell it is.
Each new book tells a different thing.
Each new book tells a different thing.
The main advantage of Agile is for project managers, who can change requirements on the fly.
Agile = Marxism
Scrum = Communism
Scrum = Communism
Scrum was a boon for snake-oil salesmen. You don't have to be very smart, or know anything about software, to become a scrum consultant. Anybody can learn the structure of the process, dress like management, and be dogmatic. The only special ability you need is the ability to make promises without caring if you can keep them, and to keep promising over and over again that the reason nothing is working is that you haven't been given enough power yet.
That said, some of the ideas in it are good, and I think these days people try to intelligently incorporate individual elements of scrum into their own process. In the long run, the influence might be net positive, even though there's a lot of damage to make up for.
That said, some of the ideas in it are good, and I think these days people try to intelligently incorporate individual elements of scrum into their own process. In the long run, the influence might be net positive, even though there's a lot of damage to make up for.
Coming from old school 'non-agile' financial world focused on bottom line I was in a bit of a shock learning about this daily standup ritual.
Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
Do these extra bureaucracy layers, meetings, checkmarks and vague "man-points" estimates actually bring any value.