views:

358

answers:

10

I'm a developer working in a small team with another developer and a QA who is split across 5 projects and I've recently been given the title of Scrum Master. I've a few questions/issues which I was wondering if I could get a hand with:

  1. I've not found any good central place for information on my new role, can anyone point me in the right direction?
  2. We're doing 2 week sprints and as you can see our QA resource is severely low. The PO is asking if dev can carry on working throughout the sprint to complete the most story points they can and at the end of the sprint if QA isn't able to complete then we can branch off the code for the next sprint. I've said that we should define the stories we can do with the resources available and assess what to do when we get to the stage that dev have no work. The PO is asking if there is a way to let the devs carry on working on code beyond this point. It's unlikely we're going to get more QA resources, but it seems a waste to have devs sitting around doing nothing because of a QA bottle neck. What, as a SM, can I do?
  3. I wanted to get opinions on a dev being a SM on the project he is developing on. What are the areas of conflict here? Why is this a bad idea?

EDIT

Thank you so much with the responses; there's a wealth of good information there. Here's an update to the situation:

  1. The QA resource impediment has been escalated, so there's some visibility on that but no time scale on a resolution.

And what I'm currently thinking is:

  1. Get my QA resource to plan a testing matrix, as detailed as he has time for, for as many items as possible within the sprint and sit down with dev to give a quick overview to testing essentials.
  2. I'm going to reduce the dev hours for dev work and put then on to QA. This will reduce the amount of work done in the sprint but will mean that at the end we are left with a releasable product. I think I may have to multiple the QA estimates by half because, as mentioned, being a good dev doesn't make a good QA.
  3. Make sure each dev doesn't test his own work.
  4. Need to reduce the number of hours I can do dev work as I've not taken in to account that the SM role will take some time.
  5. Get my BA, PM and PO to help out with testing

Again, thank you so much.

+1  A: 

The QA should be able to provide you with a continuous build environment and testing framework to get you started. They should of done this for the other 4 projects. Then you can all write units tests and track whether they all continue to pass. A task wouldn't be complete until there is also a test for it. The unit tests would combine together to prove that your stories are correct.

You then are reducing your reliance on the QA....

Are you sure your QA has no time or is just not leveraging their time correctly? There are many free CI systems that are free to download and can be set-up in about a day. The unit tests take longer but the QA doesn't usually write these anyway.

Tony Lambert
Release engineering and build management are not necessarily QA roles. If the QA resource is split between 5 projects, and there's not a dedicated resource for these tasks, the development team could take on the work.
Andy Thomas-Cramer
A CI environment is on our list of wants, but isn't feasible at the moment because of various restraints. This is certainly the plan going forwards, but at the moment I'm looking for a short term strategy to allow us to tackle the current backlog.
Martyn
If there is a QA common to 5 teams it would make sense for them to provide common functionality, unless one of the teams has put this in place then they should/could share the work.
Tony Lambert
The stated problem is insufficient QA resources in a Scrum environment. Adding additional expectations for QA does not sound helpful. Scrum's ideal of flexible roles does.
Andy Thomas-Cramer
Also, unit tests != functional tests.
Andy Thomas-Cramer
+1  A: 

A good place to start, as suggested, is scrumalliance.org. There are also many books and trainings about this. The most important part will however come from experience. Different things work for different teams. Dare to experiment! And, do retrospectives regularly with your team, so that you can reflect on experiments and improve even further.

For your QA problem: take the QA out of your team. You can not run a scrum team without big commitments (timewise) from all members. I suggest to have the devs to deliver a result, have the QA handle it whenever he can, and should that result in more work: new user stories.

In addition, you can look at whether the devs can take over the QA work partially, or make it lighter. For example, it's often worth it to have automated (unit) testing and continuos integration. There are also other metrics you can track in this system, to improve and keep good quality.

The SM also being a team member is not uncommon, and can work fine. The interests of both roles are usually aligned, so I don't see many risks there. It does require appropriate prioritization and time management.

