7 Habits of a Killer Sprint Team
With many years of architecture/development experience on several Sprint teams for as many companies I have identified some key behaviors that all of my most effective teams have exhibited. 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 change that team. Or you may want to change the team that you are on.
1. Focus on Commitments
Team pays attention to the current sprint’s unassigned stories and the burndown chart during standup.
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.
2. Continual Improvement
Team makes explicit efforts to identify what is going right and wrong and focuses on making changes necessary to improve.
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 into productivity and collaboration. This also helps to breed trust between Product Owner and team members because of the effort put towards productivity.
3. The Team Succeeds or Fails Together
Members are quick to pause work on their own stories in order to swarm an issue that may be blocking several others on the team.
Camaraderie 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.
4. Emergent Architecture
Team is willing to develop “just enough” in order to meet immediate goals.
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 and iterations spent 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.
5. 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.
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 limiting WIP every subsequent story is now free from reasoning with the unfinished changes and can continue toward completion itsefl. Team members that are diligent to shepherd their stories to production are trusted by everyone 😉
6. Collaboration
Team is comfortable implementing to a high-level description of a story and leans heavily on conversations and Acceptance Criteria as the measure of done.
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 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 the team members themselves as well as between the team and the Product Owner.
7. Testing
Team considers Unit Tests, Contract Tests and Automated QA testing as critical parts of every story’s definition of done.
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 fear of inadvertently breaking existing 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 of 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. Needless to say, the most important byproduct of practicing these habits is the strengthened trust across the entire organization.
Thanks to David Arndt for co-authoring this entry with me.