There are many concepts of Agile and Scrum that new Development Teams may have trouble with in their first couple of sprints; daily builds not working, acceptance tests not automated, regression tests not automated, and on and on. These problems will pop up and the team will need to deal with them as well as anything else that comes between the team and a quality product they can be proud of. I've listed below some problems that by themselves aren't that big but I think have a long term impact on how well a Development Team becomes self-organized and cross-functional. I believe these are transitional problems that once solved, can help turn a group of individuals into a strong Scrum Development Team.
Development Team isn't collaborating on designs and task identification.
The last thing a Scrum Master wants to hear at a retrospective is that team members couldn't help one another during the sprint because, "I didn't know anything about ___ ". This, or something like it, will happen in the Development Team's early sprints. The biggest reason for this is not everyone in the Development Team understands the high-level design or knows exactly what the tasks are about. This is usually the result of the walls people have built around technology areas or themselves. This behavior is often seen in a waterfall environment where the individual hero is praised and usually given the greatest rewards. However, the reason you and the company are most likely moving to Agile is to increase productivity, have more frequent releases, have happier customers, and increase profitability. The concept of individual heroes now becomes a drag on these plans; no one can pick up the work of a hero if that person is sick, on vacation, or wins the lottery and leaves. Heroes also tend not to ask for help if they find themselves in some kind of trouble; that wall they built not only isolates the technology but it also hides mistakes and indecision. Agile and Scrum welcomes these heroes into a Development Team but asks that they do two things: teach their specialty area to other team members and to learn the specialty areas of other team members. Having a Development Team that can do most any job, even if it takes 3 times longer to do it, will have profound benefits for the Scrum Team, the customers, and the company. A Development Team where everyone can collaborate on the design will result in the best designs. A Development Team that collaborates to find the simplest tasks to accomplish work will maximize the amount of work not done.
The Development Team's collaboration begins with the second part of the sprint planning meeting. This part of the meeting is for the Development Team to start "designing the system and the work needed to convert the Product Backlog into a working product increment." This is meant to be a collaborative effort by the Development Team to identify the work necessary for the first couple of days of the sprint. The Scrum Master should not only ensure this collaboration happens during the sprint planning meeting but should also ensure that the team does this throughout the sprint to identify the designs and tasks needed to complete each story.
Development Team feels estimating is a life and death struggle.
I was once at a sprint planning meeting where one person could not live with an estimation of 8 hours and insisted the 'correct' estimate was 12 hours. This person could not compromise on 9, 10, or even 11 hours: the correct estimate was 12 hours. I'm sure that in every company, every person estimating has experienced this in one form or another. There are going to be people in the Development Team who are afraid of being wrong or insist they're right. There may even be rumours that someone was let go because of poor estimations. Where I worked, this was a commonly stated 'fact' but even the smallest amount of research showed that this never happened; no developer was ever fired simply because they made an estimate that proved wrong. The Scrum Master can limit this by having the Development Team use story points and Planning Poker. Story point are just abstract enough to help the team reach consensus without getting too bogged down in precision. Another technique that can help is the Fist-of-Five for reaching a consensus. Use a 2 or 3 minute egg timer to hold debates over different estimations to a reasonable time limit will also hasten consensus.
The Scrum Master can show that there are no adverse repercussions with estimations by noting the estimates of tasks and stories and comparing the estimates with the actuals (don't attribute names to these). During the sprint retrospective ask the team to explain why some estimates differed from the actuals and let them suggest improvements to estimation techniques. The team will come to recognize that they provided the best estimates they could based on the knowledge they had at the time. However, the Scrum Master must be prepared to answer the inevitable suggestion that the Development Team do prototyping and design before doing story estimates and task breakdowns. The answer to this lies with the estimates Vs actuals. I had found Development Teams estimates are generally around 10% - 20%; a very good showing (the Nokia test has the goal of +/- 10%). It's likely that the Development Team does pretty well on their estimates but may have the occasional anomaly where they're off. Every time team estimates are off by > 50%, they should analyse the possible reasons during the retrospective. All of this analysis is done within the Development Team and isn't something that is made public although lessons learned are often shared with the organization. Outside the Scrum Team there really isn't any indication of estimation accuracy except maybe the team's velocity. However, velocity is an average over several sprints and won't be meaningful for new Development Teams until the 4th, 5th, or even 6th sprint. By this time, the Development Team should be less anxious over their individual estimates.
Tasks should be pooled and not assigned to individuals.
Development Team members may assign or take sprint tasks during planning and not concern themselves with other tasks not assign to them. Prior to adopting Agile, this is the generally accepted behavior but it will get in the way of a Scrum Development Team's being self-organized and cross-functional. The Development Team must exercise collective ownership of all work necessary to complete a story, after all, the team is held accountable to doing the work, not one individual. One thing the Scrum Master can do to help re-enforce accountability and provide cross-functional training is to have the Development Team members take the task from the person on their right and do that task instead of the one they announced during the meeting. This won't be popular with the Scrum Team and it probably won't be too popular with managers attending the daily scrum so don't do this too often; once or twice in each of the early sprints. This will drive home the lesson that there will be times when team members are sick, on vacation, or leave the company and the other members of the team need to step up and do work in areas they're uncomfortable with. In my experience, the discomfort is fear of the unknown rather than being technically incapable of doing the work.
The Scrum Master can also suggest that the Scrum Team do 1 week sprints. This forces the team to concentrate on just a few user stories, generally working on 1 story until it's completed before going on to the next. The Development Team members will often say that there isn't enough work on 1 story to keep everyone busy. My suggestion is for the team to sit down together and lay out all the tasks of a story showing what bits can be done in parallel and which ones have dependencies. This will generally result in a tasks for a story that are smaller and more detailed than the team would have previously done. Following a 'test first' philosophy, for both acceptance tests and unit/integration tests, will allow more people to work a single story and can even get the story completed faster.
Development Team is found skipping peer reviews and testing of software prior to delivery to repository.
This is one of those issues that occurs most often when the team feels pressure (real or perceived) to deliver something, anything by a specified time or date. If the Product Owner or management is exerting undo pressure on the Development Team, creating anxiety, the Scrum Master needs to re-educate them on the rules of Scrum, specifically, "Development Teams are structured and empowered by the organization to organize and manage their own work." It may be very hard or impossible for the Scrum Master to protect the team against excessive management pressure but the Scrum Master must try and convince management that the Development Team deserves the chance to be successful. Finally, if the Scrum Master is exerting pressure then you probably need to find a new Scrum Master, one better informed on Scrum.
I've also seen this problem because the developers are skipping reviews and tests on their own initiative. During a retrospective after a particularly embarrassing delivery to the customer, the Development Team asked that the Scrum Master double check the team's quality controls by asking for each completed task identified in the daily scrum: 1) was the new/modified code peer reviewed, 2) has all new/modified code been unit tested, 3) has the new/modified functionality been system tested, 4) have acceptance tests been run or partially run, and 5) has the product been regression tested in the affected areas. The scope and depth of testing is left to the Development Team's collective common sense. This actually worked well and after a couple of sprints the questions were no longer asked. What was interesting was how the developers reacted to these questions in the daily scrum. At first, some team members were sheepish and I got the impression that sometimes the answers weren't completely true but no one else on the team said anything. After a few more daily scrums with these questions, the other team members would occasionally question a team member's answer. Eventually the team members would question what was done before the Scrum Master could ask a question.
