Establishing Boundaries via Distributed Control
A solid working agreement between the Scrum Master and the team is the foundation for all improvements. Accountability, courtesy or law-and-order are not the key reasons. Boundaries simply make everyone feel comfortable. Comfort comes from familiarity. Familiarity comes either consciously or sub-consciously by knowing where you stand. The interesting thing about boundaries on an Agile team, is that those boundaries come from those who observe them. It’s called “Distributed Control”. (For more information on this subject, read “Managing for Happiness” by Jurgen Appelo.)
Fist of five voting gets the job done quickly!
My Default List
I usually run through this list, using the “Fist of Five” voting method. (Each team member raises their hand. One finger – strong opposition. Five fingers – strong acceptance.) Establish this agreement during your first team meeting. If you wait, you’ll probably never get to it. Working without boundaries will be very frustrating for everyone.
For Every Team
- Meeting Rules (apply to all team meetings)
- No cell phones.
- No computers.
- No work.
- No side conversations.
- Time for the Daily Scrum. (Make a recommendation and work from there.)
- Initial length of the sprint.
- Keep in mind a less experienced team and product owner, may need more time than an experienced Agile team.
- I find three weeks is a good start. Then work toward the standard two weeks as their confidence grows.
- Schedule (day) for the Sprint…
- Review
- Retrospective
- Pre-Planning
- Planning
- Definition of Ready
- More than one person on the team understands the business need.
- More than one person can give a high-level explanation of the solution.
- Confirmation by the team, the solution can be completed within the Sprint.
- Definition of Done
- Solution satisfies the business need.
- Solution satisfies the outline given for the technical solution.
- Product Owner and business accept the solution.
- The entire team is responsible to deliver on time. (Swarming may be necessary.)
If Not Already Established by the Organization
- Decide on estimation method.
- Time estimation.
- Comparison estimation. (If yes – decide on values to be used, such as story points, dog breeds, etc.)
- If comparison estimation is decided, explain the guidelines for Planning Poker (White Band Delphi technique).
Challenges
As odd as it may sound, working agreements have not always been easy to establish. How well this works, depends on the maturity the team. If the team is completely new to Agile and/or completely new to each other, you may need to do some on the spot training.
If you find a short explanation does not work, complete the list indicated above and note the items the team did not understand. Use that list for a separate meeting or during the Retrospective. Give the team a basic understanding of what the item in question is and why it is important.
Cross Team Agreements
As your team grows accustom to their agreement, you’ll find they may recommend developing agreements between teams. This likewise gets everyone on the same page as to how the teams will relate. This is a great way to manage time sensitive dependent processes. Here’s an example between a mobile app team and middleware team. The mobile app team uses Scrum. The middleware team uses Kanban.
- Mobile app team grooms the backlog.
- Beginning with the top item in the backlog, the mobile app team examines the bug or story confirming if the fix involves or is due to a middleware issue.
- If either of these are true, the mobile app team labels the issue using morios, or morandroid.
- The issue appears on the middleware team leads dashboard.
- The team lead adds a ticket to the middleware team’s Kanban board linking the original issue to the middleware ticket.
- The middleware team confirms the issue and begins work on a fix.
- The middleware team adds the tested fix to their next build.
- The build must arrive by EOD Friday of the first week of the two week sprint.
- Monday of the second week of the two week Sprint, the mobile app team tests the build.
- If the build passes, it is used to support continued mobile app development.
- If the build fails, the issue in the mobile app team’s backlog is marked as Blocked by the middleware ticket, and remains blocked until the fix is complete and passes.
Benefits
If the issue is caught before the Product Owner adds the item to a sprint backlog, the middleware team has time to fix the problem before the sprint begins. This eliminates lag time.
Conclusion
Working agreements keep team expectations in sync. It reduces tension and offers a way for the team to identify improvements.
Working agreements between teams assist in identifying blockers before suspect items are put into a sprint backlog where they may cause sprints to fail.