Ask any Titaner what exactly does a Scrum Master in Titansoft do. And the majority (more than 80%) would answer, “a Scrum Master is a facilitator.” Probe deeper, and you’d get “…of Scrum events!” (Never let it be said that Titaners miss the obvious) Well, as with many things in life such as the tragic case of a Hawaiian pizza with only one measly slice of pineapple, that answer is 100% correct and yet, it is not the full picture. Let me share with you a brief overview of what it is exactly that Scrum Masters do in Titansoft.
Facilitate Scrum events as required
Yes, Scrum Masters facilitate the events in a sprint. Their main responsibility is to be actively “idle” – once the ball has started rolling, to know when to take a step back and let the discussion continue organically. Not all events require the presence of a Scrum Master. Without a Scrum Master, Scrum team members (such as a product developer or product owner) can proceed to take the place of facilitator in sprint planning, product backlog refinement and sprint review.
Typing “Agile Development” into Google search brings up 123,000,000 results. Sift through the first 5 pages, spend 3.5 hours reading through webpages that all seem to be the exact same copy of each other with cosmetic edits, or worse, websites that say the exact opposite, and be nowhere nearer to understanding what an agile transformation is. Been there done that.
We have tried, and we have failed, and this is what we have learnt – to save you all that computer eye strain, mouse fatigue etc. 🙂
Speaking to Titaners across teams, we bring you the differences in work practices after our Agile transformation, broken down into the main areas of:
After a full month at Titansoft as interns, we have come to learn more about Titansoft’s Agile culture. So, what is Agile software development?
Agile is often compared to the traditional Waterfall methodology where a linear approach is taken with software development; each stage is generally finished before the next one can begin. On the contrary, Agile methodology emphasizes the rapid delivery of an application in complete functional components, with a high commitment level from the client throughout the project. With Agile, all tasks are “time-boxed” into phases called “sprints”.
In Titansoft, each sprint lasts a week within which a running list of deliverables planned at the start of the sprint is completed. Deliverables are prioritized according to their value as agreed by the stakeholder and product owner. If all planned tasks for the current sprint cannot be completed in time, work is reprioritized and the information is used for future sprint planning.
Unlike two years ago, when my HR colleague attended a Scrum Master course, the reactions from other participants wasn’t this great when I attended the Scrum Master course about two months ago. I guess simply because Agile practices are becoming more widespread and also, it was an internal training where we invited Daniel Teng (from Odd-E) to conduct this workshop.
Although Agile has been around for a pretty long time and has flipped the entire waterfall model on its head, it hasn’t really made headway in very traditional or highly regulated practices (such as HR, Financial services, Healthcare, etc).
While there are plenty of reasons why Agile adopters can fail, that doesn’t mean traditional services cannot become Agile. From what I have learned at the Scrum Master course, I am beginning to see a clearer picture of the ‘perfect world’ where Agile HR resides. As I am a HR practitioner, the perspective that I would like to share would (naturally) be limited to this context.
Let’s look at it from a Product angle
HR does many things for an organization, some administrative, others strategic. With the importance and ever-increasing popularity of HR business partners, we can actually consider the organization as our customers.
What if the HR service is a product? And it’s features (i.e. Recruitment, Payroll, etc) are there to resolve the needs of our customers? So for example, if it comes to the end of the month and payroll needs to be done, the entire teamwill do what it takes to accomplish it at the end of the sprint. If the customer requires a fix to an employee engagement problem, then the team will seek to understand the situation (again doing whatever it takes – research, interviews, etc) and come up with a MVP (minimum viable policy/procedure/process) to tackle it. From real users’ feedback, the team can then iterate and improve on it.
I always think being a Scrum Master is like being a legend , a Scrum Master helps the Team to understand Scrum and Agile, supports the Team to level-up technical practices, guides the Team to be self-organizing, removes impediments to the Team’s progress, etc. And to make the job even more complicated, Scrum Master does not have authority over the Team, the Team does not listen to Scrum Master (Unless Team choose to)!
Similar to the idea of continuous improvement in Agile Development, we believe that we constantly need to broaden our Agile knowledge. These 12 Agile blogs are the ones that I personally follow and read frequently (with no particular order). For me, the good point for reading other sources is that I can learn to be more adaptive – if I stumble in my current way of doing Agile, I can learn from other people’s experiences and try to adapt it into my own development.