Managing a Development Team is a juggling act where you don’t always know what you’re juggling, how many pieces, and how long you’ll need to keep them in the air. Sometimes you’re not even sure if you’ll have both hands available. Changing demands, limited budgets, hidden work, unplanned scope, countless meetings, all seem to collude against your team’s ability to deliver beneficial value.
Agile Best Practices help teams perform effectively when properly adopted, but adoption alone isn’t enough. Managed work cadence, scheduled standups, release cycle plans, and strict commit processes can backfire and create more stress than they relieve for development teams constantly having to adapt to changing needs while maturing their work procedures. So, which Agile methods work best to produce effective Agile Managed Development Teams? This article will look at six techniques that will improve the productivity of your team and reduce the delay of your deliveries: useful communication, asking the right questions, paying technical debt, creating a culture, driving a pull not push pipeline, and allow knowledge to lead.
But oftentimes the communication seems redundant or mechanical and serves little purpose to the developers or the organization. So, communication has to be centralized, searchable, effective, and insightful. We call this ChatOps. Does that mean eliminating the banter between team members? No! That’s part of the culture. But it does mean creating a channel, using tools like Slack, Microsoft Teams, or HipChat, where teams can collect the project specific communication, knowledge can be collected to benefit everyone, design ideas and engineering techniques are readily available, and pipeline processes are posted to maintain awareness of the work. The idea is to create a learning opportunity in everything you do as centralized channels fill with the lessons that other developers have learned, then questions and comments can become cross-referenced and indexed, making information easier to discover.
Teams around the world participate in various activities where each developer reports on progress and expresses obstacles through a daily standup. One issue is standups tend to be useless for high velocity development teams. Team members will often perform other tasks and listening for their name to be called, so they can quickly give a report and get back to their day. Rather than simply repeating what’s accessible by all members of the teams, managers will get more from the teams by asking the right questions, such as; what blockers do you currently have, what do you have that could become blocked, and do you have any hidden work that’s not on the board? These questions encourage all members to listen carefully to other teammates and allows better collaboration between teams as developers think through the potential blockers their project may have.
Technical debt, like consumer debt, accrues interest. Making minimum payments will satisfy debt collectors but will not decrease the level of debt for the consumer. The same is true for development teams. Any time a team states “it’s always been like that”, “it’s just something we put up with”, “one of these days we’ll fix that”, or “it always takes that long”, then they are accruing technical debt. If any process could be improved by N hours annually by investing < N hours in development, the difference between the two increases the debt the team or organization is accruing. The amount of interest of that debt can change drastically if the debt should suddenly come due because of a failure in the process. Teams pay down technical debt by investing a portion of their available bandwidth in making improvements, fixing processes, injecting failure, or solving known issues. As technical debt is paid, teams can communicate the lessons learned through ChatOps. This process then aids in creating and fostering the culture among the developers, increasing the level of velocity exponentially as the developers fix the problems while practicing problem solving skills.
Turnover is a product of burnout. As developers burn out, they move on to new challenges or opportunities that provide the potential for satisfaction. Burnout is the result of a lack of culture. Creating culture among developers drives collaboration, work/life harmony, creativity, and satisfaction. However, culture cannot be pushed onto developers. Culture must be developed from within. And there are ways in which management can cultivate culture. One way is to allow developers an opportunity for personal expression. Whether it’s a choice of tools, tech stacks, or work environments, the sense of expressions will gravitate toward clusters that form organically within the organization. Culture creates a sense of ownership within the team and within the organization. Developers will take pride in the work, in the success of the tools, and in the value of the group within the organization. Managers can encourage the creation of culture by empowering employees to self-organize, champion changes required within the organization, and by honoring the nature, rules, dynamics, and order of the culture the employees formed. The best thing managers can do is highlight the good the culture does which drives and pushes the acts of good performance, taking responsibility, cultivation of ideas, curation of action, and motivation to other members.
As managers, it’s natural to feel a need to create work from the top, and drive the work down the line, complete with drawings, details, timelines, budgets, and expectations. But in an Agile development team, a pull system, where management guides while team members lead their own efforts results in better delivery of value to the customer. Management must trust its people in the engagement of work, while making the vision visible and activities flow oriented rather than cost oriented. With a view of the value being delivered, the teams are tasked to deliver something towards goals every day. If the team cannot do every day, then every week until they can do every day. As the team self-organizes, those at the deployment end will drive other team members to deliver something they can push down the pipe. The previous team will put pressure on their previous team. In this way, the pipeline will develop an equalized pressure accounting for available capacity rather than constantly forcing teams to work beyond capacity.
This step empowers teams to accomplish the aforementioned techniques. The ones who are nearest the work understand more about the specifics of the project than those who are working with the customers to create the need. So why are they the last to know about the work being discussed? Why are they given the least amount of control over the plan, the environment, or design decisions? Part of modern agile is making people awesome. A major part of that is giving the power of the project to those who have the knowledge to perform the work.
Agile Management of development teams can be tricky. But it doesn’t have to be impossible. It requires a change in mindset, from being a Shift Manager on an assembly line to being a quality inspector of what comes of the line empowering talented people to let their creativity and genius shine. Our goal should always be to make the people we work with into the awesome team members they are capable of being.