Development's First Sprint: Things To Improve

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.

Tweet

Before the First Scrum: Development Team

The members of the new Scrum Development Team are usually drawn from the company's existing software development organization and have probably been following a waterfall methodology until now. If your company's planning on using a Scrum Coach, then most of what follows may not be applicable as the coach with have their own methods and techniques. However, for those organizations that will have their Scrum Teams self-start from within, here are some points on how to select the Development Team and prepare them for their first sprint.

Selecting the Development Team

The Scrum Guide lists the Development Team's characteristics as: self-organizing, cross-functional, having no titles other than Development Team member, equally shared accountability for the sprint, and no sub-teams within the Development Team e.g. database, test, GUI, etc. Although it's possible that your first Development Team will have these characteristics, it's very unlikely. These characteristics are what the Development Team hopes to achieve and it's the Scrum Master that will help guide the team as quickly and with as few detours as possible over the first half dozen sprints or so.

So what is it you're looking for when forming a Scrum Development Team for the first time? There's really only one thing that needs to be considered: the Development Team will need to have the technical expertise to do the work that the project's requirements demand. The company I worked at did exactly this when forming their very first Scrum Development Team and it proved to be a success. A step by step approach to select and prepare a Development Team for Scrum might look like this:

1. Review the project's requirements to determine the necessary functionality and necessary technical competencies needed for implementation. The review is probably done by Product Managers, Project Managers, senior architects, and team leads. The irony is that with the exception of Product Manager, these roles will almost certainly disappear as the software organization moves toward Scrum. The Scrum Team as a unit will replace the team leads, architects and project managers as they become more self-organizing.

My first experience with Scrum started this way. The company was doing waterfall when a new business opportunity came along. Once management, particularly Product Management and R&D Manager understood the requirements, it didn't take long to see that waterfall methods wouldn't be able to meet the contract dates. They concluded that a different development methodology was needed that could quickly implement a few hundred requirements but be transparent enough so unnecessary and problematic requirements could be dropped long before developers wasted a lot of time on them. Agile and Scrum provide the transparency and seemed a logical fit in order to meet the contract.

2. Based on these needs, create a list of 5 - 7 software personnel that will satisfy most or all of the technical competencies needed. Everyone in a development organization should be considered for membership in a Scrum Development Team. The only exception might be someone known to be totally unable to work in a team environment. Even then I would suggest placing these people in a Scrum Team as you might be surprised who fits in and who doesn't. Management should allow everyone a chance to succeed in Agile. Try to avoid putting only the very best software people into a single Scrum Team. It isn't necessary since the total of knowledge in a Scrum Development Team is usually greater than the knowledge of any one individual. And besides, if your company decides it will have 2, 4, or more Scrum Teams, the more experienced people can be seeded to every team rather than all in one team.

My first Scrum Team consisted of the most experienced people (team leads) in the software organization and were selected based on the technical requirements of the project. The project had 4-2 week sprints and was a great success. After the two month project ended, the Scrum Team split up. Although they did the principle Scrum activities; sprint planning, sprint, daily scrum, sprint review, and sprint retrospective, they didn't really do Scrum all that well. In my view, having only the most experienced or senior engineers in one team, the ones who have been doing waterfall the longest, will slow progress toward self-organizing and being cross-functional. These senior people will have to change the most to adopt Agile and Scrum. For example, during a daily scrum meeting it became apparent that one team member wasn't doing any of the tasks on the scrum board in his specialist area. No other Development Team member questioned this. When I asked what task he was doing he said it would take longer to explain what he was doing than to do it. He didn't ask his fellow team members for assistance but neither did any other team members offer to assist. The Scrum Team's team lead called in an architect to help on the problem and after working the weekend, the problem was resolved. In the post project review it turned out that because most everyone on the team was a fairly senior engineer and team leader, they felt that the Scrum Team's team lead would sort it out as they would do if they were the team lead. In the pre-Agile environment, the team lead had the responsibility for solving technical problems for the team and was generally held accountable for the team's success. In Scrum, the accountability for the success of a sprint rests equally among all the team members. This is a significant power shift for former team leads.

On the other hand, getting the more senior software people on board with Scrum through a short-ish project can have long term benefits. Once this team breaks up, they can go to other new teams and be champions of Scrum within their new teams.

