Businesses need software. Lots of businesses need bespoke software that encodes their instutional knowledge and home-grown best practices. Even when they grab off the shelf packages, they’ll often need to heavily customize them.

This is the “below the waterline” segment of software development’s iceberg. It’s the part most users never see. These are “applications” or “tools”, never “apps”. They don’t “gamify” anything, and they’re not going to ask users for reviews. These are the ugly industrial machines of software development. They make sure products ship, accounts are paid, and they know where that 55 gallon drum of benzene is.

I work for a company that makes paint. My users care about making paint. They don’t make software, and don’t want to make software. When they need software, this is a problem.

Too often, our business users view development teams as a black box. They put requirements in, and they expect working software to come out the other side. Our users can’t spend too much time building those requirements- they have to keep making paint, after all. They also can’t spend too much time talking to developers- again, they have to keep making paint.

Of course, without the users involved, the end product isn’t going to meet their needs. More to the point: it’s going to be crap. Developers are unhappy, because they know they’re working on bad software. Users are unhappy, because they got crappy software that doesn’t do what they wanted (even if it does what they asked). Management is unhappy, because they blew a big pile of time and money on something nobody wants.

We need to train our users to participate in the software development process. We need to build good habits, that drive them to participate in the process. How are habits built?

Habits have three key components:

• Stimulus
• Behavior
• Reward

When I see this, then I do that, to get a reward. All habits, good and bad, have these elements. When I get stressed, then I have a cigarette, to get a moment out of the office and a little nicotine high. When I feel down, then I work out, to get some energy and an endorphin rush.

The other big key here is timeliness. If six months pass between the behavior and the reward, the brain isn’t going to connect the two. We need instant gratification, or as close to instant as we can get.

This is where Agile can really provide us with a big win. By focusing on short development cycles, we can use them to train our users. We commit to delivering software at the end of every sprint- every sprint. The user gets a piece of software, reflecting their input, and they get it quickly.

When the developers need input, then I give it to them, to get a small subset of working software at the end of the sprint. The user sees their input reflected in the finished product. On Maslow’s hierarchy of needs, that’s fulfilling both their esteem (the developers listened to them), and their self-actualization (they see the results of their efforts). For most people, that’s going to feel pretty good.

Using sprints and frequent releases, we can train our users to be more involved, more engaged, and more committed to the software development process. We don’t need to educate them, we don’t need to institute policies or make decrees about how users should behave. This doesn’t need to be a top-down approach. By showing our users the immediate benefit of their effort, we can train our users to put more effort into software development.

The end result is better software, which is what developers want to make. Beyond that, it changes the corporate culture of treating IT as a cost center which loses money. By training users to engage with IT, we increase the value proposition. Custom software ceases to be a necessary evil, and instead becomes an opportunity to improve business.