How mini-waterfalls can appear in agile development, and how to address them

1. Steve Wells
Scrum Master, SkyGo Consoles

2. Fail!

3. Why the title?

4. PO SM
Dev
Dev
Dev
Dev
What other roles in Scrum?
Dev
Dev

5. PO SM
TA/BA
Dev
Dev
Dev
Tester
Tester

6. Analysis
Development
Test
Look familiar?

7. Why is this so bad (just because it isn’t
“Scrum”)?
Is this the real resource
requirement, every
hour, of every day of
every sprint?
33%
17%
50%

8. Why is this so bad (just because it isn’t
“Scrum”)?
Silos
• What if the analyst leaves?
• What about tasks outside of those roles?
Utilisation
• First part of sprint, testers unused - last part of sprint, devs unused
Availability
• Stories stall if resource (silo) is unavailable; sickness, holidays, leavers

9. Understanding
• PO → Analyst → Dev - “Chinese Whispers”
• Further down the waterfall - less understanding of requirements
Empowerment
• “Sign-Off” gives undue power to testing role
Involvement
• “Over-the-wall” thinking
• No full team responsibility (testers find bugs, devs fix them)
Why is this so bad (just because it isn’t
“Scrum”)?

10. It is stifling
• Throttles pace/velocity
• Stifles cross-functional innovation
It is not agile
• Not failing as early as we could
• It’s process over people
It does not result in high quality
• Requirements not fully tested (as tester doesn’t know them 100%)
• Missing features (as dev doesn’t know the full context)
Why is this so bad (just because it isn’t
“Scrum”)?

11. How did this happen?
Tester
• Fill the time with testing
• Reluctance to change, e.g. automation to speed up tests
“Developer” (coder)
• “dev complete” – move on to something else and rely on QA to find bugs
• Reluctance to fully understand the problem being solved; TA does that
Defined roles

12. Aside: What is the definition of a developer?
Q: What is the optimum number of lines of code for a given requirement?
A: None. Code is liability, not a legacy…
Developer as a problem solver:
• Determine requirements from PO
• Design, code, write and run tests
• Release
• Monitor success
• Take complete responsibility that requirement has
been met

13. Aside: What testing trends are we seeing?
• “Dev-in-test” – coding skills required; frameworks (Jasmine, Geb/Spock),
languages (Ruby), etc.
• Frameworks with more testing built in; Angular, rails, etc.
• Is there really a difference between a “dev” and a “dev-in-test”; are they not
(or could easily be) the same skillset?
Tester as a problem solver:
• Determine requirements from PO
• Design, code, write and run tests
• Release
• Monitor success
• Take complete responsibility that requirement has
been met

14. Aside: How do Google test?
• Just read the last chapter
• We can deploy extremely rapidly, so why not just
release quickly, and rapidly fix any bugs?
• Benefits:
• Less costly QA – not testing features that nobody uses
• Not wasting time fixing bugs that nobody will ever find
• More rapid feedback on new features
• Delivering actual customer value quicker

15. How did this happen? Defined roles
Cementation/entrenchment
• Process (“there must be a testing phase”) - stops potential process improvement
• Recruitment - we need (have budget for) a new “tester”

16. Big Releases
• Test release, not feature or story
Separate test stories
• Some genuine (3rd party app) → legitimise all
No slack in sprints
• No encouragement/time to cross-skill/cross-task
How did this happen?

17. Big Releases?
It takes ages to do a
manual regression test
This is expensive, so
we need to limit how
often we do it
We’d best cram as
much stuff into each
release as we can

18. “Real” Product
Owner
Proxy Product
Owner
Devs
Product Owner
Scrum Master
Devs
Are there other “mini-waterfalls”?

19. Hang on! Scrum Master?
• Does all those things that devs don’t want to do – meetings,
change requests, release notes, …
• Scrum Master removes impediments – that’s their job, right?
• Protects the devs from all that nasty outside interference

20. Hang on! Scrum Master?
The Real
World
Scrum
Master
Devs

21. Hang on! Scrum Master?
• Same problems as before…
• Silo – what if Scrum Master is away
• Devs do not have full understanding of context
• Things fall through the cracks
• Devs just code...
• Lack of full team responsibility
• etc......

22. One final “mini-waterfall”?
Scrum Master
Devs
Scrum Master
Devs

23. One final “mini-waterfall”?
Devs
Devs
Scrum Master
Scrum Master

24. Beware of
waterfalls:
They are
everywhere

25. Solutions/Ideas?
Automate
Everything
Have Constant
Peer Review
Do Pair
Programming
Have Fun
Fridays
Use Mob
Programming
Do Mob
Analysis
Have Small
Releases
Only Have
Feature Cards
Empower the
Team
Have the
Team Remove
Impediments
Team Success
and Failure
Use Slack –
Improve
Communicatio
n
Don’t Recruit
to Roles
Do
Boomerangs
Encourage
Failure

26. Solutions?

27. Q&A
Do you have these, or similar issues in your team?
Are there any other waterfalls?
Did you use to have them, but have solved/are
solving them?
Do you not even agree it’s a problem?