From Waterfall to BDD: An Agile Journey

A step by step guid on reducing feedback loops from years/month to days or potentially even hours, in sustainable way. Even had that feeling that agile is just a fancy word and it doesn't deliver the promised rewards? See here how you can change that.

Transcript

1. From Waterfall to DDD An Agile Journey
8. Where does agile come into it?
9. Reduce noise to signal ratio
10. Reduce noise to signal ratio
11. Benefits of noise to signal ratio improving • Make communication more clear • Reduce “Chinese Whispers” effect • Reduces amount of mis-delivery because the message is more clear
12. Shorten feedback loops Years
13. Shorten feedback loops Years Days Years
14. Benefits of shortened feedback loops • Teams can quickly learn about changes of direction • Teams can react faster to user/stakeholders feedback • Teams can be made aware of mistakes earlier in the process • Smaller amounts of code to change when reacting to the previous points
15. Shortening feedback loops
16. Months or years
17. Introduce the BDD loop
18. Refactor
19. We’ll look more into it later in this talk
20. It reduces the feedback loop between the program and the developer * * We’ll see later how it can help reducing the loop for the whole team
21. Introduce Sprints
22. By itself, in isolation, can reduce this loop to weeks
23. Introduce functional Demos
24. The loop can now be reduced to weeks for a broader part of the system
25. Introduce delivery of sprint in bulk
26. The loop can now be reduced to weeks for the whole system
27. Introduce deliver of feature when ready
28. The loop can now be reduced to few weeks or even days
29. Relatively short but unpredictable delivery throughput
30. What’s the next step then?
31. Improve predictability
32. Improve predictability and shorten delivery time
33. Improve predictability and shorten delivery time in a sustainable way
34. We’re now stretching the limits of scrum
35. Kanban
36. Kanban - Continuous Delivery
37. Replace sprint with a prioritised backlog
38. Deliver slices
39. Deliver shallow slices
40. We can do this by breaking our features into small deliverables instead of focusing on technical tasks
41. Shallow slices • Allows for quicker delivery of less complete features • Allows for stakeholders to identify when no more development is needed, because a partial feature turned out to be enough • Allows for quick feedback even before all of the polishing is in place
42. Introduce WIP limits
43. WIP Limits • Reduces number of items in flight • Reduce context shifting • Allows for focusing on delivery
44. Kanban Board
45. Board • One way only pipeline (items move only in the direction of delivery) • Visualise WIP limits, blockers and relationship between each step • Right to left board walking, more delivery focused than stand-ups
46. Cut on time spent in things that might not happen
47. Save time • JIT story clarification saves times looking at things far in the future that might end up not being needed (Ex: the often misunderstood “three amigos”) • Delivering shallow slices allow to eventually have a good enough feature and stop development early
48. If your product is not in production, make a barebones MVP as soon as possible
49. Quick MVP • Allows you to start getting full cycle feedback to your product • Allows you to start delivering the new features with a short feedback loop • Helps preventing “code rot”
50. Reducing noise to signal ratio
51. Change of culture
52. Proxy
53. Facilitator
54. Facilitator
55. But now we need to make good use of this open channel
56. Common problems with business/production communication: • Developers talk about technical matters causing stakeholders to lose interest • Stakeholders feel like this is not a good use of their time and become unavailable
57. We need a framework to help this communication
58. Behaviour Driven Development
59. BDD • Story level BDD (works at acceptance level) • Spec level BDD (sometimes called TDD, works at unit level)
60. Refactor
61. Benefits of the BDD loop • Quick feedback to the developer about bugs or defects, as it can show them even before the feature is finished • Provides a connection with the value they are delivering and allows that value to drive their code • Forces a conversation with the stakeholders
62. Using Story Level BDD to facilitate conversation
63. Find out who cares about this feature
64. Identify the reason why you’re doing this (value)
65. Always highlight the value
66. In order to <achieve some value> As <some stakeholder> I want to <do something that enables the value>
67. Given <some state of the world> When <some input happens> Then <some outcome follows>
68. Use the same language the people asking for the feature use to describe it
69. Benefits of focusing on value • The reason why something is being built is identified, so we can better understand if we’re moving in the right direction while still developing the feature • Empathy with the stakeholders via understanding what they care about • Brings the language that describes the problem into the application development
70. You don’t need to write gherkin during the conversation, instead use it to guide your questions, learn the expected value and outcomes.
71. Why stop here?
72. We have a communication line from business to production
73. Why not having a communication line from business to the program?
74. Domain Driven Development
75. We already have a description using the domain language, why not use it to drive development?
76. Mirror the language in the BDD scenarios implementation
77. Mirror the language in the BDD specs and let those specs drive the code
78. Code mirrors the language of people
79. Describe the solution in the language of the problem
80. Different stakeholders might have different models of the same part of the system
81. Bounded Contexts
82. Benefits of focusing on DDD • Ubiquotous language • Solutions becomes a description of the problem. This lowers the entry barrier to understand the existing solution, as knowing the problem is enough to understand the solution without having to know of previous arbitrary decisions • Solution becomes more malleable as it closely mirrors what it is trying to solve, and is therefore more able to change with it.
83. This talk touched the surface of a lot of different deep topics. A lot was left unsaid or was described in an overly simplistic way. If you want to discuss further any of the subjects mentioned here, I’d be happy to, just come find me around the office
84. Questions?