Thursday, April 26, 2012

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.
  1. 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.
  1. 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, ...]
  1. 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.
  1. 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.
  1. 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.


  1. A small team always participate and a good no of feedback can be collected from all the team members which may not happen in large teams. So, the project manager Courses should be a scrum certified, who can better handle the team size. Get yourself scrum certified from


  2. I know Laura well and she is principled, thoughtful, and extremely bright...more power to her!

    Scrum Methodology