The Land that Scrum Forgot

by Robert C. Martin (45min)

#Notes

Talk starts at 03:25.

05:55 Before the 2000s the world was dominated by waterfall.

06:08 In 1995 Ken Schwaber published a paper about Scrum.

06:19 In 1999 the industry started paying attention to Kent Beck’s Extreme Programming.

Kent’s vision was to heal the divide between business and development.

— Robert 07:24

07:46 He thought with the right disciplines and minimum process trust could develop between developers and business.

08:30 Robert also wanted a process that is controlled and designed by developers for developers and businesses. One that focuses on business value, but also on code quality. The things that mean the most to both factions. A process that fosters communication between development and business.

09:02 Kent and Robert gave classes about Extreme programming until 2001.

10:38 In 2000 Kent organized a meeting of XP leaders. Some of them were also leaders of the Design Patterns movement.

11:40 Martin Fowler and Robert wanted to create an organization for this movement. They invited people to a Lightweight process summit. Ken Schwaber and other thought leaders came and together they coined the term agile.

14:02 Ward Cunningham wanted to come up with a few statements that don’t disparage the old way of working, but that they value other things more. The Agile Manifesto was born in that meeting.

16:00 They formed an organization called the Agile Alliance.

16:30 When Ken Schwaber was the chairman a year later he wanted the Agile Alliance to generate revenue.

18:00 The Agile Conference was born by joining the XP Universe conference and the one by the Agile Alliance.

18:18 Ken started running classes to become a “Certified Scrum Master”.

19:34 Only project managers took these courses, no developers.

20:22 The Scrum master courses had the positive effect of legitimizing agile. Without this course it would not be as popular as it is today.

A Scrum master was a coach, explicitly not a manager. He/she was responsible for defending the process, not the schedule, budget, stories or backlog. The role was supposed to rotate through the various team members. The idea of the role was to slowly fade away, so that in the end you would not need a Scrum master.

— Robert 21:04

21:57 Project managers who took the courses probably didn’t like that. They wanted to be Scrum masters.

22:20 Businesses got the idea that the critical element in making a Scrum team successful was to pick the right Scrum master. (similar to project manager) That was never supposed to be the way.

23:10 It worsened the separation between business and development.

23:29 Scrum or any agile method makes you go fast at first.

24:30 In the “Certified Scrum master” course software development practices were not taught. Everything from Extreme programming was missing.

25:00 When you go fast, you need something that keeps the code from rotting.

26:30 Scrum without technical practices becomes a tractor pull. Every sprint gets harder to make progress, because the code is getting worse.

27:16 Scrum masters started a developers vs project managers attitude talking about different project management techniques without development techniques. The developers that had spawned the process felt left out.

28:20 Kent’s vision had failed. The divide between business and development had reopened.

28:57 Pressure builts on top of the developers when a Scrum team begins to slow down.

30:00 The Scrum master is not baring this guilt.

30:28 The team might go back to waterfall because of this. At least in waterfall they have these long periods of time where they could rest.

What Scrum forgot is that you can not have speed without (technical) quality. The more technical debt you carry the slower you go.

— Robert 30:46

31:30 Because of this the Software Craftmanship movement and manifesto was born. This is an evidence of the split though.

32:16 They hope for a reawakening of Kent’s vision.

34:16 If agile is going to survive it has to remember its roots. It was a set of technical practices conjoined with a set of management practices. You could not separate them and yet it was done.

Manual testing is immoral. It is not just dumb. It is immoral because you are taking people and making them act like machines.

— Robert 36:50

39:04 Manual tests are also wrong from a business point of view, because they inevitably will be killed when they increase in size.

40:00 One should not test the system thought the UI. You decouple the user interface from the business rules and test them separately. When you run your tests thought the UI you can’t change your UI anymore.

44:10 One should write a series of tests for each component separated from the UI. Then write a few tests for the assembly of some components to test if they are wired up correctly. In the end wire up the whole system together and write very few tests to make sure the wiring is correct.