Founders often ask me what they can do to improve the performance of their software development team. Many had struggled to find their way under a mountain of well-meaning Agile development advice. They had hour-long daily scrums, a Kanban board, retrospectives, and biweekly sprint planning meetings. Yet they still felt dissatisfied with the output of their development team.

Agile development facilitates efficient decision-making and delivers software faster, enabling rapid feedback. However, agile cannot fix every software development problem.

You can't fix every issue with meetings, artifacts, and processes. Agile tools work, but only with the proper foundation. Without that foundation, agile can magnify problems. If the pace of development isn't adequate, a daily standup will consume even more time and energy. If developers aren't updating their tickets, what makes you think a Kanban board would interest them?

Other arenas exist to solve software development problems at a more fundamental level.

Start with who, not what

At the most basic level, do you have the right people on the development team? Do they want to help your customers? Do they like the kind of work you give them? Do they even like writing software?

I frequently encounter software developers with minimal interest in software development. Most commonly, I see developers who wish they were managers. Remember: ambitious software engineers want to build software, not manage teams.

Motivation issues can also be more specific, like software developers who only want to work on their preferred development frameworks. Or maybe a developer doesn't like your code and wants to rewrite it.

Those people may not be a good fit for your organization. Your software developers need to be interested in doing the job you need them to do. You need software developers with career goals that align with your organizational needs. Trying to convince an aspiring actor to fix your software bugs is managing in hard mode. Why not make your life easier by hiring someone who likes the job and has ambitions of being a better software developer?

Train your developers to make good decisions

Once you have the right people, ask yourself: do your engineers know what you want them to do? I've met many CEOs and managers who believe that because a software developer is a senior engineer, they should know what you want.

But, of course, there's no such thing as "should." "Should" isn't a law of physics. The relevant law in physics most likely involves thermodynamics and increasing entropy, not some automatic organizing principle. So, to uncover wishful thinking in any business, search for "should." Yes, ideally, developers "should" know what you want. Did you tell them? If not, how could they understand your needs?

Software developers aren't mind readers. People usually don't have the social skills to figure out what their boss wants them to do. Folks with that kind of people skills often end up as leaders and founders themselves, so you're unlikely to hire them accidentally.

As a leader, your job is to train your employees. I'm not referring to teaching your software developers to write C, python, ruby, PHP, or whatever. I'm not referring to technical or academic training.

You must first instruct software developers on your vision for your company. For example, what problem are you trying to solve for your customers? How are you trying to make money? What are your short-term goals? What are your long-term goals?

Everybody who works for you should be able to answer these questions. However, I have news for leaders: you can't say your vision only once and expect anybody to remember it. If you have a strategy, you probably need to share more than you feel comfortable doing.

I suggest referring to your strategic vision in every meeting you have. Unfortunately, people focus on the most recent or emotionally charged things a leader says. If you explain your strategy in January, it will feel out of date twenty meetings later in March -- unless you have reinforced the strategic message as often as other topics. Urgent and vital events will inevitably need attention; your role as a leader is to put those events in the context of the big picture.

For example, if a critical customer requests a bug fix, you might reasonably make the call to prioritize the bug. But, simultaneously, you can remind your team of the bigger picture: "Remember, once we fix this bug, we need to return focus on the new marketing dashboard. It is critical to help our customers reduce the time they spend analyzing their data, and we think it will, on average, boost their sales by 10%."

In addition to your overall business strategy, you must teach your employees to make tactical decisions. For example, many leaders complain that they have to babysit their employees. This comment suggests that the employees have no idea what their boss wants or how their boss makes decisions. Why? Because their boss hasn't taught them.

Whenever someone asks you a question, explaining how you arrived at your answer will benefit you: It will help your employees better understand your business. Your need to explain will help you make a higher-quality decision -- you can't disguise a coin flip. Your developers will build a model of your thoughts and desires.

Your goal as a founder is that everybody on your team can mostly predict how you would answer a question. Initially, it might feel strange to teach folks to anticipate your choices. Most leaders resist the idea that they are predictable. But that's what you want; people won't trust your vision if you're erratic or impulsive. Don't you want to set the goal and delegate the big functional tasks? Shouldn't your employees make minor decisions on your behalf?

I think most founders hire developers to free up their time and work faster, not to act as a human reference library and arbitrator of taste.

But, of course, employees need to learn discretion as well. They need to know when you would want to make a decision personally. They need to know at what point you want to be informed.

There are many flexible ways to express these sorts of decision thresholds. For instance, you can use timeboxing, "if some unexpected activity takes more than two weeks, I want you to come to talk to me before you work on it." Likewise, you can use spending thresholds: "If something costs more than $1000, I'd like you to talk to me before you spend that money." And you can set the alarm on specific issues "If an issue might impact any of these three customers, I want you to tell me so I am informed."

Explaining what you want is the only way you're likely to receive it. Put another way, even the best employee can't read minds.

These are some of the three different areas you can look to try to improve the performance of a software team. First, you have the right people on your team. Next, are you training these people to do the job you want them to do? Do they know what you expect of them?

And then, finally the very top, there are the questions that agile addresses. What is the pace of the releases? What are we working on? How do we make priority decisions? Think of agile as the icing on the cake. Agile can help smooth out imperfections, but you can't credibly use it to fill in a missing slice of cake. You need a strong foundation for your team before you get much out of tweaking that project management and operational level.