How QA, Frontend, Backend development, and System administration fit in Scrum Management Framework

Question

We are a small start-up that is growing fast.

We have 4 departments: (Backend dev [2 pers], Frontend dev [2 pers], QA [2 pers], and one system administrator)

Before using Scrum methodology, we didn't have a clear idea about our progress, what others are working on, etc. Now we passed this issue, but we face a big issue now; it seems that the team is not conformable with the current methodology.

To give you a clear view on our case, here is how we proceed to handle a project:

We have a backlog meeting with product owner. The team defines the release backlog in another meeting (basing it on priority set by the product owner) Each department slices the release backlog and lists all tasks needed to be done by the next sprint. For instance, the backend group will start working on an API, front end will deal with designers and get the ready templates ready, the QA team will read and understand stories, and system administrators need to define the next priority according to the current project.

Each department creates their own sprint. (It's weird I know :s) and in the end we have 5 sprints. (The 5th one is for business employers. Well, they want to be part of the methodology, lol.)

Before we start using Scrum, we were respecting a cycle of two weeks, and after implementing Scrum, the project manager suggest that sprints need be done in two weeks. However, we just found that a sprint may take more :s.

According to our case, I have a list of question coming to my head.

Do QA, Backend, Frontend, and System Administration fit in Scrum methodology? What can we do if QA and system administration has a daily tasks? Can we use just one Sprint instead of 5?

Answer 1

In traditional Scrum, all of these roles are considered part of the same scrum team. Release backlog items get moved into the sprint backlog when committed to by the entire team (no matter what function the individual team members have) and then tasked out (again, by the entire team).

The reason scrum doesn't usually separate out the functional areas of the team are 1) just because you're QA doesn't mean you don't have something to contribute to developer discussions and 2) you're all working on the same product and should have some view/input on the product as a whole so you can catch any conflicts between functional areas. Your front-end developers need to know what your back-end developers are doing and vice-verse, as an example.

Where the functional areas really come into play are when team members are pulling items from your 'Not Started' lane of your card wall. If I'm a QA guy, I'm going to pull tasks to work on that are QA specific first. If I'm a front-end developer, I'm going to pull tasks to work on that are related to the user interface. It's up to the individual team member to work on items related to their functional area.

The question that always comes next is - What if there aren't any tasks for my functional area left? The answer is - give something else a try. If nobody's working on it, it won't hurt for you to give it a go. Not only will that give you insight into how the other functional areas work, but also how your product works in areas you might not regularly see. You can always hand the task over to someone from that functional area later (when they're available) and you'll have learned something from the experience.

That's traditional scrum, which is how the question was phrased. If you're looking for advice specific to your scenario, that's a whole different discussion and will get into the reasons you're doing things the way you are.

Answer 2

Moving to Scrum is hard as it is not as simple as having a team, the hard part is to get the team members to work together as a single unit (a team) and break the old habits of working in isolation. Much easier said than actually done.

This is the main reason we have short sprints and a retrospective, thus allowing the team to inspect on how they work together and look at ways to improve. The Scrum Master should be looking out for these behavioural issues and bringing them up in retrospective, asking the team how they are going to change they way they work.

These are some but all common problems I see with new teams; they may or may not apply to you.

• The team are thinking as job titles and not joint responsibility of getting done

• There is no clear definition of done which drives the quality

• Teams are not self-organising and Scrum Masters or managers still try control the team.

• Teams don't learn to inspect and adapt, but simply circle the same problems

• Testers believe they are the only ones responsible for quality control

• Scrum Masters don't look for weaknesses and opportunity to improve, then present them to the team; asking the team how they will fix it

• Team members have not been explained Scrum

• Tooling is often poor in many companies which impedes the teams ability to adopt good practices

• Initially Scrum will highlight many issues, but many get ignored

• Rookie Scrum masters don't recognise the difference between good and bad changes as they have not learnt the hard lessons.

• Bringing in Scrum into a company requires so strong coaching by skilled and experienced professionals. Organisational change is a different kettle of fish and should not be done without the right experience.

Answer 3

The main concept behind scrum is to get everyone (DB, UI, Dev, QA) together. This works wonders since now the dev would know what problems QA faces during testing and would be more attentive to the issues they would usually ignore before the hand-off to QA. Similarly QA would know how dev works day-to-day and would help. This comes from the joint responsibility principle of scrum. The entire team is responsible for the delivery. I can't say the delivery failed since the Dev completed late or the QA didn't finish on time.