Erik
Thanks Erik, very interesting notion to take QA out for the moment. It makes sense as it's currently the biggest bottleneck by far, but how would I ensure that there is a releasable product at the end of each sprint if no testing has occurred? We're looking in to getting unit testing and a CI env, but that's not feasible in the short term.
Martyn
@Eric I do agree with your suggesion of devs picking up QA work partially.
sjt
@Eric 'I suggest to have the devs to deliver a result, have the QA handle it whenever he can, and should that result in more work: new user stories' <--- Based on this suggestion then why not have requirement analysts have requirement gathering User Stories, and let the Developers take it up whenever they can, And next Sprint have new user stories for developers, and have testers test whenever they can, next Sprint Testers have Tesing new user stories and so on. Your suggesion is a dangerous pattern, a pattern which may be called mini waterfall
sjt
and which we call in our organisation - "Scrum - but"
sjt
+1  A: 

Pragmatically, you're going to have to continue working. However, it will be useful to understand and communicate the effects of insufficient QA resources.

You can create a definition of done that omits QA testing. However, such a story is not proven shippable. Your quality may suffer from a lack of rapid, iterative collaboration with QA. You may be building up an unknown backlog of bugs, which reduces schedule predictability. You may lose weeks of developer time to dead ends that a QA person could have prevented.

You could instead have developers doing QA testing. This matches Scrum's ideal of a cross-functional, self-organizing team with no titles. However, this will slow development. It may increase costs, since developers may get paid more than QA. And developers are not necessarily the best testers -- certainly it's bad to have the same person develop and test. On the other hand, this quickly demonstrates the need for more QA resources.

If you cannot hire a new resource yourself, consider expressing your concerns in writing to your manager -- cogently and unemotionally. A good manager will take responsibility, and a bad one will try to avoid blame. Both may lead to action.

Andy Thomas-Cramer
"...not proven shippable." QA's role is not to prove or disprove but to provide an assesment of quality. It is up to someone else to determine ship risk. That being said, I would agree that someone will need to fulfill the role to provide a proper assessment.
Mark Schultheiss
+7  A: 

For me there is no separate QA in SCRUM. Each developer is responsible for testing and creating automatic tests = each developer has to have testing skills. If you have separate QA person who is not able to complete his tasks then developers have to help him. This is main point of SCRUM team. There is no "this is his job".

Ladislav Mrnka
Cross functionality. Can't agree more. Principles and framework rules well stated, but execution is key.
sjt
Finding best and creative ways to execute within the principles and framework rules makes successful Scrum Teams. I am sure you will agree.
sjt
Yes I agree. In real world you always live with some constraints but this was example of something I'm always trying to avoid. In my team each developer has to know that he is also responsible for QA and part of QA because this is first thing you have to achieve to avoid technical depth. Technical depth is exactly what is described in the question. User stories are marked as done even they have never been tested and test are postponed to the next sprint = very very bad. If this have cumulative effect you are doomed.
Ladislav Mrnka
@Ladislav agree, I think you mean technical debt though :)
eglasius
@eglasius: Sorry for bad English spelling. Of course I mean technical dept.
Ladislav Mrnka
+3  A: 

I've not found any good central place for information on my new role, can anyone point me in the right direction?

Get the Scrum Guide (the official Scrum Body Of Knowledge co authored by Ken Schwaber and Jeff Sutherland) from Scrum.org. The Scrum Alliance is also another good place to find resources but the Scrum Guide is definitely a good start.

And if you're unclear about the ScrumMaster role and, more generally, the Scrum process (the former implies the later IMO), maybe consider getting some help (coaching, training).

(...) The PO is asking if there is a way to let the devs carry on working on code beyond this point. It's unlikely we're going to get more QA resources, but it seems a waste to have devs sitting around doing nothing because of a QA bottle neck. What, as a SM, can I do?

The PO didn't get what Scrum, Lean thinking, the Theory Of Constraint teach us. Partially Done Work is a waste so inventory of partially done work is a bigger waste. There is no point at creating more Work In Progress (WIP) and bigger batches of work if the system cannot absorb it, the whole point of Scrum is to minimize the inventory (or WIP) to minimize waste. If you identified a bottleneck, there is no other answer than "remove it".

So if QA is currently the bottleneck, the fact is that you should add more man power. And if QA can't get more man power, help them. There is nothing wrong with that, it's not Dev vs QA, it's not "us" vs "them", Dev and QA should work together. I'm not saying that this is your position, I'm just saying nothing should prevent having team members doing QA.

