Reminds me the desperate need of our suppliers to "get something signed off" to charge us.... but "that something" often stoppwd working when another feature was released....or another sprint. The integration testing showed it many times...and we ended up in a total mess of crazy backlog. THAN everything really bacame an urgent priority...
Although I agree with the title your suggestion sounds like making mini-waterfall even smaller, a micro-waterfall. I think continues delivery and testing are key concepts which has to integrated in a sprint.
@@OsorioAgustin Which is exactly the same advantage as the one gained to moving to the mini waterfalls instead of the large waterfall. All good but the huge advantage comes with automated testing and the developers should write the majority of those automated tests and do that as they develop the basic code. If a team can get that behavior in place things start to fly.
Yes but actually no. Think of the V-model folded into an "I" as you don't really assign barriers to certain activities. For example QA people could be involved in operations, concepts, design, etc. you don't need to implement the whole feature in order check the integration or the data validation. Development phases are not strictly linked to each other.
Agree, when the whole team embraces owning quality and developers use TDD it will help, however developers still need to learn to break work down into smaller increments. Otherwise you could still have all the developers working in silos for 10 days of the Sprint and not have anything "Done Done" until the end.
@@davidhawks2457 Agreed with not being able to having things done until the last 1-2 days of the Sprint. Unfortunately the team setup shown above, i.e. developers + testers (even when you split up the dev work into frontend and backend), is a common one you will encounter in most projects (not products) development, more specially in consulting industry. The above scenario is a recurring issue I personally have always faced in consulting, so in short one of the key questions would be: how to mitigate interdependency between the dev team members, right? Because that's what you have eventually; you are actually facing dependencies within the dev team (as a whole), because testing cannot commnece until development has finished (classic waterfall side effect). Unfortunately, for fixed price projects, where you as a vendor have to deliver certain scope by a deadline, you cannot always count on mitigating options such as TDD, automation testing, or even pair programming (although I question how efficient the latter can be if not properly prepped and executed). On the other hand, by breaking the stories down into smaller ones, you are indeed reducing the risk but not mitigating it. Testers will still have to wait until development gets done. Yes, you will get things done earlier, which should actually be one of your goals (I like this idea as long as it is feasible), and therefore the burndown chart will look better, and you will have better delivery predictability. Anyways, just wanted to share some thoughts as a Scrum Master. :-)
