321–330 of 462 posts
Back when Scrum was new I already wondered how it could make sense to make developers be constantly sprinting. I mean it's right there in the word choice. You can't sprint all the time! A sprint is short and fast and then you rest. Making everything in work life be only sprints is madness.
You rest at all the meetings.
Earlier quoted context omitted.
There isn't anything here about having to do daily standups: https://agilemanifesto.org https://agilemanifesto.org/principles.html It's common in corporate implementations of Agile (tm) but it isn't actually some commandment or prescribed feature of Agile itself. It's actually prescribed by Scrum: https://scrumguides.org/scrum-guide.html#daily-scrum
The business has a need for a regular status update from everyone. You can call it a standup or not. You can call it not agile, but in the end the business has needs and you cannot ignore those needs. The business needs to know when something will be done as they need to make promises to customers. The business also needs to know when things will be done as that is a proxy for cost - they need to make sure they are n…
There isn't really any such thing as "doing Agile", it isn't a prescribed process to follow.
And saying that you use Agile instead of Scrum but dislike the invasive status meetings isn't actually congruent with the actual definitions of Agile or Scrum.
Earlier quoted context omitted.
Right, so when someone says they are doing Agile instead of Scrum but don't like it because of the invasive status meetings, they're probably actually doing some form of Scrum whether or not they realize it.
There are agile processes other than Scrum. Scrum has gotten all the press for some reason, but there are other options. I personally prefer Kanban. The sprint is not a useful deadline for me so I want to ignore it.
Personally I find it more useful to organize things around useful product milestones that are actually usable and demo-able. Those might take a week, or three weeks, but probably not two months because that's a long time to go without a demo and getting feedback. Sticking to a rigid 2-week sprint with an expectation of demo-able progress after each sprint doesn't feel particularly realistic or useful to me.
Earlier quoted context omitted.
What in Scrum is about keeping managers happy?
I don't know if this is properly part of scrum, but it is how I've seen it implemented on every team I've been on where scrum was implemented. Sprints end with some kind of demo, retrospective, and sprint planning designed almost entirely to keep PMs and managers in the loop and happy. Reports are generated, spreadsheets with a few quarters worth of tasks are updated, and PMs or managers get to run that further up th…
There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum. Scrum is iterative, by design. It's supposed to evolve with the CLient's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that."
In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key.
When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic.
When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
Earlier quoted context omitted.
The reality is even good devs tend to work hard on the wrong thing. Accountability comes from your peers as much as your manager. If this makes you angry you are one of the bad ones.
Give good devs a direct line to the customer and they're apt to always work on the right thing, but will spend a lot more time dealing with the customer and a lot less time in development in order to do so. Leave good devs to play telephone through a middle-man, what we call the manager, and they almost certainly will work on the wrong things, but will have a lot more time to do it. I wonder which is actually more pr…
The devs have the opposite problem, they can imagine all sorts of new technology that would be fun to use (for them) in helping the customer solve their problems with doing foo, and even if they understand foo from the customer's business perspective they they may not have a great understanding of how big a problem it is in the grand scheme of things and what commitment of resources and expenses are justifed in solving it.
Managers talking to managers can (in theory) draw some boxes around scope and priorities and get the right development problems solved at the right time. They may talk and realize that doing foo isn't even really a great idea and they should be doing bar intstead. Line-level employees working directly with developers will not be as likely to realize that.
Developers can fall into the trap of thinking that because they are smart (mostly) at building software they are automatically smart about all the business processes and problems and goals of the company. They should certainly be informed about those things, but they are not experts in everything.
Earlier quoted context omitted.
I don't know if this is properly part of scrum, but it is how I've seen it implemented on every team I've been on where scrum was implemented. Sprints end with some kind of demo, retrospective, and sprint planning designed almost entirely to keep PMs and managers in the loop and happy. Reports are generated, spreadsheets with a few quarters worth of tasks are updated, and PMs or managers get to run that further up th…
There are no PMs in actual Scrum. Scrum Teams are self-managing, so there's no need for a PM. There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum. Scrum is iterative, by design. It's supposed to evolve with the CLient's needs and desires. They want to be able to change…
I've never been on a team using scrum that didn't have a project manager or product manager as part of scrum (or both). Most often they have been my scrum leader.
Scrum is supposed to be self-guided, but I have never seen it implemented on a team of any scale.
I also wouldn't expect a team without PMs, whether that's project managers or product managers, to be very effective. Someone needs to be focused on keeping the project moving, and often the skills needed for a scrum leader/master overlap greatly with project managers. Someone also needs to be focused on the product and how the team's efforts fit into the longer term product goals. If that isn't anyone with a PM title it will be someone else playing that role with everything but the title.
Earlier quoted context omitted.
Give good devs a direct line to the customer and they're apt to always work on the right thing, but will spend a lot more time dealing with the customer and a lot less time in development in order to do so. Leave good devs to play telephone through a middle-man, what we call the manager, and they almost certainly will work on the wrong things, but will have a lot more time to do it. I wonder which is actually more pr…
Disagree. The customer often has tunnel-vision on their needs, and doesn't know what's possible, and might have trouble even describing it except that their manager told them that their foo task was a problem. The devs have the opposite problem, they can imagine all sorts of new technology that would be fun to use (for them) in helping the customer solve their problems with doing foo, and even if they understand foo…
I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement. Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance. I’m not sure what planet the OP is from, but this…
Earlier quoted context omitted.
I would love to bring some scrum masters down to the local high school track and have them run back to back sprints until the message sinks in.
The Scrum Master is supposed to be part of the team, constantly helping with the Sprint, whether that's getting clarification for you, or pushing back on unrealistic expectations, or getting more resources, or whatever. Sprint was a bad choice of terms. It shouldn't have been related to races at all. If anything, it should be more like walking. It's about figuring out what pace is sustainable for your particular team…