Ever had a conversation with someone regarding Agile only to discover a massive gap in what actually constitutes Agile and what they are practicing? This is a regular occurrence for me, whether at an Agile meet-up, conference or teaching an Agile course. Often they have just been following a few Agile practices, sometimes poorly, thinking that this constitutes ‘Agile’. In fact, many times they don’t really understand the purpose or value/benefits of these practices.
So what should you look out for when trying to identify dysfunction in an Agile team?
- Lack of communication – when team members aren’t voicing their opinions or collaborating
- Lack of participation – when the whole team aren’t getting involved in key ceremonies
- Lack of cooperation – when there remains a segregation between traditional roles
Let’s address some specific examples on how these issues can arise across a range of Agile activities/ceremonies, and the reasons why these issues go against the nature of Agile and adherence to the Agile Manifesto and 12 supporting Principles.
The most common Agile activity is the Daily Stand-up or Scrum. This, for me, is probably the best indicator of a dysfunctional team or anti-Agile practices. This is no longer an exclusively Agile practice, as many non-Agile teams also use this type of meeting to give greater visibility of team activity and progress. In Agile, this has an extra level of importance as the team can take accountability and share the load if certain team members are falling behind in their tasks.
Communication breakdown in a stand-up is a fundamental issue and sign of dysfunction, as this discussion is essential to achieving a shared understanding of what each team member is doing and thus how it impacts the next set of tasks. Red flags include:
- Comments such as “I have nothing to report” or “I am doing the same as I did yesterday.
- Lack of discussion or interaction when reporting updates.
- Tardiness and lack of preparation.
Dysfunction can also be easily identified in Iteration Planning Meetings. An obvious indicator here is if some team members are not invited to participate in these meetings. This absolutely should not occur, as all team members should have an equal opportunity to contribute at these meetings; after all they are expected to commit to delivering work that derives from these planning meetings.
This planning meeting is the opportunity for the teams to have an in depth understanding of the product that they are building and influence how it is built. The team should have a view of what they are going to be working on in detail for the first couple of days of the iteration and what other tasks they may need to pick up to help complete all stories. These planning meetings are not just an activity to come up with a list of things to do for the next week. They should be used by the team to collaborate, ask all those questions so that the whole team has the same understanding and the team is all working towards a common goal. The meeting facilitator needs to ensure that everyone gets a say and that there are lively exchanges of information. This sharing of knowledge also has an enormous impact on decreasing the risk of key person dependencies. More than one person can therefore work on a task resulting in a continuous flow of ‘done’ product.
Full team contribution is also key in the refining of estimates in iteration planning meetings. Estimation techniques such as planning poker rely on the fact that it is a whole team estimate and not separate ones; for example, one for development and one for testing. If a team member has not spoken up about their concerns, shared knowledge or ideas, these estimates may be wildly inaccurate which can be particularly disastrous if you are working in weekly or even less frequent iterations. The Scrum Master should facilitate this meeting to ensure that all the team feel that they are being listened to and are openly contributing. For example, you should be hearing discussions such as these:
- If I build it this way how much additional regression testing will that mean?
- How can we build some hooks into the code to help with my automation?
- Can you provide us with some estimate of the likely hits to those pages when we go live and are there likely to be peak periods or unusual spikes of activity?
When identifying dysfunctional practices, it is important to look beyond the Agile ceremonies and watch the team during their day-to-day activities.
A sign of healthy Agile practice in activities include if there is a lot of movement within the team, as team members shuffle to sit next to each other or huddle to discuss the project at hand. In cases where the team is not co-located, healthy interaction can be identified by the frequent use of open video links or even shared computers. Teams may even take it a step further and adopt the practice of the “Three Amigos”, whereby there is the proactive inclusion of a developer, tester and BA in any discussion to ensure a balanced view is achieved.
Absence of these good communication and collaboration practices may be indicators of dysfunction.
In examining areas of unhealthy Agile practices, you could also watch out for signs of a traditional mentality, such as the segregation of roles. One of the most common red flags in this area are statements such as “testing is holding up completion of stories”. In an Agile project, quality is the responsibility of the whole team, with every member taking on testing activities. This observation could be resulting from a number of issues:
- Firstly the developers may still have the view that as long as we finish the coding on time, the testing can be done by the testers, that’s their role. This normally results in the testers having too many tests to run, finding of too many defects particularly those that should have been found as part of unit testing.
- The creation of too many tests that are not correctly aligned to the risk and business value of the feature under test. Testers are typically more risk adverse however what they need to do is focus on the acceptance criteria and also understand what other testing has been done to avoid duplication.
- Developers could be starting new user stories, particularly near the end of an iteration, when all the testing cannot be completed. Developers should not be coding up to the last minute and should recognise that it is better to complete stories that are still in progress rather than starting new ones.
These examples should all have been discussed during the iteration planning and included within the estimation process. As minimum if these behaviours are seen they would be good candidates for discussion in the retrospective meeting.
Agile is not about “going through the motions”, following a process or practice without knowing why or how it benefits the project. Agile is about a real change in mindset; one where collaboration is key. It is not about individual heroes making the delivery possible, rather making the whole team work together with their shared contribution delivering successful outcomes.
The Agile Manifesto and Principles lay the foundations of how you work as a cohesive high performing team. I would suggest that you have those statements posted on your walls near your workspace and continuously refer to them, challenging the tasks that you are undertaking. Particularly refer to them when you are doing your retrospectives, are these activities adding value to the product?
It is not about skipping processes as you run out of time, it is all about planning effectively so that you have time to reflect, learn and adapt from issues encountered and successes that should be repeated. Equally as important is that for the activities that are working for you ensure that you celebrate these and keep doing them.