Project delivery in an agency environment is a complex beast at the best of times. There are many factors that must be taken into account to ensure that you deliver the product that the client needs while maximising your profit margin. This is the first of a series of articles that I am putting together looking at how learned processes and behaviours from the agile movement can be adapted to optimise project delivery, regardless of whether a given project is being developed in an agile manner to the client or not.
What is 'The Conflict Principle?'
The Conflict Principle is an idea I developed as an expression of time spent with some of the best teams I had ever worked with. This goes back some time now when I was working with teams that were moving towards agile before I fully understood what agile really was. I always felt that the teams that seemed to develop the highest quality product had a high level of what I liked to call 'positive conflict'. Positive conflict is distinctly different from negative conflict in that individuals within a positive conflict environment have a healthy understanding and respect for each other but all are aware that they have different perspectives. Positive conflict arises between individuals who debate a scenario from their own perspectives. The consensus that follows in theory results in the best quality product for the least effort.
This way of working is common within in-house agile teams and doesn't really have a name as such but comes out of representation of different skills within the development team and Product Owners input in planning meetings. The end result is the same. An attempt to define the best quality product for the least effort.
What Enables Positive Conflict?
Positive conflict in a development setting requires a structure in place that allows the developers and creators (or their representative) to be at the same level as the representatives of the client. For the purpose of conflict this then creates two distinct groups, the 'Makers' and the 'Specifiers'. Developers, Designers, UX Specialists, Scrum Masters and Development Managers fall into the 'Makers' group, while Product Owners and Account Managers fall into the 'Specifiers' group. Project Managers position often sits across these groups and, herein, lies a problem. It is also a role where definitions seem to blur from one organisation to another.
For Positive Conflict to occur naturally it is essential that the two key groups remain in balance. I clearly remember a scenario in my past where, as the technical lead on a project, in a team where we had a fairly flat structure having to adjust to a situation where senior management put the business analyst in charge of the entire team. We went from having a healthy positive conflict dynamic and delivering high quality products very quickly with a very positive team atmosphere to a negative environment of simply delivering what we were asked to do and the quality of the product suffered significantly - this led to several significant rewrites on work that cost us over a month of productive time and a significant increase in technical debt. No one individual was responsible as such but the team was not able to operate in the most efficient way possible any more.
In order to keep balance it is essential to locate the Project Manager into either the 'Specifiers' or 'Makers' group. The PM should then have a single responsibility. Either they become a facilitator for the other makers (and effectively it then becomes a role similar to a SCRUM Master on an Agile team. As this article is trying to be agile agnostic we'll simply refer to this role as the 'Facilitator') or the Project Manager works alongside the Product Owner to manage the client side of the relationship in which case the PM falls into the 'Specifiers' group. In this case the 'Makers' then requires a representative at equal effective level to act as their 'Facilitator' and to ensure that the voices of the two groups carry equal weight.
Empowerment and Engagement
I talk a lot about the importance of empowerment and engagement within teams and it is crucial here too. I will undoubtedly touch on this again in following articles on this subject but the nature of enabling a constructive argument of positive conflict empowers and engages the developers and creative members of your teams and enables them to feel that they are being the best that they can be. Both directions of the positive conflict scenario are learning environments. The 'Specifiers' learn more about what can and cannot be technically achieved allowing them to interact more efficiently with clients. The 'Makers' get a much greater appreciation of how and why a client specification is what it is, this fosters a much more positive environment for personality types typically drawn to creative or technical work.
In my next article in the series 'Optimising Project Delivery' I'll be looking at ways of managing resource allocation using empowerment principles to reduce wastage from the ground up and improve an agency's bottom line.