Welcome to EMC Consulting Blogs Sign in | Join | Help

Rizwan Tayabali - Digital Strategy and Agile Blog

NOTE: My blog has now moved to HTTP://WWW.SOCIALEFFECT.ORG with all new content aggregated at HTTP://RIZWANTAYABALI.INFO - I'm writing about social business, change and human transformation, customer centricity and organisational design.

Managing different types of Agile team (R1 to R4)

If you’ve heard of the different types of Agile team, you may also have read about how they are supposed to be led and managed, but if you're anything like me when I first implemented Agile it is quite probable that you haven't. Agile team classification is basically contrived to fit what is known as Situational Leadership theory as developed by Paul Hersey and Ken Blanchard (see Hersey, P. and Blanchard, K. H, Leadership and the One Minute Manager, William Morrow, 1999). This approach is in use because running Agile teams is arguably more about providing leadership than management.

The basic premise of the theory is that Leaders should adapt their style to team maturity based on how ready and willing they are to perform required tasks in terms of both their competence and motivation. The classification uses a four quadrant grid matrix outlining four recognised types of team, classified by their Readiness Level (R) based on their overall degree of ability and willingness. For more detail on these levels see my post Recognising different types of Agile team (R1, R2, R3 or R4).

Agile Readiness Grid 

Leadership in an Agile team comes from three sources in order of impact as follows:

  1. The Team Leader (aka Scrum Master)
  2. The Responsible Owner for the Project (aka Product Owner)
  3. The Team Members themselves

The situational leadership approach under discussion applies primarily to the Scrum Master’s interaction with the team. Personally I'm not a huge fan of the classical theory so I've adapted it to make it more practical as follows:


R1 Teams – Little or no ability or familiarity, and Unwilling or insecure about Agile

Required Leadership style = Telling / Leading by example

The Scrum Master in a team like this is likely to be most successful in an authoritative role, leading by example, making decisions for the team, educating, explaining, giving feedback and demonstrating clarity in terms of both process management and task delegation. The corollary here is that the Scrum Master must already be very familiar if not expert with Agile as a process, and needs to have overcome their own issues with the methodology. Any uncertainty around the process or its merits from a leader in an R1 team rapidly cascades and balloons through the team, resulting in increased resistance to delivery and the resultant efficiency and effectiveness losses.

If the Scrum Master is also an Agile novice it is imperative that they remain positive about Agile, locate a source of expertise to deliver the structure needed, and at all costs avoid falling back on traditional ways of working to get through difficult periods. R1 teams are on a steep learning curve but are sceptical at the same time and so will challenge the process and their roles relative to each other. They also typically have very different understandings of what Agile is all about. The Scrum Master must embed the working philosophy, minimise scope for unnecessary argument around how things need to be done, and needs to take a firm stance on dispute resolution.

The major leadership focus here should be positivity, team building, education and process enforcement.

Some tips for managing novice Agile teams

  • Take the team on an Agile ‘Team-working & Estimation/Planning’ course (ideally not Scrum-Master focused); once at the start and then once again after a few sprints to ensure that all members are working from the same baseline understanding of the process and their responsibilities.
  • Make sure that continuous integration and nightly builds are in place to help with regular and positive end-user feedback.
  • Engage the services of complete neutrals for running retrospectives.
  • Be careful not to underestimate the amount of time spent managing team interaction, and at all costs avoid taking on any critical delivery role within the team as you will find yourself under significant pressure and most probably end up doing both roles poorly.
  • Finally focus on the short term and small wins to boost confidence, and ensure that the team gets recognition for their achievements, both from the Product Owner and from the business.


R2 Teams – Little or limited ability, but with Willingness to try and apply Agile

Required Leadership style = Guidance / Coaching

