Finish 2 Finish Approach in Agile

Finish 2 Finish Approach

Don't run a relay!!

A dangerous path that new Scrum Teams need to avoid is a Start to Finish approach. What this means is the Scrum Team spends the first Sprint doing Analysis and Requirements gathering, then the next Sprint it does Architecture and Design of the System, then in the third Sprint they build APIs and build basic architectural components, and in the next they start actual development and in the next Sprint they test, we can clearly see which way this is going.

Another equally dangerous path is including analysis, design, API building etc, feature coding, testing all in one Sprint (which is correct) but waiting for one activity to end before the next can start. This again is a Start to Finish approach. Both these paths can be categorized as "Activity Specific Sprints" where activities happen in sequence and a hand off takes place after one activity finished so that the team can move on to the next activity, with no overlap taking place during this whole process.

Lastly, another way of implementing Start to Finish is by making User Stories which just deal with one activity like just Coding, or just Testing. All these approaches should be avoided as much as possible if your goal is to be agile.

So how can we avoid this?

An agile way of going about this is taking a finish to finish approach. What would be more important is not when tasks or activities start but when they finish. So coding cannot finish until analysis finishes, and testing cannot finish until coding finishes and so on. In this approach the team overlaps activities and swarms through the stories cross functional rather than taking 'hand off' approach. This is known as a Finish to Finish approach.

Teams that take the Finish to finish approach correctly are able to see how to overlap some activities and create finish to finish relationships between them. Teams find ways to overlap discussions of what User requirements and Coding, and thye also find ways to overlap programming and testing. So how do they do this? By lending themselves to iterative and incremental approaches while dealing with activities. For eg. We do a white board and analysis session, and overlap it with initial testing by creating a test plan, we overlap design and analysis by creating some quick mocks, we check with users if they like it, then we code a little to make features work a little, and test just what is built, then we do an initial UAT, then we code and design some more and finalize the product by finally testing everything.

A quote by Mike Cohn which I strongly stand by 'User experience design, database design, and architecture are often cited as work that needs to be done up front because the work must be viewed holistically. I argue that we should think holistically but work iteratively toward solutions. All sprint activities can and should overlap.'

Reference: Mike Cohn from mountaingoatsoftware.com