Question from a Program Manager to SCRUMmers

What does the development team think about all this?

Does the development team want their work to be as complete as possible by the end of each Sprint. If so, this almost certainly means anyone invested in the work (UX in this case) is part of the creation, right? Ideally, the team includes the UX person this can check UI fit and finish frequently and in small steps as the feature is created.

What you seem to be describing is a set of "sign offs" or "gates" that would prevent the development team from being completely done by the end of the Sprint. Getting the feature complete without any remaining work to be done is critical to success for everyone.

It is hard to talk about things like this without real discussion, because the full context of your situation is probably not coming through in your post. There are always many sides to a story, after all.

Regardless, I encourage you to all work together in getting the feature done, with no work remaining, by the end of each Sprint.

What is your Definition of Done for these stories?

Scrum mandates that a product should be "potentially shippable" at the end of each Sprint. If a story is not shippable until it has been UX reviewed and tweaked, then it should not be considered as Done until that has happened.

As ElegantCoder says, the UX team should be considered part of the Scrum Team. The UX review is not an impediment as far as the Product Owner is concerned, and by delaying the UX review until the following Sprint you would be introducing technical debt.

> Our Scrum Master believes that this UX review cannot happen during a
> sprint, that UX must wait until after the sprint and then request the
> edits in the sprint review. He believes if he allows the current
> process, that he is not fulfilling his Scrum Master directive to
> remove impediments for the Scrum Team.

Has the Scrum Master been told, or otherwise given the impression, that UX people cannot be assigned to his own team? If so then I can see why he might adopt this position. Let's examine things a bit more closely.

In the process you describe, a "completed" story is not actually "Done" until it undergoes UX review. The reviewer documents tweaks, and then the developers perform rework accordingly.

In lean and agile terms, this is waste. There shouldn't be any going back and forth between Development Team and UX Team members so developers can complete items on their own Sprint Backlog. Neil and Elegant Coder are right: in Scrum there should be a clear Definition of Done, sufficient for work to be potentially releasable. A Development Team should have all of the people and resources necessary to meet their definition, and without dependency upon other teams for achieving it. UX capabilities should be included in the Development Team if that's what Done requires.

So, if the Scrum Master believes that he can't bring UX people into the Development Team, he may conclude that the team's Definition of Done cannot address UX considerations. After all if it *did* include those considerations, his team would not actually be able to meet it under their own steam. That's why he might be trying to remove this UX "impediment". Perhaps it's something that impedes his team from completing sprint backlog items as per the best DoD they can genuinely achieve. I can't be sure of course, but it smells like this is the problem. The Scrum Master may perceive that the exclusion of any UX dependencies is the least-worst option available at the present time.

The two key characteristics of 'Development team' are they are 'Self-Organizing' and 'Cross-Functional', which means the Dev team should have all the necessary skills to deliver the project. There are no sub-teams or any other role than 'Developer' in the development team, therefore the UX team should be treated as part of Development team and each member of UX team and Dev team should actually work together in a self organizing way as a one team. This means, the team should plan UX review/assessment as the work is getting 'done' instead of waiting all the way until end and then planning a review. As per Scrum Guide - 'Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule'.

First, thank you ElegantCoder, Neil, Ian, Pankaj, for your replies. You provided a lot of good insight for me to consider and learn from.

Yes, the UX person is on the Scrum Team. After a fifth meeting yesterday about this issue, I realized the issue isn't that Dev doesn't want the UX Scrum Team member to review/tweak, it's that they don't want her to consult with the UX lead who is not on the Scrum Team. What she provides as the UX Review Results contains edit requests from him. They want only her review results, not the non Scrum member. By the end of yesterday's meeting, the Scrum Team made the decision do a trial run of allowing this consultation during the next sprint to see if it negatively impacts the sprint.

So the meeting outcome went in my favor, good for me. But the Scrum Master is quite upset, and that bites for a number of business and interpersonal reasons. He started the meeting, which he was the administrator of, with, "I am here with the Scrum Team's best good as my priority"(paraphrase).

The Scrum Team is 12 members of the 45 member Product Team. When they sit down at a meeting and the Scrum Master tells the non Scrum Team members that he is there with the Scrum Team's wishes as his chief goal and driving force (paraphrase, but very close), it completely turns the rest of the Product Team off to Agile and Scrum. Does this Scrum Master just have bad diplomacy or is this really how it's supposed to be?

> The Scrum Team is 12 members of the 45 member Product Team

That needs some reconsideration. The Scrum Team alone is too big...and even then one of its members is deferring certain decisions to a non-team member. Agile practice is suffering.

I suggest refactoring these people into smaller Scrum Teams, preferably feature teams, each of which can *wholly* action the work given to them. They can draw this work from the same Product Backlog, and they should aim to integrate their deliverables each Sprint into a potentially releasable increment.

I'd be inclined to try and resolve these systemic problems before addressing any perceived interpersonal issues.

The other team members are Sales, Marketing, Operational Readiness, Curriculum Development, Learner Experience, Solutions. Our product isn't the development of code, per se. The code is the means by which we deliver out product. The other members of the Product Team have no interest in the code development, by nature of their expertise, and they will not be managed by agile methodologies.

Question on your comment about the size of the Scrum Team. I'm curious as to why you say that. The Scrum Team is the developers, the Product Owners (2 managers of the developers), and 2 Scrum Masters, on for AX and one for UX.

I should say, within the 12 that there are 2 Scrum Teams. I didn't explain well at all. There is an LX and an AX scrum team.

In order to be a Scrum Team, each one of these LX, AX, or UX teams must be able to take a Product Backlog Item through to completion without impediment or dependency.

The hallmark of a "team" in agile practice is the ability to wholly complete the incremental delivery of work, under a process that is wholly owned by the team itself, and in accordance with a Definition of Done that is robust enough for each increment to be potentially releasable. It sounds as though this is not the case here. It seems that teams are decomposed by functional area, rather than organized by their ability to achieve cross-functional feature completion.