Scrum in Web Dev Agency

> ... a dev team of 3 people with absolutely different skills.

What actually makes them a "team" in this case? How do they plan to work together to deliver an integrated release-quality increment every Sprint? Has their Scrum Master explained to them that this is their responsibility?

At this stage I would be principally interested in seeing evidence of self-organization. That's the essential capability which is needed. The details of whatever plans they come up with would be of only secondary importance to this.

Ian,

Thanks for your reply.

Team members do understand it's their responsibility to deliver an increment. They have proposed the following solution: split each story into sub-tasks as design/front-end/back-end and plan the sprint accordingly. So designer and back-end developer will go ahead of the front-end developer, but still will bring the whole lot to his attention on the DSM.

It means that at some point PO will have to include sub-task in the sprint but ignore the story in general, which is wrong.

What do you think?

Do you think this kind of project may need a different approach in management?

John,
First of all you should remind you developers that the team members collectively own the responsibility of getting the job done. They win as a team or they fail as a team.
As a second step, you should ask your team what will be achieved, if the proposed approach is implemented. Will it help the team to get a potentially releasable Increment of “Done” product at the end of each Sprint? Will they implement more PBIs that meet DoD criteria? Most likely their answer will be "no".
Ian already mentioned self-organization as the essential capability of the Scrum development team. But I’d like to mention t-shaped skills as well. T-shaped skills mean that a team member has deep vertical skills in a specialized area (such as UX design or back-end development) as well as broad, but not necessarily deep, skills in other relevant areas (such as front-end development). So your team should concentrate on the development of t-shaped skills that are critical to achieving shared success.
In your case it is preferable to recommend you teams to limit the work in progress, and instead encourage as many developers as practicable to focus on completing a smaller number of PBIs. Even if skills limitations prevent a back-end developer and a designer from working cross-functionally, team members should still organize their work to ensure a good flow through the sprint so that no one team members (a front-end developer) is overburdened.
And don't forget that each team member is responsible for making sure she/he is fully angaged at all times.

I wanted to suggest a different approach. Beyond looking at cross-skilling and other good ideas mentioned to make the development team more Scrum-friendly, I think you may need to assess whether Scrum is indeed a good fit for what you're doing, as you indicated in your last post.

I don't know how large your customers and projects are, so I don't want to say Scrum won't work, but keep in mind that Scrum is designed to solve complex problems iteratively. Building a simple website to do certain common things based on a design that has been blessed by the customer may be too easy for Scrum and hence may not be a good methodology fit for this.

Do your customers expect to have continual involvement in a Scrum project, attending regular spring reviews, or are they content to do Waterfall, handing off approved designs for you to implement exactly as specified and tell them when you're totally done?

Does each Scrum Team need a backend developer? Why? I would suggest that if you are using REST, could the backend developers be moved to other scrum teams to work on purely backend PBIs that support the frontend developers. Then your main teams can just have the designer and frontend developers on them. This can also help create a nicely-decoupled service architecture.

Martin

It isn't a matter of "splitting" a story into technical tasks on the Product Backlog, and expecting the PO to order them. The PO should be focused on product value. The Development Team ought to plan the stories into tasks on their Sprint Backlog during Sprint Planning.

As long as a feature-complete, fully integrated increment of release quality is delivered each Sprint, and which meets a valuable Sprint Goal agreed with the PO,, the Development Team can self-organize how they wish.