Everyone starts thinking about the improvements they can make to the system and that contributes to the success of the team. Bringing all your teams together would break the silos that may be there. There is a nice preso on team mindsets by Linda Rising here.

Answer 4

The methodology you are using is called ScrumBut.
http://www.scrum.org/ScrumBut

As for me that is fine to make any modifications to Scrum in order to gain more comfortable environment for the team. But, after you did those modifications – just don’t call it Scrum anymore.

We used to follow Scrum process on our project. The experience was horrible. Then during a year we did a lot of modifications. We still have retrospectives, (ad-hock) planning meetings, two-week sprints, small backlog, demo at the end of the sprint. We do not measure velocity and we have additional sprints for regression testing and bug fixing. We joined Demo and retrospective together.

As a tester, I have no chance to perform deep testing for the feature that was completed 2 hours before final demo, so I am saying about that on Demo+Retrospective meeting. I am usually taking those testing days from next sprint.

That’s not Scrum, but that works for us.

Answer 5

Expanding on what @NightMan and @Nikhil Gupta wrote in their answers: it might be very counter-intuitive to you and your team, but bring them all together as one team and work on one Sprint.

Yes, it will be rough at the beginning, but you will build sense of common goal and most of all you will start to improve your organization.

Some of example areas that will change/improve:

QA

Problem: we cannot do this during the same Sprint as we're done coding 10 minutes before Sprint ends. Solution: Introduce test automation, developers and testeres from the very beginning of coding of particular Backlog Item also automate testing as there is hardly any way to get enough time to do testing during the Sprint. Long term you will have huge productivity benefit out of it.

Administrators/DBAs

Problem: We cannot put our DBA as part of Scrum team, he/she is "shared resource". Solution: Include them even partially in the team and let them pair with other team members, over time they will start to pick up part of their skillset and won't be relying that much of one particular person.

---

Bottom line is: get them as one team, try it and you'll be surprised how much you will benefit of it.

Answer 6

I've run very similar teams before and what I've found is incredibly vital is to have all roles work as the same team.

First off, I think you should definitely run a single team. The reason is this: your team members are working toward a common goal. Everything about your team structure should work toward that. A single scrum team has common commitments in their sprint goals, a common deadline, and they need to work together to get that done. If you add artificial separation, you ask for people to play the blame game. I can't count the number of times I heard things like "Well, it's done, it just hasn't been tested" or "We couldn't do our work because Bob was sick and didn't set up the server." Sure, you're more efficient when you let people focus on their area of expertise, but when the whole team is on the hook equally for meeting goals, you find that there's a lot more overlap in knowledge than members would otherwise admit.

Secondly, I think you will lose a lot of the advantage of scrum. To read into your case a bit, you mention that the BE team is working on the API. If this is done in isolation from the FE team and the business group, then how do they chose what they write? It can be very difficult to show that at the end of each sprint they are delivering a releasable set of functionality that delivers value to the end customer. This is a situation I've seen too many times. When asked what value is being created by work, I've heard "Well, none right now, but in June when everything else is done, it'll be pretty key." This is great as long as we get to June. I've been part of a few projects that have been cut off early and the company was very frustrated that they'd wasted all of the spent project time and gotten nothing out of it. One of the great advantages of Agile is that you constantly deliver value, so if you're cut short, you're getting functionality out of the project proportionate to the effort that was put it.

I hope this helps.

Answer 7

That sounds to interesting.. You will always face some roadblocks when you migrate to SCRUM.. To solve the issue which you face..

1. First and foremost thing you should do is to educate your team on SCRUM.. Get some Agile Coach and train your team on SCRUM...
2. Make your different depts are one team.. If there is no coordination between team you cant be successful in Agile
3. You should have a Business Analyst or Scrum Master to drive your team, thus they are not deivated from achiving the objectives
4. When you get a requirement, your BA should break down the requirements in smaller user stories.
5. Discuss the user stories and get it prioritized
6. Call your team for a planning meeting and make them understand the requirements
7. Ask your backend and frontend team to sit together and do the effort estimation because they both are interdependent on each other. Get one effort estimation not two.
8. Ask your QA team to prepare test cases when the sprint begins and they should test it parallely when the dev team completes each tasks. (I dint understand the role of your system admin)
9. Once you get the effort estimation plan for your sprints and go ahead
10. In this you can involve your whole team into one sprint..