Twenty years ago, an agile rebellion started among a small pocket of besieged software developers. Today, the benefits of agile methodologies have improved stock trading, federal bureaucracies, celebrity chef-led humanitarian efforts. Yet Agile has started to lose favor. This has prompted us to get back to basics and start a series focusing on the Principles of Agile.
The fourth Principle of the Agile Manifesto is one of the shortest:
Business people and developers must work together daily throughout the project.
It’s only 11 words, but it has had an outsized effect on my career and how I think projects should be managed.
Start With Why
When I interview applicants for software developer and designer positions, I always pay close attention to how they describe the systems they’ve worked on and which parts they emphasize.
For example, do they say it was a Rails system with Vue.js and Tailwind? Or do they say it was an internal contract management system for the compliance group?
Do they focus on the technical pieces or on the purpose of the system?
It’s perfectly reasonable for them to focus on the technology; many interviewers just care about what tech skills you bring. So I don’t judge anyone negatively for leading with that. But I do hope to get good answers if I ask about the business goals of the system, why it was built, or what effect it had on the teams using it. If they can’t demonstrate an understanding of the business or users, that is a red flag.
If you don’t understand the goals of the organization and users who will be using your system, how will you ever deliver something truly valuable?
Every day we make dozens of small implementation decisions that affect the systems we work on. You can’t possibly specify every detail ahead of time. Project plans are not blueprints, and we wouldn’t want them to be. We’re not typists. We don’t just translate specs into computer-readable syntax. We are creative professionals with deep experience using software to solve problems. Our systems are better when we can bring our full expertise to bear.
But the only way we can make good decisions that align with our business users is if we understand them and their workflows, beyond a surface level.
Working together daily is not the only way to do that, but it’s a reliable and foolproof way to build that bond, empathy, and shared vision.
We’re All People People
There’s an old joke in software:
“How can you tell an extroverted software engineer?”
“They look at *your* shoes when they talk to you.”
I mean, it’s a little funny and still somewhat true. I’m definitely an introvert, and large groups of new people can still feel a bit awkward. A lot of introverts are naturally drawn to fields where you have long periods of solitude, thinking through problems. But the days are long gone of software engineers being some antisocial geeks you lock away in the back office.
This is especially true in consulting, but it’s true across all product teams I’ve seen. The most effective engineers and designers are those who can communicate clearly and comfortably with all manner of business users.
The truth is that it doesn’t matter how profound your designs are or how genius your algorithms are if they don’t solve the problems that the business needs solved. Building software is expensive enough without having to rebuild it. Excess rework is one of the surest paths to project failure.
The best way to make sure you’re solving the right problems is by working together frequently with the business stakeholders, getting fast feedback and collaborating freely on small problems.
If you’re feeling anxiety about meeting with lots of business folks, I get it. Meetings can be stressful for a lot of introverts. The good news is that communication is absolutely a skill you can improve. Sure, it’s naturally easier for some personalities to lead a meeting, but anyone can learn some basic tactics to be effective in workplace meetings. It’s normal to be nervous doing new things; it will get easier with practice.
Support, Not Shield
I like to have little focusing phrases to help me remember what my goals are. When it comes to structuring client interactions, one idea I like is to support, not shield our team leads.
I fundamentally believe that team leads need to be interacting frequently and freely with business users. They should not be shielded by project managers or other nontechnical staff.
Shielding technical team members is a natural outcome. They often don’t want to be in so many meetings and often prefer to do work that feels more productive in the short-term. But getting them more time with business users tends to reduce the mistranslations and accelerate feedback loops. Skipping those meetings is often penny wise and pound foolish.
Of course it can be a delicate balance. For example, there are some meetings that large enterprises have purely for compliance reasons or change control. Does the team lead need to be in all of those? Eh, maybe someone else can go and report back. Or maybe there are important integration dependencies that only the team lead would realize will have a major impact on the project. And on the other end of the spectrum, there are times when we want the whole team interacting with various business users. We don’t want to shield the rest of the implementation team all of the time. They need to focus but they also can’t feel disconnected from the users.
Like most hard questions, the answer is that it depends – on context, on people involved, on goals, etc. Deciding how to invest the team lead’s time is never an obvious choice. It’s also not static; it changes as the needs of the project change. But as a rule, I try to focus on how we can support a team lead, to remove the toil of frequent collaboration, while still getting the inarguable benefits.
For example, having another team member facilitate the meeting and take notes can reduce much of the cognitive load for the team lead – and make it so the meeting is less stressful and draining overall.
Finish Strong
I waited tables off and on during college, and I’d notice how new servers would often neglect a table at the very end of the meal. They’d provide good service throughout the meal and then disappear at the end, leaving the diners annoyed right when they were deciding the tip. On the surface, it’s crazy. Why would you ever do that?
Well, if you’ve been a waiter, you know that it can be a stressful job, balancing so many priorities. Nobody was choosing to ignore the diner at the end of the meal. They just had other tables that were getting food, taking orders, needing refills, etc.
Software projects often feel similar to me. We have a lot of frequent collaboration in the beginning of a project, working through UX and designs, system architecture, integrations, etc. But then somewhere along the way, we fall into a habit of just doing regular demos, reviewing progress, and not really intentionally collaborating. We let our attention stray when we’re making some of the biggest decisions.
I’ve seen that pattern on lots of teams across different organizations. It’s not bad. It works okay, but as I reflect on this fourth principle, I’m looking at that last part and wondering if we can do better: Business people and developers must work together daily throughout the project.
I don’t know. We do try to have regular planning sessions where we can collaborate freely, and the truth is that there are times in projects where we just need to focus and get things done. There comes a point where discussing an idea any further is a waste of time. It’s better to build a simple version and get feedback quickly, iterate your way to greatness.
It still feels like there’s an opportunity for improvement here. I guess it depends on a few things. It always depends. 🙂
Software Requires a Team
There’s that old idea that if you want to go fast, go alone; if you want to go far, go together. For me, that’s the main takeaway with this principle. It was true 20 years ago; it’s even truer now. Most software requires a team of people to be successful. You need designers, developers, and the business users who are experts in their own field. Alone, none of those groups can build a great software system.
Get them together frequently, in a setting of mutual respect and appreciation, and you can build software that changes the world – or at least changes their world.
Day by day, you might go a little slower than if you just sped forward writing code, churning out designs as fast as possible. But frequent collaboration can produce better results with a bigger impact than you could ever make in isolation.
For me, that’s ultimately what building software is all about: helping those around me by solving problems with technology.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
