I find it works well in two situations: 1. Protecting a software team in a non-software organization. In this situation the team has no voice in prioritizing w

I find it works well in two situations: 1. Protecting a software team in a non-software organization. In this situation the team has no voice in prioritizing work, is under constant pressure to deliver, and is generally viewed as a cost-centre by leadership. Taking a lead role and introducing an agile/scrum-like process is a way to deflect unreasonable demands off of the team. The goal is to convince leadership that deadlines aren't as important as progress. Demonstrating regular progress and having check-ins is a way to console the existing leadership and build trust with them while the team gets breathing room to address their concerns and learn to prioritize what needs doing with what users want to be done. Don't get too invested in it. The incumbent leadership might try to wrest control of the process back from the development team. If they get involved you'll notice more meetings, new job roles, and presentations with charts and diagrams explaining how the scrum/agile process works. This is plain old Taylorist micro-management sneaking its way back in. Be prepared to give up on agile/scrum before it gets to this point or make sure that your team is in control of the process and not external stakeholders. 2. Establishing a new team with customers in the absence of management. In this situation the customer is basically your manager. And they will want deadlines because money. Similar to the first situation, agile/scrum here is about managing expectations and getting parties on two sides with different priorities to work together and trust one another. If you can build up that trust you can ease off on the agile/scrum stuff as needed. In every case the important part is that the development team, the people writing the software, are in control of prioritizing what work gets done and how it gets done. As soon as you have diagrams and presentations and several layers of "managers" involved in directing a software team you've entered into the Agile Industrial Complex and have dropped the ball. Caveats: you will find that some developers will refuse to work with customers. They do not want to co-operate with management. They only want to write code and view any process to manage work as a waste of time. The important thing to remind them of is that you don't need to use any of the scrum/kanban/whatever processes forever. The goal is to get management off your backs by showing them your team can deliver results by shipping stuff on a regular cadence. Once things get into place you can change the process to whatever works for your team as needed. That's the whole point of being "agile." No need to cargo-cult rituals for the sake of performing work. Do it until you get the trust you need to get back to work.