Return to site

SCRUM: Why Scrum Requires Completely โ€œDoneโ€ โœ… Software Every Sprint by Christiaan Verwijs

ยท scrum

๐Ÿ”ฅThe most essential rule in Scrum: ๐˜ค๐˜ณ๐˜ฆ๐˜ข๐˜ต๐˜ฆ โ€œ๐˜‹๐˜ฐ๐˜ฏ๐˜ฆโ€ ๐˜ด๐˜ฐ๐˜ง๐˜ต๐˜ธ๐˜ข๐˜ณ๐˜ฆ ๐˜ฆ๐˜ท๐˜ฆ๐˜ณ๐˜บ ๐˜š๐˜ฑ๐˜ณ๐˜ช๐˜ฏ๐˜ต.

An increment is โ€œDoneโ€ or it isnโ€™t, there is no gray area:

๐Ÿ‘‰No remaining stabilization

๐Ÿ‘‰No remaining install package

๐Ÿ‘‰No remaining acceptance tests

๐Ÿ‘ฉ ๐Ÿซ ๐——๐—ฒ๐—ณ๐—ถ๐—ป๐—ถ๐—ป๐—ด โ€œ๐——๐—ผ๐—ป๐—ฒโ€

โ€œDoneโ€ depends on various factors:

๐Ÿ‘‰quality guidelines

๐Ÿ‘‰critical level

๐Ÿ‘‰users involvement


๐Ÿ‘‰and many more...

It requires an effective workflow to deal with all the stakeholders.

It may be tempting to limit โ€œDoneโ€ to what a Development Team can do

So many teams end up with a definition of โ€œDoneโ€ like:

๐Ÿ‘‰code review

๐Ÿ‘‰ Unit tests coverage

๐Ÿ‘‰merged to develop-branch

๐Ÿ‘๐Ÿ‘Ž โ€œ๐——๐—ผ๐—ป๐—ฒโ€ ๐—ฎ๐—ป๐—ฑ ๐—จ๐—ป๐—ฑ๐—ผ๐—ป๐—ฒ ๐—ช๐—ผ๐—ฟ๐—ธ

Such a previous definition of โ€œDoneโ€ is incomplete.

You will still have to handle:

๐Ÿ‘‰PO review of the feature

๐Ÿ‘‰Unnoticed bug

๐Ÿ‘‰Merge conflict of other teams' code

๐Ÿ‘‰Wrong scale on mobile

๐Ÿ‘‰Install failure on prod

๐Ÿ‘‰Security flaws

๐Ÿ‘‰Latency bottlenecks

๐Ÿ‘‰User calls support due to deficient documentation

๐Ÿ‘‰UX/UI accessibility flaws

๐Ÿ˜ฎ๐—ฆ๐˜‚๐—ฐ๐—ต ๐˜‚๐—ป๐—ฑ๐—ผ๐—ป๐—ฒ ๐˜„๐—ผ๐—ฟ๐—ธ๐˜€ ๐—ต๐—ฎ๐˜ƒ๐—ฒ ๐—ณ๐—ผ๐˜‚๐—ฟ ๐—ฐ๐—ผ๐—ป๐˜€๐—ฒ๐—พ๐˜‚๐—ฒ๐—ป๐—ฐ๐—ฒ๐˜€:

1๏ธโƒฃ It draws time and energy

2๏ธโƒฃ This decreases the transparency of the Increment

3๏ธโƒฃ โ€œstaying busyโ€ feeling while there is no potentially releasable product increment

4๏ธโƒฃ The risk of software development not being fully validated

๐Ÿ—ฃ๏ธ ๐—ค๐˜‚๐—ผ๐˜๐—ฒ:

The bigger the gap between what a team defines as โ€œDoneโ€ and what is needed -- the more disruptions and interruptions will happen in future Sprints due to undone work.

๐Ÿ‘€๐—˜๐˜…๐—ฎ๐—บ๐—ฝ๐—น๐—ฒ๐˜€ ๐˜๐—ผ ๐—ถ๐—น๐—น๐˜‚๐˜€๐˜๐—ฟ๐—ฎ๐˜๐—ฒ ๐˜๐—ต๐—ฒ ๐—ฝ๐—ผ๐—ถ๐—ป๐˜

1๏ธโƒฃ A scrum team doing software for complicated machinery.

For practical reasons, they roll out to production in the end and use the pre-prod along the way.

In the end, they discovered that the prod hardware causes so many issues that they revert to the old solution and negate their work investment.

2๏ธโƒฃ A PO makes a scrum team work on a market disruptive solution, but he chose to deliver it after one year. This was too late, the market did not respond positively, and all the investment was wasted.

๐Ÿ—ฃ๏ธ ๐—ค๐˜‚๐—ผ๐˜๐—ฒ:

๐˜™๐˜ฆ๐˜ญ๐˜ฆ๐˜ข๐˜ด๐˜ช๐˜ฏ๐˜จ ๐˜ต๐˜ฐ ๐˜ถ๐˜ด๐˜ฆ๐˜ณ๐˜ด ๐˜ฆ๐˜ข๐˜ณ๐˜ญ๐˜บ ๐˜ข๐˜ฏ๐˜ฅ ๐˜ฐ๐˜ง๐˜ต๐˜ฆ๐˜ฏ ๐˜ช๐˜ด ๐˜ต๐˜ฉ๐˜ฆ ๐˜ฃ๐˜ฆ๐˜ด๐˜ต ๐˜ธ๐˜ข๐˜บ ๐˜ต๐˜ฐ ๐˜ฎ๐˜ช๐˜ต๐˜ช๐˜จ๐˜ข๐˜ต๐˜ฆ ๐˜ณ๐˜ช๐˜ด๐˜ฌ.

๐Ÿ˜‰ ๐—”๐—ฑ๐˜ƒ๐—ถ๐—ฐ๐—ฒ:

1๏ธโƒฃ Maintain a ruthless focus on โ€œDoneโ€ software

2๏ธโƒฃ Make the gap between what you can do and what is needed for โ€œDoneโ€ transparent

3๏ธโƒฃ Make it smaller & simpler #refinement

4๏ธโƒฃ Itโ€™s not about Scrum, but about reducing risk and maximizing value, and making impediments transparent.

#scrum #dod #done