I wanted to get opinions on a dev being a SM on the project he is developing on. What are the areas of conflict here? Why is this a bad idea?

The problem is that a SM should be able to focus on impediment removal, this should be the top priority. And depending on the organization, there might be a huge number of impediments, especially during an adoption. And problem solving can be highly time consuming. So committing to the realization of Product Backlog Items potentially conflicts with this job. But this is hard to avoid in small teams. Just try to strictly time-box your ScrumMastering time.

Pascal Thivent
+1 For first paragraph. It's amazing how many people I have come across who have never heard of the Scrum Guide and yet are following scrum.
sjt
@sjt True. I believe the SA is still shadowing Scrum.org, somehow. I'm not saying it's intentional(?), just observing. Happy birthday Scrum.org by the way!
Pascal Thivent
+3  A: 

I've not found any good central place for information on my new role, can anyone point me >in the right direction?

Scrum Guide is the first thing you should refer as commented above.
scrum.org/storage/scrumguides/Scrum%20Guide.pdf then once you are done with that move to scrumalliance.org or others.

We're doing 2 week sprints and as you can see our QA resource is severely low. The PO is asking if dev can carry on working throughout the sprint to complete the most story points they can and at the end of the sprint if QA isn't able to complete then we can branch off the code for the next sprint. I've said that we should define the stories we can do with the resources available and assess what to do when we get to the stage that dev have no work. The PO is asking if there is a way to let the devs carry on working on code beyond this point. It's unlikely we're going to get more QA resources, but it seems a waste to have devs sitting around doing nothing because of a QA bottle neck. What, as a SM, can I do?

Assuming that all the developers on your Team have 0 knowledge of testing - 'Lack of resource with QA knowledge within QA standards' should be raised as an official impediment, and as an SM it will be your responsibility to resolve it. The advantage of this is it will make this issue visible to the upper management, unless you are the upper management then you will have to hire someone soon and rethink the whole Scrum adoption process. Now if you ask what does the Team do till that new person arrives? Well, if you follow pure scrum, this problem should never arise, because as per the Scrum guide Scrum Team has to be cross functional. An analyst or Developer should be able to take Testing tasks. Also as per the Scrum guide a PO can also take up tasks and help the Team. You will have to ask these bold questions: 1. Does anyone in your current Team have any slight amount of testing experience - I surely think there must be atleast one, unless you have role-ist (I think that is a word) developers in your Team? 2. If yes, Why cannot the developers in your Team pick up testing tasks? 3. Why cannot the analysts (if there are any) in your Team pick up the Testing tasks? 4. Why cannot the PO assist in Testing some of the Backlogs Items? 5. What is stopping you from switching your role from developer to tester? 6. If none of the above work, can you have QA (split across 5) do a quick test matrix creation and testing demo to the fellow non QA team members, and have developers pick up QA tasks gradually.

And lastly if they don't have domain knowledge the PO SHOULD pitch in as a domain SME to rescue the team, after all PO is the single ringable neck if the release goal is not achieved!! I professionally challenge anyone who fundamentally disagrees with that.

I wanted to get opinions on a dev being a SM on the project he is developing on. What are the areas of conflict here? Why is this a bad idea?

With all due respect, it does not seem that you have a lot of experience working in the Scrum framework. I would suggest just focus on the SM work initially till you get good at it. Why? The reason will be answer to your question: Areas of conflict - Scrum Master resolves impediments, Developer is a cross functional team member who picks up tasks in a Sprint. If you do not separate these two duties your impediments might not be handled on time and you may get distracted which can be detrimental to the Team.

Why is this a bad idea you ask? To be honest, this is not a bad idea really. The scrum guide never bans a developer from being an SM of Team and do development work in the Sprint. But it does very diplomatically warn you that it can be harmful if not executed properly. When you are SM be an SM, and when you are a developer be a developer, not only make yourself consciously aware of the change in duties, but also make everyone else aware. You could just pretend to switch hats by a hand motion OR wear an actual SM hat for the first few Sprints when on SM duties. Get creative, it helps. Finally, once your Team is past the storming phase start picking up a percentage of tasks to help the Team, the team will appreciate this and will respect you for it. Bottom line is just use common sense - if the Team needs help sometimes you just have to take up tasks but the SM duties are always placed higher in priority!!

