Practical Agile Tips

Amazon lists over 3,000 books related to Agile Software Development and there is no shortage of information on the internet about how best to implement Agile, but I think there are still small improvements and tips  I don’t see often mentioned that I think are useful.

Practical Agile Tips

Biggest impact on success of a team is the people on the team

No matter what software development process you follow, technology stack you choose, or incentive you offer, the single biggest determining factor for the success of your project is the people on the project.

This means hiring the right people and creating an environment that helps bring out the best in people is really important. Don’t undervalue the importance of hiring, but also be careful to not to hire only those good at interviewing. Sometimes the best developers are awkward interviewees. For an alternative, the guys at Triplebyte are actively experimenting with building a better hiring process and sharing their results.

Don’t interfere with successful self-organizing teams

Agile is a software development process, not a management technique. Don’t impose Agile on teams that are already performing well. The result will probably be reduced productivity, push back and unhappy team members. High-performing teams are probably already doing many things in an Agile manner. This is not to say such teams should sit still. Teams look to Agile for processes and practices and frequently retrospect on ways to adopt them.

Give Product Owners Feedback

Because Product Owners are often not present in team retrospectives, they get little chance for feedback on the quality of the stories they are bringing to the team. It can be difficult for a PO to find the balance between ensuring a story is ready for the team and not including so many requirements the story locks into a specific solution. Sometimes it is helpful to have a team lead or SME to briefly review stories a few days before the rest of the team to help the PO ensure they are ready for estimation or tasking.

Estimation

When providing story-point estimates, try not to spend too long or go too deep. The reason story-points are pseudo-Fibonacci is because they are known to be imprecise. Spending a lot of team time to determine if a story is a “5” or an “8” misses the point. If the team cannot decide on a estimate after a relatively short discussion, assign the higher estimate and move on. Backlog estimation meetings should not drag on and should not be something the team dreads.

Commit Comments

Merging code histories can be hard enough, but cryptic commit comments like “fixed bug” or “refactor work” can drive one crazy. Try to include a dense but descriptive sentence about the change. Include links to relevant tickets or work tracking systems (Jira, Rally, etc). See this if you are still trying to decide if the commit comment should end in a period.

Check Sprint Progress During Stand-Ups

It might seem obvious, but I think this one is often overlooked. Besides reporting status and moving tasks, make sure that during stand-ups, the team evaluates how well the current sprint is going. Review the current sprint burn down and look at the tasks that are still “TO DO” and have the team honestly assess how well the sprint is going, especially as the end of the sprint approaches. Here are more ideas on improving daily stand-ups.

Adapt and Adopt

I think the most important thing to remember is there is no single right way to follow Agile. Go back and read the original Agile Manifesto and adopt the practices that fit your organization and team, adapt them as needed, and leave the rest behind.