6 tips to be really Agile

6 tips to be really Agile

And not being hated because of it

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!

ย