blogs.conchango.com

As promised, but somewhat later than I was expecting to write this blog, I intend to answer some issues that Kevin Brady raised in his article Agile/Scrum does not get to grips with human psychology, namely:

• People will always put their own interests ahead of the interests of the group.
• People are self-interested
• Karl Popper’s “First law of collective action”. You can never get more than 5 people to agree on anything.
• The Project Managers /SCRUM MASTERs turned themselves into Project Administrators.
• The project teams had in almost all cases been taken over by strong personalities leading to mini dictatorships.
• Knowledge Monopolies.
• Most of the talented young development staff were leaving
• Clients fed up with never-ending, continuous involvement in IT projects

To me this list arises not from the development methodology used but rather in people's inability to communicate effectively their desires and preferences when a conflict arises.  I think there are four ways in which to handle conflict:

• Aggressive: Directly telling someone what it is you want or prefer without recognising the needs of others in order to win the argument.  This can involve threatening, intimidating or humiliation.
• Passive: Hoping to get what you want by hoping someone else will guess your needs
• Passive Aggressive:  to use subtle indirect techniques to get what you want or prefer including manipulation and emotional blackmail
• Assertive: Directly telling someone what you want or prefer in a controlled fashion whilst recognising what they want and what they would prefer in order to negotiate a solution

When reviewing this list, it is obvious to me that assertiveness is the best way to resolve conflict, yet as so often in life, it is a technique that is so underused in everyday life (for example, I often tend towards the passive aggressive rather than assertive to get what I want).  So why is this the case?  For me it is because it takes courage to stick my neck out and say directly what I want as I fear humiliation, ridicule and rejection. 

Often when I think about what Agile means I often think it is about flexibility, balance and being reactive, but none of these would be possible without strength.  Like a good tight rope walker, gymnast or ballerina the core of there skill lies in their strength.  So how does strength translate in software development? For me it is the strength required to assert oneself starting with me the Scrum Master.

As a Scrum Master I act as a facilitator between factions to ensure that progress is maintained and the project is delivered.  In order to do this I need to assert the rules of the Scrum process in a fashion that is assertive and not aggressive.  This involves me being genuine and having respect and empathy for the parties involved.  To do this I like to remember the 4I's technique:

• Introduce - Introduce the topic e.g. "When the team are interrupted with new requirements"
• Impact - Describe the impact of the topic e.g. "the team are distracted from what they are working on in the Sprint"
• Inform - Say what you want  e.g. "I would prefer if new requirements are introduced at the sprint boundaries rather than in a sprint"
• Incentivise - say why they benefit from the proposal "that way the team are not distracted and this is the best way to ensure that the most functionality is delivered for you" 

In order not to appear aggresive, I try to remember to keep it impersonal by never saying "you" (apart from the incentivise part), keeping it as much about myself as possible and avoiding words like “should” and “must”.

The next thing I must do as a Scrum Master and facilitator is to encourage the parties to be assertive rather than aggressive, passive or passive aggressive.  This may involve me asking quiet people their opinions, asking passive aggressive people what they want to achieve or by reminding aggressive people of the rights of others.  This encourages equality across all parties so the various needs and preferences become the issue and not the personality of the parties involved.  When the personalities have been removed creative thinking becomes the forerunner and a solution is almost always achieved.  To do this I like to remind people of one or more of their (and others) "basic human rights", namely

1. I and other people have a right to be treated with respect
2. I and other people have the right to say no
3. I and other people have a right to get emotional
4. I and other people have the right to make mistakes
5. I and other people have the right to have feeling, convictions and opinions
6. I and other people have a right to change their mind
7. I and other people have the right to negotiate for change
8. I and other people have a right to ask for help and support
9. I and other people have a right to protest against unfair criticism or treatment
10. I and other people have the right not to know something 

So how does this answer Kevin Brady's points above.  I shall work through each one I say how I would like to deal with these as a Scrum Master.

• People will always put their own interests ahead of the interests of the group. - I really do not agree with the "always" in this sentence, we are social creatures who work together to achieve our disparate goals.  However  if someone is repeatedly putting their interests ahead of the delivery, the Scrum Master should assert themselves with this person to remind them of the rights of the other team members or groups.  It may even be necessary to remove them from the process altogether.
• People are self-interested - And?  This is somewhat obvious, but as above, someone who only puts their interests first may need to be reminded of other people’s rights.
• Karl Popper’s “First law of collective action”. You can never get more than 5 people to agree on anything -As a Scrum Master I try to keep the team size to between 5-9 individuals.  I also recognise that the various skill set will focus on different areas so that overall agreement can be made in Sprint planning  for example .
• The Project Managers /SCRUM MASTERs turned themselves into Project Administrators. - I have found this in both Scrum and waterfall projects.  As a Scrum Master I would remind myself of my duty as "process owner" and as such all the administrative duties fall on the Product Owner and the Team in the Scrum Process. 
• The project teams had in almost all cases been taken over by strong personalities leading to mini dictatorships. - Teams will often develop with a leader, which is usually a good thing, however, a good leader listens to his troops and if this is not happening then the Scrum Master should intervene to ensure that the team members do assert themselves and they are not bullied.
• Knowledge Monopolies. This can definitely happen on Scrum projects, with people sticking to their "comfortable" silos.  As a Scrum Master I would encourage some pair programming but I admit this would be a little passive agressive.
• Most of the talented young development staff was leaving - probably because no one was listening to them.  As a Scrum Master I want to ensure that everyone is heard by encouraging all the team that the input is valuable.
• Clients fed up with never-ending, continuous involvement in IT projects.  Good sounds like an ideal project!  As a Scrum Master I want to encourage the Product Owner to take full responsibility for the direction of the project on a day-to-day basis.