3. The Scrum Master introduces Agile and Scrum to the newly formed Development Team. The focus should be the Agile Manifesto and the 12 principles. The Scrum Master should describe the Scrum Roles, the expectations of the Development Team as they relate to Scrum, and emphasize the Development Team's empowerment to find and implement an appropriate solution. I would suggest this be a short introduction; no longer than 60 minutes. Review the Agile Manifesto and Scrum Guide and then tell the Development Team that they're empowered to run the sprint as best they see. Start sprint planning that day or the next.

A short meeting (< 60 minutes) just to present the facts of Agile and Scrum will help the Development Team 'hit the deck running.' If you have a long, drawn out session, the conversation will eventually lead to discussing waterfall  which will invite comparisons between "the way we used to do it" and Scrum. This will lead the team members making choices between the two i.e. which is better. The purpose of this meeting is to familiarize the Development Team on Agile and Scrum and not to debate whether the company should be changing to Agile (I assume those discussions and decisions had already taken place). I suggest going through the Agile Manifesto first and then the Scrum Guide. When doing the Scrum Guide, relate the points in the Scrum Guide back to the Manifesto to help re-enforce the principles of Agile. An agenda might look like this:

1. Agile Manifesto
2. Scrum Roles
3. Scrum Principle Activities
4. Scrum Rules
5. New Techniques And Concepts [user stories, planning poker, acceptance tests, continuous integration, daily builds, ...]

4. Co-locate the Development Team removing any partitions, bookcases, or other office furniture that prevents the newly formed team from being able to make eye contact and hear each other talk. Get some whiteboards or have a wall located with the team where they can track their sprints (Scrum Board), add notes, do designs, document user stories and acceptance criteria, and plan the release. All this will help facilitate communication within the team. The Scrum Master and Product Owner should sit next to the Development Team's area where they can hear snatches of conversation and be summoned quickly but they shouldn't sit with the Development Team. Co-locating the Development Team, will help empower them to self-organize, makes it easier for the team to learn from each other (cross-functional), and fosters direct, face-to-face communications.

A few people, usually the shy or paranoid, will absolutely loath moving but the majority will be able to see the benefits. After a few sprints, the shy people will be noticeably more open and communicative and the paranoid people will be less fearful of their work being scrutinized.  Be sure to have plenty of white board space for the team.

5. Establish a Definition of Done for the Scrum Team (see the short paper Definition of Done: How to Ensure Compliance). The Scrum Master might want to assess the Development Team's capabilities for their first couple of sprints and allow the team to adopt a Definition of Done that offers the team a chance to succeed and yet has room for growth.  As the Scrum Team re-assesses their Definition of Done at each sprint retrospective, any weaknesses in the Definition of Done can be addressed and the Definition of Done modified to strengthen and improve the team's sprint results.

I found that the Scrum Teams had a terrible time adhering to their Definition of Done, especially in their first few sprints. I think the reason for compromising the Definition of Done is due to the long tradition of shipping products even when they weren't ready. The line goes something like; the customer would rather have something that almost works than to have nothing.  In pre-Agile you deliver something that doesn't always work whereas in post-Agile you deliver something that works but may not have all the features. This is a subtle difference but I think it's the key to Agile. The customer is meant to see new and working features and capabilities at each sprint review.

6. The team needs to develop the capability to generate daily builds before starting the first sprint. This phase is often called sprint zero. To take full advantage of Agile, the team needs the ability to generate workable builds on a daily basis.  This is part of continuous integration. Continuous integration is the practice of performing a clean build, conducting full integration, and running all tests every time a change is committed to the code repository. This is accompanied by frequent integration of each developer’s work into the code repository.

Working builds were a luxury during my first sprint but steadily improved during the subsequent sprints. This was a most import lesson learnt in our first venture into Scrum. At a minimum, the team needs to successfully run automated unit/integration tests on a daily basis to help ensure the quality of new code and ensure there's no regression on legacy code. The team needs to have a build notification message, usually emailed, that lets people to know what the build status is and exactly which feature was being delivered or what in a feature was being fixed.  The team should be striving to have acceptance tests automated and run on a daily basis. The team needs to get to the point where it is unacceptable for a build to be broken.  If the build breaks or the product regresses, the offending code is removed from the build and the daily build is then released.  The team must fix the bad code before any new functionality is added to the code base.

