13

The Scrum Team

  • 3 x Developers
  • 2 x Testers
  • 1 x Automation Test Analyst

We are not a multi-functional team in that the developers don't test and the testers don't develop. I believe this is the root cause of the issue.

We currently do two-week sprints.

At the start of the sprint everyone is busy, the developers are making a start on the development work and the testers are doing their test preparation (writing test cases, etc.)

Once the testers have finished their preparation they are now waiting for the development work to be complete OR the development work is complete and the developers are waiting for feedback/bugs.

The developers get itchy feet here and start to work on items in the backlog which are outside of the current sprint. This has created a strange affect whereby we are always developing next sprints work in the current sprint. To me this doesn't feel right.

From managements point of view, they would rather the developers do work than sit at their desks doing nothing but at the same time I feel like the scrum team's goal and focus should solely be on the current sprint. I wish our team was multi-functional but unfortunately it isn't achievable. The testers don't have the necessary skills to do development work and the majority of developers have the opinion that testing is beneath them.

Is this considered a problem in scrum? Is there a solution to this? Does scrum only work with multifunctional teams?

I'd like to know other peoples experiences with this if possible :)

Improve this question
11
  • 4
    I agree with management. Having people sit around because of an arbitrary two week period is a terrible idea. Perhaps your team's responsibilities are too rigid; in teams this small it is not uncommon for all team members to be "cross-functional," allowing them to jump in where needed in the current sprint.
    – Robert Harvey
    Jan 8, 2017 at 19:51
  • ...or perhaps you're not putting enough into your sprints to keep the team occupied for two weeks.
    – Blrfl
    Jan 8, 2017 at 20:16
  • 3
    Is a hybrid pair development/test mashup practical? In a sense the process is the same-ish as the unit testing cycle; write a little test a little. We did not have this formally but the testers were in the habit of coming to us directly as a bug or two was found. We did not communicate via formal bug reports. By the time "my tester" finished testing I was finished fixing. Being a web app made fix turnaround efficient. But at least experiment. And frankly, even if it is no better or worse mgt will perceive less individual wait time.
    – radarbob
    Jan 8, 2017 at 20:25
  • 3
    Does the work that was initially planned for a sprint generally get completed with sufficient quality? Or are you also left with half-finished stories out of the original planning?
    – Bart van Ingen Schenau
    Jan 8, 2017 at 20:54
  • 3
    You could just keep your process but call it 'kanban' instead of 'scrum', and then you don't need to worry about whether your process is right with scrum. /somewhat sarcastic, but not really
    – Eric King
    Jan 9, 2017 at 15:02

7 Answers 7

Reset to default
18

That's a rather common problem, caused by pipelining. The team is multifunctional, but of course there are internal silos which diminish the performance.

Firstly I'd like to note a couple of things that I think are important:

  1. If your developers work an iteration in advance, they are pre-empting your planning meeting. Your product manager and the team need to discuss what is most valuable for the next iteration properly. Prioritization should not be effectively done by developers because they have nothing better to do.

  2. No matter how you divide and arrange the iterations, you can't really keep everyone occupied all the time and have a single team with a single planning meeting as long as your team has specialists working in silos. Even with a pure waterfall approach, you would still need to "throw stuff over the wall" and wait for feedback.

  3. You also have the problem that often a single story needs to have a development phase, followed by a testing phase, followed by a bug fixing phase, followed by... this can really make your team inefficient -- especially if they work in advance, because they need to context switch.

Clearly there's a very real cost to this situation: the team is not collaborating. I've encountered this every time there was a QA team involved, so I've had a little time to experiment different solutions.

What worked very well for me are these two tools:

  1. Stress the principle that the whole team is responsible for getting stuff done. Refuse "dev done" stories, as they are a way for developers saying "not my problem anymore", which is both not constructive and patently false. If a team does not deliver a story they accepted, it is the whole team that did not deliver.

  2. To occupy the time of both developers and QA, pair them. This is by far the best way of sharing expertise and domain knowledge you can choose. Developers can help testers automate their tasks. Testers can show developers where it is important to test the code because it's brittle. Both collaborate and work faster than not.

Using these two techniques the team should get less siloed and more performant. While testers and developer are very unlikely to be able to swap jobs, they will be able to work as a team and solve the issue internally, instead of blaming each other.

