Over the past six decades, software development has evolved from what was thought to be an engineering discipline complete with rigorous methods and processes to much more of a crowd-sourced social engagement involving skilled craftsman and iterative collaboration. Executives and managers have had to adjust their thinking from a “command and control” style where every aspect of software development was tightly timed and controlled to a “servant leader” style where the goal is to empower the team to make decisions and remove obstacles to their success. I have written previously about these “softer” aspects of software development. In this article, I will pull together the previous concepts into to a holistic view of Agile software development team empowerment. My intention is to create a framework which can lead to more productive teams that produce high-quality code stemming from of business-focus, trust, and collaboration.
Before I begin, there are a few assumptions I make as precursors for any software shop as follows:
Good Talent. Any high performing team needs to be staffed with talented staff. Most well-functioning agile teams will police their own ranks and either help to raise the performance of mediocre members or identify those that need extra help and support. This self-policing comes from a strong sense of team and focus on the development goals. If you don’t hire the best talent and then allow Agile team dynamics to work their magic, then you may be forced to resort to command and control means to reach your goals. Resorting to command and control methods with Agile teams usually produces the undesirable outcomes of demoralized teams and high turnover.
Best Intentions. Most software development staff, given half the chance, will strive to understand a align with the business goals. In cases where they don’t, it is usually traced to a failure of the culture to support employees’ line of sight to the business. We must assume from the start that both software development staff, management, and executives work from a common set of good intentions. It is when we attribute mistakes to bad intentions that software projects spiral out of control in a frenzy of finger-pointing.
Supporting SDLC and Tooling. Agile software development is adaptable to many industry scenarios. Teams need an established software development lifecycle which sets expectations for how Agile is applied and governed. Agile works equally well at any point along the spectrum from loosely to highly regulated industries. Teams also need appropriate tooling to support their use of Agile and these are abundant. Open source shops might use tools from Atlassian or HP while Microsoft shops might use Team Foundation Server. The tools are mostly fungible across target technology stacks, but it is important to use a toolset to enforce SDLC quality gates and to automate manual tasks and tracking.
With assumptions out of the way, let’s drill down on the steps toward the empowerment of software development teams.
Organizing the Teams for Success by Keeping Tensions Healthy
In the three-part series, “Designing an Accountable Software Development Organization,” I discuss the principles of organizing a software development shop for success. The very nature of software development includes the tension between project requirements, the ability to translate those requirements into high-quality working code, and the governance to ensure that it’s done in an orderly and timely fashion. It is impossible to avoid these tensions, but it is possible to design an organization that acknowledges and harnesses the healthy tension while avoiding the tensions from becoming destructive. Put another way, the tension between requirements, technical delivery, and governance are necessary to producing great software. It is entirely up to managers and executives as to whether the tensions will remain healthy or turn toxic. Software developers will flock to healthy shops and flee toxic ones.
Supporting Decision-making by Maintaining Line-of-sight to the Business
All too often, business keeps its software development staff in the dark about key business strategies, goals, successes, and failures. At the same time, we expect our software development staff to make key decisions about software requirements and their implementation to drive business success. To use an old 1950’s B science fiction movie quip, “This does not compute.” In the article, “The Technology Executive and the Software Craftsman,” I discuss treating software development staff less as vendors who simply produce a product and more as partners who share a common desire for favorable business outcomes. The goal is to create a line-of-sight from the business to software development to enable better decision-making at the closest point of impact. This turns software staff from simple doers to thinker/doers who constantly weigh the needs of the business in their decision-making process. This is best summarized by L. David Marquet in Greatness. Creating line of sight and empowering decision-making at the closest point of effect will not merely provide incremental gains in team effectiveness, but will increase effectiveness multi-fold.
Aligning Intentions and Setting Expectations Between Management and Software Development Teams
In addition to the disconnect between business goals and software development, there can also be a disconnect between the senior executive team and software development staff. In the face of this lack of understanding, software developers sometimes fail to understand how and why decisions are made. In the article, “The Technologist’s Guide to the C-Suite,” I discuss the various roles at the executive table as well as what each role is concerned about and listens for. My intention is to foster an understanding on the part of the software development staff so that they will be more effective at synthesizing requirements stemming from and evangelizing solutions to senior executives. The end result is to create better collaboration that ultimately engenders trust.
Identifying Risks, Removing Obstacles, and Continuously Improving
Once we have a well-organized and well-informed software development team, we move onto the nitty-gritty of developing software. As mentioned in the introduction, software development management is transitioning from a traditional “command and control” style of tight control to a “servant leadership” style of team empowerment and removal of obstacles. With a well-functioning Agile software development team, the obstacles to success are frequently external to the software development effort itself that manifest as inefficiencies in the development of software. The obstacles may be related to requirements instability, churn on architectural design, unmanaged tensions between groups, or any number of other issues. In the article, “Better, Faster, Cheaper: Picking Three,” I discuss a model for managing risks to the timely delivery of software in Agile projects. The purpose of the delivery risk model is to identify obstacles to team efficiency as early as possible them work to mitigate those risks. When the delivery risk model is applied judiciously, the end result is higher quality code, more timely delivery, and less time spent fixing defects later, i.e., better, faster, and cheaper. The delivery risk model is an essential part of any servant leader’s toolkit. Without it, risks accumulate and snowball precluding the opportunity to head off problem while they are manageable. Further, the delivery risk model is a gateway to continuous improvement efforts where teams learn from and correct mistakes rather than get punished for making them.
Before concluding, there are some management caveats follows:
Sprint Micromanagement. Agile software development is by definition a highly iterative and self-correcting process. This works when teams are permitted to make mistakes, be honest and transparent with themselves and their management about issues, and work to correct those mistakes. A “command and control” mindset often drives managers and executives to micromanage Agile teams at the sprint level by holding teams strictly to burn down goals and punishing teams when they do not meet those goals. This is a grave mistake since it drives Agile teams to artificially pad estimates, limit transparency, and hide mistakes. Rather, I recommend setting interim delivery goals spaced throughout the project and have executives and managers hold teams accountable for those deliverables. The team should then be allowed to experiment and adjust their own processes within the sprints to improve velocity and quality without fear of punishment. Obviously, the teams need to deliver the agreed-upon functionality for the interim deliverables and may need to push harder to do so. But if the team is permitted to control the progress of sprint, they will usually willingly find a way to meet the interim deliverables.
Agile Dogmatism from Above. Agile methods are a fluid and changing set of guidelines stemming from the original manifesto. Agile software development is designed to adapt to the business and technical challenges at hand. In a strange twist of irony, I have encountered managers and executives who take a dogmatic approach to Agile methods and strive to impose strict doctrine around process and procedure. I recommend starting with a well-defined Agile process then listening to the teams about what’s working and what’s not. Experimentation and adaptation are at the heart of Agile, and the team should be allowed to make adjustments within reason. Depriving the team of this opportunity not only stabs at the heart of the spirit of Agile methods but disempowers Agile teams to influence their own destiny.
Agile Dogmatism from Below. Agile practitioners can sometimes be dogmatic as well. One of the more persistent narratives I’ve heard says that Agile is not about committing to or hitting deadlines. My response continues to be, “Any software development methodology that cannot deliver on a predictable timeline does no good service to the business.” Another chestnut asserts that Agile is about producing software rather than documentation when, in fact, Agile values working software over documentation but does not preclude the need to produce documentation. As from above, there is a certain irony about dogmatism when applied to Agile by its practitioners.
Developing truly great software has never been easy. Software is among the most complex things produced by humans. Its complexity stems from the vast number of states that a software product can assume. In short, the “soft” is software assumes complexity and flexibility. Getting software right is as much a social engagement as a technical one. There are vast tomes and training materials about getting the technology right but woefully little guidance on addressing its social aspects. In this article, I have endeavored to highlight the social aspects of software development and provide a framework for getting best from the skillful and well-intentioned professionals who develop it. In the end as with any social endeavor, we get better results when people are fully engaged in a trusting, collaborative environment. Great software happens where talented people and great software development culture intersect, and that’s what empowerment is all about.