Agile: it’s not for the Fragile…

Over the last 10+ years as a Business Analyst, Product Owner & Product Manager in a wide variety of teams, environments, sectors & projects – and, indeed, as a Customer overseeing my own Product development (see flowdaq if you’re interested in that) – it has become clear that Agile philosophies, concepts and techniques do actually work – at least, when appropriately adapted to the circumstances. However, it is also clear that Agile does not suit some scenarios or some projects. Project professionals (hopefully) adapt the Agile techniques that work for their scenario or project and omit those that don’t.

More importantly, however, Agile does not suit some people. Unfortunately, it is often not possible to adapt people who Agile is suited to, or even to ask unsuitable people to adapt Agile ways of working.

Much has been written about how all stakeholders in the modern Software Development world need to adopt an Agile mindset. Unfortunately, it isn’t as simple as that. Asking an individual team member to adopt a mindset different to their natural mindset will probably result in a lack of efficiency and even a lack of job satisfaction. Insisting on it will only magnify that effect. This is ever more apparent when an entire culture is asked to adopt a mindset contrary to their culture. Yet, it happens – a lot – and not always successfully. In Agile, people are one of the most – if not the most – important factor in the success or failure of a project.

Self-organising Teams

One of the main forms of Agile, as implemented in Software Development, is Scrum and its (apparently unlimited) variants. It embodies one of Agile’s “selling points”, namely self-managing, multi-disciplinary Teams. The Team, as a group, are responsible for accepting, understanding, evaluating, allocating and then delivering on the requirements provided by the Customer (often represented by the Business Analyst, Product Owner or Product Manager).

This gives the Team a lot of freedom but also a lot of responsibility. One of the main characteristics of the interactions between Team members is that the contribution, perspective & opinion of each member is equally important, equally valid and equally valuable. Another is that the Team acts as a unit. In other words, they accept and then deliver on the requirements as a Team. Therefore, success or failure is the responsibility of everyone in the Team. Individual Team members do not succeed or fail in isolation. This is both a positive and a negative.

This can be very empowering, especially for less experienced Team members who soon learn that they are permitted (often actively encouraged) to challenge the more experienced. Not only does this keep the Team’s ideas ‘fresh’, it’s also a fantastic way for Junior members to develop quickly, utilising the knowledge provided by the Team as a whole (e.g. when debating how best to implement a particular requirement).

However, it can also be a great hiding place for Team members who don’t contribute, for whatever reason. Where the reluctance is caused by simple caution, inexperience or fear of being seen as ‘wrong’, a well-functioning Team will soon correct this by encouraging reluctant contributors. If the reluctance is cultural, it can still be overcome but it requires explicit, active effort to do so and can take quite a bit of time. Conversely, if the reluctance to contribute is simply down to laziness, lack of ‘ownership’ or lack of motivation, a well-functioning Team also needs to correct this as it can become much more damaging than simple inexperience.

This is where the mental strength of Team members comes under pressure. Like most humans, Software Developers hate being criticised, especially in ‘public’. It is no different in an Agile Team than anywhere else. For this reason, individual Team members need to be mentally strong but the rest of the Team – all of them, not just whoever takes the ‘leader’ or ‘manager’ role – need to be responsible, constructive, honest and transparent as well as being as open to accepting criticism as they are to offering it.

In addition, praise and acknowledgement must be equally obvious when warranted. Eventually, Team members will realise that the feedback is task-specific, issue-specific or purposeful rather than being personal. For those Team members who are simply not pulling their weight, the recurring criticism and lack of praise will soon make it clear that their involvement in the Team is not exactly as desired / required. If it does not improve, the Team can, and should, deal with this as a problem (including escalating if necessary). Otherwise, the necessary inter-Team relationships will deteriorate and the Team dynamic – and its output – will suffer.

Argumentative…? Good. Welcome to Agile

Self-organising Agile Teams also encourage – and, in fact, demand – what is often an underrated skill: debate.

While some people consider any argument to be a negative, this is a fundamentally flawed and potentially limiting / dangerous viewpoint in Agile. Team members who hate witnessing (or, worse, being involved in) arguments will perhaps find Elaboration, Collaboration, Estimation of Bug Triage sessions uncomfortable as this is where conflicting perspectives often come to the fore.

However, it is crucial to question other Team members’ positions whenever appropriate. Just because someone has been a UI Developer for 50 years, doesn’t mean their Ux ideas are right (in fact, with the speed the world of Software Development moves, it almost certainly means there is a good chance they are wrong!). Just because someone is called ‘Team Lead’ or whatever, does not mean they are inherently right or that they should get their own way.

When a Bug is identified, a Team that is comfortable debating will not simply accept that it is, in fact, a Bug but – if it is – will then be comfortable debating the root cause (note: root cause is not the same as ‘who to blame’!) and then be equally comfortable debating any proposed solution.

Similarly, when a Team is presented with a requirement, debating what the requirement actually means and how it should be implemented (instead of just accepting the interpretation of the ‘leader’ or ‘manager’) is very important. It is a mechanism by which the Solution (and then the Estimation) can be validated with some level of confidence.

Team members should be comfortable enough to (and should be actively encouraged to) question anything they do not understand or agree with, rather than just accepting them because of seniority or hierarchy. In fact, Team members should be encouraged to disagree, disagree, disagree (withing reason!)… and then commit to deliver what they initially disagreed with, but the Team has decided to do. This willingness to accept being overruled by Peers – particularly where the Team has decided to ‘go with’ a conflicting proposal made by a Junior or someone with ‘less expertise’ – requires a level of maturity and self-confidence that comes with time, of course, but can also be promoted by a well-functioning Team. Egos can be bruised, of course, but (most?) Team members will survive such a bruising!

Modern social evolution towards a less confrontational and more subtle approach to criticism can actually be damaging in Agile. A simple example: a sentence that starts with “It isn’t that bad, but…” could be interpreted as “It’s good enough” or as “Good effort but not quite good enough”. In the absence of clarity, the Team dynamic and the individual members’ mindset will provide their own interpretation. It might not be correct. Since the Team as a whole is responsible for delivering, the Team as a whole is therefore responsible for ensuring clarity – including where that means “Close, but no cigar“.

So, whether it is the courage to disagree with the ‘resident expert’, the courage to interject in the middle of a discussion between two highly experienced Team members to point out that they are both wrong, the courage to simply say “I don’t understand…“, the maturity to accept being questioned, the humility to accept constructive criticism or the mental strength to accept being overruled, Agile Team members need a lot of personal psychological strength.

Agile is definitely not for the fragile.