Context and agile practices

At times we have competing responsibilities - ship code or don’t ship it because of a small edge case bug; put pressure on our team or make the business happy; coach our friends or write code.

This is a normal part of our everyday professional lives, and it’s important to strike a balance that will help us in the future, but also deliver in the short-term.

One of the hardest things to balance is when to modify our delivery practices to satisfy certain team members, when we know the changes have been harmful in past projects. Here, it’s important to understand the context of these changes and to have empathy for the individual pushing them.

Often when people want a drastic change in delivery it’s to help them in their own jobs, it’s also important for us to truly understand the change that is desired. Asking questions like why has it failed in the past? and what’s different about past teams? may help you actually recognise that things won’t go as sour as you think.

For example: You’re in a small team (<=3) and a team member feels strongly about wanting to size using an n+1 sequence but this method didn’t work in a larger team. You’ve discussed, argued but they wont budge. In this scenario, it’s probably worth actually making the change. Why? Because of context. Team sizes change, software requirements change from one project to another and interactions between team members change. You can still recognise that specific practices may not scale, or may not work in most situations, but if they work in your current situation, people are happy with it and saves time from arguing and allows you to actually start delivering software. Then it’s probably worth the change.