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.

Like most modern developers I value Agile principals like customer collaboration and responding to change, but what happens when a product-owner (or whoever determines requirements and priorities) changes requirements and priorities too often? Like several times a day?

I recently inherited a smallish code base that was buggy, incomplete, and couldn't even handle the simplest scenario it was supposed to. I can deal with the technical issues but I get several emails, texts, or phone calls a day saying "OMG you MUST work on this RIGHT NOW! TOP PRIORITY! This is a MUST!!!oneone" (that's only a slight exaggeration) What makes it even worse is that most of the things are minor details that aren't even relevant to what the software is actually supposed to do and would take days to implement anyway. I've tried explaining that there's only so much time and that we should focus on the most important things first, but something seems to get lost in translation because the same thing happens a day or two later.

Is there some sort of Product-Owner-Handler role, in-depth study, metaphor, or quote that can help me reduce the amount of wasted effort or at least explain the costs of this chaotic behavior?

share|improve this question
    
Is your team following some sort of agile methodology? –  Aaron Kurtzhals Aug 15 '12 at 0:26
    
I'd say that we're agile-like, but don't follow a specific agile methodology other than what the tools (PivotalTracker, Jenkins, etc) impose or support. –  Trystan Spangler Aug 15 '12 at 0:49
    
You say agile-like, I'd say agile-but ;) –  Marcin Sanecki Aug 15 '12 at 6:55
add comment

7 Answers

up vote 12 down vote accepted

This is what the backlog is for. New requests get put on the backlog, and priorities can only change on iteration boundaries. An average of one week delay (half of a two-week sprint) is plenty agile enough to handle all but the most dire emergencies.

share|improve this answer
5  
+1 for what is the one and only correct answer. How do you say it - "Once an iteration has started, you cannot change it." What part of 'CANNOT' do you not understand? –  mattnz Aug 14 '12 at 5:17
    
+1 to the answer and to mattnz's comment ("What part of 'CANNOT' do you not understand?"): I had a similar problem: three week iteration and during the third week a colleague starts to be extremely creative and to change / move things around. Agile means a lot of flexibility but there are some lower boundaries to it: after you have fixed some minimum units of work you should focus on them without being distracted. –  Giorgio Aug 14 '12 at 5:39
    
I agree that this is what the backlog is for, however, you are allowed to drop items from an iteration, or even swap them for items of equal effort, as long as you have not begun work on the dropped/swapped items yet. –  Joshua Drake Aug 14 '12 at 13:52
    
I agree that the team should be able to choose to allow mid-sprint changes or not. Too many externally-imposed changes are disruptive, whether you've started on it or not. It's up to individual teams to decide how much is "too many." Sometimes you have to set that number at zero in order for people to get the picture. –  Karl Bielefeldt Aug 14 '12 at 15:23
add comment

SOP. Standard Operating Procedure (or at least a loose protocol that is signed off by your management team). Your department needs to develop one, or work with your management team to develop one. The people you need to talk to are above the product-owner/account manager.

Some examples of what your SOP should define.

  • What procedures are to be followed when a client or internal entity requests a change
  • What are the implications and/or impact on the quality control or verification of this product?
  • What is the method to reasonably determine a timeframe for delivery? This iteration? Next version?

Without such procedures in place, everyone is going to run at you like they are being chased by zombies and expect everything NOW NOW NOW. People like that won't respect your polite 'no' or 'please wait's. With a firm policy in place, these code-craving mutants will understand that they are in the wrong when asking for things on such a loose basis.

The end result is unhappy you, and that isn't in your companies best interest.

On a side note, you may have inherited someones mess caused by such blatant disrespect for his/her position and duty. People in that situation tend to find it hard to produce quality product. Is it any wonder? Software engineering 101.

share|improve this answer
add comment

Here is how I dealt with a similar problem .. Back in the days when we were agile before Agile.

For any change request, the customer sets the priority. The developer can only, and must, stop work on a task to work on a higher priority task. Equal priority tasks are schedules in order of arrival. (Task Priority cannot be changed once work has started.)

It will hurt when you tell the customer that you cannot work on his task because you are working on unimportant task X that has the same priority as his latest request. You then tell him that at that priority level there are 50 trivial and unimportant tasks ahead of his latest request. Now the real catch - all these tasks are at priority level 1 (the Highest), set by ... HIM ... So he cannot bump you off the task you are doing. Now, when you have finished moving the window frame 3 pixels to the left to make room for the longer word in the Icelandic translation on the rarely used configuration option.....

I also close the door to the SD office, locked it and took the phones off the hook. Emails were ignored until at 10AM, 12PM and 2PM. Despite what people thought and felt, the world still went around the sun, we got our work done and the "Customers" got software delivered to them quicker and better than any time in the past.

