Virtue Signaling and Agile! | Agile Story 14
Disclaimer: The below are all my personal opinion and does not in any way should be considered as an advice or suggestion. Every organization will have different needs depending on culture, preferences, size, etc.
What is virtue signaling?
The action or practice of publicly expressing opinions or sentiments intended to demonstrate one’s good character or the moral correctness of one’s position on a particular issue.
Has agile frameworks and method fallen prey to virtue signaling?
In recent times we see tons of posts/blogs from agile practitioners trying to make their own interpretations of various frameworks and prove their own understandings. While there are various framework/methods that have evolved in the last two decades, how does showing knowledge of these methods/frameworks prove that you are a true agile champion. Isn’t being agile is all about ensuring that you get maximum value through minimum waste through a growth mindset.
Let’s look at one of the popular Agile frameworks used — SCRUM.
The word SCRUM, as you might know, came from the game of Rugby where a Scrum is the huddle the team forms on the field during the game to call plays and make strategic decisions.
With that out of the way there are few aspects of Scrum which have been used by management as virtue signal of choice.
The Sprint:
As per scrum guide — Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
This gives a great weapon for management to track schedule. While it does provide great motivation for team to get a sense of achievement at the end of each sprint (remember you need to have fixed sprint length consistently) it is mostly to pacify the management who gets a sense of control over schedule and cost.
Now consider this problem. There might be a microservice which the team is building and in no way, it would be valuable unless built in full. The developer is asked to split and scope it in parts and complete in multiple sprints. The developer is incentivized to stop after every sprint and hence would lose time in the process. The developer might well have continued without any break and finished it much earlier. This may lead to Imposter syndrome to set in, but at least management will have pretty burndown charts.
Estimates:
Many super-hip organizations enjoy using the most confusing scales for estimates. They claim that this somehow makes estimating a faster and less stressful process. The Scrum guide is vague on the topic, so managers take matters into their own hands. Within Scrum, estimates have a primary purpose — to figure out how much work the team can accomplish in each sprint
One of the most dreaded form of estimation is “Story Point”. Following is the quote of the inventor of Story Point — Ron Jeffries, “ I like to say that I may have invented story points, and if I did, I’m sorry now. ……” More of his point of view can be found on this Blog.
As per the oxford definition estimate is: “roughly calculate or judge the value, number, quantity, or extent of”
So, estimates are just estimates. Isn’t trying to perfect an estimation technique a complete waste of time? If an estimate turns out to be bad it must be allowed to be re-estimated at no detriment to the estimator. The time saved in not trying to make best estimates can then be redirected in creating more value.
How can then we determine the how much work the team can accomplish in each sprint. Well, if sprint in itself is not a great idea, then we should have an alternative way to look at things!
So, what then are alternatives? Will see in Part 2 of this article!
TO BE CONTINUED ……….
#letscreate2succeed, #teamHCM, #manage2succeed, #ibmconsulting, #teamagile
This is the continuation of sharing our Agile Stories/Thoughts Series. I strongly recommend referring #teamagile for previous insightful blogs from our in IBM
Originally published at https://www.linkedin.com.
