We take a look at Agile patterns as we come to the end of this season. There has been a lot of content covered. However, we do not want to move on without looking at tools for implementing these practices. Fortunately, there is an excellent DZone article on Agile patterns for those that want to dig deeper into these.
Avatars
An avatar is exactly what you might expect on a project. It can take the form of a magnet, a pin color, or a miniature of some sort. It could even be a playing piece from a board game. This pattern aims to give each dev team member a limited number of items they can work on at a time. When a ticket is “claimed,” the avatar is used to mark it. Thus, everyone can see who is doing what and it keeps members from being spread too thin.
The Backlog
This pattern is one of several of the agile patterns we will cover that have already been mentioned numerous times in our discussions. These items are likely already known to you in some way. However, they are still patterns we want to embrace as part of the agile process.
Controlled Failure
We are allowed to stop or pause tasks and even sprints as part of the Agile approach. There are many discussions available about the challenge of addressing lost opportunity and sunk cost. However, that is only part of what this pattern addresses. Also, we need to be able to stop forward momentum at times to embrace change. Controlled failure permits us to stop what we are doing to focus on something that has greater value.
Done
It is amazing how varied the idea of “done” can be. Likewise, that makes it one of the agile patterns we need to address as part of communicating. We need to agree on what certain terms and concepts mean, so the team members have a firm understanding of what is needed and communicated. The idea of “done” and how we progress tasks is important to define. When we do, we give the team members the tools needed to dive into tasks and complete them in the agreed manner.
This pattern extends to assumptions that include testing, quality assurance, code reviews, and more. We want to define how tasks are worked on and progressed through to deployment. That gives us a consistent method of evaluating progress and quality.
Estimating/Forecasting
The scrum approach avoids specific time estimates, where possible. Instead, we provide general forecasting around task complexity and level-of-effort. That ambiguity requires the team to have a common understanding of what our scoring mechanism relates to. For example, a team that uses estimates values of 1,2,3,5,8,13,21 needs to have some basis for assigning those values to tasks. We are not saying a 1 takes one hour of work. However, we do need to provide a framework for assigning these values. The team will always have variations on their forecasting (based on understanding and experience). Nevertheless, we need some common ground to keep the variations from being too broad.
Challenge of The Week: Are you missing any of these patterns?
