What is the team's performance? Is it the amount of lines the code team produces per week? Is it the amount of hours put in design? Size of the documentation per feature? Often happens that we feel that the team is doing a good job, but the effect on a business is not what we have expected. In the end it does not matter how much work we do, it matters only the actual value that we bring. In this article we combine our experience and explore why on the surface the team does a great job but in the end the value is not what it has been expected. And we hope to help any size, agile or enterprise, environments to take steps in correcting this, to encourage teams to perform better and in the end start bringing the value they actually can.

Software development business or service is rarely about just delivering software itself. It should always solve a problem or need of the client and provide direct benefit to the business. But solutions and products become more complex as development continues. There comes a time when growth and progress gets stagnated. Teams do not provide the same value as before and hiring new people does not produce the same effect. And tech debt, design debt, test debt, product debt gets the blame. And rarely people are asking questions — why does it keep happening? Usually that comes because of the mistakes that were done at early stages. And that is happening because teams when designing solutions or choosing a path did not think of one of the directions and missed an important aspect. We will call these directions — “Mindsets”. Let’s talk a bit about situations in which lack of just one of the mindsets will lead to loss in performance for the teams. If you already know your problem and just here to find the solution, then you can skip this part and go right to the mindset explanation below. If you would like to explore possible situations and maybe even find the one that applies to you, then continue reading.

A quick example - products actually have a lot of tech debt, the code base is so massive that it is almost impossible to fix one thing without breaking another. And usually people are blaming mistakes in architecture or other decisions that in reality could not have been avoided at the time because business had no experience in these areas yet. What people are not blaming usually though are features and product decisions that were not needed. These small bits of excessive functionality consist of code that is not needed. They add complexity that should not be there in the first place. This code needed to be tested, deployed, connected and supported throughout adding more and more costs just to maintain it in working state. All because teams, project managers and product owners never actually asked the right question - do we really need this piece of functionality? Should we really make this decision now?

Often happens that the backlog of the product is not revised on time and teams are taking pieces out of it without concern that they are outdated to the point that there is no sense in doing them anymore.

Another problem that can become very visible when the company tries to transition into agile. They do all of the right things, they hire agile coaches and trainers, they follow the frameworks, but teams effectiveness does not skyrocket. Again, usually (because) agile transitioning should have given teams the accountability and responsibility but as ex project manager has been put as product owner and he used his authority to constantly push his way onto the team, and in return team has lost their confidence. "Why ask questions if it will not matter anyway? It is easier just to do as you are told". After that it does not matter if you have sprints or standups. Teams will not ask the right questions like - "can we make this better"?

Or in case of a cultural problem, for example a heavy development oriented company. Most of the employees are developers and all employees that do not do coding directly are considered (openly or behind the curtain) as second class. Let’s say a tester that is pushed around and though he can do an amazing job he is pushed around and tasked with only simple manual testing tasks that are still not automated. His opinion and voice is disregarded all the time. He does not have the will to tell his team that “solution will not work, because...”. And solutions with complex technical bases are developed and deployed as a result and they are turning up to be not stable or fragile to any outside interference. And that starts to eat more resources of developers. So everyone is busy fixing something and growth is stagnated. Person with critical thinking was silenced.

These examples are especially confusing if your company tries really hard on the culture front, and hires top talent. And this top talent does not produce the effect that business expects of them.

In enterprises it leads to rotation of the masses, constant hiring and firing, that leads to huge losses. In smaller agile companies it leads to internal conflicts and blaming teams or individual employees in troubles they allegedly caused. Problems can happen in any kind of business, software, service, consulting, production, research, marketing.

This happens because of lack of one of the mindsets in the teams or domination of one team sets above every other.

But that is enough on negativity (or reality for many). Let's talk about how to actually fix these situations or avoid them completely.

Short story time.

“It was just another Agile conference, nothing special. I was browsing the workshops section and stumbled on the workshop regarding Testing mindset with title: Can developers test their own work? I thought it might be interesting and I signed up. During the workshop we explored the idea that if a developer can change his mindset from creation and question “How do I make it happen?” to destruction with the question “How can I break it down?” then he will be able to properly test his own work, product, code. And the only problem is that it is hard to learn how to actually do it.

And it got me thinking. You need different mindsets for different phases of product development. Can one person for example create a perfect product by changing their mindset? How many types of mindsets are there? Which of the mindsets are needed to create a successful product. If a person has a prefered mindset, how can he learn to switch it? Can the team balance the mindsets? If it is hard to switch mindsets, then how do you balance it out in the team?”

That is how the mindset idea was born. In its core, in every team we need a mindset responsible for making sure that

• the product/feature/software/service is needed and valuable
• solution is perfectly designed based on resources and constraints
• team knows exactly how to make and deliver product/feature/software
• everything that team is delivering will work as intended and serve its purpose

In this article we are not aiming to psychoanalyse mindsets but rather focus on practical usage of knowledge based on observation of human behavior at the workplace.

Mindset is a tendency of people to concentrate on certain parts of the problem. When finding the solution people tend to lean towards certain questions, some begin to think on the solution straight away, some begin to criticize the whole idea, some start fantasising on feature prospects. And the main thought of this article - all of that is good. If you balance these behaviors within the team, this team will be able to solve any problem that you put before it.

Another thing about mindsets - people are usually not trained or not used to change it. You can train yourself to change mindsets and look at the problem from different angles, but people usually do not think about it. They are who they are and they are doing what they think is working best. Often, when trying to solve the problem - people tend to lean to behavior that worked best for them in the past. So in most cases it is better to have people with different mindsets in the team and balance missing mindsets with techniques and processes.

So, let us meet our heroes, what drives them, what makes them best in what they do? And how do these heroes balance each other when they are in the team?

