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

Before the First Scrum: Velocity

Before an organisation goes Scrum, they're most likely to be following a waterfall paradigm and using Function Points, Lines of Code (LOC), Analogy, etc., for software estimation in hours per task. They'll probably also use Earned Value or Microsoft Project as a means to measure their progress and ultimately, their profitability. In Scrum, story points are generally used as the estimation mechanisms and Velocity is used to measure progress and, indirectly, profitability.

Velocity In Hours

If the Scrum development team chooses to use hours as their estimation mechanism then velocity is easily arrived at: (number of team members * effective hours/day) * number of days in sprint. Using hours has a certain appeal to teams unfamiliar with Scrum and story points but using hours implies a estimation precision that simply doesn't (and never did) exist. Another issue with using hours is the 'User Stories' can read more like the waterfall-ish requirements that preceded them and be of a technical nature. Although these may capture the basic functionality, they may fail to grasp the end users' point of view, give little or no hint of usability, and tend to read like development tasks; telling the development team how to implement the feature.

Unlike estimating in hours, story points are at best only an approximation of the effort required. The Scrum Master should steer the team toward using story points as soon as practical.

Velocity In Story Points

Prior to the first sprint, have the development team define a reference user story. A reference user story is one were the entire development team can reach an agreement on the effort involved in developing the feature, the complexity of developing it, and the risk inherent in it. This can be one of the user stories the product owner has written for the team or can be some small bit of previously implemented functionality that is familiar to the team. In either case, the reference story is usually something that can be completed by the whole team within a day or two. Once the reference user story is established, give this story 2 story points. All other user stories are estimated compared to this 2-point reference story. A story that is assigned a 4 should be twice as much as a 2-point reference user story. A story assigned 1 is one-half as much as the 2-point reference user story. The actual length of time eventually becomes unimportant. Planning Poker is probably the best estimation technique to use when estimating user stories.

All stories considered for the first sprint are estimated by comparison to the reference story. The team selects and estimates stories they believe can be completed to the satisfaction of the team's Definition of Done in the first sprint (see Definition of Done: How to Ensure Compliance). The total count of story points becomes the team's initial estimated velocity.

Velocity Is For The Scrum Team

Once the team has arrived at an estimated velocity, the Scrum Master can then begin using this as a KPI for the team. However, care should be taken to ensure that velocity is not used to compare between teams (see Velocity as a KPI in Scrum). The Scrum Master can track the team's velocity and over time, measure the team's performance (see  Increasing Velocity Vs Stable Velocity).

Tweet

Before the First Scrum: Management

You're a manager, a process person, developer, or product manager and your business success has been OK but you think it could be [much] better if your development strategy switched from waterfall to Scrum. How will you begin the transition? This entry will provide some advice on what needs to happen to convince a reluctant management team of the advantages of adopting the Scrum framework.

First Steps For Management

You've heard it over and over again that management needs to support the philosophy and practical applications of Scrum in order for it to work and be successful.  In my situation, the R&D Manager and Product Management Manager were both experienced with Agile and were eager to experiment  with Scrum to determine if the results would be better than the waterfall methodology then currently followed. The key point was that it was an experiment and not a full commitment; Agile would have to prove itself and that proof would be measured in the quality of the product and the speed at which the delivery was made. The business itself was not fussed on the means but were very keen on the results. Having the two department managers who are directly responsible for new product development supporting Scrum was, I believe, crucial for our ultimate success of adopting Scrum.

But what if there's no management support or worst, opposition to change i.e., adopting Scrum.

I worked at a defence company in the early 80's and the company's policy was no one would be hired as an engineer unless they had a 4 year college degree. My manager wanted to bring in someone as an engineer but without the necessary 4 year degree. The manager ended up writing a memo (remember those?) and eventually got the person in as an engineer. He later told me that the length of the memo was directly related to the hurdles before him and to get the person hired as an engineer required an eight page memo. The point of course is that the bigger the obstacle blocking your goal, the bigger the effort in making your case to reach that goal. To convince management that Scrum is a better alternative to current development methodologies, usually waterfall, you need to make the business case that Scrum can improve both quality and productivity; get better products out to the paying customers more quickly.

You must sell the idea of Scrum to management starting the first day and every day following without letup. Management needs to learn that through Scrum, there's higher productivity, greater innovation, quick reaction to customer or competitive changes, high visibility to progress (or lack of progress), higher product quality, and more potential evaluation deliveries to customers after each sprint. At a training session given by Jeff Sutherland, he stated that even if you do nothing else but have a daily scrum meeting, you should see a 20-30% increase of productivity. Jeff Sutherland has lots of practical information and statistics that can be used to help convince your management that Scrum can help your business. There are also many, many resources on the web that have anecdotes and other stories that can help bolster your arguments for Scrum adoption. You will need to understand what exactly the manager's opposition to Scrum is and address those issues directly.

