There are many possible failings that can occur when transitioning between Waterfall SDLC and Agile. You can skip daily stand ups, let a single sprint iteration go for months, don’t use a daily burn down, let the scrum master assign work, have talking chickens, or skip sprint planning. Any one or more of these makes your process begin to smell (Mike Cohn: http://www.mountaingoatsoftware.com/system/article/file/11/ScrumSmells.pdf). One particular agile principle that I see questioned often is why does all of the testing have to be done in this sprint; why can’t we do dev one sprint and do testing the next. It’s not very efficient for dev to write code and test it at the same time.
These are all trappings of ScrumBut; looks like scrum, feels like scrum, but definitely doesn’t smell like scrum; in fact it smells very bad indeed. One of the key principles of scrum that shouldn’t be discarded is creating complete work within an iteration. If your organization has a history of constantly changing priorities, half finished work, and low team morale I would strongly urge you to focus on the principle of finishing your work during a sprint.
As software development professionals we should count on changing priorities, it’s the nature of business to reflect and adjust to meet the constantly changing needs of the marketplace and to effectively compete in today’s global market. Half finished work is work that has high potential to be thrown away because it can’t offer immediate value. Team morale suffers when hard work isn’t recognized by shipping to customers. In general this is something that we want to avoid whenever possible.
Going back to the question of why can’t we do dev in this sprint and test in the next; what happens when the CEO (or other senior manager) decides that you should immediately begin work on the “next” thing that will make an impact on the market. Testing a half finished product feature probably doesn’t qualify as a high priority and risks being tossed.
Teams that find themselves in this situation are kidding themselves if they think they can predict the future. As a Scrum Master I often find it difficult enough to ensure discipline to the current sprint without asking that we hold an additional sprint to finish what we started. When agile is proposed to management it’s pitched as being complete within a single sprint (narrow feature scope, complete work). If we remove this benefit from management we should expect them to question other areas the team finds beneficial (self organizing, trust, committed).
Let’s be disciplined to completing the work, don’t drag along technical debt and deliver high quality products to market faster. Yes, it’s a little more coordination effort on the part of the team but it’s also something that needs to be done to deliver on the value of agile.
