Skip to main content

Question from a Program Manager to SCRUMmers

Last post 03:31 am March 29, 2014 by Ian Mitchell
9 replies
07:07 pm March 20, 2014

This is our first project using Scrum and Agile. I am the Program Manager of a software project.

I am being told by our Scrum Master that a process we are using is not allowable in Scrum.

The documented process is, during our 3 week sprints, when a story involving a new graphical design element is completed, a member of our UX Team reviews it to see if the HTML rendering of the design looks similar enough to the static comp of the design. If it doesn't, he documents some tweaks and the developers tweak the elements. If the tweaks the UX Team wants are greater than the few points allowed for tweaking, they go into a story and then are put in the backlog for a future sprint.

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.

IF UX does not perform these reviews, the Scrum Team continues developing the design not as desired, and they have to perform rework in the next sprint. It also pushes out the UX timeline in the project.

It seems to me that Scrum is the enemy of the good - that it is so fragile that any flexibility to accommodate the best good of the product, will "ruin it".

It is growing resentment in the rest of the team. In their opinion, the Scrum Team doesn't play well in the sandbox.

Is Scrum really this rigid?

12:33 am March 21, 2014

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.

03:23 am March 21, 2014

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.

05:25 am March 21, 2014

> 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.

12:18 pm March 26, 2014

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'.

12:55 pm March 26, 2014

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?

01:37 pm March 26, 2014

> 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.

01:48 pm March 26, 2014

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.

01:51 pm March 26, 2014

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.

03:31 am March 29, 2014

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.