Timeline for Does Scrum create additional overhead for projects where requirements don't change?
Current License: CC BY-SA 4.0
32 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 24, 2019 at 16:30 | vote | accept | Artem | ||
| Jan 23, 2019 at 17:42 | comment | added | Mason Wheeler | No matter how many pervasive problems are found with a system, no matter how many different implementations in distinct places and circumstances show the same problems, the True Believers will always insist that the problem is not systemic; that the fault lies entirely with the people who are Simply Not Doing it Right, because the system itself is perfect! This basic truth appears to be just as valid when it comes to bad development ideas as bad political ideas. | |
| Jan 23, 2019 at 17:37 | comment | added | Chronocidal | @BartvanIngenSchenau Or Regulatory projects where the Requirements have been defined externally, and are not permitted to change | |
| Jan 23, 2019 at 14:26 | comment | added | senseiwu | SM is only part of the problem. Many of them are nice and trying their best. But that is not my main point. My main point is that scrum which is a process management methodology which was invented to manage product development which involves 2 parties -- a customer(who gives the contract) and a vendor(s/w consultancy) is being blindly used for internal product development and R&D work | |
| Jan 23, 2019 at 14:03 | comment | added | Cubic | @senseiwu To reiterate, if the above wasn't clear enough: A scrum master is not a manager. You could have the same person act as both a scrum master and a manager, but if someone is managing you - micro or otherwise - they're not acting in their capacity as a scrum master, regardless of what their job title says. | |
| Jan 23, 2019 at 13:33 | comment | added | Cubic | @senseiwu The scrum master does not decide what work needs to be done or how to do it. The scrum masters job is explaining scrum to the team and helping them adhere to it. If they're involved in technical decisions in their role as the scrum master, they're overstepping their bounds. Which they should realise if they actually understand scrum, which they should if they want to be a scrum master. | |
| Jan 23, 2019 at 11:19 | comment | added | Simon | Thank you for a good laugh that requirements don't change in military projects. They change a lot. And because often military projects last for a couple of years, they can change diametrical as in "oh we ordered an interceptor aircraft, but now we want a bomber which carries a lot more load." | |
| Jan 23, 2019 at 10:20 | comment | added | senseiwu | I agree, daily is not theoretically targeted at SM, but SMs are usually the showmasters there 😉 | |
| Jan 23, 2019 at 10:19 | comment | added | Erik | @senseiwu I mean literally the fact that you think "reporting to a non-tech" is part of Scrum suggests you haven't, because that's not anywhere in the guide and is, in fact, the exact opposite of the real purpose of the meeting you're describing. | |
| Jan 23, 2019 at 10:18 | comment | added | user304877 | @senseiwu The daily is not targeted at the scrum master, it's targeted at the team. You should not have to explain what you are doing to the scrum master, you should just talk about what you are working on so everyone on the team knows what other team members are working on. This avoids problems like work being duplicated and provides an opportunity for people to give input if they have additional knowledge. It is also a place to inform the scrum master of impediments hindering your work which he needs to resolve. It is not a status meeting. That said,I agree on not applying it blindly though. | |
| Jan 23, 2019 at 10:10 | comment | added | senseiwu | @Erik I have in fact. The truth is that in any job which involves at-least a bit of creativity, this micromanagement and reporting becomes a painful chore. It can be OK if you work in clerical jobs. Scrum can be OK in certain types of s/w projects where Product has already reached a mature state and further bug fixes and feature development can be done (usually by an outsourced party or a less skilled team) in 2/3 week sprints based on feature priority. In those case, it can be also OK for those developers to be managed by a Scrum master or a PO. | |
| Jan 23, 2019 at 10:07 | comment | added | Erik | @senseiwu the idea that an engineer is "forced to explain their work every day to a non tech" suggests that you've never done anything resembling what the Scrum Guide talks about. Which, sadly, is pretty common among people who claim to have done Scrum. | |
| Jan 23, 2019 at 10:05 | answer | added | Borjab | timeline score: 1 | |
| Jan 23, 2019 at 9:29 | comment | added | Thorbjørn Ravn Andersen | The advantage of SCRUM is the improved communications between all members of the team (and by extension the surrounding organization). This should be considered in comparison to the amount of mails needing to be sent otherwise. | |
| Jan 23, 2019 at 8:09 | comment | added | Lee | I work in the healthcare field and our requirements change all the time too. | |
| Jan 23, 2019 at 7:57 | comment | added | senseiwu | Scrum is not just an overhead, but very disastrous for RnD kind of projects whether requirements change or not. When really good engineers are forced to explain their work every day to a non tech. "scrum master" and long term thinking is replaced with 2 week sprints, you have a problem. Scrum was promoted by s/w consultancies who wanted to have some bargaining power with their customers. Blindly applying it to internal product development within an org. was a bad idea. This blog is a good one.. | |
| Jan 23, 2019 at 5:59 | comment | added | Gorkem | it is really hard to write complete and consistent requirements. people try do it, if they managed(which probably not) they realized that, what they wanted is something different. | |
| Jan 23, 2019 at 0:47 | answer | added | Beejamin | timeline score: 1 | |
| Jan 22, 2019 at 18:32 | answer | added | Cort Ammon | timeline score: 0 | |
| Jan 22, 2019 at 16:03 | comment | added | Jack Aidley | The CHAOS reports have issues - see, for example few.vu.nl/~x/chaos/chaos.pdf - and while, on balance, research into the effectiveness of agile and Scrum methods shows a positive effect, there are systematic problems with the comparator groups since "non-agile" is less well defined than what it is being compared to. | |
| Jan 22, 2019 at 15:20 | review | Close votes | |||
| Jan 29, 2019 at 3:05 | |||||
| Jan 22, 2019 at 15:03 | comment | added | gnat | Possible duplicate of Can fixed scope + fixed deadline + fixed price contract ever be made to work with "agile"? | |
| Jan 22, 2019 at 15:00 | history | tweeted | twitter.com/StackSoftEng/status/1087726764674240512 | ||
| Jan 22, 2019 at 14:37 | comment | added | alephzero | I've been involved with military projects where the requirements "didn't change" because they were so vague as to be useless. For example, the performance requirements for a fighter aircraft engine: "The engine will perform satisfactorily over the full flight envelope of the aircraft". That one sentence was the entire spec. The reply to a request for more details was "Well, we don't know what the full flight envelope will be until we have test flown the prototype aircraft". And no, I'm not making this stuff up. | |
| Jan 22, 2019 at 14:19 | history | edited | Thomas Owens♦ | CC BY-SA 4.0 |
added 3 characters in body; edited tags; edited title
|
| Jan 22, 2019 at 11:47 | answer | added | Daniel | timeline score: 13 | |
| Jan 22, 2019 at 11:42 | answer | added | amon | timeline score: 10 | |
| Jan 22, 2019 at 11:39 | comment | added | Bart van Ingen Schenau | The only projects where requirements don't change are cancelled or terminated projects. It might be that in some industries the cycle from idea to deployed product is longer than in other industries, but that doesn't change the fact that ideas/requirements change constantly. | |
| Jan 22, 2019 at 10:52 | answer | added | Thomas Owens♦ | timeline score: 69 | |
| Jan 22, 2019 at 10:44 | comment | added | HorusKol | Military project requirements change constantly - which is how they end up massively over budget and delayed | |
| Jan 22, 2019 at 10:35 | review | First posts | |||
| Jan 22, 2019 at 22:18 | |||||
| Jan 22, 2019 at 10:34 | history | asked | Artem | CC BY-SA 4.0 |