Theories that Form an Agile Mindset

When people talk about Agile Software Development people will often cite how important having an Agile Mindset is to the success of any Agile project or team. But I’ve never heard a great definition of what an Agile Mindset is. It’s always a mix of personality traits and problem solving goals that no one can seem to precisely describe.

Part of it is clearly an Growth Mindset and that has been well defined and analysed. But it’s more than just that so I’ve been thinking about what that more actually is.

So I propose that an Agile Mindset describes someone that has the Growth Mindset and also operates with the following theories. These theories drive how a person tries to solve problems and helps separate their thinking from a lot of non-Agile approaches. But these theories alone do not describe what Agile is.

1. We do not know what the ideal solution to the customer problem is.

We hold this true at all times. Making informed guesses as to what we think will help then gathering feedback to see if we are correct. Feedback might be with metrics from the live software system or just a conversation at a demo. It keeps the software development process as one of exploration and discovery rather than a fixed end goal. It makes us value all communication we have with a customer. Even communication that may not be obvious like a customer not engaging and using an new feature.

2. Conversations are key to delivery.

We need to keep having conversations, ideally face-to-face, to deliver the right solutions. While we may write down a Story card the card is just a placeholder for the conversation. We like building BDD style tests but the conversation in creating those tests is the most important part. We want to keep collaborating every day.

3. Teams need sustainability to be productive.

Rushing will only make us slower in the long term. Having someone work late into the night is not actually helpful. We want people alert, relaxed and able to use their minds effectively. I’ve seen what happens when people are asked to work late into the night. They call in sick the next day. We might have estimates or plans that tell us when a feature may complete. But we also measure the reality and adjust our plans rather than our teams.

4. A productive team is a happy team.

I’d love it if modern workplaces measured happiness as part of the working day. Trends down in happiness are a good indicator of many possible problems that could be happening in a team and gives a business a chance to help before there’s a measured drop in productivity. But positive trends in happiness drive innovation and productivity too. This is knowledge work and we need our brains working at peak performance more than hands on keyboards.

5. Frequent small releases is will reward more than large releases.

With an Agile Mindset we push back against the desire of a perfect release. Yes a customer may have asked for lots of features but we will give them working software as soon as it has one of those features. Maybe they will not use it as they need something else with it. But that’s great feedback so we know what to prioritise next. Or maybe they’ll use it and immediately be getting value. The goal is not to get the highest value in one big hit. The goal is to get value early because point 1 applies and we don’t know what that is yet.

6. Software is NEVER Done

The world has moved on from software in boxes on the shelves of stores. But even if you’ve got a product that you cannot update after it ships your code should never be done. You will have parts you will reuse for the next solution. Or a chance to revise and improve it as you get feedback from the early releases. Code should be alive and constantly changing. Dead code should be deleted as useless.

Leave a Reply