4

I've read up on scrum and the company I work for has started using this. I find that laying out tasks really helps everyone to see what needs to be done and what to work on. One of the issues we're running into, is that we're just "trying out" scrum with one of our projects. We have many custom built applications for clients. Some of these clients get priority over others. If they call in and demand a report, we provide.

Is there a process (scrum or otherwise) that we can utilize to help us with these demands? As it currently stands, daily demands are not calculated into our sprint as we don't have time to do story time and planning poker every day.

Any thoughts?

I did find this question that talks about how to incorporate multiple projects, but not daily demands.

Community
  • 1
  • 1
nwalke
  • 3,170
  • 6
  • 35
  • 60
  • 1
    I'm voting to close this question as off-topic because it is not about programming. – Vadim Kotov Nov 03 '17 at 17:02
  • The downvotes are certainly not necessary to close this question. Please keep in mind this question was asked in 2013, long before SO was scoped the way it is today. I believe this question falls under "a practical, answerable problem that is unique to software development" but that's my opinion. – nwalke Nov 04 '17 at 18:24

2 Answers2

5

You should make your clients follow a Change Management process, irrespective whether you use Scrum or not. You must agree that you're not immediately doing what your clients ask but arrange the items according to priority and plan them before doing it. If these are some urgent issues, like bugs found on production you should anyway follow the process but fix them more urgently. We're actually doing it this way:

  1. Assign a priority to the issue
  2. If it's low or normal priority add it to backlog and plan for a Sprint later on
  3. If it's urgent assign it to dedicated support engineer who'll make it without Sprint in hotfix code branch The latter point must be avoided as much as possible.
Alexander Vasilenko
  • 66
  • 2
  • 2
    This is really why scrum relies so much on the Product Owner to handle and streamline this. He/she should be the shield between the team and the people making the demands. The team must also be mature enough to say no often enough. In case of emergency, the team should go ahead and fix. Don't let formal processes get in the way of solving true emergencies. – jessehouwing Feb 25 '13 at 12:47
  • So in this scenario, you actually have one of the developers sit out of the sprint? – nwalke Feb 25 '13 at 14:05
  • 1
    Yes, we do have one out of the Sprint. We call him a support guy. But to stress once again - he doesn't fix the issues unless he's told to that by Scrum master. Scrum master here acts as an old-fashioned project manager - manages changes according to pre-agreed process. – Alexander Vasilenko Feb 25 '13 at 15:53
2

Perhaps Scrum is not the right agile approach for you as it is more suited to teams where work can be planned in advance, e.g. one to four weeks at a time.

For teams that do support and maintenance, I suggest looking at Kanban.

Brett Maytom PST
  • 1,193
  • 7
  • 6