Rational Agile

Problem

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.

Actions taken

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.

Lessons learned

• 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.