It took a few weeks for the priorities to settle to something more realistic, we were able to unlock the door etc.... But the system remained for quite a long time. You may not need to be so extreme (we did), and will need support from Senior management. But it will work....

share|improve this answer
    
+1 "Task Priority cannot be changed once work has started." Agile only allows a developer to drop items from an iteration that they have not started working on. –  Joshua Drake Aug 14 '12 at 13:51
    
I like the idea of the customer setting the priority, the hard part is laying down the law and saying 'I've started on task X, no you can not change the priority now' –  sevenseacat Aug 15 '12 at 5:23
add comment

It is very difficult to work under these "ready, fire, aim" conditions. It sounds to me like you are receiving requirements from a very insecure person, whose opinion changes each time a higher up person suggests a conceptual idea.

In these kinds of situations, I have found it valuable to wait AT LEAST an hour before responding to emails. (I'd ignore the texts, unless texting has widely replaced email by your organization as a whole.) Read them, maybe, but not respond. This way you can spend your time focusing on the actual work you need to do, not the discussion of random urgencies that may become irrelevant tomorrow, or even two or three emails later. In my last job, if something was REALLY urgent, someone would come over and talk to me in person, assuming I hadn't seen the emails yet (if you work remotely, a phone call with an actual two-way conversation may be the equivalent).

When you have the face to face or phone conversation, it is helpful to repeat what the person is asking for in your own words, and then ask your questions about the new requirements and priority. "If I understand correctly, you're saying we should stop working on Current Top priority X and now focus on Priority of the Minute Y. That's a big shift. Can you explain the change in the business? I might need to do more background work than just changing the UI. Will there be changes in other business processes, like billing or inventory (for example)? Are you going to expect these new data elements to appear on all the monthly reports?" It is also useful to say something to the effect of " You understand that if we proceed with this new effort, it will delay the release of Current Top priority X by at least a (week, month, fill in WAG time estimate here), right?"

If it's a real emergency, the requestor should be able to answer these kinds of questions, or immediately refer you to someone who could. If it's not a real emergency, this kind of conversation will force the requestor to slow down and determine how important the change really is, given that they need to get you more information. Often they'll see that what's already in the pipe is more important, or at least not worth stopping, and the new request can go on the list.

If the changes are determined to be necessary, I've found it useful to write down what was requested and your understanding of the changes in an email, and send it to the original requestor, asking if they agree on the scope of the change, again, as clarification. This way you have written documentation of what needs to be done, and why it was requested, in case there is any blow back on why you are no longer working on Current Top Priority X, or need to explain why the original deadlines are not going to be met.

This should hopefully improve your relationship with the requestor, since you are demonstrating your knowledge, and making sure that you are working on what they want, but you are being honest about what it takes to make changes. By asking about the request in detail, they see that you think ahead, and consider things they might not have originally.

share|improve this answer
add comment

It looks like nobody mentioned it yet, Sprint and its user stories ideally should be locked till the next sprint (typical sprint takes 2-4 weeks). By locking - i mean no additional tasks should be added into already started Sprint.

If user story is big enough not to fit to the sprint then brake it down to smaller, achievable tasks during the sprint. Also, as mentioned even prioritized tasks need to be hold in backlog, and during the next sprint planning high-priority once get the flag up :)

Edit: only minor changes can be introduced during the spring. if they carry emergency state. However, if there is always couple emergencies during the sprint, then something needs to be changes in Sprint planning itself.

share|improve this answer
add comment

Scrum has the Scrum Master role, which would be the person who should address the issues you mentioned.

If there is someone like a team lead, project manager, scrum master, etc. who is responsible, I would talk to that person.

I've tried explaining that there's only so much time and that we should focus on the most important things first, but something seems to get lost in translation because the same thing happens a day or two later.

I think that you will have to keep explaining that again and again and again. It sounds like you may need to accept that certain people you work with have unhelpful habits. If you are fortunate, you will see a change eventually.

share|improve this answer
add comment

Agile Manifesto says that one of the most fundamental principals is:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

However, I don't believe that they meant change on a daily basis. You might need to change the base price of a product many times a day, but not changing how that product might be sold many times a day. Rather the workflow of sales of a product might change on a week basis (in highly responsive and dynamic businesses).

Again, while workflow of sales of a product might change each week, I think the overall product won't be changed each week. I can't imagine a Microsoft which today gives us Office, but tomorrow will give us Offooose, and a week later Offasooooooooooos.

Nope, that's not what agile means by change. I do believe that it comes from poor visions, and a big deep misunderstanding of the concept of change.

Let alone mentioning that change is not welcomed in a sprint, where developers go to their caves and do need to concentrate on what their doing. Rather, changes should be added to Product Backlog, and be analyzed and prioritized before they get delivered to the hands of the scrum team. In other words, a Sprint Backlog is not immutable. More agility should be sought using shorter sprints, not by injecting changed directly into developer rooms, many times a day.

share|improve this answer
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.