This post was co-authored by Dave Arndt and Kevin Miles. With 40+ combined years of architecture/development experience on various Sprint teams at different companies, we have identified some key behaviors that all our most effective teams have exhibited as well as noting some (sometimes subtle) unhealthy behaviors.

If you are currently on a team that is performing poorly and claims that “Agile does not work for our team, we’re different, we’re unique” or you’re just experiencing pushback and foot-dragging while attempting to adopt these types of healthy habits you will have to be the change for the team. Or, you may want to change the team that you are on.

This article requires some basic understanding of Agile Software Development.

Focus on Commitments

Team pays attention to the story burndown as a primary chart during standup.

Unhealthy: Team pays attention to the task burn-down.

We all know that a story takes the time that it takes regardless of your best estimations, but keeping an eye on the burndown helps the team evaluate what actions may help get things back on track. For example, by watching burndown you may realize that QA is often light at the beginning of a sprint and slammed at the end, perhaps holding up several stories from finishing. This may tip you off that you can reorganize story priority so that some stories can be delivered to the QA column earlier. Delivering on Commitments helps to build trust with your team and its stakeholders.

Continuous Improvement

Team makes explicit efforts to identify what is going right and wrong and focuses on making changes necessary to improve. Retros are genuinely valued and anticipated by team members.

Unhealthy: Team views the retro as a gripe session without results and discontinues.

This is simply taking advantage of the power of continuous improvement or Kaizen. These changes are often small and easily achieved. When a team focuses and revisits items that they themselves have deemed important to change, add, remove or simply improve they will be making minor adjustments and corrections that will ultimately add up to big gains for productivity and collaboration. This also helps to breed trust between Product Owner and team members because of the effort put towards quality and productivity.

The Team Succeeds or Fails Together

Because the team is working to a known business goal each sprint, members are quick to pause work on their own stories in order to swarm an issue may be blocking several others on the team, confident that the product own views the sprint goal as more important than individual task.

Unhealthy: Members focus on completing their own tasks because they are measured by the tasks they complete.

Comradery and common cause will unite your team in success. We’ve all been on teams where one developer is a Rockstar and she gets more points than everyone else, but the team itself isn’t meeting all of its commitments and worse she is the bottleneck for all important deliverables: miserable. Everyone needs to help the other succeed. Decentralizing important team knowledge may slow down one developer, but it will increase the speed and success of the team overall and more importantly it will leave the team less vulnerable to losing important knowledge in the event of losing key members. This team trusts itself.

Emergent Architecture

Team is willing to develop “just enough” to meet immediate goals.

Unhealthy: PO doesn’t allow time for architectural debt, so team has no room for mistakes.

This is difficult for most of us engineer types and requires real discipline, but let the problem fully expose itself before architecting a solution. This will greatly reduce the time spent and iterations on a solution if a team can wait to see a problem from multiple angles before creating a library or pattern to address it. This also requires a team to build in margin to every sprint for tech-debt. This is the antithesis to the Ivory Tower Architecture Paradigm. Can you guess what this helps to foster? Yes, trust: that the team will deliver now and address tech-debt in due course.

Delivery

Team considers deployed-to-production as the definition of done for every story and takes an active role in “shepherding” a story all the way to done.

Unhealthy: “Release sprints”

A clean code repository is a happy one. Get that code OUT! to PROD! For every story that stacks up in Non-Prod it becomes work in progress (WIP). By adhering to this rule every subsequent story is now free of that WIP. Team members that are diligent to shepherd their stories to production are trusted by everyone.

Collaboration

Team is comfortable implementing to a high-level description of a story and leans heavily on conversations and ACs as the measure of done.

Unhealthy: Team wants PO to document every detail in the story and relies on “letter of the law implementation” of the story.

This allows the team to bring its considerable talents to bear on the actual implementation. A story should not be a task. A story should be a desired result. A good Product Owner will be in frequent contact with stakeholders and will capture in a story what is required and let the team collaborate to produce the desired functionality. The necessary conversations that this approach fosters may come in the form of pairing, opportunistic pairing or simply rallying a handful of members around a whiteboard. Either way, folks are discussing issues, arriving at optimum-for-now solutions, decentralizing knowledge and building trust between team members themselves as well as between the team and the Product Owner.

Testing

Team considers Unit Tests, Contract Tests and Automated QA testing critical parts of every story’s definition of done.

Unhealthy: Team views story as done when coding and unit tests are complete.

Great teams have QA members side-by-side with developers. QA is development. This emancipates a team to make critical changes, bug fixes or refactoring without the stress of breaking functionality. Having a robust test triangle will supercharge a team’s ability to make changes quickly and get those changes quickly into production. A team that writes testing as due course is a team that trusts itself to safely deploy to production.

Practicing all these habits really adds up to produce great results. These behaviors also create a cultural momentum that helps with communication, collaboration and is especially effective for onboarding new team members. Some changes will be seen immediately, and some will take time to manifest as the team builds trust with itself and its partners. Comradery, sense of purpose, team morale and trust are very tangible benefits to creating a killer sprint team. The most important byproduct of practicing these habits is the strengthened trust across the entire organization.