According to the Scrum Guide the Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

Development Teams have the following characteristics:

• Self-organizing. They decide how to turn Product Backlog Items into working solutions.
• Cross-functional. As a whole, they’ve got all the skills necessary to create the product Increment.
• No titles. Everyone is a Developer, no one has a special title.
• No sub-teams in the Development Team.
• Committed to achieving the Sprint Goal and delivering a high quality increment.

A GREAT DEVELOPMENT TEAM…

• Pursues technical excellence. Great Development Teams use Extreme Programming as a source of inspiration. XP provides practices and rules that revolve around planning, designing, coding and testing. Examples are refactoring (continuously streamlining the code), pair programming, continuous integration (programmers merge their code into a code baseline whenever they have a clean build that has passed the unit tests), unit testing (testing code at development level) and acceptance testing (establishing specific acceptance tests).
• Applies team swarming. Great Development Teams master the concept of ‘team swarming’. This is a method of working where a team works on just a few items at a time, preferably even one item at a time. Each item is finished as quickly as possible by having many people work on it together, rather than having a series of handoffs.
• Uses spike solutions. A spike is a concise, time-boxed activity used to discover work needed to accomplish a large ambiguous task. Great Development Teams uses spike experiments to solve challenging technical, architectural or design problems.
• Refines the product backlog as a team. Great Development Teams consider backlog refinement a team effort. They understand that the quality of the Product Backlog is the foundation for a sustainable development pace and building great products. Although the Product Owner is responsible for the product backlog, it’s up to the entire team to refine it.
• Respects the Boy Scout Rule. Great Development Teams use the Boy Scout Rule: always leave the campground cleaner than you found it. Translated to software development: always leave the code base in a better state than you’ve found it. If you find messy code, clean it up, regardless of who might have made the mess.
• Criticizes ideas, not people. Great Development Teams criticize ideas, not people. Period.
• Share experiences. Great Development Teams share experiences with peers. This might be within the organization, but also seminars and conferences are a great way to share experiences and gather knowledge. Of course writing down and sharing your lessons learned is also highly appreciated. And yes, for the attentive readers, this is exactly the same as for the Product Owner.
• Understands the importance of having some slack. Great Development Teams have some slack within their sprint. Human beings can’t be productive all day long. They need time to relax, have a chat at the coffee machine or play table football. They need some slack to be innovative and creative. They need time to have some fun. By doing so, they ensure high motivation and maximum productivity. But slack is also necessary to handle emergencies that might arise; you don’t want your entire sprint to get into trouble when you need to create a hot-fix. Therefore: build in some slack! And when the sprint doesn’t contain any emergencies: great! This gives the team the opportunity for some refactoring and emergent design. It’s a win-win!
• Has fun with each other. Great Development Teams ensure a healthy dose of fun is present every day. Fostering fun, energy, interaction and collaboration creates an atmosphere in which the team will flourish!
• Don’t have any Scrum ‘meetings’. Great Development Teams consider the Scrum events as opportunities for conversations. Tobias Mayer describes this perfectly in his book ‘The Peoples Scrum’: “Scrum is centered on people, and people have conversations. There are conversations to plan, align, and to reflect. We have these conversations at the appropriate times, and for the appropriate durations in order to inform our work. If we don’t have these conversations, we won’t know what we are doing (planning), we won’t know where we are going (alignment), and we’ll keep repeating the same mistakes (reflection).”
• Knows their customer. Great Development Teams know their real customer. They are in direct contact with them. They truly understand what they desire and are therefore able to make the right (technical) decisions.
• Can explain the (business) value of non-functional requirements. Great Development Teams understand the importance for non-functional requirements like e.g. performance, security and scalability. They can explain the (business) value to their Product Owner and customer and hereby ensure its part of the product backlog.
• Trust each other. Great Development Teams trust each other. Yes, this is obvious. But without trust it’s impossible for a team to achieve greatness.
• Keep the retrospective fun. Great Development Teams think of retrospective formats themselves. They support the Scrum Master with creative, fun and useful formats and offer to facilitate the sessions themselves. Deliver features during the sprint. Great Development Teams deliver features continuously. Basically they don’t need sprints anymore. Feedback is gathered and processed whenever an item is ‘done’; this creates a flow of continuous delivery.
• Don’t need a sprint 0. Great Development Teams don’t need a sprint 0 before the ‘real’ sprints start. They are able to deliver business value in the first sprint.
• Acts truly cross-functional. Great Development Teams not only have a cross-functional composition and act truly cross-functionally. They don’t talk about different roles within the team but are focused on delivering a releasable product each sprint as a team. Everyone is doing the stuff that’s necessary to achieve the sprint goal.
• Updates the Scrum board themselves. Great Development Teams ensure the Scrum/team board is always up-to-date. It’s an accurate reflection of the reality. They don’t need a Scrum Master to encourage them; instead they collaborate with the Scrum Master to update the board.
• Spends time on innovation. Great Development Teams understand the importance of technical/architectural innovation. They know it’s necessary to keep up with the rapidly changing environment and technology. They ensure they have time for innovation during regular working hours, and that it’s fun and exciting!
• Don’t need a Definition of Done. Great Development Teams deeply understand what ‘done’ means for them. For the team members, writing down the Definition of Done isn’t necessary anymore. They know. The only reason to use it is to make the ‘done state’ transparent for their stakeholders.
• Knows how to give feedback. Great Development Teams have learned how to give each other feedback in an honest and respectful manner. They grasp the concept of the ‘Situation – Behavior – Impact Feedback Tool’ and hereby provide clear, actionable feedback. They give feedback whenever it’s necessary, and don’t postpone feedback until the retrospective.
• Manages their team composition. Great Development Teams manage their own team composition. Whenever specific skills are necessary, they collaborate with other teams to discuss the opportunities of ‘hiring’ specific skills.
• Practice collective ownership. Great Development Teams understand the importance of collective ownership. Therefore they rotate developers across different modules of the applications and systems to encourage collective ownership.
• Fix dependencies with other teams. Great Development Teams are aware of possible dependencies with other teams and manage these by themselves. Thereby ensuring a sustainable development pace for the product.
• Don’t need story points. Great Development Teams don’t focus on story points anymore. They’ve refined the product backlog so that the size for the top items don’t vary much. They know how many items they can realize each sprint. Counting the number of stories is enough for them.