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