Category: Project Management

7 Habits of a Killer Sprint Team

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 Continue reading

Agile Flaws Worth Considering

I read an article recently concerning flaws of the agile development methodology.  While I do believe agile has merits, I have always felt that there are shortcomings to this process.  I’m especially concerned about how well agile works with IT projects that involve a long data development time period with much data movement and transformation and relatively little user interface (from a development effort perspective).  This is often the case with data warehouse projects. Continue reading