Scrum is simple. It has 11 elements. 5 Events, 3 Roles and 3 Artifacts. But even though Scrum is simple, it is hard. Hard to do right. Daily scrum’s only on Tuesdays? A Sprint Demo? The team asking for approval from their Product Owner at Sprint Review… These are only a few of the ways scrum can get corrupted. Let’s scan out collective Scrum hard dive and run chkdks /f on it to get rid of some of the bad sectors, rebuild some of the indexes and resolve the lost files.

2. Jesse Houwing
Lead Consultant Xpirit
@jessehouwing
#TECHDAYSNL #PROSCRUMDEV
Jesse Houwing
Lead Consultant Xpirit
@jessehouwing

3. Scrum trainer at Xpirit

7. Scrum says… ?

8. Or when is Scrum bad?

9. Velocity your primary
measure of progress?

10. Looking good at a glance?

11. Direction is needed

12. If you measure anything
Measure happiness

14. My tool is better than yours

15. It encourages you to use what works for you…

16. Working software and
#NoDocumentation?

17. Because, come on who reads
all this stuff?

18. Ever tried assembling Lego
or Ikea without a manual?

19. Executable Specifications…

21. Approve or blame?

22. git push origin -f

23. Continuous Delivery!
and of course integration

24. Only show accepted work, in a releasable state.

25. Cross functional individual
Everyone can do everything

26. Cross functional team
The team has every skill in order to reach its goal

29. The team must have all the skills to create a product increment

30. Commitment

31. Forecast

32. people commit to achieving the goals of the Scrum Team

33. Too many meeting
Not enough time…C

35. A maximum of 25%

36. 34 hours in events
About a day per week

38. Are your reviews effective?

39. minimize the need for meeting not defined in Scrum
end whenever the purpose of the event is achieved
do not allow waste in the process

41. Done
Done Done! Done Done Done! London?

42. Sometimes manifested as:
The perpetual MVP

43. Or manifested as:
The twinkling pixel…

44. everyone must understand what “Done” means
a product owner may choose to immediately release the increment

45. Definition of Ready
Yet another stage gate?

46. Up to specs?

47. Items that can be “Done” by the development team within one sprint are deemed “Ready”

48. To support more teams?
That includes all the Orcs and Goblins

49. One PO to rule them all
That includes all the Orcs and Goblins

50. Product Owner is the sole person responsible for managing the Product Backlog
the Product Owner is one person, not a committee, but may represent one
the entire organization must respect his or her decisions.

52. Not much. Except to be ready and to embrace change when needed

53. Dealing with unplanned work

54. All work comes in through the Product Backlog (though some work faster than others)
Ideally no work interrupts the sprint. If it does the team should inspect and adapt to prevent reoccurrence

55. The most prickly one
Really large scrum teams or multiple scrum teams

56. It only adds more confusion

57. As products / projects / releases scale
Teams, the way they work and the product change

58. Architecture changes

59. The two pizza team
or was it the two team pizza

60. You’ll need to formalize
It can’t be one big party

61. The optimal Development Team size is small enough to remain nimble
Yet large enough to complete significant work.
Large teams generate too much complexity for an empirical process to manage

62. Scaling is hard
Lots of good practices, but you need to make it work for you

63. Is Scrum the ultimate
Process Compressor?

64. Not much… Only to use empiricism to improve

65. It gives you a mirror

66. And by working hard to improve

67. You may come to like what you see

68. Next steps…
Stay calm and Scrum on.

69. Scrum trainer at Xpirit

70. Jesse Houwing
Lead Consultant Xpirit
jhouwing@xpirit.com
@jessehouwing
#TECHDAYSNL #PROSCRUMDEV
bit.ly/XpiritMagazine
Jesse Houwing
Lead Consultant Xpirit
jhouwing@xpirit.com
@jessehouwing