2

We have a team of full stack developers and one specialist UX expert. We had enough work for everyone, now as we approach release we hardly have any UX work. Eventually I am left with two options,

  • Inform the product owner and find appropriate UX items and have them prioritized. Which is kind of against the rule of backlog prioritization and need in the product..
  • As a scrum master, discussed this with development team and asked them to come up with some solution, which eventually ended up with below point.
  • Groom the specialist to explore different areas so that he could contribute without boundaries. Its understandable that initial days would be tough and time consuming and help is available readily.
    • The problem in this is, this has the initial hesitation of the developer to dive into completely new territory but I wonder what's right and how should this be handled.

How would you handle the situation?

I wonder, lots of the cross functional teams will have specialized UX developer(say for mockup's), UI developer(JS dev), code behind guy (say c# or java) and Database (say SQL, Mongo) etc. How do they handle situations when a sprint may have only UI/UX items prioritized for some reason.

Or

Given a time frame when the application faces background slowness and product owner expressed interest of prioritizing the code behind items. What will the UI/UX guys do?

I hope I was able to explain my situation.

  • Since you have UI jobs in the backlog, why not have UX expert work on a branch for a future release? – Danny Schoemann Jan 21 at 12:51
  • We were doing that @DannySchoemann but now we can see that soon someday there may be nothing in terms of UI. – user12427779 Jan 21 at 12:55
2

TL;DR

Projects change, products evolve, and team composition often needs to change along with them. Slack and reasonable levels of idling are the cost of doing business in an agile framework, but don't be afraid to add or remove people from the Development Team when it measurably benefits the project.

Analysis and Recommendations

Analysis

You may have a cross-functional team, but your UX person sounds like they aren't themselves cross-functional. This is really the X in your X/Y problem. At heart, you're asking what you should do with this person when they aren't being adequately utilized within your current business context.

Don't fall prey to the 100% utilization fallacy. 100% of the Development Team does not need to be utilized at 100% for an effective Scrum implementation. In fact, very high levels of utilization will often reduce flexibility, throughput, and self-organizing behaviors within the team. Don't do that!

If you've gotten towards the end of a project, it may be too late to start encouraging a Development Team member to become cross-functional in a way that brings a near-term benefit to the current project. The optimal time to have done that would have been earlier in the project lifecycle.

However, if you take a longer view, it's never too late to train teams or individuals for future needs. This is especially valuable in organizations with long-lived teams that will work on multiple projects over time, or companies where there will be similar/related projects in the future.

Recommendations

In your specific use case, I'd evaluate whether the project still needs a dedicated UX specialist on the team. If any remaining UX work can be handled by another cross-functional team member, or if the Product Backlog can be pruned of optional or non-essential UX work (under the YAGNI principle), then you should strongly consider removing your I-shaped UX person from the team altogether. You can then decide whether to stick with a reduced headcount for the time being, or if it makes more sense to replace the I-shaped person with a more T-shaped individual who can work on other deliverables in addition to any future UX tasks.

Don't think of this as a matrixing opportunity; that's not at all agile. Removing a specialized team member may require treating future UX work as an external dependency or schedule risk. Adding another team member in the future, whether the same person or someone unfamiliar with the product, often requires significant ramp-up time on both product and team process, and this will likely fall afoul of Brooks' Law.

In the end, it really just comes down to a cost/benefit analysis. You should calculate:

  1. Whether the cost of carrying an unproductive team member for the remainder of the project against potential future need will have a material impact on the project's budget or profitability.
  2. The opportunity cost or schedule delays that might be encountered if the team loses a dedicated resource.

Collaborate with the Scrum Team and line management to determine the cost/benefit and gain consensus; then have senior management make a business decision. It doesn't actually matter what you collectively decide, so long as the majority of project stakeholders (including the team itself) see the decision as sensible and necessary. Treat any residual risk related to the decision the same way you handle other project risks: accept, mitigate, or transfer it.

Disrupting a cohesive team should be a last resort, and shouldn't be done based on the needs of a Sprint or two. However, updating team composition to better meet the needs of the project in a forward-looking way is a valid way to "[w]elcome changing requirements, even late in development."

  • I agree, thank you for your help. We are proceeding towards making the member cross functional, rather than hiring a new one. – user12427779 Jan 22 at 4:14
1

A similar situation happens with the developer-tester relationship. In simplified terms, at outset there is nothing to test and everything to develop, but at the end of the project the opposite is true.

There are several common strategies to deal with this:

  • Blur the role boundaries. For example, developers do some testing at the end.
  • Have the team perform support functions when there is nothing else to do. For example, testers create test plans, developers write documentation.
  • Move team members in and out of the project depending on the project's resourcing needs.

In your case, the situation with the UX expert sounds fairly pronounced. I'd move the UX expert onto some other project until needed again. If there isn't any other UX work, you may need to take another look at how much value a full-time UX expert is adding to the organization.

  • Thank you Robb, we are trying to groom the specialist in other areas also. Slowly and gradually. – user12427779 Jan 22 at 4:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.