A client recently told me of some members of a development team saying how they couldn’t see the value of adopting Agile. It’s not uncommon to hear similar sentiments in many teams.
This got me thinking about how we often externalise the indefinable in order to; understand it, sell it, master it and sometimes resist it.
The common coaching attempt to reposition Scrum/Kanban as a ‘framework’ rather than a ‘process’ doesn’t come close to the visceral resistance (fear) we feel to something ‘other’, that is outside of us.
The real challenge is not one of semantic classification, but of human self-identification and engagement.
In essence this is about our ‘way-of-working’, something we are fully immersed in. Like being in water, we can’t push against it. This is what we do, hour-to-hour – it’s not external to us… it is us. And that’s the quasi-Zen bit**.
That Kanban board over there is merely a reflection of the way we currently work – it’s not ‘a process’. If it’s not an accurate representation – let’s improve it.
If it turns out that my way of working is less than perfect, and I find myself wasting time then what could I do to improve the situation. [Hopefully we move to replacing ‘I’ with a team ‘we’… but ‘I’ is where it begins.]
When it comes to Agile principles there is no external 'process' unless you choose to define one. Scrum, Kanban or XP are merely instantiations of those principles – they bring those principles to life.
We need to find a way for people to see beyond their own work and to the results of their collective efforts with others. After all, the ultimate purpose in our work is in delivering value to users – and that usually requires other people.
I’m keen on ‘optimising the whole’ and ‘Systems Thinking’, however that too is a form of externalisation and should be introduced carefully.
My current (June 2014) , evolving recipe for Agile adoption is:
And what I would say to a team is:
This probably comes across as a negative perspective – and yet, I think it evokes a particularly powerful emotion in us – because it’s based on actual feelings.
A more ‘positive’ perspective like, “deliver more value” arises from abstraction that doesn’t resonate as deeply or evoke emotion in me. As an individual I can’t influence (on my own) the behaviour of that system – and so, whilst I might recognise it as a laudable goal, it doesn’t impel me to action – at least in the early stages.
Whilst there is positive emotion associated with recognition of a job well done or in the sense of completion when one puts something in the ‘Done’ column, I think the ‘negative’ is more likely to stop us tolerating the status quo.
** I am in no ways a Zen practitioner, however I did find these ten Zen principles have some resonance with Agile principles: Awareness, Present Moment Focus, Non-judgment, Acceptance, Validation, Tolerance, Compassion, Invitation, Patience and Practice http://www.drnataliemasson.com/TenPrinciples.html
Apologies if by the end of this you saw it as a thinly veiled attempt to blog a catchy title (See Zen And the Art of Motorcycle Maintenance http://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance ) However, there is something illusive about this topic which requires a certain contemplative mind-set, which is another aspect to that I was trying to convey.
Email Bazil Arden
© Copyright 2020 RippleRock