Why you should involve your developers right from the project's inception
From time to time I join a team, department or company that has not (yet) formed the sort of culture necessary for Agile software development to flourish. In situations like that I begin looking for opportunities to help my colleagues succeed. One thing I like to look at is how projects get started.
In some places, projects are conceived by a select group of people. In such a group you’ll often find product managers, designers and maybe a tech lead. With best intentions the group sets out to analyze the market, to design a solution and to make a plan. Once made, the plan is written down carefully, enriched with pixel-perfect design specifications and handed to a team of developers for implementation.
Although this description might have just brought back memories of unrealistic Gantt charts, project death marches and management by hope, an awful lot of software is still made in this way. Furthermore, I have to admit that I’ve rarely seen this way of working leading to catastrophic outcomes.
However, just because that way of working is not terrible, doesn’t mean that it’s good either. There’s a lot of room for improvement here. But don’t despair. While it might be hard to convince your colleagues to try out a new way of working, the benefits will be obvious to them quickly.
A whole-team approach
About two decades have passed since the Agile manifesto was signed. Based on its core value of “individuals and interactions over processes and tools” and the principle that “business people and developers must work together daily throughout the project”, many techniques for starting a project have been invented. Just to name a few there’s the Lean inception, Design sprints or the Inception deck.
They all boil down to one fundamental idea: when starting a project, involve your whole team. Instead of handing a fully specced out project to your developers, bring your developers in before you even know what the project is all about! Then work together to continuously ship something of value and refine it.
Over the years, I found that the whole-team approach leads to better project outcomes. Including your developers right from the start has five key benefits:
You build the foundation for tight collaboration: seeing how other people approach the project, listening to the words that they use to describe it and paying attention to their emotions about certain areas is a great way to establish trust and to arrive at a shared vocabulary. You’ll benefit from this early investment all the way through the project.
You find better solutions: bringing in diverse perspectives and skillsets allows you to learn about the project from different angles. As you learn more about the original problem, you can compare different solutions to each other and see which one fits your project better.
You discover dead ends earlier: every potential approach can immediately be checked for technical feasibility. With rough estimates (e.g. t-shirt sizes) you can compare different approaches. And best of all: your developers might be able to suggest a solution that takes less time but delivers the same amount of customer value.
You allow for better decision-making: developers need to make a lot of small decisions when writing a piece of software. If they had rich conversations with the other stakeholders, they will be able to make better decisions later on.
You foster higher engagement: when people are involved in a project’s inception, they often have a sense of ownership, pride and purpose. Nothing is more encouraging than working on that project you helped to shape!
Can your tech lead step in for the entire team?
I’ve talked to some people who suggested that a team’s technical leader or manager could serve as a proxy for the other developers. It’s possible, of course, but you’d miss out on all of the benefits listed above.
Why? Well, how much time does your manager spend writing code? How intimate are they with your systems and tools? How much time will they dedicate to pair programming with other developers on the team?
If you’ve answered with “very little” to any of the questions above, it’s probably not ideal. Get your team onboard instead and trust them to get the job done. They won’t disappoint you.
I’m sold! How do I start?
Just pick one of the existing project inception techniques (Lean inception, Design sprints, Inception deck) and read a little bit about it. You don’t need to be an expert, but it’s worth preparing well enough to be able to lead your team through the sessions.
Next, convince the rest of your team to try running a lean inception for your next project. Listen to their concerns. Seek first to understand. See if you can begin by trying it once. Depending on your company culture, this might take some time. Always remind yourself that you don’t need to be a manager to help your team being more successful.
After you’ve done your first project inception together, run a retrospective. What worked? What didn’t? What did you learn? What can you do better next time?
Now go and try to put what you’ve learned into action!