SCRUM: Get Your Requirements Straight Before Coding
Here are some comments on requirements needs for a SCRUM motivated by postings in the firstname.lastname@example.org list. Here I am talking about product companies. There are parallels for IS internal development.
The SCRUM's that I work with deal with changes to the requirements during the sprint iteration. The product manager is part of the SCRUM for this reason. The development SCRUM does not define initial requirements unless they are a product marketing SCRUM.
We have always started a development SCRUM with some working code. Thus a SCRUM is designed to improve a codebase. The functional specification provided by marketing should be based on running prototypes shown to customers or potential customers who agree that is what they want for the next release. It may be one sprint or several to get to the release.
My current customers are physicians and they don't have time to meet in the daily SCRUMs, so product marketing physicians have to be their surrogates. Physicians have taught me that a product WILL NOT BE USED, unless it carefully meets their workflow, is extremely responsive, and can be customized quickly whenever it has shortcomings. Since failure is immediate by physician refusal to use the product for more than a few days, it must be close to right the first time and fixed within a month, or you fail and have to go find another customer.
This tight discipline required by the physician environment has made me realize that all projects should be run with this discipline. If they are not, failure may take longer, but the system ultimately does not sell well or get used well. So I think my comments are relevant in other environments. You won't win big unless you do this.
In addition, if product marketing is not clear about customer (or market) needs, neither is senior management. If senior management is not behind a project, priorities will get confused. This will sap focus and resources from the SCRUM and reduce probability of success.
If product marketing can't function, development has to do it. They will not do it as well and they should not treat it as cutting code. They must get out of the office, do market research, and get into the customers offices unless they can bring the customer to them. They must do sales support and be there when the customer is buying or not buying and understand why or why not. They must give up their development job long enough to define the use cases, get a user interface the customers love, and clarify the customer workflow and business logic. When that is done, they can think about coding the product.
In a greenfield project without existing code, I have seen a development SCRUM work on a prototype for a week and define it as their code base.
The task then is to refine the code base to better meet customer need. If that is not clear, the programmers should not write a line of code. Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won't be needed. If they write code that ultimately is not used, I will be paying for that code for the life of the system, which is typically longer than my professional life. If they went surfing, they would have fun, and I would have a less expensive system and fewer headaches to maintain.
When the customer need is clear you write the minimal lines of code to meet the defined need. This is the XP view and should be the SCRUM view.
That said, product marketing should be run as a SCRUM. I once led a senior management team (CEO, EVP, SVPs, and Product Marketing Directors) as a product marketing SCRUM. With one lunch meeting a week they made more product changes and inovations in 6 months than they had made in the five previous years.
This topic probably requires a book, rather than a note. So keep the comments coming.