May 2008

Monthly Archive

Creating a Team Working Agreement

Posted by on 02 May 2008 | Tagged as: Agile, Leadership, Scrum

While coaching teams I have found the creation of a Working Agreement as an essential step for a Team to initialize their adoption of an agile framework. I have also noticed that the ideas behind along with the process of creating a Working Agreement is not widely understood by coaches, ScrumMasters, and team members. Although there is no single reason or way to facilitate a Team in the creation of their Working Agreement, here is what I have found to be helfpul.

As a facilitator you can help the team understand the reason for creating a Working Agreement by discussing the need for understood team norms because agile frameworks involve increased collaboration. Becoming a Team involves commitment to working together and supporting each other in our common goals. This commitment is supported by writing what all team members believe are important protocols for the Team to comply with to maximize their capabilities to deliver faster and with higher quality.

With Scrum Teams I have found the following topics are a good starter list to start the creation of a Working Agreement:

  • Time and location of Daily Scrum
  • Testing strategy (unit, functional, integration, performance, stress, etc…)
  • Build and infrastructure plans (shared responsbilities)
  • Team norms (be on time, respect estimates, help when needed, etc…)
  • How to address bugs/fires during Sprint
  • Product Owner availability (phone, office hours, attendance in Daily Scrum)
  • Capacity plan for initial Sprint(s)

A common way that I facilitate is to put these topics on a white board or piece of easel pad paper and then ask the Team(s) to create their working agreement with these as guidance. If they find other topics which are important please add them to the list. I highly recommend creating a Working Agreement for your Team. It helps all team members understand what are common protocols for the Team and an opportunity to work through conflicts in practices.

Managing Software Debt

Posted by on 02 May 2008 | Tagged as: Acceptance Testing, Agile, Architecture, Leadership, Product Owner, Scrum, TDD, XP

At a recent Seattle Scrum users group meeting I presented on the topic of “Managing Software Debt”. Here is a link to a PDF of the presentation and the following is a description of the topic:

The Product Backlog in Scrum is used to prioritize implementation of features into software based on value. A Product Owner is charged with managing the Product Backlog to direct software implementation for the greatest possible Return on Investment (ROI). Entirely feature-based Product Backlogs do not consider the decay of software over time, and the resulting software debt can sink a project or company. This presentation will highlight ways Scrum Teams and Product Owners can work with stakeholders to manage software debt over the life cycle of the product.