Trust but Verify – Measuring Value with Agile
In my last article, I talked about how trust is the secret ingredient to high-performing Agile teams.
Dear Proud Dad,
Congratulations to your daughter—we need more women in our field! Here are a few things for her to think about:
Whether she’s graduating from a top-tier university or is self-taught, your daughter will need to demonstrate that she understands the basics. Recruiters may consider coursework, online code repositories like GitHub, and student or volunteer projects to get an initial sense of her skills.
She probably already knows it’s also a great idea to have some internships where she can pick up not only technical knowledge, but practical experience in how software development works in the workplace (not the same as at school, in most cases). As she advances in the interview process, she can expect online coding challenges or talking through a solution on a white board.
In addition to questions about her background, education and experience, recruiters may throw out problems to solve on the fly (a still-common practice, even if weird brainteasers like "How many golf balls can you fit into a school bus" may have fallen out of favor).
Partly they’re trying to get a sense for her mental agility under pressure. But they’re also assessing her communications skills. Even if you don’t have the “right answer,” can you defend your approach? Do you come quickly to the point? Can you tell a story?
Some of the most important skills for developers don’t involve code and aren’t taught in books (at least, not the ones I read as a student)!
Software development is about moving a product forward every day. That demands great teamwork: shared goals, good communication, empathy, being able to spot opportunities and taking initiative. These are all critical ingredients in what I call a Product Mindset – essential to building great software that people love to use.
It starts with feeling ownership over your team’s deliverables. That doesn’t mean you work on everything. It means you treat your teammates’ success or failure as your problem. If your team doesn’t succeed, you don’t succeed. New developers sometimes struggle with this. They worry about getting blamed for mistakes they didn’t make. But the point isn’t to spread blame—it’s to encourage everyone to contribute everything they can to the success of the team.
Your daughter should be ready to describe examples of successful collaboration and shared ownership. These might come from the workplace, volunteering, school, hackathons -- and yes, even sports.
Developers are sometimes quiet by nature (I am the exception to that rule). Quiet is fine, but in an Agile environment, your daughter will have to stand up and talk in front of a group. Standups generally happen every day -- often with clients in the group.
You have to speak concisely, with precision. (Long standups are bad standups.) You shouldn’t take more than a couple minutes to explain where you are with your story, where you’re going next and what, if anything, is blocking you.
Product-minded developers aren’t ashamed to admit they’ve run into an obstacle—or even that they don’t know what they’re doing. That’s part of product ownership. You can’t let pride get in the way of the team’s success.
Outside of standups, developers also have to find diplomatic ways to challenge assumptions.
At Nexient, we consider being an “Honest Challenger” to be a core value. It means you don’t just blindly follow orders, but demonstrate respect to your colleague, boss or client by sharing the best insights you have, including ones that might involve a different approach. (Of course you need to be tactful – and gracious if the final decision doesn’t go your way.)
One of my colleagues has a sneaky reputation for being able to recruit some of the best junior developers to his team. I noticed that he doesn’t typically pick the ones with the best grades or the quickest responses in our agile boot camps. So I asked him how he does it.
He told me he pays attention to the devs who maybe couldn’t get the right answer at first, but just keep tinkering and thinking about it and asking for feedback. “When I see someone who can’t get put problems down, and are constantly looking for a better solution, that’s when I pounce,” he told me.
This kind of relentless problem solving doesn’t just apply to code. Product-minded developers are always trying to make the team more efficient. They avoid unnecessary meetings and remove blockers. They can tell you what everyone else is doing. They volunteer suggestions about how to streamline processes and will often experiment with new tools in their own time.
What I really mean is, don’t JUST code. I look for T-shaped people, who might have depth in one or two areas, but are insatiably curious about other technologies, tools and competencies.
Encourage your daughter to poke into unfamiliar aspects of development: from marketing to digital accessibility, estimation and so on. Not only will it improve her understanding of the software business, it will get her into the habit of looking for opportunities to pitch in.
In particular, I encourage developers to get closer to the people who will actually use their software: interviewing them, watching as they use the software, and analyzing usage patterns and feedback mechanisms. This isn’t just a job for experience designers – everyone on a product team needs to develop this kind of empathy to create fast, beautiful software that is tuned to user needs.
And that is the best recipe for a very long and satisfying career as a developer.