Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Our team is going to adopt scrum and agile technics. We've got a product, which we develop for multiple customers. This customers supplied us with necessary requirements, so everithing is fine to adopt agile techinics.

But at some moment (for example during sprint), new customer apears, and he wants to get a demo of product slightly different from what we have now. This may be some new features or minor differences in behavior. And he wants to get this demo for example during the week. It is very important to show that our product supports this features (because otherwise he will address to our competitors), so we have to develop this features (may be partly) during the week.

How we must handle this sort of features with agile? Move them to current sprint backlog? Or split one team to two and create another sprint? Or may be there is another way?

share|improve this question
add comment

3 Answers

up vote 10 down vote accepted

If you are doing scrum, you should have a Product Owner, no? It's his or her job to prioritize the stuff that comes along and manage the relationship with the customers. That said, the product owner should not be adding items to a sprint unless the team agrees to it and that there are items that have not been started yet and can be pushed out of the sprint to compensate.

If the new customer results in a second product owner, that makes for a second project. In that case you should form a second team and create a prioritized backlog for the new project.

If you are running into a lot of this, you might look at kanban as an alternative to scrum.

share|improve this answer
    
+1 for "if there are one or two product owners" and the kanban alternative –  k3b Jan 6 '13 at 9:19
    
Every customer is independent product owner. Usually we have 3-4 customers at the same time. Our team is about 6-7 developers so we can't split them in 4 teams. By now we just do most urgent features first. And if new customer demo is required, part of the team begins preparing to it and then turn back to planned features. –  andrey Jan 6 '13 at 9:24
    
+1 for you might look at kanban as an alternative to scrum, scrum isn't a good fit for every business, if pre-sales work requires you to re-prioritize at short notice, maybe it isn't a good fit for you. –  Carson63000 Jan 7 '13 at 1:49
    
second product owner - I was under the impression the number of product owners should correspond to the number of products, not to the number of customers. Of course, if you create a second branch of your product (perhaps a "demo" branch), and treat it completely as a separate product and work at this branch with a separated team, then two product owners make sense, but isn't this causing way too much organizational overhead for this kind of "1 week" situation, just for the sake of sticking formally to the Scrum method? –  Doc Brown Jan 7 '13 at 9:18
add comment

No customer worth having wants less than a week worth of programming.

Show them what you can do, and say you can modify it to do what they want once they sign the deal. Then schedule it for some future sprint and get it done.

share|improve this answer
    
This may be not a week but day or two. Ignoring his needs we may lose him, because competitors will have this features. And we can't afford lossing him, because every new customer is valuable –  andrey Jan 5 '13 at 22:20
7  
@andrey - if you're losing customers to competitors with a day or two's worth of features why are you not spending your sprint implementing those features? If you're not working on them, then whatever features you are working on will gain you more/better customers. Trust your prioritization. Juggling things is wasteful overhead. –  Telastyn Jan 5 '13 at 22:30
    
This is what overtime is for. Knock up a prototype, make sure your manager (at the very least) knows you're going beyond the call of duty. If it happens often allocate some time in your sprint for this eventuality. –  James Jan 6 '13 at 3:54
    
-1, this answer means "stick to the formal agile method whatever comes". I am pretty sure this is not what the "agile inventors" had in mind. And the other misconception here is that the worth of a feature for a customer is directly related to the programming effort. –  Doc Brown Jan 6 '13 at 9:22
1  
this smells suspiciously like Sales or Marketing trying to tell Engineering how to do their job - it could be argued that your answer is Engineering trying to tell Sales and Marketing how to do their job –  Carson63000 Jan 7 '13 at 1:50
show 3 more comments

There are times when the marketing promise a potential customer having a feature that is not implemented yet :-(

From mangement point of view the "new feature or customer will not buy" is similar to a "critical production bug that must be fixed and deliverd as soon as possible" .

For this emergency situation i suggest

  • stop the sprint and
  • stop working on the current development-branch and
  • create a new emergencybranch that originates from the last released-stable-fulltested-production-branch and
  • fix the bug (or in your case create the "new customer" feature)
  • do the testes, deployment, create patches,... (for bugfix only)
  • if every thing works ok this bugfix/feature is merged into the stopped development branch and the sprint is either resumed or canceld_with_new_sprint_planning.

Your management should be aware this workflow is costly and should only be used in real emergency situations.

share|improve this answer
    
+1 for the comparison to "critical production bug" –  Doc Brown Jan 6 '13 at 9:27
    
+1 for essentially suggesting that this is a "drop everything, all hands on deck to resolve" situation. Both because it rarely really is such a situation, and because treating it like one will make the product owner understand the impact it has. –  Ross Patterson Jan 6 '13 at 13:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.