Introducing Agile and Story Points

Problem

I started working with an engineering team that had previous negative experiences with Agile and so were resistant to changing their process. However, their software was consistently not matching stakeholder expectations. It was buggy and late. I felt that the team could benefit from moving to an Agile approach.

Actions taken

I talked with the most resistant engineers to understand their previous experience and concerns. I also started to slowly introduce the Agile concepts that I felt would be most beneficial. For example, we started with daily 30 minute sit-downs (instead of 15 minute stand ups) to get the team in a regular cadence of communication and progress tracking.
I also introduced a backlog grooming meeting every other week where we went through the upcoming user stories and assigned story points. I had the product manager review the story and then all members of the development and QA team gave estimates via story points. To start, we did not use story points to track velocity, only for estimation of backlog grooming. If, between all members, we were off by more than two deviations, we discussed why someone felt that it was easier/harder. This allowed for requirements clarification between PMs, devs, and QA. Within a month we were able to release most of what had been developed, as it met stakeholder expectations and was bug free.

Lessons learned

• Some people have a negative association with Agile due to previous bad experiences. Start slow with the team and introduce the most valuable concepts first to slowly get buy-in.
• Story points are an effective way to ensure alignment between PM, Dev, and QA and can help bring up misunderstandings early on in the process. It is a valuable exercise to do even if you're not using it to track the velocity of the team. The more a dev team can feel that there is full accountability across PM, Dev, and QA, the more enthusiastic they will be to embrace new processes.