I have noticed some Scrum teams approaching the work of a Sprint\/iteration as a “mini-waterfall”.\u00a0 The work is thought of as having a progression just like a typical waterfall:<\/p>\n
requirements gathering- -> analysis- -> design- -> coding- -> testing- -> promotion to staging… etc.<\/p>\n
or something like that, but instead of spanning a year or so, it is applied to the work of a single 2 week iteration.\u00a0<\/p>\n
Dividing Work up by role seems logical<\/em><\/strong> But there are problems<\/em><\/strong> When a well formed and performing team works together to\u00a0 investigate, discuss, and work through a problem together they will have a better chance of uncovering a great solution than if they work separately, communicating only through documents and “meetings”.\u00a0 It’s my observation that working separately and only periodically coming together as a team makes it hard to benefit from the synergy of a co-located and closely working team.\u00a0\u00a0 When all the minds of the team are focusing on the same thing at the same time, and are communicating openly and without fear, the progress of the team is enhanced.\u00a0 It can be argued that thinking is a very private thing, and that the distraction of working closely with others can hamper our own ability to “work through our thoughts”, and I’ll be the first to agree.\u00a0 So I am not suggesting that we work exclusively as a team – we need both time to ourselves as well as time with our team members.\u00a0\u00a0 But I am suggesting that we must make a concentrated effort to do as much work as possible in collaboration with our team.<\/p>\n Using a mini-waterfall can lead to an Agile backslide<\/em><\/strong> There are other ways to work, but it is hard to get some people to even consider them<\/em><\/strong> Let\u2019s look at a very limited example that involves 3 people:\u00a0 Mary – the coder, Wilbur – the tester, and Arty – the “product owner” or customer proxy.\u00a0 We have a story with coding tasks and testing tasks.\u00a0 The code involves adding behavior to a business object, and the tests will be done with FIT or some similar tool.\u00a0 It would be helpful for the coder (Mary) to know what the UA or system tests are going to be since the UA\/System\/Story tests define how we are going to know that the code works \u2013 these tests are being the definition of the new functionality being added.\u00a0\u00a0 On the other hand, it would be helpful for the tester (Wilbur) to know what services the code is going to make available and the signatures of that code so he can write his tests.\u00a0 And both Mary and Wilbur need information and direction from the customer (Arty).<\/p>\n So, in the mini-waterfall it could look like this (or some variation):<\/p>\n Arty documents requirements -> Mary codes the functionality -> Wilbur tests the functionality<\/p>\n In a more collaborative approach we would have:<\/p>\n Arty, Mary, and Wilbur discuss and write tests that define the functionality -> Mary and Wilbur work together to code the functionality, continuously running the story tests and checking with Arty along the way whenever they have a question.\u00a0<\/p>\n At any time during the day they could be exploring ideas either in code, in tests, or in discussion and white-boarding.\u00a0 Of course, this is just a very simple example.\u00a0 In real life it is possible that much of the coding will be very complex and won\u2019t require any involvement from Wilbur.\u00a0 During that part of the work, Mary would be pairing up with another developer and Wilbur will be refining and expanding on the tests previously created.\u00a0 Still, throughout the process Mary and Wilbur will be in close contact and consulting with each other continuously as any questions come up.\u00a0 The understanding by the team of the problem and the solution grows together.<\/p>\n The end goal is to find better solutions by everyone working as closely together as possible with a focus on one or two stories at a time if possible, and cross-pollinating continuously.\u00a0\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":" I have noticed some Scrum teams approaching the work of a Sprint or iteration as a \u201cmini-waterfall\u201d. The work is thought of as having a progression just like a typical waterfall: requirements gathering -> analysis -> design -> coding -> testing -> promotion to staging\u2026 or something like that, but instead of spanning a year or so, it is applied to the work of a single 2 week iteration.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,20,4],"tags":[],"class_list":["post-10","post","type-post","status-publish","format-standard","hentry","category-agile-stuff","category-boring-story","category-waterfall"],"_links":{"self":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/10","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/comments?post=10"}],"version-history":[{"count":6,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/10\/revisions"}],"predecessor-version":[{"id":277,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/10\/revisions\/277"}],"wp:attachment":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/media?parent=10"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/categories?post=10"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/tags?post=10"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nAnd of course, the work is divided among the team member\u00a0to the person who fits the role of the phase – a business analyst doing the requirements & analysis, an architect doing the design, and etc.\u00a0\u00a0\u00a0 This model isn’t unusual\u00a0– I’ve seen it used with IID (iterative and incremental development) and Spiral methodologies.\u00a0 I guess old habits are hard to break, and a lot of\u00a0folks have gotten very comfortable thinking and working in this way.\u00a0 Maybe it seems like the most logical, reasonable,\u00a0 and direct way to think about things.\u00a0 But there are problems with this, and they are similar to the\u00a0problems\u00a0with the traditional waterfall.\u00a0<\/p>\n
\nOne problem is that this disregards the value we gain from the collective genius of a team working in a collaborative manner.\u00a0\u00a0 In the Mini-Waterfall we gather a team of bright and capable people, and then divide up the work in such a way that there is very little chance for effective collaboration.\u00a0 Granted, if we are working in an Agile environment with a co-located team we have a good chance of\u00a0overcoming\u00a0some of the problems with the traditional Waterfall, but we are still missing out on some of the most valuable benefits for Agility.\u00a0<\/p>\n
\nAnother common issue of a mini-waterfall is\u00a0that workers “down the waterfall” are waiting on the deliverable of another team member up-stream.\u00a0\u00a0 To keep everyone busy and productive starts to smell like micro-managing.\u00a0 People start thinking that its reasonable to have Sprints overlap, with testers working into the next Sprint to finish up the work of the previous Sprint so that coders can start in on new work and the testers aren’t idle during the beginning of the Sprint (or vice versa depending on how you approach testing).\u00a0\u00a0 I have seen this proposed and used in a few cases without good results.<\/p>\n
\nI don’t see the work of the individual team members as being “solo” work.\u00a0 Almost any task a team member is going to tackle can be done as a team, or with two or more people working together – and ideally with the whole team involved in some way or another.\u00a0<\/p>\n