sjt
I cannot not upvote this.
Pascal Thivent
+3  A: 

We're doing 2 week sprints and as you can see our QA resource is severely low.

That's all that's needed to know the situation. You don't need to read the rest to know that without doing anything QA won't be able to catch up. Worst when you add "is split across 5 projects".

QA needs to happen, just because you don't have enough people with that hat on the project doesn't mean the team can forget about those tasks. And this is not about a QA person not being half time in the project, if you have 2 or 3 devs that would still not be appropriate if you leave it all to that person.

Get the developers involved in the test automation. You are done when the feature is built, with its tests in place. Already have baggage? have them do the test automation and then continue.

But what about the 8 hours x week of the QA person? Have them:

  • coordinate with the developers to make sure key scenarios are automated
  • check tests where done, and those are being done appropriately
  • use their skills and focus on QA to give input to the related team's tasks

Depending on the size of the team, the QA person may or not have enough time for the above, but that's certainly far more doable than trying to test what all those devs built. What happens if you try that, is that it isn't really tested / or the coverage is ridiculously low.

Finally, don't approach the above with a I need to get approval mindset. That's the way it is, its professional software development. Negotiable alternative would be shifting some of those activities to More QA team members. Or shipping with lower quality (doesn't mean 0 of these activities, just less), but don't do that if they are not willing to put into production what you just built in the iteration / otherwise they are not being honest to themselves.

I wanted to get opinions on a dev being a SM on the project he is developing on. What are the areas of conflict here? Why is this a bad idea?

Just a personal opinion, so don't take it as fact: I'd say its more of an issue of skills and discipline. The first because being a great developer doesn't make you a great SM (but you could have a skill set for both). The later because its hard to think in something else when you are focused developing something. If both are an issue it can turn v. bad at the end. If the skills are there, and focus goes bad it'll usually be addressed at the next cycle.


re update:

  1. Get my QA resource to plan a testing matrix, as detailed as he has time for, for as many items as possible within the sprint and sit down with dev to give a quick overview to testing essentials.
  2. I'm going to reduce the dev hours for dev work and put then on to QA. This will reduce the amount of work done in the sprint but will mean that at the end we are left with a releasable product. I think I may have to multiple the QA estimates by half because, as mentioned, being a good dev doesn't make a good QA.
  3. Make sure each dev doesn't test his own work.
  4. Need to reduce the number of hours I can do dev work as I've not taken in to account 5. that the SM role will take some time.
  5. Get my BA, PM and PO to help out with testing

I read the above as: we are going to proceed with manual testing. #1 is fine thought.

No. 2, 3 and 4 its possibly very specific to your environment, getting those automated tests in place is part of developing that feature. So its not like dev vs. QA tasks, is part of the same task - develop the feature. Its part of the velocity of the project, but I guess there are political reasons in your environment to track separately.

What's more like a separate QA task, would be things like: doing reviews of tests done, adding more test scenarios by building on top of existing tests. These activities benefit more from having a different person do it.

No. 5 more from a feedback point of view would be good. As for running the tests its best if that runs automatically on a QA environment as new versions are committed / continuous integrated testing.

eglasius
+1  A: 

As several have pointed out, in your case the developers should perform the QA when your designated QA person isn't available. That may mean reducing the workload for a particular sprint but if you don't have the "traditional" QA resources to dedicate that's what you'll have to do.

If you don't test at all what you'll end up with is little better than waterfall.

Chuck
+2  A: 

I think you're on the right track. Especially with escalating the impediment. A Scrum Master is supposed to be the bulldog for the team and process and it looks like you're doing that.

I also agree with your approach to have the QA member produce guidance, although they might not have the time to execute the test.

But the QA person needs to be on the team, and task should be created to quantify the matrix or scripts. Also, is the BA be on the team?

If someone is contributing without being on the team, they don't have their skin in the game, and the team could well feel that there will be roadblocks to their success that are out of their control.

Angelok
+1  A: 

If you want to write quality code, I think that code reviews are even more important than relying on QA to find bugs. Sit down with your developers and review each other's code. You will identify many bugs this way, and it is a good way to improve communication among your team.

Jeff Atwood elaborates in his article Code Reviews: Just Do It:

...software testing alone has limited effectiveness -- the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent...

Donald