I also think that trialling Scrum is a better approach than trying to completely change the way things are done all at once. By trialling, management is more likely to allow a single team to adopt Scrum without, in their minds, risking everything. When my company first trialled Scrum, only one team was formed. After the team was able to deliver a new product in only three months, a feat that had never happened before with waterfall, the CEO asked why all of development wasn't doing Scrum. 

If you have any stories on how you succeeded in winning over management to use Scrum, please let me hear from you.

Tweet

The Self-organizing Agile Team's Scope of Power and Authority

The means for the Development Team to fully realize the power and authority granted them by Agile is through self-organization.

From the Agile Manifesto:

• “The best architectures, requirements, and designs emerge from self-organizing teams."

 The Scrum Guide defines the power and authority of the team in terms of self-organization:

• defining the Scrum Team: “Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”
• defining the Development Team role: “They [Development Team] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.”
• defining the Scrum Master role: "The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality."
• defining the Sprint Planning Meeting: "The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint...By the end of the Sprint Planning meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment."
• defining the Daily Scrum: "Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated increment in the remainder of the Sprint."

It's clear the Scrum Guide expects the Scrum Team, and more specifically, the Development Team, be a self-organizing body. However, the Scrum Guide gives no hints on how self-organization is achieved and maintained.

What is a Self-organized Team?

In his book, "The Leader's Guide to Radical Management: Reinventing the Workplace for the 21st Century", Stephen Denning defines a Self-organizing team as a team that can "decide how the work will be organized, who will do what, and in what order; select leaders and spokepersons; and can decide who should be a member of the team" *.

Qualities of a Self-organizing Team

Self-organizing teams are given the freedom to find the best solution to the problems given them. The Development Team is in full control of finding a solution to a given business problem and is not directed to a specific solution from outside the team. This means that although outsiders may provide solicited or unsolicited advice to the team, the team has the freedom to ignore that advice and follow their own instincts and intuition.

Self-organizing teams can react to problems quickly. Instead of waiting for a manager’s approval, the team has the authority to take necessary actions by itself. The team 'owns' the solution and Scrum provides the team all the latitude necessary to achieve it.

Self-organizing teams are cross-functional. The Development Team does not have dependencies on others outside the team to accomplish their work. The team doesn't have divisions of work based on specialized skills within the team e.g. the whole team is responsible for testing, not just the "tester". By being cross-functional, the team has the ability to organize themselves to respond to changes in project, customers, technologies, and requirements. Being a cross-functional team does not mean team members have equal knowledge and talent. Creativity and innovation largely result when team members of differing knowledge and talents debate possible solutions from their respective view-points.

Self-organizing teams value self-improvement and continuous learning. The team actively pursues self-improvement; to find better and innovative ways to work smarter and to satisfy the customer. For example, in order for the team to be cross-functional, they need to learn from each other; the "tester" on the team is teaching all the team members about testing. Furthermore, teams need to learn about the customer's needs and get frequent feedback from customers. Self-organizing teams are given the freedom to chose their own team goals every iteration to facilitate and implement self-improvement actions.

Self-organizing teams have a common focus. The self-organized team collectively understands the goal of the iteration, release or project and has a shared understanding of the solution. The team needs a compelling goal; one which the team feels is worthwhile to achieve. The team needs to re-enforce the understanding of the goal throughout the iteration.  This is done through the inspect and adapt Daily Stand-up meeting.

Self-organizing teams have mutual trust and respect. Self-organizing team members are always open and honest, have the ability to voice ideas and opinions without fear of ridicule or rejection, and knowing others will accomplish the tasks assigned to them. Self-organizing team members value other team members for their unique contributions and opinions.

The Role Of Managers and Customers On The Self-organizing Team

In a recent InfoQ interview, Rashina Hoda says two environmental factors need to be in place to enable self-organization to emerge. These are:

1. Senior management at the teams' organization must be able to provide freedom to the teams so that they can self-organize themselves.
2. Customers must support the teams by being actively involved in the development process through providing regular requirements, clarifications, and feedback as required.

Senior management

"Self-organizing Agile teams ... require organization structures that are informal in practice, where the boundaries of hierarchy do not prohibit free flow of information and feedback. In an informal organizational structure, the senior management is directly accessible by all employees (maintaining an ‘opendoors’ policy), and accepts feedback—both positive and negative."

- from "Supporting Self-Organizing Agile Teams What’s Senior Management Got To Do With It?" by Rashina Hoda, James Noble, and Stuart Marshall, 

