When you look up the definition of “Agile”, you will find it to be something like “being able to move quickly and easily”. As someone who graduated in Human Movement Sciences, this is a topic that naturally interests me. But not just in the literal sense of moving the body. The level of successfully managing an IT project the agile way has caught my interest since I became familiar with it. And just like we go to a personal trainer or a physiotherapist for advice or help, we sometimes need some help in how to properly manage an Agile IT project.
Flexibility gives you freedom to move
When you ask people to describe what an agile project is, people will often use “being flexible” as one of the traits. And being flexible is indeed one of the great aspects of the Agile approach. We don’t know exactly what the future looks like, so staying flexible to be able to adjust to change is great.
But flexibility has a downside. When you look at the human body, flexibility gives you the freedom to move in countless different ways. Which is great up to a certain extent. When you are too flexible, you are what we call “Hypermobile”. This means you can move beyond the normal range of motion. This can be awesome to execute some extraordinary dance moves, but also comes with downsides such as instability. Instability can cause damage to the body. Damage will lead to pain and pain will have a negative effect on your ability to move freely. The same principle applies to your Agile project.
As previously stated, an Agile project is defined by a certain amount of flexibility. However, it is of great importance to make sure there is a clear general understanding of what the overall function and goal of the project is. Some features and wishes can change, but that doesn’t mean the whole idea behind the project or functionality is supposed to flip during the project lifecycle. To obtain this understanding, it is important to focus on the “Why?” of the features. The “Why?” tells you about the (business) value of the project and it is therefore very important to understand. The User Story refinement sessions are a great moment for discovering and challenging this “Why?”. When we define a user story, we do this according to the following template:
As a <user role> I want <specification of functionality>, because <explained why this is important and/or useful>.
Very often the “because”-section of a User Story is missing or the information in there is unclear. By challenging your Product Owner on the “because” of their Stories, you will ensure that you have a clear mutual understanding of the business case and the “Why?” of the project. This will minimize the risk of a Product Owner suddenly wanting to change direction halfway down the line and it will therefore significantly increase your chances of delivering a successful Agile project.
Never compromise on quality
When I look around in a gym, I often see people trying to lift as much weight as possible, causing them to compromise on technique and quality of the movement. Unfortunately, this strategy does not lead to better or quicker results and at some point, this kind of behaviour even causes injuries. The golden rule in this is to choose quality over quantity and actually the same goes for your Agile project.
When working on an Agile project we often struggle to say “No” when our Product Owner comes with new ideas that initially weren’t part of the scope. Because the Agile way of working is based on fixed Sprint lengths, increasing the amount of work will directly increase the load on your team. This means that suddenly there is less time for each individual requirement to be developed, reviewed, tested and accepted. This will result in the team compromising on the quality of the delivered work.
Even though it might seem like you are doing the customer a great pleasure by delivering everything they ask for, the quality of the delivered work will be far from perfect. On a smaller project the danger of this might seem small, but remember that every big project once started small. When this kind of behaviour continues, bugs and instability problems will start piling up, creating an exponentially growing hot mess. So instead of adding load when a Product Owner comes up with a new requirement, challenge your Product Owner about the priority of the required feature. If the feature really has a high priority, you can offer to exchange the new requirement(s) with existing requirements that cover an equal number of story points. This way the load won’t increase and you won’t have to compromise on quality.
Be a team of pro athletes
The science behind being a professional athlete is something that is vastly studied. Talent scouts get trained to see which kid has the right skillset and traits to become a professional athlete. Despite this effort in finding the right high potentials, a lot of kids don’t actually manage to pursue a career as a pro athlete. It turns out that it requires more than the right physique and talent. A big difference that is found between the kids that become professional athletes and the ones that don’t, is their mindset. Pro athletes are convinced they are in control of their achievements and results. Also in a team context. When their team wins, they praise themselves for their contribution to it. When the team loses, they feel responsible for it. In other words; They hold themselves accountable for the team result. This principle is also key for being a successful Agile team.
As an Agile team you carry a joint responsibility to achieve the estimated goals and to deliver a successful product. Often this joint responsibility is mistranslated into something like “no one is individually responsible for the result”. This misinterpretation and flaw in mindset start to be a real problem when there is stress in the team. In these situations, we see that team members start blaming each other for the situation and they will try to defend why they were not personally responsible for what happened. This is a very unsustainable way of working. It causes a lot of stress and has a negative impact on the cohesiveness of the team and on the chances of success.
To tackle this, you and the other team members have to get into that mindset of a pro athlete. Be accountable. Be convinced that your input has impact, that you contribute to the win. Carry the joint responsibility when something goes wrong. By setting up a workshop about the team’s joint responsibility and accountability before starting the Development Phase of the project, you can make sure your whole team gets into this right mindset. I can assure you that a team with the mindset of a pro athlete will lead you to Agile victory!