The Development Team should also automate their legacy acceptance tests and other system tests and have these run on the daily build. Legacy tests will most likely not be automatic but the team can add user stories to the product backlog to create automatic tests.

The Scrum Guide places the responsibility for educating and training the Development Team, along with the Product Owner, on the Scrum Master. Getting the Development Team together and ready for their first sprint is the easy part; the Scrum Master must now teach the concepts and intent of Scrum and Agile to the Development Team until they can do Scrum in their sleep. Hopefully, the day will come when the Scrum Master recognises that the Development Team really doesn't need a Scrum Master anymore.

Tweet

Before The First Scrum: The Scrum Master

The role of the Scrum Master is arguably the most important role on the Scrum Team. The 2011 Scrum Guide by Ken Schwaber and Jeff Sutherland define the role of Scrum Master as:

"The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practises, and rules. The Scrum Master is a servant-leader for the Scrum Team."

If a Scrum Team is having problems following Scrum practises and rules or is being interrupted and distracted, it's the Scrum Master we hold accountable to correct this. It is imperative that the right person is selected, appointed, or steps into the role of Scrum Master.

Selecting The Scrum Master

The Scrum Master must understand Scrum. This doesn't necessarily mean that the person has committed to memory the Scrum Guide or completed a Certified Scrum Master course but should have an understanding of Scrum that goes beyond these two artifacts. The prospective Scrum Master should have an ingrained knowledge and comprehension of the Agile Manifesto and the twelve principles behind it. The prospective Scrum Master should be committed to following the 5 principal Scrum activities, Sprint Planning, Daily Scrum, Sprint, Sprint Review, and Sprint Retrospective, and the rules of Scrum as outlined in the Scrum Guide.

The Scrum Master is usually selected from within the existing software organization. This may be project managers, team leads, senior software engineers, senior testers, etc. I've listed what seems to be the more experienced personnel of a software organization but I really don't think that a lot of software experience is essential for a Scrum Master. You won't find any technical requirements in the Scrum Guide for the Scrum Master role. In fact, a lot of technical experience could work to the detriment of a Scrum Master. For example, a strong technically minded project manager or team lead is usually an asset in a waterfall, command and control environment but in Scrum, a strong, technically minded Scrum Master may start 'telling' the Development Team how to do their work. The Development Team is meant to be self-organizing and Scrum assumes the people doing the work know best how to do it. From the Scrum Guide: "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality".

Where I worked, the first Scrum Master came about when the person was asked by management to research the various Agile methodologies but focusing on Scrum, and provide a recommendation on how to best adopt Agile. This exercise really served two purposes: 1) Figure out which Agile methodology best suited the company's current situation (Scrum hands down) and 2) Give the potential Scrum Master a means to obtain a broad understanding of Agile and build a solid knowledge base of the recommended methodology.

Whoever the company or software development organization chooses to be Scrum Master, this person should have the following qualities:

• Be an early adopter,
• Understand, embrace, and be fluent in the Agile Manifesto,
• Be fully conversant in Scrum,
• Be well read on adopting Agile and Scrum,
• Have the stamina and patience to teach Scrum to the organization, and
• Have enormous enthusiasm for all things Scrum.

Be an early adopter: For most organizations, adopting Scrum is or will be a big change from a waterfall methodology. The Scrum Master must believe that Scrum is a better approach to software development. The Scrum Master can help convince the Development Team and software organization that Scrum is a better than waterfall if and only if, the Scrum Master believes this to be true to the core. Suppose a retrospective is skipped because the Development Team couldn't see the value in it two weeks after the last retrospective. If the Scrum Master allows this, the Scrum Master is not convinced a retrospective is needed after every sprint.

Understand, embrace, and be fluent in the Agile Manifesto: This document is the heart of Agile. Customer collaboration, high visibility of work, frequent deliveries, openness and honesty, continuous improvement, face-to-face communications, working software: they're all part of the Agile Manifesto as they are to Scrum.