Improve this answer
5
  • 1
    Thank you for your answer. I really like the idea of pairing the developer and QA resource together. I'm going to suggest this at our next meeting and hopefully we can trial this in the next sprint. I'll update the question and let you know how it goes!
    – fml
    Jan 9, 2017 at 14:23
  • @Sklivvz This happens more often than just when there's a QA department. It happens every time when QA is a role that only "certain people" can perform. Instead of the idle resource picking up the "next" high-priority task, the developer goes idle, then picks up more work while QA is perpetually reacting to the developer output.
    – Edwin Buck
    Jan 9, 2017 at 20:06
  • 1
    If it wasn't clear above, the "next high-priority task would be "reducing the QA backlog so items can be shipped" not the next high-priority development task from the backlog.
    – Edwin Buck
    Jan 9, 2017 at 20:13
  • 1
    Advice, such as the whole team is responsible, while it sounds good, in reality, doesn't serve the team. It suggests that everyone is interchangeable and it's a lack of everyone not pitching in. This is wrong. Each person in the SDLC has a particular role and has spent YEARS honing their skills. Asking a software engineer to test is detrimental to the quality as they don't have the necessary experience to test for quality, and will likely make a half-hearted attempt. Even if the QA engineer mentors them, the mentoring would take time away from the testing and make the work take even longer.
    – Chuck Conway
    Jan 12, 2017 at 6:44
  • 1
    @ChuckConway no one is suggesting what you say. Pairing is not substituting or mentoring. Ideally you trust the team to find the best way to minimize downtime, and that can only start with people understanding each other's roles and needs. The best, most efficient teams self organize (true or not, it's a basic principle of agile).
    – Sklivvz
    Jan 12, 2017 at 7:21
2

There is no issue with the way you are working related to SCRUM and sprints, provided it will go on record at evaluation time that developer work was finished in less time (and how much less time) then planned. This will allow the team to take on more story points for the next sprint. After all, the point of sprints is to get better at planning. Obviously you still have room for improvement.

we are always developing next sprints work in the current sprint

Whoa! This is technicaly not possible in Scrum. You do not know what backlog items will be in the next sprint, that is to be established at the start of the next sprint in a sprint planning session.

It remains interesting to learn about new creative ways organisations invent to sabotage Scrum.

Improve this answer
3
  • 3
    The problem with statements like "Whoa! This is technically not possible in Scrum" and "...new creative ways organisations invent to sabotage Scrum" is that they imply there is a correct way to "do Scrum". For there to be a correct way, Scrum needs to be proscriptive, ie put processes before people. Scrum therefore is not an agile process if there is a correct way to do scrum.
    – David Arno
    Jan 9, 2017 at 11:12
  • @David Arno That is nice, you are basically saying any methodology is by definition non-agile. Even the agile manifesto. Only sheer unpredictable chaos would be agile. But wait.. who is telling me to be chaotic? Serious now: the agile adagium "people before processes" is there to resolve conflict. If one has to choose, one should do what makes sense, not necessarily what the rules say. It seems to me the OP's team could go by the Scrum book without issues. And perhaps they do, the key question seems to be how transparent they are about is.
    – Martin Maat
    Jan 9, 2017 at 13:12
  • 1
    @DavidArno actually, that only implies that there are specific wrong ways to do Scrum, and that seems uncontroversial. For example, anything that contradicts the Agile Manifesto seems objectively incorrect.
    – Sklivvz
    Jan 9, 2017 at 14:01
1

Scrum optimizes for the team, not the individual. The whole point of scrum is for the team to become efficient. If developers are starting to work on things outside of the current sprint, they are doing the team a disservice. It also shows that you're failing somewhat at your planning process, if you fail to plan for enough work to fill the spring.

If developers have run out of development tasks, they absolutely should pitch in and help the testers or the tech writers or the designers -- anyone on the team. They don't necessarily have to write actual tests (though, they should), but they can still participate in the testing process. They can write scripts that help the testers be more efficient, or they can simply discuss with the testers what their challenges are and go about helping them overcome those challenges (eg: adding id attributes to web page elements, providing hooks or APIs that the testers can use in their tests, etc).

I think the heart of the problem is that if your developers aren't always working on the current sprint, they are not yet working as a team. Your scrum master should take notice, and work toward getting the team to work as a unit rather than a collection of individuals.

I also suggest that this is a management problem. If they are putting pressure on developers to stay busy then they haven't fully embraced scrum. This is another thing that the scrum master can help with. They can work with management to help them understand how scrum works so that they can help support and encourage the development teams rather than subvert them.

Improve this answer
0
0

I think the key problem here is the following:

the majority of developers have the opinion that testing is beneath them