The Customer's (or customer surrogate's) task is to set the priorities, decide when each requirement is satisfied, and write stories and acceptance/functional tests together with the team. Self-organizing teams are responsible for collaborating effectively and often with the customers to elicit and understand the product requirements. (See "Agile Undercover: When Customers Don’t Collaborate" for more on how customers can help or hurt a team's ability to self-organize.)

Roles Facilitating Self-Organizing Agile Teams

In the paper, "Organizing Self-Organizing Teams", Rashina Hoda, James Noble, and Stuart Marshall concluded that Scrum Teams adopt 6 roles to facilitate their team’s self-organization (see the table below). Although any Scrum Team member could do any of the 6 roles, it was generally the Scrum Master (agile coach) and Product Owner (business analyst) who take on the roles. If the Scrum Team doesn't have the capacity or ability to fulfill these roles or someone outside the Scrum Team is occupying one of these roles, it may indicate the team is not yet self-organizing.

Role	Definition	Played by
Mentor	Guides and supports the team initially, helps them become confident in their use of Agile methods, and encourages continued adherence to Agile practices.	Agile Coach
Coordinator	Acts as a representative of the self-organizing Agile team to coordinate communication and change requests from customers.	Developer, Business Analyst
Translator	Understands and translates between the business language used by customers and the technical terminology used by the team, in an effort to improve communication between the two.	Business Analyst
Champion	Champions the Agile cause with the senior management within their organization in order to gain support for the self-organizing Agile team.	Agile Coach
Promoter	Promotes Agile with customers and attempts to secure their involvement and collaboration to support the efficient functioning of the self-organizing Agile team.	Agile Coach
Terminator	Identifies team members threatening the proper functioning and productivity of the self-organizing Agile team and engages senior management support in removing such members from the team.	Agile Coach

*Although Stephen Denning states that the self-organizing team "can decide who should be a member of the team", I would suggest looking at Mike Cohn's removing team members blog and the role of leaders on a self-organizing team blog. There may be times when the Scrum Master or management juggle the team make-up to help foster self-organizational improvements.

Tweet

Increasing Velocity vs. Stable Velocity

The question often comes up whether a Development Team can reach a point where their sprint velocity becomes stable. I think that velocity may tend to stabilize but it won't be stable until the Develop Team executes its sprint perfectly and nothing new exists for the team to experiment with. Here are some ideas that I believe can help the Scrum Team achieve a stable velocity.

If the Development Team is doing:

• Product Backlog grooming (stories and acceptance criteria are understood and broken down to an appropriate size),
• Small User Stories (each story taking 1 or 2 days depending on how many people work on it),
• Defining acceptance tests before the start of the sprint (understand the acceptance criteria, the scope of testing, and the most probable approach to testing),
• No "unplanned" work in the sprint (e.g. Support calls),
• No unnecessary "manual" work (identify and analyze manual work to see if it's cost effective to automate),
• Pair Programming and/or following a Coding Standard for code review,
• Test Driven Development (TDD),
• Acceptance Test Driven Development (ATDD),
• Continuous integration (new/modified tested code is integrated daily for automatic component/functional/system/regression testing),
• Code Refactoring (to improve the code quality and the overall design),
• Automated Unit Tests,
• Automated Integration/Component Tests,
• Automated Functional Tests,
• Automated User Story Acceptance Tests,
• Automatic Regression Tests (Team is probably not doing good regression testing unless these are automated).

And the Development Team is:

• Cross-functional (has the necessary expertise among its members to take a user story from its initial concept to a fully deployed and tested piece of software within one sprint),
• Working "normal" work hours (Development Team is working at a "sustainable" pace),
• Happy as individuals and as a team (no one "dreads" coming to work),
• Not interrupted or distracted by anyone or anything outside the team (Scrum Master stand guard if necessary),
• Identifying impediments to the Scrum Master quickly (hopefully before there's any impact),
• Not distracted by email (turn off the mail server),
• Not distracted by the phone (have a phone available to the team in a separate room),
• Not adding to its Technical Debt during sprints (adopt a zero introduced defects as part of the definition of done),
• A cohesive entity (has a shared view on the development objectives, the design ideas in the code and what makes for good code),
• Self-organizing (always on the lookout for ways to improve).

And the Scrum Master and Product Owner are:

• Shielding the Development Team from "unplanned" work,
• Shielding the Development Team from outside distractions,
• Removing the Development Team's impediments in a timely manner,

If all the items above are being done then I would say that the Team's velocity will probably be fairly stable.

However, the Scrum Master is responsible for helping the Development Team to improve even when it appears that the Team is doing everything as efficiently as it can. From the Scrum Guide: “The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.” The point being that trying to improve the team's velocity should be the norm – not standing still. To achieve improvements, the Scrum Master should ask the question:  Is the Scrum Team trying new things every sprint to help improve themselves? The Scrum Team should be able to identify how it can improve its velocity by working smarter, not harder.

Tweet

Definition of Done: How to Ensure Compliance

Near the end of the Scrum Guide, there’s a section on the Definition of “Done”:

When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the “Definition of Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

Who is everyone? Everyone includes the Product Owner, Development Team, and Scrum Master although key customers, sales, product management, product support, and managers should also be aware of what the team understands 'Done' to mean.

 

The Scrum Master ensures that a definition of done exists for the scrum team.

How to Define 'Done' for Your Scrum Team

Chris Sterling of Sterling Barton, (www.gettingagile.com), has written an excellent paper on "Building a Definition of Done". Chris Sterling has identified a four step process toward getting a definition of done. These are:

1. Brainstorm – write down, one artifact per post-it note, all artifacts essential for delivering on a feature [user story], iteration/sprint, and release
2. Identify Non-Iteration/Sprint Artifacts – identify artifacts which cannot currently be done every iteration/sprint
3. Capture Impediments – reflect on each artifact not currently done every iteration/sprint and identify the obstacle to its inclusion in an iteration/sprint deliverable
4. Commitment – get a consensus on the Definition of Done; those items which are able to be done for a feature [user story] and iteration/sprint

Let’s assume you have your definition of ‘Done’ documented in a team charter or some other means and have it properly displayed on your scrum board for all to see.

 

Now What?

 

Complying With The Definition of 'Done'

 

In the sprint planning meeting, the Scrum Master should get the Scrum Team to re-confirm their commitment to the team’s definition of ‘Done’. This ensures that everyone on the Scrum Team, which may include new people to the team, is aware and understands what ‘Done’ means. It’s possible that the definition of ‘Done’ had changed during the last sprint’s Retrospective, maybe to tighten up on the quality goals. The Scrum Master goes through the definition of ‘Done’ with the Scrum Team and everyone re-affirms their commitment to it.

 

During the sprint, everyone on the Scrum Team is responsible to follow and adhere to the definition of ‘Done’. It is the Scrum Master’s responsibility to ensure the other members of the Scrum Team (Developers and Product Owner) have been coached and trained to do this. If the Development Team and/or Product Owner are not following the definition of ‘Done’, we hold the Scrum Master accountable.

 

What should happen if the Scrum Team cannot follow one of their definitions of ‘Done’ to the letter? Let’s assume for the moment that a Scrum Team has the following definition of ‘Done’ for a user story:

• Acceptance tests written covering all acceptance criteria.
• Acceptance tests and regression tests run and pass.
• Acceptance tests results reviewed by the Product Owner.
• No known introduced bugs.
• Product demo’ed with Product Owner.
• Product documentation, technical and user, updated.

The Scrum Team works hard following the definition of ‘Done’ and is successful except that they’ve introduced some new bugs, violating the ‘no introduced bugs’ clause of the definition and the sprint ends today. What should happen? This is where the Scrum Master might need to hold back the torrent of people, (managers, sales, product management), all of whom want those stories now! Strictly speaking, the user story or stories that introduced the new bugs cannot be considered ‘Done’ and the story(s) are not demo’ed in the sprint review. However, during the sprint review when discussing what didn’t get ‘Done’, the offending user story bugs might be discussed and stakeholders and Scrum Team alike may determine that the bugs are of little importance to the end-users. (Why this didn’t happen before the end of the sprint is another matter that the Scrum Team would analyse in the Retrospective.) The user story would be added to the next sprint to be integrated into the ‘Release’ branch, probably re-tested, and the insignificant bugs closed as ‘not a problem’. It’s most likely that the Product Owner will have the user story ‘Done’ within 24 hours of the sprint review and can then release it at their leisure. If the bug is significant but the stakeholders and Scrum Team determine that the bug is of little importance to the end-users now, the bug could become a new user story to be addressed later. (You'll note that this second scenario is actually adding to technical debt.)

 

The whole point here is that the definition of ‘Done’ should stand uncompromised throughout the sprint. If there’s a problem with the definition of ‘Done’ that came out during the sprint, it should be addressed during the sprint Retrospective and any changes to the definition made and agreed to there. However, the Scrum Team should heed the words in the Scrum Guide which say, “As Scrum Teams mature, it is expected that their Definition of ‘Done’ will expand to include more stringent criteria for higher quality”. This means that the definition of 'Done' should be strengthen rather than weaken as time and sprints go by.

Tweet