Skip to main content

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.


Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?