UI in scrum - what's the silver bullet?

Question

I'm a certified scrum master and, by trade, a UI/UX/Front end dev guy.

More than most I come across the issues faced by having folks with my skill-set within a cross functional team (the 'vertical slice')

The problems are:

• Front end dev effort and back end dev effort aren't pinned. 2 extremities of this are: A sprint backlog contains 40 story points and all are UI specialist work, and only 1 person is available to do them with another 5 being left with nothing to do. Polar opposite: A sprint backlog contains 40 points of which 0 front end / UI effort is required. 5 devs are busy but Mr/Mrs UI has nothing.
• Nearly always UX, usually UI and sometimes front end development can be forerunners to development. If you wanted to follow the vertical slice strictly you'd be creating a severe bottle-neck by waiting on that work before development starts.

I've seen solutions batted around, some better than others...

Don't have specialists, teach everybody to do everything.

I don't think this works. Developers can't design and UI/UXers are not going to learn Java overnight. Likewise we've all seen what happens when we test our own code.

Have a separate UI/UX/FED team

Personally I like this solution and have implemented it in the past, but it's oft criticised as it introduces a specialist team. It also plays with velocity as you're taking work away from the team.

My chosen solution, which I'm looking to improve on

The UI team is a Kanban team working alongside scrum dev teams. When a story goes in to a dev team's sprint, if any UI work needs doing a card also goes on to the UI team's kanban board. Stories can also appear on the UI Kanban board from Business Analysts, Product Owners, other Scrum Masters, Devs. The TODO columns is very fluid and constantly re-prioritised. Story estimation works as before. The difference here is that there is a constant throughput, based on priority, from UI. The problem you might have (going back to our all-UI example) is that when a large story gets dropped on UI this last-minute it becomes a bottleneck. The benefit with this system is that the product owner or BA could have dropped that on the UI team ahead of time.

---

TL;DR

Is there a better way to make sure specialist skills are kept busy in a sprint which you believe to be better than my chosen solution above?

Answer 1

A sprint backlog contains 40 story points and all are UI specialist work, and only 1 person is available to do them with another 5 being left with nothing to do.

Have the other 5 help the 1 person in other ways:

• Optimizing images using graphicsmagick
• Dogfooding the UI for security and feasability gaps

Nearly always UX, usually UI and sometimes front end development can be forerunners to development. If you wanted to follow the vertical slice strictly you'd be creating a severe bottle-neck by waiting on that work before development starts

Look to eliminate queues to solve the problem:

Despite a total development time of only two weeks, features still took two or more months to become a reality. Why was this?

It happened because features spent most of their time simply waiting around in queues. The product department had a backlog of requests from biz-dev, the design team had wireframes waiting to be made beautiful, engineering had specs waiting to be made whole. Every step involved a queue and an associated delay

And create a limit on the usage of the backlog:

Suggestion: Do not allow more than a month or two of work to get into the feature backlog list. Once the backlog is full, do not allow new items to be added unless you remove an item. Do not spend any time speccing, designing, or talking about backlog items: the backlog, in fact, should be seen as a list of things you are not allowed to talk about or work on

References

• Peter Nixey - Engineering is not the bottleneck

• Software Inventory – Joel on Software

• 7 Reasons Why Lists Are Slippery, Treacherous Creatures And Not Necessarily Your Friends After All – Procrastination: Cultural Explorations

• Feature Teams

• 7 Problems Growing Design Teams Face – Leading Design – Medium

• Functional Teams versus Cross-Functional Teams | How to Grow Structure | InformIT

• The Lean UX Anti-Pattern - Cross-Functional Silos | Tendayi Viki | Pulse | LinkedIn

• Break down silos, build cross functional teams, and run twice as fast

Answer 2

It's worth noting that a team is not only cross-functional, but also self-organizing. This means specialists should be open and honest about whether their skills can help achieve a sprint goal set during Sprint Planning. The team is empowered to use their skill constraints as a means to address work that is deemed valuable for the sprint goal.

This means the team can, and should, reach out to subject matter experts to help them understand their gaps in order to achieve the sprint goal. Value is higher priority than readily-available skillsets, and the Scrum Master should coach both Product Owner and Development Team on keeping this in mind. These gaps should be addressed during Sprint Planning, when the team works together to plan HOW they will manage their work during a sprint. Development Teams should be empowered by the organization to organize and manage their own work.

Changing Development Team members is not advised mid-sprint, but if the Development Team believes that re-organization would help them to meet the Sprint Goal, they should be empowered to introduce other team members to the sprint, preferably before work begins.

Answer 3

As you've probably seen from the diverse answers, there is no silver bullet. The answers I see are about how to organize the way you approach UI/UX now in a better way to improve flow or work distribution. Those are all awesome places to start. You will hit a ceiling on that improvement pretty fast.

UI/UX is a lot like DBA work and Testing work in that the way we used to do it won't scale well - it's a solution designed for a different way of working. When we talk about testing, teams move to a style where testing is done throughout the development process and sometimes it's done by the tester, sometimes by developers. They use new approaches like BDD and TDD to approach the whole discipline of quality assurance in a more agile way.

Sooner or later, you'll need to do the same with UI/UX. The approach of creating a design that other people implement has too many predictive assumptions built in. The problem you end up needing to solve instead is "How do I ensure that anything we create is easy to use, intuitive, and meets our desired aesthetic. I am an amateur graphic designer at best, so I can't tell you exactly how to do that. However, just a few things I've seen teams use to enable this:

• Style Guides: If you help your developers get used to style guides, a lot of the most menial design work goes away, freeing you up to focus on the harder problems.

• Paper prototypes: this is a great way to quickly discuss the experience with the developers and the users (even at the same time). I've seen UX experts use this tool to go through a dozen design iterations in under an hour. It's also worth noting that there are some great software tools for doing this that make it easier to take those prototypes and turn them into a finished product, but paper is always a great place to start.

I hesitate to try to give any more "answers" than that - you're the UI/UX expert. But this is the direction you'll need to go after the improvements in the answers give you all of their value.

Answer 4

A smattering of thoughts and suggestions:

• How "complete" do you require UX specs to be before dev work can start? Can UI pre-work take it as far as approved wireframes, then detailed "pixel" design done in parallel (and in close collaboration) with development?
• Does your UX team do much usability testing or focus group work? This is valuable but non-urgent work that can fill UX team cycles when the dev team is busy with non-UX dev work.
• UI/UXers learning Java may not make sense, but they may be able to handle CSS or other stylesheet notations, if the product code is architected well to modularize stylesheet code away from functional code. Thus a UI team can engage in some global design improvements more independently from dev. You may even be able to give them a test environment where they can experiment with and user-test minor design changes independently of the dev team.