A mindset is a set of assumptions, methods, or notations held by groups of people that is so established that it creates a powerful incentive within these people to continue to adopt or accept prior behaviors, choices, or tools. Simply put, it is a way of thinking about things that those in a group share or have in common to the point that it becomes a way of life.

There are several characteristics I believe make up the agile mindset:

• Positive attitude
• Thirst for knowledge
• Goal of team success
• Pragmatism
• Willingness to fail

To me, an agile mindset is "There is no failure, only feedback." It's about taking everything as lessons, adjusting actions according to the feedback, and proceeding toward desired outcomes, resulting in continuous improvement.

The ideal is for everyone to have what the team decides is its collective agile mindset, but that all starts with the individual. I have worked with some great people who I think embody this mindset. They attack their work with a positive attitude, providing suggestions to overcome obstacles. They ask questions to understand what is in the best interests of the business, often coming up with innovative solutions as they experiment. They have realistic and practical attitudes focused on helping the team succeed.

When looking for people to be part of my agile teams, these are the mindsets I look for. It is difficult to change people’s intrinsic personalities and ways of thinking, so it is important to get the right selection of people for your team.

Positive Attitude

There are always challenges on projects; people are human and make mistakes, and everything is not always going to go well. What is most important is how the team members deal with these situations.

As issues are identified, they need to be dealt with in a timely manner with a positive attitude. In most cases something that may look negative can be turned into an opportunity for improvement. I expect my team to recognize problems—or, even better, potential risks—quantify them, and come up with suggestions for solutions.

For people new to agile, self-management is often difficult. This is where keeping a positive attitude is so important. Some of the things they try may not always work, but they should not give up. It is easy to become downhearted, but instead, team members should keep in mind that they have learned something.

Thirst for Knowledge

Agile is about learning and adapting. Your goal should be to gain as much information possible in order to deliver a quality product—you should not make assumptions that what you are doing is best for the client. With the fast pace of business requirements and new technologies seemingly appearing every day, industry professionals need to keep abreast of changes.

This is particularly true for agilists, who often are challenged to think outside the box to get tasks done within the tight timeframes of an iteration. Participation in meet-up groups and reading technical articles are good sources of new ideas.

A person with an inquisitive mind asks questions to help the team gain a common understanding of user stories. They are the people who adapt best to the use of experience-based techniques such as exploratory testing, where you start with a simple plan, execute tests, learn about the product, and then make informed decisions about what to explore next. They do not rely on lots of documents; if they do not understand something, they find the right person to give them the answer.

A good technique for gaining knowledge is the “five Ws”: asking who, what, when, where, and why. When you ask a question people may not give the real answer at first—they will give you the symptoms of the problem, and it can take a number of probing questions to understand the underlying issue.

Testing is now the responsibility of the whole agile team, so everyone needs to be eager to gain knowledge about the product in order to improve quality.

Goal of Team Success

Agile is about the success of the team, not individual success or heroic behavior. It is more important for the team to succeed than for the individual to have completed her tasks.

A good example of this is when team members are working on user stories of varying priorities and realize that they are not going to be able to complete a higher value story by the end of the iteration. Those who were working on lower value stories will swarm together and offer to help to complete the higher value story, even if they do not have the exact skills to complete the tasks left.

Being prepared to move outside of your comfort zone in order to help on a particular project for the overall good of the team is a valuable trait. Likewise, it it important for team members to be willing to train others in areas where they may not be confident. If there is a culture of finger-pointing, people are less likely to volunteer to work on an important task if they are not an expert in that area.

Taking the time to coach others or walk through the user story design with those who are less familiar with the coding in that function is a sign of a good team member. This shares knowledge and lessens key person dependencies, plus the whole team having a common understanding of what the story involves leads to more accurate estimates and planning for sustainable commitment.

Pragmatism

Quality is an important facet of agile. However, everyone may have a different view of what “quality” means. It is critical that the team understands what is important to the business and then deals with things sensibly and realistically in a way based on practical rather than theoretical considerations.

Instead of making excuses, team members need to provide options. Don’t say it can’t be done; explain what can be done.

You can’t force change on people. Instead, show them how the future might be and help them participate in creating it. The team needs to be willing to help each other to succeed on the higher priority items, even if it means you will not complete your individual task. Often, if team members see someone “walking the walk,” they understand that it would be beneficial for them to do the same.

When faced with an impossible problem, identify the real constraints. Ask yourself: Does it have to be done this way? Does it have to be done at all? Once you start breaking a problem down, it can seem easier to resolve.

If there is a defect, it doesn’t really matter whether it was your fault or someone else’s—it is still your problem, and it still needs to be fixed. While you are in that piece of the code it is often quicker to just fix it rather than document or discuss it. Be pragmatic about the greater good of the team and the product.

This is often where I think common sense comes into play (although it seems to not be that common). For example, do not spend hours compiling a status report when what your customer simply wants to know is whether the project is on track and a simple explanation if it isn’t. Find out what your customers really want instead of assuming and potentially wasting time, even if it has always been done that way in the past.

Willingness to Fail

Some people say that the best way to learn is to fail at something. I am not sure I agree with this totally. I want people in my team to have done as much research or questioning as possible beforehand and to ask for help from someone with more knowledge in that area to guide them so that they fail less.

Having said that, not everything is going to work well all the time. If it is a choice between having a go with the possibility of failure and not having a go at all, then I want them to feel comfortable to try. While I want my teams to challenge themselves without the fear of reprisal if they fail, there are some important lessons:

• Learn from this experience and, given a similar situation, do not make the same choice leading to failure
• Understand that it did not work in this situation but it may in others, so you have a new technique to add to your toolkit
• Feel empowered to talk about this failure so that others may learn from it
• Do not hide the failure; be open with your team

Innovation often comes from trying things that you may not have thought of carrying out during your normal tasks. For example, my team was using a mandated configuration for a tool that was just not working for them. They decided to change some of the workflow, trying different configurations, which eventually saved them considerable time entering data in a more logical flow. Don’t be afraid to question the norm if something is not working as well as it could.

Continuous Improvement

My take on the agile mindset is that it should include the quest to learn (even when you fail) and leveraging what you learn to continuously improve on what you do.

The agile mindset is an attitude that equates failure and problems with opportunities for learning and invaluable feedback. In other words, it’s a belief that we can all grow stronger over time if you put in effort to increase your knowledge and support the team, and the organizational culture gives you the space to do it. Though there are undoubtedly many definitions of an agile mindset, these are all characteristics that would be good for any agile team member to have.