SHTT-Lead-Image-Costumes

The 25 Characteristics of a Great Development Team

Recently I wrote an article about the characteristics of a great Product Owner. It gave me the idea to do the same for the Development Team and Scrum Master. This blog post focuses on the Development Team; I’ll describe the characteristics, skills and conditions.

Great Development Teams…

  • Pursue technical excellence. Great Development Teams use Extreme Programming hereby 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).
  • Apply 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.
  • Use spike solutions. Great Development Teams uses spike solutions to solve challenging technical, architectural or design problems.
  • Refine 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. Although the Product Owner is responsible for the product backlog, it’s up to the entire team to refine it.
  • Respect the Boy Scout Rule. Great Development Teams use the Boy Scout Rule: always leave the campground cleaner than you found it. This means they always check a module in cleaner than it was before.
  • Criticise ideas, not people. Great Development Teams criticise ideas, not people. Period.
  • Share experiences. Great Development Teams share experiences with peers. This might be within the organisation, but also seminars and conferences are a great way to share experiences and gather knowledge. Of course writing down your lessons learned is also highly appreciated. And yes, for the attentive readers, this is exactly the same as for the Product Owner.
  • Understand 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 hereby 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: create 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!
  • Have 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 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).”
  • Know 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 technical tasks. Great Development Teams understand the importance for technical tasks 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 already deliver business value in the first sprint.
  • Act truly cross-functional. Great Development Teams not only have a cross-functional composition but also really act cross-functional. They don’t talk about different roles within the team but are focused to deliver a releasable product each sprint as a team. Everyone is doing the stuff that’s necessary to achieve the sprint goal.
  • Update 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.
  • Spend 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.
  • Know 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 ‘impact feedback’. They give feedback whenever it’s necessary, and don’t postpone feedback until the retrospective.
  • Manage 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 used 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. Hereby they ensure a sustainable development pace of the product.
  • Don’t need story points. Great Development Teams don’t focus on story points anymore. They’ve refined the product backlog in such a manner, the size for the top items don’t vary much. They know how many items they can realise each sprint. Counting the number of stories is enough for them.

That’s it, some characteristics and skills of great Development Teams. There are probably much more examples, if you know any, feel free to share them!

Barry is a freelance Agile Coach and Professional Scrum Trainer at Scrum.org. He is an active member of the Agile community and shares his insights and knowledge by speaking at conferences and writing articles. Since 2000 he fulfilled several roles within the software development environment, these vary from application consultant, project manager and team lead. Since 2010 his primary focus is applying the Agile mindset and Scrum Framework. Barry is specialized in the role of the Scrum Master and helping people understand the spirit of Scrum and hereby using the Scrum framework better. Due his own practical experience as a Scrum Master, Barry gained a lot of experience with starting new teams, coaching teams through the different stages of team development and applying different types of leadership. Sharing these experiences and hereby contributing to other persons growth is his true passion!

  • This list sounds like a great idea, like the software equivalent of the knights of the round table (excellent equals).

    “Basically they don’t need sprints anymore.” … “don’t focus on story points” … “no dedicated roles needed” [paraphrasing for that last one]

    -> “You must unlearn what you have learned” – Yoda

    Maybe we´ll look back at the current status quo with amazement in a few years 😉 :
    – “How on earth did they live without nominating a new team member as product owner / scrum master for each iteration?”
    – “Why did they call it ‘Sprint’ when every one was always directly followed by another? Who sprints for 2 years?”
    – “Was there ever a developer who said: ‘Let´s estimate that for story points’?”

    • Barry Overeem

      :) let’s see how it evolves! Or better, let’s experience it!