As someone new to Agile, when you hear or read about it, the impression you essentially get is that there is a homogeneous philosophy and set of working practices that you and your team will follow. In fact, while this applies to artefacts like the backlogs and cornerstones like the daily stand-up; when it comes to working practices, this is not the case at all. Depending on level of experience and willingness as a group, Agile teams have different and recognisable natures, and require different styles of management and interaction. Obviously this adds complexity to what is essentially sold as a very simple, and thus effective, delivery philosophy. However, in the hard-skills focus of the development environment, this, along with many other change and behavioural aspects of Agile, is crucial knowledge that is often overlooked.
There are four recognised types of Agile team, and these are classified by their Readiness Level (R) based on their degree of ability and willingness. The levels extend from 1 to 4, with 1 being the lowest i.e. Novice.
R1 – Little or no ability or familiarity, and Unwilling or insecure about Agile
R2 – Little or limited ability, but with Willingness to try and apply Agile
R3 – Good ability and familiarity, but Unwilling or resistant to Agile
R4 – High level of ability and experience, with Willingness and confidence in Agile
By this point you're probably thinking, that's good to know, but why should I really care? Well, the short answer is risk management from an organisational perspective, and also quality of life as a team member. If you know what you're dealing with, you can sidestep a lot of otherwise 'unexpected' pitfalls, both as a team and as individuals.
To carry on then, arguably teams progress from R1 through to R2, then R3 and finally R4. However, I'm not certain this is the case. Unless you are joining a well established and long standing Agile team, chances are your team will fall into the R1 or R3 categories. In the new to Agile space, a lot of people are initially positive and willing to give Agile a shot, so it is easy to feel that they fit into the more comfortable and positive R2 category, but the real test is when pressure kicks in and team members begin to feel the effects of working outside their comfort zone. Look for evidence of significant incentives and an experienced Agile leader before feeling confident that a new team will naturally pull together to overcome obstacles and change, regardless of their technical abilities. If you don't see this, assume it is an R1 and not R2 team, and log it as a risk factor that needs extra contingency and greater management effort. To reduce risk, the Scrum Master in this sort of team really should not be new to Agile, and must bring confidence and pragmatism to their role.
In the experienced arena, things don't necessarily change all that much. Simply having worked on numerous Agile projects does not make individuals more receptive or forgiving of this way of working. They may know the process and what to do, but their previous experience is not guaranteed to have been successful; they may have been through a host of different versions of 'Agile' and have a muddied view of what the philosophy is really all about; they may have been through badly managed or supported projects and seen Agile as the cause; or they may simply continue to feel that traditional methods suit them better. Recognising this can reduce risk by helping to focus effort on addressing resistance and implementing approaches to improve take-up and willingness, rather than ploughing ahead on the assumption that everyone is experienced and willing and therefore requires little or no support and management.
Finally of course, if you're lucky you will join or work with a team that has experienced success with Agile, is confident and practised, and has achieved the level of self-organisation and motivation that reduces the behavioural risks to delivery as negligible. This is when it is fun and challenging and delivery is most effective and relevant to business need. This takes time and perseverance, but is what we aspire to. So on to R4... upwards and onwards eh?!
NEXT POST: How to manage different types of Agile Team.