After a couple of weeks, your team has undergone a couple of sprints. As an agile coach, scrum master, or team member you start to wonder if there are any signs that the agile team roles are performing up to par, or better yet, if there are tell-tale signs that your team is likely to under-perform in the long run.
Below are some distinct signs that you need to look out for:
1 – Velocity is fluctuating and unpredictable
The point behind tracking and managing velocity is to expect that eventually the velocity will stabilize at some point. This will go hand-in-hand with being able to make decisions on how many remaining sprints can be used to eventually complete the prioritized items in the product backlog, or how many points will be used for planning the subsequent sprints. If the team members are being pulled in and out of external assignments or multitasking on multiple projects, it would be expected that velocity is not going to stabilize any time soon. This type of issue can be rectified if the scrum master role or agile business coach point out to team members that they should remain exclusive to the one project being measured.
2 – Scrum and standup durations go off topic and outside timebox period
In many circumstances, we tend to go off topic on meetings where the members involved lose sight of the purpose or agenda of the call. If everyone is stuck on trying to resolve an issue on the scrum or standup, there needs to be a clear signal to all, “make a note of the issue,” and the respective members close to the issue can work together to help resolve it after the meeting. As a self-organizing team, all members should eventually realize that the scrum/standup meeting is not about problem solving, nor is it entirely about status. Some agile practitioners do not realize that the meeting ultimately is about commitment to the team. The update comes when saying what was done yesterday, but what will be done today, given there are no blockers, is the commitment. Beyond that, there should not be any reason why a scrum/standup would take so long.
3 – Overly dependent on fill-in roles
This issue comes with improper planning, lack of agile training, or missing skills assessments. It becomes a very awkward situation when large gaps in skill sets occur in the project. This may also be a result of disengaged stakeholders that may have misrepresented their requirements early on. The main idea behind having a self-organizing team is to be sure they can cover each other’s skill gaps in a general sense, but if there are huge gaps, i.e. there’s nobody with agile business analyst capabilities, and project requires one, there certainly needs to be a discussion around why that position isn’t filled right from the start. Other issues start when agile team members are partially assigned to another project at some point mid-flight in the project. As an example, if a Product Owner is not fully engaged, the backlog ordering and prioritization will suffer. This may put a strain on the entire team to fill in for. Since the Product Owner is the one who knows the business values of the features to be ordered in priority, it’s not necessarily an easy gap to fill. Someone needs to step in and take over that role on a full-time basis so that the backlog is groomed effectively and with the expectations of the stakeholders.
4 – Loss of transparency and hidden agendas
There may be instances when some members are no longer motivated, perhaps because of personality incompatibilities, or superiority complexes. Obtaining an agile mindset is not easily achieved by everyone, but there are some that fall back into command-and-control mode, or don’t feel the need to attend agile courses. In doing so, this may bring about the sense that some team members are trying to “one-up” the other by keeping information hidden from others until the last possible minute, and catching everyone by surprise. Nobody would want to find out toward the end of the sprint that a particular feature can not be implemented, if that information was actually known at the beginning.
5 – Repeated anti-patterns that were identified in Retrospectives
As you come to the end of a sprint, the team’s opportunity to provide continuous improvement feedback is driven in most part by the retrospective session. This allows everyone to identify what they did that went well, and didn’t go so well. Further to this, there are categories of instances that should be identified as what to “continue doing,” “stop doing,” and “start doing.” As you might guess, the hardest part to do out of those three instances is the “stop doing.” We can see even in our present lives, that habits are hard to break, and in most cases we like to keep the good ones, but really try hard to get rid of the bad ones. Over time it may be normal to see that certain bad habits within the agile team continue through multiple sprints, however if you’ve reached past your third or fourth sprint with the same habits continuing forward, there may need to be some further process analysis to zoom into why these ineffective workflow processes or habits have not been extinguished. A simple and fast way to get to the root of most issues, is through activities such as asking the “5 Whys” or drawing (and populating) a Fishbone Diagram.
What to Expect From the Team
The agile working team is one that learns and innovates over time. If everyone is there only to keep up with the status quo, the team will inevitably under-perform, too many negative issues will be left unresolved while leaving no time to address value-added tasks. The team should be engaged right from the start, with ample opportunity for buy-in from each member. If there are doubts being raised early in the game, that might be normal, but keeping those doubts on the radar, and perhaps even asking the product owner to add them to a risk-adjusted backlog (no matter how ridiculous they may seem) can provide some great benefits over time.
[Image courtesy of iosphere at FreeDigitalPhotos.net]
Share this:
This work is licensed under a Creative Commons Attribution 4.0 International License.
