Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
During the current Sprint, my Team is doing mostly front-end tasks, I don't have any tasks, because I do back-end.
My Scrum Master says that I have to pick up tasks from another Team.
Question: Is that possible in Scrum?
I think we have awful business analysts that don't write adequate specifications. I think that is the reason why I am left without any tasks.
TLDR: Beware the 100% utilization fallacy.
I'm going to ignore your stated question ('is this normal?') and instead attempt to answer the underlying question.
As per the Scrum Guide:
Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.
As a corollary to this, as long as there is sufficient work for a Team, then there should be sufficient work for Team Members.
While it's not necessary for every Team member to be an expert in every functionality, a well-functioning Team should be sufficiently well-bonded, with enough opportunities for knowledge sharing, that swarming should at least be feasible for any given story.
Even if you know absolutely nothing of back-end development, you still should be able to swarm. You could, for example, sit alongside a back-end developer as s/he works, thereby increasing your cross-functional competency, which will help swarm more effectively in the future. Or, especially since your Team is working on bugs, you could spend your time as a QA - both confirming the found bugs are being fixed properly, and hammering at the product to find more.
Even if you don't want to work directly alongside your Team members, there are other activities you can perform to benefit the Team. You can do research or spikes to improve your own knowledge, and then disseminate it to the Team. You can go through the existing codebase and clean it up. You mention there being poor specifications - so perhaps you should work to improve them.
It seems to me that your Scrum Master is seeing you as idle as you have no tasks (or perhaps because you are idle, In which case, for the solution, see the section above).
However, the thinking that this is a problem is itself a fallacy. You need to work with your Scrum Master to clarify expectations. It's the Scrum Master's job to be a servant-leader to the Team, as well as to ensure that Scrum is being followed properly. Nowhere in there is the duty of making sure all Team members are being 100% utilized.
Normal, probably not. Lots of folks have the "it's not my job" syndrome.
Personally I (as their Scrum Master) motivate our teams to get better at swarming:
Swarming: A behavior whereby team members with available capacity and appropriate skills collectively work (swarm) on an item to finish what has already been started before moving ahead to begin work on new items
If you do not have the appropriate skills you could pair with someone to start getting them, leading to T-shaped people.
T-shaped skills: A metaphor used to describe a person with deep vertical skills in a specialized area (such as UX design) as well as broad but not necessarily very deep skills in other relevant areas (such as testing and documentation). Team members with T-shaped skills better enable swarming behavior.
http://www.innolution.com/resources/glossary/t-shaped-skills
Swarming means keeping a low work in progress limit, preferable one or two. Helping other team members to get work really done (also known as DoneDone).
We have awful business analysts that don't write adequate specifications. That's why I am left without tasks..
Help him/her? Get some skills in writing specs and do the work together. Be proactive, instead of reactively saying it is their fault.
I think being an Software Engineer means that you can go from ideas to full-fledged solutions. This means breaking down an idea to smaller tasks that result into a working software product that is adaptable over time. This is your job, not?
Update:
This does not solve your question about doing work for other teams, but just how to help your own team finishing their work. Which I think should be your first priority.
My Scrum Master says that I will have to do the other Team's tasks.
I think the only good reason to work for other teams during a Sprint is if you can assist them with something they are stuck on. Helping them complete their goals, while not jeopardising your team's goals.
Picking up work from another teams Sprint backlog seems very uncommon, as you missed their planning session and context. Pulling in full stories into your Backlog seems acceptable if your team can work on it independently. You could start on it the next Sprint or when the current Sprint goal has been achieved earlier. The Scrum Master should not change your workload during the Sprint, only the Product Owner can renegotiate the scope with the team, according to the Scrum Guide.
Other things that come to mind are: Cost of context switching and Stages of group development. Working on a single area of a codebase and with a stable team is way more effective in the long run compared to switching teams and code of of other teams.
I am hearing:
These are impediments. As a member of a self-organizing team, you have a responsibility to ensure the team makes them visible and works with the Scrum Master to resolve them.
I can't agree you have nothing to do.
From your question and your comments:
You are not doing Scrum. Your Scrum Master (arguably the most important role in Scrum) has not understood their job. They are there to protect the Scrum team. Scrum has no mechanism to protect a team from a bad Scrum Master. That your Product Owner is not keeping the backlog filled enough does not help either, but is of secondary importance as far as I'm concerned. If yours were a smoothly running Scrum team, you would simply jump in and help the analysts produce requirements when you are running out of those, but it seems that's not possible due to silo'ed analysts.
That said...
I would not worry so much about all of this. This happens all the time; Scrum is, in my experience, one of the most misunderstood aspects of modern IT. It's healthy on a personal level to accept this and not get too hung up about it. Yes, it is bad for the project and the company, but on the other hand plenty of projects like this survived just fine in the past, before there was Scrum or Agile around.
In your case, I would focus on your actual job of creating software, and start relaxing about the process. Sure, keep following the Scrum rules as far as you can, within the confines of your particular environment, but don't let a Scrum-gone-wrong (A.K.A. Zombie-Scrum, Scrum-But...) destroy your good mood.
Yes, sure, if your main "Scrum" team/project is not able to produce work for you, there is nothing keeping you from doing work from/for other teams. If this repeats, maybe you can naturally migrate into another, presumably better-working Scrum team in your company, over time.
Scrum aside, in any company, there is still one person who has the final say about what you do, and that's your direct boss. Put them into the picture with a small status email ("FYI, my main project didn't turn up tasks for me this sprint, I'll support team XYZ with their project for these two weeks - give me a head's up if you wish me to do something else") and then go find interesting IT work.
If you should have real downtime, sit down and optimize anything you can find. Be it something in your main project; researching a new framework; trying again to sit down with the requirements engineers to help them, etc.; or even just polishing up your CV...
I think that picking up other work when otherwise idle has been a standard expected feature of just about EVERY job I have ever held, I mean why would you not?
Now I might take the view that the lack of spec is a problem, and iff I have any real task domain skills in the area where this product lives, I would probably take writing some spec and getting it signed off to be the most valuable thing I could do to remove the block on the backend work, but your team, your team dynamics....
Frontend/Backend is pretty much an artificial split at least during prototyping, and if you don't have a pretty good spec, you ARE prototyping.
The real question is, do you have good enough skills in whatever the frontend needs to actually contribute without being net negative work? I am a pretty good low level hard realtime guy, (Assembler, C, C++ on small cores and DSPs), but I know that if I tried to pick up some of our website stuff our web team would be cursing me, be sure of the reality of your skills before stepping outside your core competence.
I don't see anything particularly unique to Scrum methodologies here.
Consider asking to take this opportunity to swarm/pair with another teammate. This will give you insight into new areas and build the cross-functionality of your team.
Working outside of the team is (at best) an edge case scenario. It may be an OTO instance (sometimes crazy stuff happens) but asking you to work outside the team is not an agile practice.