The way we handled this in our company is that we asked the developers how can they say that they actually finished their work if they cannot prove it. Of course, the only way to prove it is to demonstrate that the code they wrote actually works, and this is done through testing. It should be pointed out to them that if they agree to participate in testing, then the testing will be done quicker, and they will have more time to code additional functionalities (that will also need to be tested).

Make a point that testing your code is not beneath the developers level. It is an integral part of development process. It cannot be separated from just coding. Anybody can code. Not everybody can code and prove that what they coded actually works.

Another way to keep the developers busy is to have them work on coding automated tests for the functionalities they developed in the sprint. Those tests could then be used for regression testing that would be run periodically.

Either way, doing something that was not planned at the beginning of the sprint is a big no-no. It is better to do nothing, than doing something that was not planned. The functionality that they write in those cases most likely does not meet DoD (Definition of Done) criteria, as it is probably not tested well, since the testers were busy by testing what was originally planned. This is a sure-fire way to introduce bugs and deteriorate the quality of the product, which then sends the team into a downward spiral of regression problems and context switch, resulting in stress, reduced velocity and finally, quitting the team because of it.

Improve this answer
2
  • I'd say the programmers are testing the code, they just don't create automated tests. There's a big difference.
    – JeffO
    Jan 9, 2017 at 19:12
  • In this particular case, I am willing to bet that the only testing these programmers do is that from IDE. Not many developers actually build the solution into an installation package, deploy the package from scratch as the end user would do, and then actually test the solution. This in most cases is not enough, and is a reason for significant deterioration of quality.
    – Vladimir Stokic
    Jan 10, 2017 at 7:49
0

In theory all members of a SCRUM team should have the same knowledge, so that each member can take every task from every other member. If not, you should spread the knowledge.

But in practice there is always some kind of specialization. The software may be complex, the team member have different skills, etc. Splitting the team into developers and testers is just one (very common) example of specialization.

Spreading the knowledge may take more time than the management wants to accept.

To my experience, you could do several things:

  • Do not make the team too small. If you for example have 4 developers and 4 testers it is much easier to move a task to another developer or tester then having only 3 / 2 like on this example.
  • Try to split up bigger tasks. If you have more smaller tasks you will be more flexible.
  • Define some optional tasks which could be done if there is time left.

These suggestions might not be 100% SCRUM theory, but first you have to keep development working. SCRUM is just a toolbox.

Improve this answer
0

It appears you need to desychronize you team. Like that:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

If I understood the test automation guys have to begin a few days early.

But I sense a problem in your team: I have a problem with developers that does not test their own code. If the test guys prepare the test without reviewing the code they probably are doing only blackbox tests that does not take into account the decision points of the developed program. You are satisfied with the quality of your software?

Improve this answer
0

I'm gonna throw my opposing bone here and tell you first: not only is ok for developers not to test, it's counterproductive to make them.

i started my career as a tester and i was good at it (means: i enjoyed finding errors in other people work and pointing them up). Eventually i moved up to developer and suddenly i discovered that, as a developer, most of the time i felt the urge to look the other way when i found bugs that were annoying to fix. And it turns out, that's a normal behavior.

As a developer you do the simple testing of "does it fulfill the need?" and that's ok, because that is your focus: producing results. the job of a tester is to tell you "here, you missed this".

When a tester learns to develops it gives him some understanding of how things work and may help him find more specific, technical bugs, but it also put them in a frame of mind. As i always say, i have never seen somebody found more bugs than a little kid playing alone with the program. why? because he doesn't know what's supposed to happen, so for him putting a bunch of special characters as his name seems ok, but for the programmer that wrote that code is a no-brainer that nobody will do that.

When a developer learn to test they fall in the rabbit hole of "ok, how can the user f*ck this input?", which sound good on paper but defensive programming means a lot more time to develop something and a sharp increase in complexity in some cases. At the end of the day you have a slow developer and an untrustworthy tester, not good.

Letting the developer focus on developing and the tester focus on finding errors is the most efficient way to work, even in you case when you have such a delay between phases.

now, about your question:

The truth of the matter is that if you want to reduce the delay between developing and bug fixing you need more testers. i don't know if there's a correct dev-to-tester ratio (it seems to depend on the complexity of the project), but in your case it seem that 1 to 1 isn't enough. if you think the amount of testers you have is ok, but don't want your developers getting ahead on other task you can offer them the new time as challenge to improve their code or to do peer code reviews between themselves, so you keep them with the task at hand fresh in their minds and you may get extra quality code and knowledge transfer from it, without compromising the specialization of the developer.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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