And this is directly linked to 4 major questions any team should ask and find answers for when working on software solutions.

Ranger is one of the most important members of the party. He is responsible for getting his team to the right destination. His driving question is: Are we going in the right direction? This mindset is all about the target. Usually crucial for analytics and product owners it is very important to have this mindset present in the team. Questions that drive the mindset are:

• Is the feature/product worth doing at all?
• What needs of the client are we solving with this product/service?
• Who will be using it?
• What is the real value behind?
• What is the value for the client/user?
  • Why will clients use the product?
  • What people will stop using/doing in result?
  • What will happen if this product/feature/service will not be made?
• What is the value for business?

Getting answers to these questions can save business a lot of money. It is often teams are doing great work of developing features only after finding out that features were not needed. And every piece of code written without value leads to losses. Code deployed without value will still need to be fixed, supported, updated, maintained or removed after. It can create dependencies that will make it much harder to develop valuable features in the future. So asking these important questions is crucial. Absence of this mindset in the team often leads to compliance - team doing whatever it is told, never questioning if it is right for the business. Lack of “Ranger” or “Business analytic” mindset can be clearly seen in many teams in Enterprise level companies. Strict hierarchies often make this mindset very hard to act. But smaller companies that recently tried to go agile are suffering from absence of this mindset as well.

Wizard brings value to any party. He is responsible for finding shortcuts or unconventional ways to solve party problems. His driving question is: How do I make it better? This mindset is all about perfection and needs to be balanced. It brings a lot of value if used properly and as with any mindsets, when dominating in the group he can be very destructive. While usually present within Designer professions it is not uncommon in Developers. Questions that drive the mindset are:

• Is this the best solution?
• Are there any better ways to achieve the same goals?
• Will clients be satisfied with it?
• Which parts of the solution are not good enough?
• What team can do even better?

Lack of “Wizard” mindset is usually resulting in finding better solutions too late. They become obvious only after most of the work is already done and it is too late to make a step back. In enterprises this is often one of the most undervalued mindsets. That leads to solutions that are made by the book. That usually leads to stagnation. In agile environments lack of a designer's (Wizard) mindset can be seen if the team has their retrospective log and does retrospectives regularly, but it still leads to no improvements. Because there is no one to lead the initiatives and find a better way of doing things.

On the other hand when a designer's mindset is dominating - it usually leads to very low performance with high fuzz about initiatives and new ways of doing things.

Now the Knight is the core of any team. He is responsible for actually doing the job, be that actually slaying the dragon, breaking an obstacle, shielding his team mates or saving a princess. His driving question always is: How do we get a job done? While usually you expect developers to have this mindset, in our experience we’ve met teams with a lack of this mindset. The main questions for the mindset are:

• How do I do it?
• What is needed to reach the goal?
• What to do first? What to do after that?
• What is needed from the team?

Lack of ‘developers’ mindset usually means that the designer or tester's mindset is dominating and often leads to managers taking on the lead role of thinking on how to actually do stuff. In enterprises that results in creating very passive teams that can talk about the problem but never propose a solution, always relying on people on top to tell exactly how to do the task. This leads to great inefficiencies. In agile environments it is a rarity.

When dominating the scene, Knight mindset bullies every other mindset out. Usually present in company cultures where the programmer profession is the only one that is really valued. But can also be present when a team is built around one programmer who nobody dares to criticize. Usually effective at first it quickly creates stagnation and underperformance hiding behind authority or predgedus of other professions and in result mindsets. In result - teams are constantly doing something, but the effect on business and evolution is minimal. Knight always requires the support of other mindsets to pick the right direction.

Knights mindset is actually very common in project management roles. Especially in enterprise environments, where trust for teams is not very high, project managers with Knights mindset are valued. Which usually creates a problem, because transition to agile is basically impossible without trusting the team. And Knight’s mindset project manager will usually have troubles letting the team to decide on a solution for themselves.

Any party without a rogue will quickly fall into a trap. He is the character that is always cautious and complains about dangers of the dungeon that party is exploring. He is also usually the only one not falling into a trap and saving the team after they are captured. His driving question is: Why will it not work? While usually considered as a mandatory for “quality assurance” or tester professions. Another name for this mindset is - critical thinking. The main questions for this mindset are:

• Why might it not work?
• What are the dangers of the chosen solution?
• What are the dependencies?
• What may go wrong?
• Why should we find another way to do it?

Invaluable for tester, and common for developers or analytics or product owners this mindset is used from the start of any service or software development. Allowing to test solutions from the first idea and translate into a regression test at the end. This mindset allows people to find things that might stop the delivery and develop a plan to overcome obstacles and mitigate the risks.

And even though this mindset is invaluable - lack of it is a very often case. In enterprise level companies this usually leads to constant fight with problems and consequences. Big structural problems can be hidden in a big enterprise body pretty easily resulting in whole departments being hindered and dissolved in the end. In agile environments - lack of this mindset is critical and it is one thing that might stop agile transformation completely. Without a culture of “valuing objections” critical thinking (rogue mindset) is usually considered as a negative thing that puts everybody down. And instead of looking closer to the cause of the objection and finding a way to mitigate it, people consider it discouraging and negative thinking, and in turn try to ignore it.

And in cases when a rogue (tester, critical) mindset is dominating the scene it usually leads the team to find a thousand ways of not to make something instead of finding the one that will do the trick.

But let us stop here. If you got this far - I am very proud of you. It was a lot of text and you have read it all.

We had looked at mindsets and the problems around them. In the Part 2 of this article we will look closer at ways to preserve the balance of the mindsets of the teams and turn their downside into advantage.

Thank you for your attention and may the force be with you all.