Forums

Hello all,

I am sharing one of the problems that I do not have a definite answer so far. We develop Cloud products and the components are rather complicated, i.e. there are multiple teams, each focuses on one functional area, e.g. for backend teams: on the hypervisor alone, on featured software that will be deployed into VM via some enablement, etc., then, there are also API and UI teams (which can be merged).

As far as I understand Scrum, a Story has to be completed. And given that these teams work at different functional areas, and the product dependencies are unbreakable or not-easily decoupled, they therefore, are running as separate teams and handle their own backlog items instead.

So, here's my problem, let me pick a sample User Story,

In order to prevent search engine to index the content
As a user
I want to have an option to block web crawler

The acceptance criteria/steps are straightforward for a site within the cloud product, a user can adjust a flag via the API or UI, and running a web crawler on this site won't be able to index anything.

This feature requires the API team to support a new flag and the backend team to make the web server to read the flag and perform the blockage.

If I have to force features to be completed end-to-end in each Sprint, the backend team may not be able to catch up as the work on API is relatively simpler. You may suggest that I should scale up the backend team instead?

Or should I split the Story, so that API stories can be accepted as early as possible, simply by verifying if the flag has been set? But that's bad because the Story is not considered really done, and we will have to come back to test it end-to-end, and it sounds like duplicating half of the work we have done earlier.

Or should I adjust the length of a Sprint so that the API and backend team can complete these Stories within the same Sprint?

Hi yclian,

if i underdestand you right you did split your teams in a horizontal way like an UI Team, an API Team, a Backend Team and so on. So you have developers in your team which focus on one specific layer of your product. According to the Scrum Guide a Team has to be cross functional in order to complete a user story by it's own. What about splitting your teams verticaly so you have at least one "specialist" of every layer in every team? This does not mean that those persons are forever responsible for their layer in the Team since every Team member in a Scrum Development Team should have the skills to do nearly every task but they could lead the discussion and help the rest of the Team.

Note that this is just my personal opinion :-)

I just attended an Agile conference in Orlando last week, and I brought up this exact same issue with some of the experts. They suggested, like Pascal above, to slice the teams vertically. One expert even called them 'Dynamic Feature Teams'.
Sure, Scrum says to keep teams together as much as possible to build trust, stable velocities, etc. But, adding a bit of Kanban flavor, go ahead and create/adjust these Dynamic Feature Teams as needed.
We are trying it right now in phase 2 of our application. It does help. It also brings up a few new issues. But they aren't as bad as the issues with multiple horizontally sliced teams waiting on each other.
In phase 1 of our application, we had team C waiting on team B which was waiting on team A. By the time team C got started, team A forgot what it had done because 3-5 sprints had passed. So they had a hard time supporting teams B and C on that feature. A lot of time was wasted. So we're hoping these Dynamic Feature Teams are the answer.

I go with Pascal in his thought of having crossfunctional teams, is the best solution. But if there is no way to mix up your UI and your backend team may try to change the relation of the team, so you not get both of the parts as one feature to your customer. Let the UI-Team be the customer for the backend team, so you always have delivered parts of the implementation from the view of the the teams. You avoid having the done team hanging in an "I don't know" state while they are waiting for the other team. They are done, and have delivered (to their customer) and can go on.

It's not the optimal way (as a said before, I think the optimal way is to make the team crossfunctional over UI and backend) but this can be in some company-context a long way, and you can may use this to deliver between teams and keep every team in a state where they can follow scru,m.

Hello all,

Thanks a lot for the response. Yeap, I would go with vertical slicing the features too if I could, IMO, it's the matter of time to have the skill set required to work on HV to be shared across the team - and it can be a really long time.

What I see feasible are (at least within a shorter and predictable period of time)

- Have the backend team to learn the frontend API stuff as a start
- Choose a few team members and start setting up the dynamic team - it might sound too ambitious to make every one cross functional as a start?
- Make frontend the customers (but this is arguable, the backend can be the customer of frontend as they need data, maybe I just need to settle than arguing the direction)

Yclian,

A few other things that might be important to know are:

1. Have you asked the teams? If so, what did they say?
2. What is your role on the team?
3. How big is each team that you're talking about?
4. Are your teams co-located or distributed?
5. Is the PO the same person on both teams?
6. How would you describe the Scrum maturity of your teams?
7. Do you do all other Scrum practices(besides cross functional teams)? If not, which ones do you currently not do?
Some of the answers to these questions might lead me to suggest other ideas.

Here is an idea that ignores the above questions, but if I had the answers to the above questions, my advice might change dramatically, so reader beware. :-)

1. This is why feature teams are better. I don't necessarily agree with the Dynamic Feature Team concept,but you can certainly begin building feature teams in an incremental way, with the goal of eventually achieving a cross functional, feature team. See Cohn's Succeeding With Agile... and http://www.mountaingoatsoftware.com...ture-teams for more good info on feature teams vs. component teams. This(not having fully cross functional teams) should be considered a fairly high priority impediment.

2. If at all possible, I'd recommend getting a good Scrum coach because problems like these are not easily solved by practitioners. It sounds like you could use a good re-org of your teams into specific feature and component teams in the short term, then move to full on feature teams in the longer term. Often a coach can help in this arena tremendously. Keep in mind that this statement of mine is self serving in that I'm a professional Scrum coach. :-)

3. Now, if #1 and #2 is just not possible at all, I consider this to be a problem of "external dependencies" between Scrum teams. In your situation, which is complex to convey over the internet using text, I think I would approach it this way:

The back end team is a "component team." The API team is a "feature team". Someone from the API team is either the PO or a *very* key stakeholder involved in the backend team.

It sounds like the dependency really only goes one way. The API team depends on the back end team. So, the back end team has one Story whose title is something like "Add option to block web crawler." They consult with their PO and key stakeholders(the API team, among possibly others) as to how to define the *interface* between the API layer and the "back end layer." -- in other words, the "what". The backend team finishes the story and demonstrates the functionality at a Sprint Review, where our API team PO or key stakeholder is present(as well as anyone else from the API team who wants to attend).

The API team now implements the story you speak of and performs end to end testing, and demonstrates that feature to it's key stakeholders(presumably the backend team is not a key stakeholder here on this story).

That is how you coordinate a story using what I call "the sequential method".

You can also do the "parallel method" like you described, where both teams take it on at the same time. I only tend to favor the "parallel" method when I'm 95+% confident that both teams can finish their piece in the same sprint, and where both teams have a strong history of tight and happy collaboration.