Robert C. Martin - The Land that Scrum Forgot

What people said

Recommends user115440 · 2014-03 · Software Engineering Stack Exchange · on “Does anyone else feel Scrum isn't agile?”

Yes. Even one of the "fathers" of agile doesn't agree that Scrum is really agile : [this video] – Euphoric [LINK] I think this link from one of the comments above really says it all. It's worth a watch, Uncle Bob gives a brief history on Scrum and basically says Scrum is not an Agile development process because Scrum has evolved over time to become a management process . The reasons behind this appear to be because it was project managers, and not developers, who were taking the Scrum courses.

Recommends MichelHenrich · 2014-08 · Software Engineering Stack Exchange · on “Evolutions in Agile development field”

I would actually advise you to look for even OLDER books. Look for the original books from Ken Schwaber, Kent Beck, Alistar Cockburn and so on. Look for the OLD and ORIGINAL stuff. The reason I say this is because Agile has become a marketing buzzword in our industry, and most companies are simply applying bastardized versions of the processes listed within Scrum/Lean/Whatever as management practices, just to say that they are Agile, with no regards to the actual change in culture and values that are necessary for both the customers and the team to enjoy the process. This is my opinion of course. But you can see in the following links that I'm not alone in this thought: Half-Arsed Agile Mani

Recommends oopexpert · 2017-06 · Software Engineering Stack Exchange · on “Where and when do design, architecture activities take place in Scrum”

Robert C. Martin had a talk about that you can find on youtube: The land Scrum forgot [this video] There he adresses this common issue that in Scrum architecture and design is never mentioned so it is up to the team to identify what architecture and desiogn should mean within the project. My personal opinion is that you should have one instance in the team to be responsible for architecture and design. The contract should be: The architect decides how these subjects are adressed. On the other side he should not be able to escape resulting questions that came out of his decisions. In my current project we are currently facing several issues, that can mainly be broken down to concept diversificatio

Recommends BЈовић · 2017-08 · Software Engineering Stack Exchange · on “How do I deal with a counterproductive scrum team?”

One of major agile principle is to go back, and correct whatever is wrong. That doesn't only include code refactoring and bug fixes, but also fixing the development process. So, why don't you make a meeting with your team, and see how can you improve development process? If that means, no scrum or standup meetings, then be it. Also you are breaking one of principles in agile manifesto [LINK] : "Individuals and interactions over processes and tools". On the other hand, if your team thinks that iterative development is bad, then maybe you are doing it wrong. It doesn't matter if you do not finish everything you planed for one iteration - you can always move things to next iteration. That is al

Cites MichelHenrich · 2014-09 · Software Engineering Stack Exchange · on “Is randomly refactoring code allowed in scrum”

I really don't mean to attack other answers, but is nobody else writing automated tests here? Here [LINK] 's a fun reading from Martin Fowler for anyone doing Scrum without proper software engineering practices. Robert C. Martin also says a lot about this here [this video] . So, to my answer... In short, it goes like this: Yes, "randomly" refactoring code is allowed in Scrum , as long as the team decides that it should be done. (After all, it is self-organizing) And now for the long answer: It's evident that leaving more and more technical debt after each Sprint is a recipe for disaster. Soon, everyone will slow down as the code bocomes more messy; every change will be harder to make because the