15 July, 2021
I was lucky to be able to adopt the Agile methodology very early on. After moving to the States, I got my first job in the industry and one of my managers wanted us to give it a try. They got us all a copy of the Agile manifesto. We started from there, straight from the book itself.
It was one of the best implementations that I had ever gotten a chance to use, even to this day. It was new, fresh, and made a big difference. It shortened long release cycles; suddenly, there was this quality of “ownership” when it came to the work that we were doing.
Later on, I felt that the concept of Agility had been watered down to some extent. It’s become a buzzword. Large companies would try to shoehorn the ideology into a very light sort of framework, which can sometimes be less than helpful. The engineers get bogged down in all of this bureaucracy, so many meetings, so much demoing, and so many unnecessary processes. You’re left with so little time to code under these conditions.
For me, there has always been this cognitive dissonance. The industry is always trying to move in a progressive direction, sometimes distorting itself in the process. I know that Agility is great. I know that it works, because I’ve seen it working.
In a general sense, a Scrum Master can be considered an engineer who acts as product manager. For me, it can sometimes feel as though the function may be an extra piece of the puzzle not necessarily required to succeed. Scrum master is an ordinary engineer who is a bit more extroverted, people-oriented, and organized.
Agile, in essence, is the story of the self-organizing team. A product vision is articulated and everybody works together to bring that vision to life. The Scrum Master is there to lead the discussion and to keep the team on track. Any challenges to be communicated to others are passed on to this person so that they may share context with the rest of the company. They ask the right questions and work a bit more closely with QA.
I’ve set up these processes from scratch several times before, following this methodology. I’ve seen the progress first-hand, the teams change a lot. That’s always rewarding. Sometimes, though, when I talk to developers from my network about Agile, there is some pushback. They’ve seen too many poor implementations of the methodology.
Risk mitigation and planning both have their place in the Agile methodology, but communication really is the goal. If everybody is on the same page, the sprint starts and the sprint ends. There is a backlog, and the work is done.
- Agile is the process, and this process is meant to optimize communication. It is instated so that people do not ever have to be over-communicating while working with one another.
- The methodology is a way of looking at your JIRA dashboard (or any ticket management system of your choice) and knowing what’s going on instantly, even if your work in particular is not at the forefront. That’s what this framework is meant to accomplish. You are more able to communicate down, across, and up.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Alishah Novin, Sr Program Manager at Microsoft, shares his experience creating a viral LinkedIn post that led to a specialized take on mentorship, micro-mentorship.
Sr Program Manager at Microsoft Corporation
Yang Wang, Engineering Manager at Bond, shares how diligently she transitioned from a large company to a series of startups, all balancing between the role of being a working mom.
Head of Product Engineering at Bond
Jason De Oliveira, CTO for more than 10 years, describes his methods of re-platforming an organization with nearly thirty years of existence using specific techniques and technologies.
Jason De Oliveira
CTO at Vialink
Jason De Oliveira, CTO for more than 10 years, shares his experience completing a reorganization, implementing agile, and collaborating with multiple teams.
Jason De Oliveira
CTO at Vialink
Saarthak Vats, VP of Engineering at noon, shares how he began setting realistic estimations, thinking about the complexity, number of unknowns, and scope of each project.
VP Engineering at noon