Latest Venn News
Jan 12, 2022
| Membership (fee-based) getty If you want to guarantee that your agile software development process will fail, then you should definitely manage your dev teams with a heavy-handed, top-down, hierarchical approach. Whether you prefer XP, Kanban or Scrum, you should create a command-and-control structure that is highly directive and forces all decisions through a narrow bottleneck at the top, preferably someone far removed from any direct understanding of the problem being solved or the thinking behind the engineers’ chosen approach. With rigid authoritarianism, you too could undermine the ability of high-performing small teams, as I recently wrote , to “finish projects faster, more efficiently and with a higher-quality result.” This is true for all software development work, though the impact is sometimes overlooked at small dev shops working on small projects. But as you scale up to larger projects with multiple small teams , top-down management is incredibly effective at producing garbage code in twice the time and cost while crushing any threat of a generative culture under the weight of overbearing bureaucracy. Or, you know, you could also try leading your agile teams in a manner consistent with agile methodology. Because hierarchies are for waterfalls, where everything goes downhill. In agile development, small dev teams thrive in Venn diagrams. MORE FOR YOU Areas Of Overlap And Autonomy The interesting thing about Venn diagrams is that there’s meaning not only in where the sets overlap but also in where they don’t. Imagine a Venn diagram with dev teams, product owners and other stakeholders collaborating on a large and somewhat complex software development project. Each group gets a circle. In the overlaps, people in conversation coordinate their efforts toward the desired end result. It’s collaborative communication, not directive. This is a diagram, in other words, of a social network. Social networks can facilitate effective collaboration, or they can waste time with needless distractions. The key to an effective agile software engineering culture is in the blueprint of its social network, which must provide those opportunities for communication that support quality engineering and omit those that don’t. Product and engineering come together to verify that they’re attacking the right problems with a solution that will actually serve the stakeholders. In larger engineering projects, multiple small engineering teams collaborate on a solution. These conversations in the overlaps are at the highest levels and should be structured as facilitations toward consensus, not presentations of punch lists that reduce engineers to fulfillment machines. Outside the overlaps, communication and control only slow people down and usually lower the quality of the work they produce. Where there is no overlap, autonomy should rule the day, so stop micromanaging and get out of the way. What We Create In Conversations Waterfall originated in manufacturing, where downstream changes were usually too expensive to implement. So you fully specified the design of your wonder widget before you started to build, then turned it over to the production team to manufacture exactly to plan. But in software development, we can easily iterate, making a product even better as we go. This is true in any agile methodology. I’m a Kanban leader myself, and it’s a key tenet of Kanban that you don’t know what your product will look like when you begin. Committing to any agile methodology means giving up a lot of control. Trusting the process. Trusting the people. You take a lump of Play-Doh and shape it into the sculpture as you go. The good stuff happens in lateral collaboration, where different perspectives, priorities and areas of expertise come together in conversation. The solutions that emerge from this process are better than anything a hierarchical leader could specify and dictate from above. A Little Leadership Goes A Long Way That’s not to say that leaders don’t have a role. We’re part of the conversation, too. Writing code can’t be completely democratic. Software engineers are so full of opinions that, without able leadership, they would argue forever over whether water is wet. Leaders do have to make decisions and drive change. But effective leaders also know where and when they’re needed (areas of overlap) and where they are not (areas of autonomy). Trust your teams to solve the problems you give them; or, if you can’t, figure out what you did wrong in assembling them. You don’t have to know everything that’s going on in order to lead. Don’t let insecurity about yourself or your teams push you to add unnecessary lines of communication and control. This becomes even more important as IT departments or software development companies grow and scale. My company nearly doubled in size over the past year, to about 50 software engineers. As we grew, I found myself becoming the thing I dread the most: a bottleneck. Too many decisions were flowing through me ... slowly. I wasn’t even the best person to make some of these decisions, but old habits from my company’s more compact days kept the momentum moving through me. My answer? Redraw the Venn diagram. Remove myself from all the areas of overlap where I wasn’t actually needed and trust my people instead. I elevated several of my top engineers — those with the best people skills and other leadership qualities — and made them engineering managers, each of them overseeing the work of several small development teams. With clearly delineated roles, able engineering leadership and a culture of mutual trust, I broke the bottleneck, empowering my engineers to do their best work. Yes, I’m still in charge of my company, and ultimately, I set the standards and direction. But I exercise that authority predominantly through the culture I nurture, the people I hire and the teams I assemble. Then I trust my engineering teams to figure out the best solutions, in conversations that rarely include me, conversations I’m often not even aware of. They earn that trust every day. When you have skilled software engineers working together in well-formed teams, you don’t need a heavy-handed hierarchy. Let the necessary conversations happen. Stay out of the areas of autonomy. And watch your small teams thrive.