call me a nerd. or don’t. guess i am just awkwardly in the middle. so, i dont claim to be an expert in either life or scrum hahaha.
well, for those of you who are not familiar, an agile cycle is a software development life cycle methodology, ideally based on collaborative decision-making between requirements and solutions teams, whereby a working software iteratively developed, typically every week/ other week. and scrum is basically a type of agile cycle. specifically, the scrum methodology is made up of ceremonies (with my very simplistic understanding on purpose of each one):
- sprint review. to clarify the scope and effort of work (in jira terms, tasks, stories, bugs).
- sprint planning. to raise all concerns and allocate resources as realistically as possible.
- sprint execution. the actual work!
- daily stand-ups. to raise any blockers that others could possibly help eradicate.
- backlogging. usually mid-sprint, to rearrange commitment in accordance with current assessment of under/ overcommitment.
- retrospective. to reflect on how the team could have done better/ should continue doing, and become more effective!
it is believed that by practicing all these ceremonies (of course with some tailoring to the needs of your team), would you be able to cyclically deliver a software that is gonna only get better with every iteration.
i have only in part of/ had the chance to work with, not for super long but enough to make observations, 4 product teams so far. my observations:
- everyone’s super brilliant in their domain, IQ prolly + 100000000 of mine (fine, i exaggerate – maybe just * 1000).
- this means everyone understands concepts (duh, cuz they be smart), and the theories (specifically w.r.t. the benefits of each ceremony) very well.
- when operating at max, could have super high productivity.
- some teams would have dysfunctions/ not be as efficient as it could be is usually because:
- teams which are not willing to slow down to properly execute specific ceremonies because the “short term gains” are low. e.g. clarifying scope and effort of specific tasks. eventually, they would feel the effects – remember the “karmic patterns”? how about tech debt?
- people not voicing potential issues due to various ego/ need-to-upkeep-image issues – remember “satya”? how about that premature code refactoring required?
- teams not cutting out sufficient amounts of time for reflection and consciously acting upon the possible follow-up, whether for past/ current task/ project, for various reasons – not wanting to recognize there is an issue/ not accepting of criticism/ not wanting to dedicate the time for reflection – remember the sound of pagerduty right after a release?
the asana sutra says stability -> effort/effortlessness -> duality;
the “product nirvana”: product team function stability (finding out which ceremonies/ artifacts work for you) -> put in effort to practise them until they become habits -> have no fear that app is always gonna be more stable and better than the previous one.
as a yogi, i am taught to practice what i learn on the mat AND off the mat – break the bad habits, form the good ones, and make incremental growth.
as an employee, people may tell me work is not life, hence we shouldnt take it (team dysfunctions/ product failures) so seriously ^.
NEWS FLASH: work is not life, but work is part of your life. however you choose to execute it, you are forming a habit that you are going to bring somewhere else. and whoever you are working with is gonna contribute to that effort you are in forming that good/ bad habit. there is not a switch whereby you can simply toggle on and off, like oh let me build a habit of procrastination here at work!, ok now i am going for lunch, let me switch it off.
one day, everything will catch up.