4 ms·

"That's the core of Scrum, and I don't see what's wrong with it." Depends on what you are trying to do. Add some buttons and a new report feature to some 100K

by RogerL 11y ago

"That's the core of Scrum, and I don't see what's wrong with it." Depends on what you are trying to do. Add some buttons and a new report feature to some 100K code base with 5 programmers? Sure, why not. Get changes in front of the customer quickly, backtrack or iterate, and so on. Software for a medical device? Not so fast, bucko. Endless regulations (for good reasons), extended test cycles, changes require changes to hardware, long sales cycles, well, scrum is not your friend. Neither is waterfall, or whatever strawman someone wants to erect. I've worked hard projects (military hw/sw) and no well defined process gets you there. It comes back to the real core of agile, which the OP emphasizes - inspect and adapt. 2 week sprints (or any other number) makes no sense if you are held to an external release schedule (work for TV, sports? You are going to be releasing on that schedule, not your 2 week sprints, sorry). Do you have subcontractors? Scrum usually doesn't work there, especially if they are making hardware. Work in a truly 'requirements change' environment (TV, war, etc). Ya, sorry, not going to work to the end of the sprint no matter what, no requirements changes allowed. Conversely, is someone making hardware for you, or are you making hardware? Changing something could change delivery dates and costs by months to years. You can't just treat every 2 weeks as a new day (so to speak), changing things willy nilly. Want to build a search engine or a cloud infrastructure? Lots of planning required - you can't just add features every two weeks. Scrum is a tool in the toolbox - if the problem you are trying to solve fits its assumptions it'll work fine. But it sticks it head in the sand about things that it considers hard. For the right domain that is brilliant - requirements are hard, let's get ideas in front of the customer sooner, because they don't know what they want anyway. Scrum says 'schedules are hard' and decides not to do schedules. Great if you don't actually need schedules, but if you need to deliver a hw/sw system for a business opening (say), well, you better be scheduling. And soft starts are not an option (as I said before, I used to work for the DoD, now I work for TV - you mostly can't soft start war or the Super Bowl). In military work every meeting is basically risk assessment - what are the risks I am facing, and you manage and mitigate from there. Risk is not in the vocabulary of scrum, and it is hard to think about things when you don't have a vocabulary for it. When I start something or work something I think in terms of 'goals, strategies, and tactics.' Ya, military again. But it works. Goals usually don't change, and you need to choose strategies and tactics to meet those goals. But people get wound around the axle 'we must do X' - well, not if X doesn't meet the goal. 'but X is agile'. I don't care, it's the wrong thing in this case. Scrum, as practiced, doesn't give us the vocabulary for that (the linked article does in the 'think and adapt' paradigm, but that is still a bit too loosey goosey for me). What are we trying to do (goals), how are we going to do it (strategies), and what are we doing today (tactics) is a pretty good, but imperfect way to organize your thoughts. Scrum can work in places in those things, sometimes. Have a mobile app that is digesting and displaying the data of your system? Maybe/probably that can be scrum (maybe not if medical - regulations, extensive testing, and so on). Brooks is still right - there is no silver bullet. There is no alternative except think, observe, pull the levers for which you have control, observe the feedback loop, adapt, and continue on. If you need a schedule, make one, and then adapt a risk control methodology to keep costs and other creeps in line. Scrum is a system. Where else in engineering would we have 8 or 10 rules where we argue that would result in a functioning system? No where. Why expect it to work in running projects. The agile manifesto didn't. They expected thinking and agility, not fixed 2 week sprints, no matter what. People over process. Scrum is a process. Enough said?

matthewmacleod 11y ago
I completely agree that Scrum isn't suitable for all software development, and that there's no silver bullet. If it doesn't work, then that's totally okay – don't use it. Doesn't mean it's 'broken' or 'dead', as so many claim. Scrum is a system in the sense that it provides a framework upon which you can build a sensible process. Not every aspect works for every environment, and that's totally fine! It's the key principle of agile development. I think what's happened is that so many places have completely ballsed-up the implementations of processes like Scrum, and that's given it a bad name. People naturally push back against that. I do find it a little frustrating that the two issues are conflated so often. As an aside – at it's core, Scrum is just a process that breaks development work down into small, actionable parts. In most cases, that's an internal implementation issue, and is still compatible with meeting fixed external deadlines. Again, it's situation-dependent, but that's why it's advisable to avoid agile-by-numbers and implement the parts that work.

by RogerL 11y ago

matthewmacleod 11y ago

I completely agree that Scrum isn't suitable for all software development, and that there's no silver bullet. If it doesn't work, then that's totally okay – don't use it. Doesn't mean it's 'broken' or 'dead', as so many claim. Scrum is a system in the sense that it provides a framework upon which you can build a sensible process. Not every aspect works for every environment, and that's totally fine! It's the key principle of agile development. I think what's happened is that so many places have completely ballsed-up the implementations of processes like Scrum, and that's given it a bad name. People naturally push back against that. I do find it a little frustrating that the two issues are conflated so often. As an aside – at it's core, Scrum is just a process that breaks development work down into small, actionable parts. In most cases, that's an internal implementation issue, and is still compatible with meeting fixed external deadlines. Again, it's situation-dependent, but that's why it's advisable to avoid agile-by-numbers and implement the parts that work.