Separate frontend team

Last post 01:11 pm February 10, 2022
by Darwin Achab
4 replies
Author
Messages
08:14 pm February 3, 2022

Hello,

I'm looking for advice and open debate around an idea I've been having. I'm well versed into Scrum, acting as a (proxy) PO in a relatively big company (financial sector). I feel we have a deep-rooted frontend problem in my team, and, generally, at the company.

First, my team: we are but one team of approx 10 in a bigger department which has perhaps 200, some offshore, some onsite, and we effectively have a frontend and a backend subteam. I am well aware that this horizontal slicing is against all best practices in Scrum, hence, I'm doing my best to treat everybody as one team and promote exchanges between the members (common stories for all, outcome oriented etc, refinements together and all). However, there is a physical and financial gap here: all the frontend is litteraly outsourced, and the company is being, frankly, not that attractive to good, local frontend people. The skillset is really siloed, and we cannot seem to attract any new talent.

Quality-wise, we are highly inefficient in terms of making good frontends - directives come from up above, and despite my best attempts to get feedbacks from users, these directives end up imposing themselves on us, good or bad. There are heavy traces of top-down waterfall of yore, but it tends to slowly get better with a lot of direct and indirect coaching. Technically, the outsourced frontend devs do sadly not produce the best work at this moment in time. We are also missing Designers, UX experts. Also, I cannot budget-wise get any designer, try as I might.

Now, the company as a whole: we notice that historically, the company has been a master of financial processes, and culturally, this is associated with backend and DBs. Today, the company has understood that it needs to get in a conversation with its users, and this also implies having a frontend culture - we end up producing UIs as well, and on that we have big deficiencies. Ideally, we'd say backend and frontend as one solid unit, hand in hand. Scarily enough, many departments are reporting what I described though: scarce frontend resources, and also, a lack of cohesion in terms of styling in the company and in the work processes between backend and front. Our big problem now is: the company has earned a bad rep from years of old school thinking and internal turf wars, and is not attractive for the talent we're looking for. I want to produce solutions which fit our users, and am effectively doing my best day-in day-out to break or drive around the barriers we have here. This is my personal drive, and I'm patient.

To my question then: looking at the symptoms - no designers in house, scarce frontend engineers across all teams, lack of guidelines, lack of operational power to enforce some changes -, I'm openly wondering if it wouldn't be a bad idea to have a "frontend team" (with engineers, designers, ux experts) which is acting across the whole company. I see it this way: we consolidate resources, have a clear mandate, and could help the teams. It's also an easier sell for talents ("you're getting in a frontend/ux/whatever team, yeah", instead of "you're getting in an old-school team where you draw what's been decided by top management"). The team members would then be sent to other teams who request it, and intervene there as consultants over multiple sprints, just long enough for the "receiving" team to have clear guidelines, technical know-how, and design consultancy to be able to fly alone.

Of course, the bad side of it is that it flies in the face of the idea of one team = one product = one self-sufficient team with all appropriate skillsets. But we're not in the silicon valley let me tell you, and we do not get that skillset today nor within a good one or two years until the company improves its image. Also, if done badly, it means: more handovers, less productivity. Yet, seeing how the company cannot get its frontend/ux strategy operationally effective, would that not be a solution ?

I'd be highly interested in your point of view here. Thanks.

10:11 pm February 3, 2022

Why are you only a proxy and why doesn't the real Product Owner get a grip on the extensive product issues you mention?

06:08 am February 4, 2022

The product owner has a mix of management authority and is as well one of our best devs. That all stems from historical reasons.

I do respect him very much but obviously there are real conflicts of interest in here and he delegates the fronted part to me. I need to be creative with this, let alone in terms of resources can overlap.

03:36 pm February 4, 2022

This A solution that I've seen used successfully is that all of your UX Designers work as part of the Product org and that the designs are provided as part of the information used to describe the problem to be solved.  This will provide your company wide style and behavior consistency that you are missing. 

The Scrum Teams will still need to have full stack development capabilities.  But by moving the UX design to the Product org, your Developers will all work off of common designs.

Another option is to create a team that delivers an internal product.  That product would be components to be used to create front ends.  The team's Product Owner would gather Product Backlog ideas from the various Scrum Teams. The individual Scrum Teams would use those components to create a UI.  This still allows teams to own the UI for their part of your product offerings and it also allows for maintaining commonality across the look/feel.

There is nothing in the Scrum framework that says all Products have to be for external use.  Scrum is intended to help solve complex problems where requirements can evolve. I think your situation fits that definition.

01:11 pm February 10, 2022

Thanks for the answer.

I should point out that we do have a shared library of sorts, yet it is not being developed actively, or rather, by a few individuals. This then slows down the work.

I notice as well that many individual teams just move without those components for that reason. I’ve seen results which look like less of the sum of their parts, as of components had been cobbled together.