Interrupting software development methodology

Question

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?

Answer 1

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.

Answer 2

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.