I'm in trouble, my team (3 devs including myself) works with mobile and backend development and we are dealing with some problems trying to order this process. Let me try to explain my situation, our team has two main problems:

  • No testers (dev tests their own code)
  • Lots of interruptions along the sprints, to do another stuff wasn't planned

What I'm thinking that could fix it:

  • About tests (Mobile): Unit and Automation tests covering almost every line of code and all screens
  • About tests (Backend): Unit tests, and continuous integration
  • About the interruptions: No longer work with sprints, keep a huge backlog, and getting tasks from this amount and adding others when needed and pushing previews tasks forward, all of this, doing weekly reviews about what was done.

Problems I think I'll face:

  • Lost of track, because now I have this huge pile of tasks, even doing weekly reviews
  • More expensive development process

Do you have any idea what I should do, or how can I get out of this dead end?

  • How would you classify the interruptions that you are experiencing? Are these to do with defects that need to be fixed or changes in the sprint content or additional tasks that come up and need to be done? How do you go about documenting the various work and tasks needing to be done and allocating work to the various team members? Nov 6 '17 at 12:38
  • @RichardChambers the interruptions are minor changes or executions or procedures that are executed directly to database. The documentation only occurs to major development changes Nov 6 '17 at 12:43
  • 1
    Do you have a Product Owner, who is responsible for prioritizing all the work, and a Scrum Master, who is guarding the process? If you have strong people in those roles, they can do quite a lot to reduce the interruptions for the developers. Nov 6 '17 at 13:18
  • @BartvanIngenSchenau the point is these interruptions are part of the process, I'm trying to figure it out how to make it affect the minimum possible. Nov 6 '17 at 13:31
  • 1
    @guisantogui If those "interruptions" are "part of the process", then they aren't interruptions and they shouldn't be "unplanned". Nov 7 '17 at 0:52

With only 3 devs you might find Kanban a better fit than scrum.

It will allow you to deal with the interrupts within the system without having to restart the sprint.

re testing, as long as you have a testing stage and sign off the lack of a dedicated tester shouldn't be a big issue.

Make sure you have that test environment and automated tests though. Unit tests help you develop faster, but front end tests for each screen are what you need for the definition of done.


On Testing

No testers (dev tests their own code)

I truly hope that all developers test their own code before they send it anywhere else, but having dedicated testers is also great for a second set of eyes. It might be possible for you to get this second set of eyes without dedicated testers, for an example by doing peer reviews of code.

Regarding the automated tests, consider the following: It will take a lot of time and concentrated effort to write these tests. They will very likely be good but it's a huge undertaking which will soak up almost all of your time. There definitely is a pot of gold at the end of the rainbow but you should really, really limit the scope of these tests to critical functions and execution paths. Build a test suite over time.

It's very possible that lack of tests and testing of code is a reason you have a lot of interruptions but instead of having the goal to test everything you've created before try to establish better goals for new code. If you create a new function create tests for it. If you update an old function and no tests exist: Write them.

On Interruptions

Lots of interruptions along the sprints, to do another stuff wasn't planned

I've worked like this as well but what to do really depends on the interruptions. You really can't get away from some of them; ever heard someone say "We'll get the servers back up and running during the next sprint?"

Interruptions are a side effect of several things and there are certain remedies which could help you alleviate the pain. Try to take steps to release:

  • Stable code
  • Bug free code
  • Code which accomplishes the intended task

Some of the previously mentioned things will help with this. Better verification of code stability and that there are no bugs should keep some of these issues away from your table.

Making sure that tasks are properly specified before someone starts coding is incredibly useful and, I find, sometimes not done at all by people. Working in a small company I prefer to walk up to the person who is going to use what I'll be programming and ask them to tell me about their problem. This might not be viable to you and might be completely impossible depending on company size as well as culture. Joel Spolsky has an interesting series on writing specifications.

In addition, just as Ewan said Kanban can be a great tool when you have many tasks coming in from the side line. Simply keep a backlog that's in prioritized order and whenever a new important thing comes in it's put on the top (or wherever else is appropriate).

Sometimes you also have to educate the people putting in new requirements on what an interruption means. If you put people through an exercise where they have to prioritize tasks to be done they'll usually say that everything is top priority and somehow believe that this means that every top priority thing will be done fast. After all, nobody puts effort into low priority. Here it's important to teach people that interruptions take more time, see once more Joel Spolsky in Human Task Switches Considered Harmful. In addition, make people really ask themselves if asking a developer to change that indigo into a magenta color really is as urgent as they believe.

A General Recommendation

If your current process isn't working or isn't good enough, don't be afraid to change it. Keep in mind that if a certain change doesn't work out you can try something else or go back to how things were done before. Don't make huge changes or change everything at the same time but incrementally improve your process. Improve the process like you improve your code.

  • "We'll get the servers back up and running during the next sprint?" – Well, a sprint is a kind-of contract. Management promises to let the developers undisturbed for a week, in return the developers promise to deliver a certain set of previously agreed-upon features. So, management can decide: either finish the sprint or get the servers back up and running. But not both. If you interrupt the developers, the sprint is canceled, and you start from the beginning with a new sprint planning meeting. Maybe you shift your normal sprint rhythm, maybe you insert a shorter (or longer sprint) to keep the Nov 6 '17 at 18:10
  • … rhythm but either way, there will be a new planning meeting, and there will be new (and possibly reduced) commitments by the developers. So, in a sense, yes, if you want the developers to deliver the features they promised, then you put the broken servers in the backlog and schedule them for the next sprint. The next sprint might be "right now" if you decide to cancel the current one, but in a certain sense "We'll get the servers back up and running during the next sprint" is exactly how you should approach this. Nov 6 '17 at 18:12
  • @JörgWMittag I completely agree that it's a contract and that the purpose is to promise that given a set amount of time in which focus is put on completing a specific set of tasks. My point was to make a simple and stupid example to prove that at times there are tasks which will take priority and that in some cases you will need to adapt your process for that.
    – Robzor
    Nov 7 '17 at 8:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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