Be fully conversant in Scrum: The Scrum Master will need to understand the Scrum Guide and it implications. Following the Scrum framework right from the start is essential; anything less will weaken the value of Scrum and can eventually lead back to waterfall. At first, the Scrum Team will probably resist the change to Scrum and will be reluctant to self-organize. What I found was developers new to Scrum are able to go through the mechanics of Scrum but with little appreciation of the benefits of Scrum. A Scrum Master must be able to identify and correct any variances from Scrum immediately.

Be well read on adopting Agile and Scrum: When a Scrum Team first forms, there will be some resistance to change but the Scrum Master can help ease people through it by citing examples of how other organizations got through the various issues the team will face. If the Scrum Master can address the issue and provide possible solutions immediately, the Scrum Team will gain confidence in Scrum and the Scrum Master. Almost any issue a team will face has probably been seen by someone else and they have somewhere documented it on the web. The Scrum Development Group on Yahoo (http://tech.groups.yahoo.com/group/scrumdevelopment/) is an excellent source of information but there are many blogs and other web sources that can be mined for solutions. Or, if you like, you can email me with your issue which I promise to answer quickly. Some areas that will probably cause confusion are:

• User Stories-How to write them and how to estimate them.
• Story Points-How to do relative estimations.
• Acceptance Testing-How to write acceptance criteria and who runs these tests.
• Continuous Integration-How to deliver new/modified capabilities every day.
• Daily Builds-Automating a daily build with automated system, acceptance, integration, and unit testing.
• Daily Scrum- Getting the most out of the meeting in < 15 minutes.
• Technical Debt-How to deal with partially completed stories and bugs.
• Self-Organization-What this means and how to achieve it.
• Development Team Structure-How to deal with former hierarchy and titles in Scrum.

There are many other issues that will pop up but the ones above I've seen in every team new to Scrum.

Have the stamina and patience to teach Scrum to the organization: I think this is the most demanding aspect of the Scrum Master's job.  I was lucky in that my boss was a superb listener and I was able to talk to him and come to better understand some of the issues I was confronted with.

Usually when I had problems with an individual or worst, the whole Development Team, it was paramount to separate the emotion from the logic and facts. I tended to speak a bit slower with carefully chosen words and appeal to the logic of the situation. I once spent over an hour with 2 people trying to explain that failing to meet a commitment (sprint goal) is not the end of the world. The team was unable to complete one of the user stories in the sprint and felt they had failed. My argument was that the complexity of some user stories is not entirely known at the start of the sprint and that the team's velocity, the average amount of work the team can expect to achieve during a sprint, is really a guide of the amount of work the team might achieve. If the team doesn't feel they can meet the goal of the sprint then the goal should be re-negotiated. In this case, the team was unable to see that they weren't going to meet the sprint goal-a common practice of developers I've seen over the years. Like the people on the Titanic, they believed that rescue was only moments away even while the ship was so obviously sinking. Why developers sometimes feel they'll be fired; not yelled at, not take a pay cut, but fired for making an inaccurate estimate is beyond me. In almost 30 years I've never seen the slightest disciplinary action against an individual for making an estimate that proved in fact to be wrong. In any case, after spending over an hour talking about vagaries of software estimates and about using the retrospective to figure out why the team over committed, I went home thinking that I failed to reach these people. You can imagine my surprise and strong emotional response when early the next morning I found an email where one person got it and realized that with Scrum, they can only do what they can do and that over commitment, especially in the early sprints, is something nobody is too upset over and that during their retrospective, the team needs to understand why it over committed  and make the appropriate modifications.

Have enormous enthusiasm for all things Scrum: If you need to pretend to be enthusiastic about Scrum then being a Scrum Master is not for you. I really loved being a Scrum Master. I was genuinely moved when the light turned on for team members as they comprehended the various facets of Scrum. My philosophy was that you initially do Scrum by the book (i.e. Scrum Guide). If something isn't working after you've given a fair chance then solicit from the Scrum Team on what should change. However, after two years doing Scrum, nothing about Scrum changed. Of course there were changes on how user stories were written, how to do acceptance testing, and other technical components but nothing about Scrum actually changed. The Development Team may take a while to make the transition between waterfall and Scrum but the Scrum Master knows Scrum is better and will be constantly pointing out to the team why Scrum is better.

Tweet