It is perhaps the most obvious but also the most forgotten fact of humanity. We are not all created equal. Some, much to my frustration, can eat a lot but remain slender. Some hardly exercise and look really good. Some are tall, some are short, you get the idea. So why do we think that one diet or one exercise routine can change everyone’s health? In the same vein, why do we think that getting a Scrum certified person can make a project, or worse an organisation, “Agile”?
It boggles my mind how many Agile Technicians are out there yet so few Agile Practitioners. Let me explain. I believe if you’ve:
- gotten a Scrum Certification of some sort
- mastered Jira or similar systems and can configure stuff in your sleep
- mastered the Microsoft Outlook Calendar with rituals like stand ups and retros
- acquired a well-worn sledge hammer for breaking down blockers
… You’ve achieved the Agile Technician status. You are very proficient in “technical agile”. However, is this sufficient for an organisation in a world where businesses are starting to adopt a more “agile way of doing things” – whatever that means?
Here is where, I believe, the Agile community falls short. I believe that both the hirer (Businesses who want to “go agile”) and the Agile Practitioner needs to rethink the role and their expectations. You see, “going agile” for any project or business is very much 20% Agile technique and 80% culture change. Yes, I believe that a true Agile Practitioner must upskill in the areas of Culture Change, Leadership and Change Management. And the organisations who hire these practitioners must support and empower the practitioner to do the change. In fact, organisations must elevate their seniority within the organisation to have any real long-lasting impact. “Going Agile” is more than just sending your staff to a course, hiring Scrum Masters and replacing all your project subtitles to have the word Agile inserted in every other sentence. It’s a transformation, or at the very least a change management, exercise. It needs to be implemented as such.
It is a mistake to believe that people can change overnight just by attending a two-day course on something. Most of us operate through routines and habits. For any individual or organisation who has operated for years and years in a traditionally waterfall culture or mindset will be inherently risk adverse and documentation hungry. Moving to 2-week sprint cycles and expected to work towards a so-called Minimal Viable Product (MVP) is uncomfortable and unsettling. Of course, when something goes wrong they will blame “going agile”!
To the Agile Practitioner:
- Skill up on Change Management, leadership and organisational culture change topics
- Rethink your role. Challenge status-quo. Don’t say, “it’s not my job”. Try to move into a position of change agent, manager or champion.
- The opposite of point two is to hide in Jira and micro manage. Instead, aim to educate and empower the teams to self-manage so you can be free to do point one and two.
- Learn to manage conflict and manage upwards. It’s a tougher path than managing the Agile Team(s)
To the hirer or organisation thinking of “going agile”
- Remove the mindset that Agile can be implemented by one practitioner armed with training and a system like Jira.
- Budget for culture and change management.
- Pay your Agile Practitioner a manager’s pay. As they say, when you pay peanuts…
- Hire the “Charismatic-types” not the “Technicians” of Agile
- Trust and respect the Agile principles (whichever framework). They are there for a reason. Avoid the trap of wrapping the word Agile over a waterfall operation.
For more on this, have a look at this article. A few months back, I sat down with Craig Smith, one of the early founding practitioners of Agile to discuss this divide between Technical Agile and true business agility.
Happy to discuss this further if it makes sense to you. Or even if you disagree, happy to hear your thoughts on this. Drop me an email.
About the Author
Chief Operating Officer
As Procensol’s Chief Operating Officer Mervin brings more than a decade of experience in strategic thinking, software, systems and process-centric design for business transformation to the operations of the organisation. Mervin is responsible for Procensol’s Asia Pacific region. Originally from Singapore and now based in Brisbane Australia, Mervin has held positions ranging from strategic BPM consulting, channel management, CIO, CTO to vendor management.
Low code platforms are a fantastic tool for any business but the real ROI comes from quantifying the benefit from the very beginning. Take a look at the key metrics you should be monitoring during delivery and beyond:Read More