While Agile methods are becoming increasingly popular and well-used, teams frequently state that they ‘are Agile’ by just adopting a couple of well-known techniques such as task boards and daily stand-ups.

However, if they are not looking at continually improving and addressing their issues, then it is unlikely that they are going to be successful in their transition to Agile. In my view, a team working in a truly Agile manner is a happy, motivated and successful team.

You may have heard the term ‘being Agile, not doing Agile’. Agile is about a change in mind-set, which requires teams (and subsequently every individual in that team) to be hugely collaborative and supportive of one another.

Individuals that learn and continually develop their own skillsets, such as becoming cross-functional, not only gives them a sense of pride, but also helps the team to support each other when needed to deliver the highest business value and meet their goals. Agile helps with this by providing team members with new opportunities to expand an individual’s set of skills.

Agile team members need to step outside of their current knowledge and skillset to become more cross-functional. Examples of individuals learning new skills are:

• developers understanding the system architecture or automating their unit tests;
• developers and business analysts learning testing skills so they can help out with exploratory or acceptance testing prior to a release;
• manual testers developing their technical skills to automate their tests during iterations; and
• testers picking up business analysis skills or understanding code to investigate defects when they arise.

Don’t get me wrong – I’m not saying that Agile teams don’t have their challenges. A team who is transitioning from traditional to Agile methods can encounter multiple issues, such as:

• how they break down their work into smaller pieces;
• getting user stories and acceptance criteria to the right level of detail;
• organisational culture changes to allow the team to be self-managing;
• understanding each role in the core Agile team; and
• the importance of their participation in the team’s planning, stand-ups, review and retrospective meetings.

Challenges are inevitable with any change, but the trick is for teams to openly discuss their issues and ensure they choose the optimal way to resolve them – then act on those solutions.

The idea is for Agile teams to remain as a team for future pieces of work, as they understand each other’s communication styles, have built good relationships and trust each other, and work in a collaborative way conductive to Agile methods. This is commonly known as “sticky teams”.

Bruce W. Tuckman created a well-known model which talks about teams going through the various stages of development to become high performing teams:

• Forming – when people first meet and everyone is nice and polite, with little or no conflict;
• Storming – as different characters and personalities arise, it can cause conflict which the team needs to resolve;
• Norming – when the team has resolved these issues and are working in a collaborative manner; and
• Performing – the optimal goal where team members are continually addressing the way they work and make improvements to become a high performing team.

Not only do teams need to consider these phases if they are a newly-formed team, but also when any of the team members change. For example, if a team member resigns and is replaced, they will need to understand the team dynamic with multiple personalities and vice versa.

The new person may also introduce good ideas from their previous experience, so the existing team shouldn’t assume they are performing at the highest level already – there is always room for improvement. A saying I heard recently was that “you don’t have to be sick to get better”, which I believe resonates well with all Agile teams.

Training and coaching can help the team in the move to Agile, but it is also up to the individual team members to continually adapt themselves, and to be open and honest. If teams do not address their issues, I have seen them becoming increasingly frustrated with people no longer raising issues at retrospectives, resulting in low morale and overall job satisfaction.

Walking around an office working in an Agile environment, it is really clear to see which teams are working in a collaborative manner. Namely, they are in huddles, having discussions, white-boarding solutions as a team, and other collaborative and productive activities.

These collaborative teams work in a close-knit manner, have a sense of belonging, support and appreciate one another as they all play a big part in adding value. They have a real sense of ownership when discussing the options and selecting the best ones, and relish the opportunity to design and build a system in the best possible way.

During planning sessions, the team discusses the work needed to achieve the customer or business requirements, and collectively commit to delivering it. If they are unsuccessful in delivering what they have committed to, the whole team is responsible for this. Thus, it is in their interest to support each other and continually collaborate to achieve their goals.

You may come across individuals who are really uncomfortable in an Agile environment. For example, naturally conservative people may find it difficult to work in Agile teams initially.

Similarly, traditionally developers can be heads-down types that work in a more isolated manner and predominantly focus on coding tasks. However, Agile teams require all members to understand the need for their participation – all voices in the team must be heard and all opinions are valued.

Retrospectives can be sometimes seen as unnecessary and taking up time that could otherwise be spent on tasks which add more value. However, retrospectives are critical to the team becoming increasingly effective and addressing the issues they have faced as soon as they happen. It is important for actions to be taken forward into the next iteration to ensure those issues are resolved and, hopefully, become topics for what went well at the next retro.

If your retrospectives are getting a little dull and the team’s enthusiasm appears to be diminishing, try adding some collaborative games to spark some meaningful fun into the sessions. You could also get another team’s Agile lead or Business Analyst to facilitate and share what they are doing. Also remember that retrospectives are about celebrating the success of the team, and not only about the negative aspects!

Assessing for success

In summary, getting Agile right can lead to teams who take great pride in their work, have high morale and job satisfaction, share common goals, and generally love coming to work every day. Taking a step back to assess your own team’s processes and behaviours can be a very enlightening experience – it’s always a great place to start and some quick wins are often easily achieved!

However, becoming collaborative and cross-functional is not something that can be learned overnight. It requires both commitment and perseverance, something that Agile training can help with.

If you are starting on your Agile journey, or feel that you are not getting the value from implementing Agile that you thought, contact us today to find out how we can assist.