6 tips to be really Agile
And not being hated because of it

Web Developer with a background in Nursing
Games amateur developer
Born in Spain, living anywhere
When I found my Agile powers
Some years ago π΄π», I wrote an article in a company tech blog about how we used Agile Methodologies in our development team.
I must say I was a bit obsessed with SCRUM events and roles at the time π but since then I have worked in many different teams and companies. Some were using Kanban, some said they were using SCRUM and others just weren't using any method at all π€·πΏββοΈ.
So today I have a more clear picture in my head about what's really useful to integrate from Agile into a real-world development team process and what it's just "noise" π£.
If you havenβt worked with SCRUM before, I recommend that you read the SCRUM Guide π before continuing, itβs actually quite short and straightforward!
What hurts the development process
π‘ Introducing new ideas in a Grooming/Planning Meeting. Itβs better to let Developers (from now on, Devs) do some analysis before doing a meeting where estimations will be asked. The Product Manager π©πΌβπ» (PM from now on) needs to assess which new features prioritize for the next Sprint depending on the effort needed, so itβs relevant that Devs do a proper analysis beforehand.
π Using Dailies as simple reports for PM. PM should be able to tell the status of the current tasks by looking at the Board. Dailies should focus on mentioning blockers and asking for help from other members of the team π¬. Avoid giving that help in this meeting: thereβs nothing more unproductive and irritating for the rest of the Team than looking at a technical discussion between two Devs that they could have by themselves later on π₯±.
β Forcing the team to follow all SCRUM rituals. For example, Sprint Review is a quite complex meeting because it should include Stakeholders so you need to coordinate with different team schedules π. Sometimes it makes more sense if the PM meets those Stakeholders separately.
What helps the process
π©πΌβπ» Having a dedicated PM for the team that acts always as a filter between Stakeholders and the Development Team. Devs cannot be productive if they are constantly asked about bugs or new features by many different people. At the same time, is useful that the PM has a complete picture πΊ of the current project status, knowing about all bugs and features being proposed.
π Actually using Jira: Jira is present in all the companies I have worked for, but almost nobody usually uses it effectively. Doing SCRUM Sprints and having a Jira Board doesnβt pay off if your team doesnβt measure their stats π using the tools Jira provides. It's necessary to do retrospectives too if the team wants to improve its productivity.
π§ Using Trello or other similar tools that are simpler than Jira. if you don't really want to measure your team performance or implement SCRUM completely, maybe you donβt really need Jira π€·ββοΈ. Trello makes creating a simple Kanban board very easy and itβs more intuitive to use for new users and people with 0 agile experience.
What do you believe in?
Are you a full SCRUM follower? Or a Kanban lover? Let the world π know in the comments below!




