Stefan Wolpers July 23, 2020 TL; DR: Scrum’s Nature: It Is a Tool; It Is Not About Love or Hate
Regularly, we find articles from developers detailing why ‘Agile’ in general and Scrum’s nature, in particular, deserve our collective disdain.
What has always struck me in this discussion is the fact that Scrum is a tool useful to accomplish one primary task: delivering value to customers of emergent products in complex environments while mitigating an organization’s exposure to risk at the same time. So, if Scrum is not working in an organization, maybe it is because Scrum is applied to the wrong cause in the first place. Or, that its application has been mechanical, driven by folks who don’t know what they are doing. (Seriously, how hard can Scrum be if the manual comprises of 18 pages, right?)
The question then is: Why would I “hate” a tool unsuited for the intended purpose or applied incompetently? Would I hate a hammer for not being capable of accurately driving a screw into a wooden beam? Probably not, as the hammer wasn’t designed for that purpose, and neither sheer will-power nor stamping with your feet will change the fact.
Scoring Big on Hacker News or DZone
Have you ever dreamt of scoring big, as an author, on Hacker News or DZone?
That’s simple; let me help you: Write something about how awful “Agile” and Scrum are. These rigid methodologies inevitably turn developers into mindless cogs in a corporate machinery—churning out more and more code—while ignoring the true potential of these knowledge workers. Then find a catchy headline like “Why I [Hate, Despise…] [Agile, Scrum, …],” and the response will be liking shooting fish in a barrel.
In a recent article on Scrum’s nature, the author describes his experience with “Scrum” in detail. Let’s have a look at some of the author’s issues:
- Definition of Done: “I entirely agree that every task should have a definition of done. But the definition should be task related […] Figuring out ‘Done’ is also difficult because the client may not have a good idea of what done looks like.” The Definition of Done in Scrum serves a higher purpose than merely checking off tasks as in quality control. The Definition of Done is the quality standard that applies to all Product Increments. It is well-understood by everyone who is inspecting Product Increments, thus providing the basis for empiricism to work. It comprises of everything necessary to ship the Product Increment to our customers, including but not limited to engineering standards, governance, and legal requirements. Considering these attributes, no one expects the customers to have a complete understanding of what ‘Done’ means. That is why we pay the Development Team to accept the responsibility to deliver a ‘done’ Product Increment.
- Timeboxing and delivery: “When things are done, they are done. And you should be able to ship with the done feature at any time. Waiting for the end of a sprint and a sprint review means waiting to ship a done project.” The statement is plain wrong. The decision of whether to ship a Product Increment is the prerogative of the Product Owner. An Increment might be shipped at the end of the Sprint, or its shipment is delayed. Or the Development Team is continuously delivering Increments during the Sprint. At no point is the delivery of a Product Increment depending on the Sprint Review as this event is not a Stage-Gate®-like approval instance.
- Scrum Master: “What the Scrum Master really is is the project manager stripped of the ability to manage the project. […] But there are times when something needs to be done and a project manager can make the changes and get it done.” Scrum relies on self-organizing and cross-functional teams that decide on how to create valuable Product Increments. The job of the Scrum Master is hence to support the Scrum team by removing impediments—problems the team members cannot solve by themselves-thus supporting this decentralized leadership approach. Moreover, those impediments are mostly situated at an organizational level. Here, change is not happening by simply “getting things done,” but by working with other stakeholders and their plans, agendas, objectives, etc. This need is also the reason that being a Scrum Master is a full-time job. Scrum Masters are not getting paid to facilitate a few Scrum events, order stickies, and book meeting rooms. Their primary role is that of an organizational change agent.
- Scrum events: “While I like the basic concepts, I don’t like the huge time sync associated with these events. I don’t like meetings and I like non-productive meeting even less.” If you don’t know where you are going—we are working on an emergent product—, any road will get you there. Hence it probably makes sense to regularly allocate some time to figure out whether we are heading in the right direction. All events are time-boxed to reduce the risk of wasting everyone’s time without creating value for our customers. No one expects that your events will be effective, starting with Sprint 1. It will take some time to get them right. Fortunately, we also have a formal event to support the team’s strive for continuous improvement, which also means that we do not have to wait for the Sprint Retrospective to start changing things for the better. Just do it.
- Team: “I believe in individual effort and that individuals should get credit for their efforts. […] I also reject the concept that every team member should have an equal vote on everything.” Spoiler alert: Scrum is not for everyone; heroes and rockstars—self-proclaimed or otherwise—will be probably disappointed. Scrum stresses the importance of ‘true’ teams, as the team needs to assume responsibility for creating a valuable Product Increment with the regularity of a Swiss clockwork. A diversity of experience, background, and opinion will support the required self-organization and deliver superior results in that respect. Finally, remember the adage: If you reward firefighters, you create a culture of arsonists. Guess, where toxic engineering department cultures come from?
- Scrum is Not a Team Player: “In the Scaled Agile Framework (SAFe), you get to the time boxed scrum teams by having an ‘Architectural Runway’ filled with ‘enablers.’ Scrum is Scrum; SAFe® is SAFe®. Please, do not confuse the two as Scrum does not have anything to do with SAFe®. As far as a successful collaboration between several Scrum teams is concerned, both NEXUS and LeSS offer the appropriate framework extensions to the Scrum Guide. Of course, it is possible to create new products with more than one Scrum team working on them, unless you remove critical collaboration and self-organization components. As Ron Jeffries so eloquently put it: “We Tried Baseball and It Didn’t Work.”
- User Stories: “I’m not even going there. Here is a smattering of why user stories aren’t the be-all and end-all.” If nothing helps, read the manual. Please point me to where the Scrum Guide is mentioning User Stories. If you like to apply them, and it works out, good for you. However, there are other ways of dealing with Product Backlog items, for example, job stories. Employ whatever helps your ProductBacklog become actionable to create value for the customers.
- Working Software: “Scrum is based around dropping working software every two weeks. […] But the real problem I have with the working software model is that it gives short-shrift to planning and documentation. […] o you have two weeks to do planning then you can forget about that drudgery. And after that two weeks, don’t plan or document, just code, code, code.” The author argues that Scrum’s focus on working software leads to poor design decisions, inferior code quality, and a lack of documentation. In my experience, this only happens in environments with poor engineering standards and probably would happen anyway regardless of the development framework employed. Scrum’s success depends on strong engineering culture and teams that strive for craftsmanship, which is the reason that Scrum and Extreme Programming, for example, work together so well. When TDD, refactoring, and emergent architecture meet a continuous Product Backlog refinement process, none of the issues mentioned before will materialize.
Cannot see the form?
Please click here
Scrum’s Nature: It Is a Tool — Conclusion
Agile software development is not about solving (code) puzzles all day long. As a part of creating new products in complex environments, it is first-of-all about identifying which problems are worth solving from a customer perspective. Once that is established, and Scrum’s empirical approach has proven to be supportive in that respect, we strive to solve these puzzles with as little code as possible. As the Manifesto of Agile Software Development puts it clearly: “Simplicity—the art of maximizing the amount of work not done—is essential.”
To better understand Scrum’s nature, let me rephrase Churchill’s quote on democracy: ‘Many forms of Government software development have been tried, and will be tried in this world of sin and woe. No one pretends that democracy Scrum is perfect or all-wise. Indeed it has been said that democracy Scrum is the worst form of Government software development except for all those other forms that have been tried from time to time.’
What is your experience with Scrum’s nature? Please share it with us in the comments.
Business & Finance Articles on Business 2 Community
(27)
