It's not about scrum or agile, it's about people

One of my ongoing pet peeves it's the marketing over substance of the usual "agile" and "scrum" proponents.

I've found near constantly that the focus of this approach by it's advocates, is not to facilitate a team; but to prove that the process (i.e. scrum based agile) is the best (and typically only) way to run a technical project, and write software.

Agile? ......... sounds more ridged to me.

I find this ironic as the pushers  (appear, in my experience to) rarely come come from a software architecture, or at least development back ground. It more appears a thinly veiled covering over typical old school management tactics.

As in part demonstrated by this post :

http://www.infoq.com/news/2010/11/working-with-difficult-people

Ignoring the apparent "I'm right your wrong" title (which sums up what I'm talking about) and going straight for some of the contents of the post, that  supports my points.

(Points they are ironically trying to distance themselves from, reading Arnold Mindell would help so many .....).

"Will Jessup notes that developers tend to be highly intelligent people and often won’t just do something because we say so. He suggests a dialogue."

A dialogue ? You mean actually communicate with a team, share a vision and try and focus on a desired outcome opposed to just telling people what to do ? ......... now there is a strange approach that will never catch on ......... sheesh, is there that much ego about still ?

I'll ignore the "developers tend to be highly intelligent people" as anyone can see that for how it's meant.

There is really little surprise there is resistance to the technique when this approach in used.

"Kevin Shine suggests that we should move from selling to getting them to buy in of their own accord: “There is a big mind shift between these 2 thinking approaches. One is collaborative and cooperative and the other is more command and control."

The obvious issue here is that the very common C&C driven approach is much more accepted and the norm, as well as being from the middle ages. The premise of "us and them" is set up by the method even before the person has met the "software team".

The situation is walked into with the mind set :

"I'm going to have to tell them how to do it and what is right. If they resist it's because I've not talked enough and told them what to do. Developers are difficult, I really need to dominate to prove myself." 

opposed to :

"I'm here to facilitate an outcome, that of a cohesive efficient directed team. The team will deliver a finished product. I'm not actually building it or solving the logic, though I do have a role to support the team how ever I can, and interface with the business. My role here is to understand the context of the work within time lines and communicate that to both areas. This is we, not us and them"

If the focus was an outcome opposed to being right, the focus would be on humble facilitation and progress, not proving process. One of the biggest failings of the application agile (not the method itself) being the tenant that it's pushed as:

"Agile right - developers and experience wrong".

It's top down hierarchy, "Developers are stupid and argumentative, treat them as such", again no surprise there is resistance.

But the focus of dealing with that resistance is always the developers? ......... how about the cause of it, the manner in which the change is being applied, and by whom ........ an applier of agile who is complaining about resistance maybe .......

That is seems some kind of revelation that team work should be collaborative or cooperative to the usual pushers of this technique speaks volumes.

This has nothing to do with agile or scrum. The title of that piece should of been : "Why being difficult, condescending and telling people what to do without engaging them will cause difficulties".

An example :

"In addition he points out that a new Scrum Master needs time to gain the respect and trust of  the team members."

Isn't this kind of thing blindingly obvious?  Sure I might of trained as a counsellor to help me understand group work, communication and respect. Let alone how to be client focused (which I switch to the "client" being the  project at work) to help me take ego out of it.

But given that these kinds of points are being talked about as if they are new or some kind of magic approach, is very disheartening and explains a lot as to the failure of enforcers of scrum & agile.

Lacking a clear and compelling and a sense of urgency the team doesn’t commit. Ashish goes onto suggest 1-1 coaching, root cause analysis and rigorous use of retrospectives to help team members discover issues on their own.

You don't need urgency, though I sense that is just code for "panic and rush everything".

What you do need is an understanding of timing in a business context.

The 2nd point that isn't talked about from this quote, is that the assumption is that it's always the developers or "other team members" that have the issues. Wholly arrogant in my view. It's just as common that it's the people trying to enforce agile/scrum or management themselves who have issues, just as we all do, it's called being human.

---------

Overwhelmed by ego and the need for the method be be right, makes most view anything that challenges them as something that is "wrong" or "difficult".

Opposed to seeing the method as a way of facilitating a better outcome for all. How long are we going to have to endure this kind of thing being top down and prescribed?

Little wonder a lot of successful software houses now are small developer lead teams. Any why ? Because it's fluid, communication is done when necessary, and the subject experts are allowed to engage opposed to being manipulated. Let alone the lack of interruptions .......

Leadership it's about communication and facilitation,  process is just a way of managing that.

Resistance is a good thing, it means there is passion and thought, there is a reason and likely something that hasn't been considered. You investigate it, you don't try to bully or scare it away, as some would seem to advise.

I think a lot of this is tied into typical business people's lack of ability to listen, either to a team to hear what is actually going on, or more importantly themselves to detect the real root cause of the resistance ....... ego.


A good summary here :

http://www.businesspundit.com/interview-why-businesspeople-dont-listen/

-------------

Also note ............ I've not said agile is bad any where here, only the way it's commonly pushed. I actually believe that it's well places in some projects and can help, though it's just a tool.

It is suitable in some places, though you can do a lot of damage with the "right" process tool in the wrong place. And a lot more damage using the wrong tool in the wrong place, in the wrong way!

-------------

As always it's about people interacting and cooperation, and the core essence of that is self awareness for each member, and quality communication.


It's not rocket science, though for most it's not east and something we all have to work on. Process is nice, though people are more important.

@JeremyHutchings