We are currently trying to change the work process from waterfall to Agile. 

We are currently trying to change the work process from waterfall to Agile. 

Right now it sounds as though you are trying to compress a waterfall process: one in which Developers (front end, designers etc) adhere to narrow skill silos at the expense of collaboration, shared commitments and joint accountabilities.

With good transparency over workflow, the bottlenecks and starvation issues you describe will surely become apparent. What will the Developers then do about it? Will they step out of their silos to improve joint focus, limit work in progress, and thereby stop starting and start finishing? Have you had that discussion with them yet?

1. There will be no design right after Sprint Planning, but in this case, will the front-end developer not have work until the design comes out? (If the development setting was finished early...) It is said that all team members will have a meeting on planning and design, but isn't it right that the front-end developer has nothing to do until the designer makes the design result?

What, exactly, do you mean by "design"? There are multiple types of design, but it seems like you're talking about product design, user experience design, user interface design, or something similar, as opposed to technical (systems or software) design.

There are many ways to handle this, and which one works best depends on your team and environment.

One possible approach is to move this type of design to product management and refinement. Product management is about figuring out what to build. Understanding how people will interact with this system falls squarely into the category of "what to build". You can have some level of user experience or user interface design done when the Product Owner adds Product Backlog Items to the team for refinement and eventual selection in a Sprint Planning event.

Another approach would be to move this work into the Sprint and have the designer as a member of the Scrum Team. The designer can pair with someone, perhaps a front-end development specialist, to do the design work and even begin to implement it. There is likely to be cross-development of skills, so perhaps you'll end up with a designer who can do some front-end development work and a developer who can take on some design work. Having cross-functional people is the next step beyond a cross-functional team.

2. Likewise, I think there will be a time when each position has no work at some point. For example, we only took one story per sprint, and I wonder what the designer does after the designer completes his/her work in the middle of the sprint. 

At that point, it will be time for developers to focus on developing, and I wonder how planners or designers can help developers. Or I don't know if it's possible to help them. 

You shouldn't necessarily be trying to avoid idle people. It's good to have some slack that allows you to handle the unexpected. But there may be some work that adds value that people can do, like building skills in other areas, refinement of future work, paying down technical debt, or automating parts of the process that are manual. These are things that can be dropped quickly to help the team accomplish their goals but would add value if done.

Scrum is about the team, not the individuals. The Sprint Goal is a commitment for all the Developers. The team strives to be cross-functional and to help each other achieve the team's goals. Look at what the individuals can do to help the team accomplish their immediate goals or set the team up for success in the future.

3. In the same situation as above, some people say that we can bring another backlog then plan and design it. However, from what I learned, Agile only takes user stories as much as they can handle in one sprint. I think even if you add a backlog that was not in the Sprint Planning meeting, you may able to complete only design it. Also, it doesn't seem to make sense to take developers to the time they focus on developing and have a meeting about additional backlogs. Because of this meeting, I think that the backlog that was originally planned may not be completed.

Idle people or starting a new Product Backlog Item aren't the only options that the team has. Refinement is one option, to start to prepare additional Product Backlog Items for upcoming Sprints. If the Product Backlog is well-ordered, people can look at the top and make sure the top is decomposed sufficiently and has enough detail to allow the team to make progress when it's pulled into a Sprint. Every team should be setting time aside for refinement. Skill building is another good thing to do. But if you know that a particular piece of work is going to be necessary in the upcoming Sprint, there's nothing wrong with starting it even though it won't finish within the Sprint timebox, but there's some risk that other, more important work will supersede it following the Sprint Review.

Not to be self serving, but send someone to a Scrum.org class.  

I've seen people implement Scrum by using Scrum.  Make a change backlog, a change team with a PO and Scrum master.  Use Sprints to implement changes.

The advice given above is fantastic.  But I want to ask you something.  Is the organization ready and willing to change in order to support the new world?  If the organization continues to dwell on the need to have a person busy 8 hours a day it will have a difficult time with the transition. The organization has to learn that it is more important to be delivering valuable increments of usable functionality than it is to have people working 8 hours a day.  The goal of agile practices is to deliver increments of value, learn from them what is needed next, deliver that, repeat.  You do not plan to deliver a new feature in 6 weeks.  You plan to deliver some value in every Sprint and stop delivery when there is no longer anything the stakeholders want or need. 

The organization has to recognize that there are ways to be productive that does not involve writing code or designing user interfaces. Personal development benefits the individual and the organization for which they work.  Cross training will help the individual learning as well as the individual that is training as they frequently improve their own abilities by teaching others.  

Refinement of Product Backlog items is necessary and there will have to be time allocated by all of the people doing the work to the activity.  

Working on technical debt is as important as delivering new features.  So that should also be included in your Product Backlog. 

Scrum Teams need to be able to self-organize and self-manage their work.  Decisions should be made closest to the actual work as possible.  Managers do not assign work.  Individuals pull work from a backlog of items that are needed in order to improve the product.  

Have all of these things been discussed and plans put in place for those transitions? If not, the questions you asked may not matter.

I think I should have learned Agile's philosophy first, not Agile's methodology. 

  

Thank you to everyone for your advice.