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.
A team that asks what's wrong with developing for a sprint and then testing in the following sprint hasn't grasped an essential truth: the goal is not to code, or to test, it's to deliver business value in the form of working software at the end of every sprint.
ReplyDeleteI would also challenge the assertion that "It's not very efficient for dev to write code and test it at the same time." Why isn't it? Why isn't it more efficient to write code once, and deliver it knowing that it has passed a series of automated tests? Is the alternative of writing code and throwing it over the fence to a test group, and then writing more code only to be dragged back into fixing the bugs that the test group has found more efficient? How can constantly jumping between different areas to fix bugs be more efficient? And what about the impact on the consumers of the buggy code? How efficient are they going to be when they're struggling to get their code working and not knowing if it's their bugs or your bugs that is keeping them from finishing? Yes, if the goal is simply to sit at the keyboard and produce lines of code, it is more efficient to do it without stopping. But is that our goal? Or, to reiterate, is delivering working software our goal? If it is (and, yes, it is), then overlapping testing with coding is much more efficient than "coding and throwing."
Ron, your example of Scrum-But is classic, a reflection of the saying "Scrum is simple, but not easy." As you point out, doing it right takes discipline. But really, is there a viable alternative?