Arguably the key difference between and R2 and R1 team is that members in an R2 team are not sceptical either about the process or working together. This removes some of the need for focusing on trust or team-building and selling benefits of the process. There is more scope to let the team engage in discussion about how they prefer to work, but still a high requirement for the Scrum Master to lead by example with clarity on process and task management. The main challenge is to prevent any loss of confidence, and as such the same elements of the telling style apply. Education is paramount and planning is vital to prevent excessive overtime. Retrospectives can be more open and tend to be more effective because there already are the necessary levels of trust.

The above can be elaborated further, but at this point I’m going to be contentious. I’d argue that except right at the beginning of a project there is no such thing as a true R2 team and as such is not an area worth elaborating too much on. Willing or not, people are inherently resistance to change that forces them out of their comfort zones, and in pressure situations will revert to tried and tested ways of coping in such situations – and in some ways rightly so. Even if you introduced Agile to a close team that has worked well together over a significant period of time, the removal of roles and hierarchies, and the dependencies on cross-functionality will change team dynamics and disrupt trust and confidence.

In essence then, unless you’re working with a team that already is familiar and comfortable with Agile, you can safely assume that you will be working with an R1 team, and apply a leadership/management style that focuses primarily on telling and leading by example, but with a focus on coaching and selling benefits.

Combined R1 & 2 Leadership Style = Telling / Leading by Example / Decision-making / Educating


R3 Teams – Good ability and familiarity, but Unwilling or resistant to Agile

Required Leadership style = Supporting

R3 teams however are clearly distinguishable and must be considered separately. This type of team already knows what the Agile process is all about. They are able to go through the motions, manage the artefacts and know how to survive within an Agile environment. They do not need much educating or coaching with regards to the process and their responsibilities. However they are unwilling most likely because their previous experiences have not necessarily been successful and/or successes were achieved at a high team or individual price. This type of team reacts badly to being told what do because it is already capable of self-organising if it wants to. And ‘wants to’ is the key. The Scrum Master here needs to focus on moving the team towards wanting to work this way by being support and participative; and by showing commitment to the team and allowing it to use Agile to its advantage. There must be more room for discussion around process and group consensus on ways of working. There is still need to be positive about the merits of following Agile working practices and enough expertise to provide clarity when needed.

But most importantly it is the Scrum Master’s role as a remover of obstacles that comes into play. Success horizons are longer because the team can see future issues better than R1 or R2 teams and the Scrum Master must start planning further into the future to deal with dependencies and ensure that necessary conversations are able to be held at the appropriate times. They must make the bigger picture clear to the team and keep members involved with management of deliverables. The Scrum Master also needs to ensure that they are clearly perceived as an integral part of the Agile unit through demonstrating strong commitment and support to all members, as well as confidently backing team decisions to the Product Owner or business.


R4 Teams – High level of ability and experience, with Willingness and confidence in Agile

Required Leadership style = Delegating

R4 teams work well and confidently both with each other and with the process. They require little or no process or task guidance and exhibit mature working behaviours. The Scrum Master is there to help but not to make delivery decisions, which should be delegated to the team itself to keep them motivated and engaged. This is in other words a ‘high-performing’ team, and thus will most likely be self-motivated and driven by the satisfaction of taking on and overcoming technical and time challenges. The Scrum Master can help keep the team engaged by focusing on removing obstacles, and ensuring that there is a constant throughput of work with the Business capable of feeding back at the pace of delivery.

An R4 team is fully capable of self-organising and managing itself, and let’s face it, is therefore an extremely rare occurrence! Frankly it really shouldn’t need a full time Scrum Master, and typically in organisations where these exist, a Scrum Master would probably be involved with a number of Agile teams rather than just the one.  

Agile Leadership Grid

Published Thursday, October 11, 2007 1:37 PM by Rizwan.Tayabali

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS


No Comments

Leave a Comment


About Rizwan.Tayabali

Background in business and management consulting. Current focus - Social Business and Social Enterprise.

Contact: http://rizwantayabali.info or email at rizwan dot tayabali at gmail dot com
Powered by Community Server (Personal Edition), by Telligent Systems