Managing Software Development Teams
In most ways, managing a software team is just like managing any other type of technical team. Technical teams are all made of talented experts. The manager’s job is to enable these experts to improve the organization’s business capability.
But managing a software development team is also different than managing another type of team. Tools change and languages change, but software development is a profoundly creative enterprise. The widgets, libraries, and other primitives grow in size and complexity, but there are a nearly infinite number of possible ways to accomplish a particular task. A member of a software development team can put a personal stamp on his or her contribution in a way that most other technical people can’t.
Note A primitive is one of the basic building blocks that is assembled into a program.
With that nearly infinite number of ways to get from A to B comes a need for judgment and intuition. A good programmer will consistently identify efficient and easily communicated ways to accomplish a given task with the tools at hand.
It is probably impossible to come up with a definitive procedure for producing good code. That is why writing code is a human enterprise, and the talented humans who write code need both skill and intuition to do it well.
Defensive coding should be your foundation. Good programs should be resilient, easy to troubleshoot, and allow for graceful recovery from errors.
Fault-tolerant code will anticipate the possibility of problems, and will recover without causing data corruption. Error handling is an under-appreciated, critical part of good coding practices.
When evaluating your team members’ work product, emphasize error handling, logging, and recoverability. As with any other value that you define as being important for your team, message relentlessly. Recognize excellence. Require dependability. If you measure and reward reliability, your team will produce reliable software.
Software that is big enough to really be useful is seldom written by one programmer. Most software is a collaboration across people and across time. As new capabilities are added or bugs fixed, new code is incorporated into a software package.
Maintaining software written by someone else is not usually a programmer’s favorite task, but it has to be done. The same discipline and attention to detail that goes into a new development project has to be applied to software maintenance.
If your software development team understands the importance of maintainability, they will implement it. Make sure that they think of the development not as just a cool technical puzzle to solve, but as writing a block of code that can stand for generations.
Use code reviews and other techniques to make sure that the code coming from your team is clean, well-structured, and easily understood. That may mean in-line comments, or it may mean external documentation. Whatever method you use, make sure that your team’s code will live well past the time when the team members have moved on to their next big jobs.
Maintainable code can achieve its own sort of immortality. If code is maintainable, the business has an incentive to keep the existing package (with enhancements) rather than undergo a painful migration. Help your developers develop a vision of their software as something that will help solve problems that they haven’t even thought about yet. And then help them to follow disciplined documentation and structural practices that will help them achieve that goal.
If software is not written with operations in mind, it will fail in its primary mission: bringing value to the organization. Finicky, unreliable software consumes operational resources, creates resentments, and destroys the reputation of a software development group.
Operational excellence is built on attention to detail. Little things, such as disk housekeeping, log rotation, configurability, and security of temporary files all are hallmarks of excellent software. It doesn’t take that much extra effort to be thoughtful. But the payoffs to the organization can be huge. And what helps the organization helps the development team.
When designing software, consider how it will operate in a disaster recovery context. If the software cannot recover gracefully in your organization’s business continuity environment, it will be a liability to the organization’s disaster readiness.
How well does the code deal with an interruption in the plumbing connections to the database and other programs? How difficult is it to point it to new data sources in a new context, such as a disaster recovery?
If continuity is not built in at the beginning, the code will be a monster to recover. Nobody appreciates spending time and money developing an infrastructure to recover an application that was not developed with continuity in mind.
Your team’s software also needs to be able to operate in the context of your organization’s job scheduling environment.
Environment-variable settings should be addressed within the program context, from configuration files, rather than requiring that the execution environment have certain variables set in certain ways.
Status codes should be clearly defined and discrete so that the scheduler can branch execution paths depending on the outcome of the program.
It all boils down to understanding your team’s code in a broader environmental context, rather than focusing on a narrow piece of functionality.
Another type of software immortality is reuse. If a module is useful, well-documented, and maintainable, why write another module that does the same thing?
Objects created by developers should be organized into libraries that can be tapped by other developers. Recognize the tool builders within your team for the valuable contributions they make. And also recognize the people who increase the efficiency and velocity of your development process by reusing code from the repository.
Obviously, not every piece of code is suitable for reuse. Some problems are too specific for their solution to usefully be applied elsewhere. Experienced developers should be able to identify modules that are suitable for sharing in the repository.
There are some obvious obstacles to implementing an infrastructure that supports code reuse:
- Organizing the repository in a way that will be useful is nontrivial.
- The code in the repository needs to be maintained as bugs are fixed.
- The mind-set of the developers needs to be changed to look in the repository.
- There needs to be enough useful material in the repository for developers to have an incentive to look there.
- The organization’s development mind-set needs to become more product centric and less project centric.
These obstacles are significant, and that is why so few companies have an organized code reuse system. Especially in organizations where project managers are brought on for a short-term project, there is little incentive for a project manager to invest resources from a limited budget into a code repository that will mostly benefit other project managers in the future.
If your organization hires project managers on a per-project basis, someone outside the project management infrastructure may need to take on the challenge of making the changes necessary to encourage code reuse.
A common challenge for software development managers is that they need to pull in team members who actually report to someone else. There are some challenges involved with managing a team whose members’ primary loyalty is to someone else.
When you don’t have direct executive authority over someone, you still have a lot of things that you can offer as a project manager.
- Access to new technologies.
- The excitement of being part of a team making something new.
- Leadership opportunities within the project team.
- Project work looks good on resumes. Especially if it comes with a good recommendation from a project manager.
- A chance to get away from the daily grind.
Obviously, everything gets harder if the team member’s regular manager is not enthusiastic about his or her participation. You may need to exercise some of the skills we discussed in Chapter 10 to encourage the manager to see the importance of the project. Or you may need to engage the project champion to reinforce the priority of the project.
Keep in mind that your project schedule depends on the availability of the resources you demanded when your project schedule was approved. If the resources available to you change, that also will mean that your project schedule is impacted. Make sure that this message is passed along to the project sponsors so that they understand how important it is to reinforce your authority over the resources you have been promised.
In Chapter 4, we discussed the importance of battling scope creep. For software projects, scope creep is especially dangerous.
Maybe the nature of creating something out of nothing excites people and fires their imagination. Maybe the inputs are largely invisible to the end-user, so they assume that their requests are cheap. Whatever the reason, scope creep will strangle your software project if you don’t tame the monster first.
Change management is your friend. Establish a process to examine the cost of every change before it is considered for approval. Cost may come as time, it may come as money, and usually it comes as both. If costs are inflexible (as they usually are), approvals may require a trade-off of another requirement. Let your change management process work for you to let the ideas compete against each other.
You also can use the promise of the next version to put off requests that threaten your project. Suggestions that don’t make it into the current release can be considered for the next release. When the time comes to scope out the next release, make sure to take a hard-eyed look at the accumulated suggestions. Some of them will be gold; some will be junk. Make sure to select requirements based on merit, not the length of time they have spent in the queue.
A common problem is that people think that a feature that is easy to describe is easy to implement. This is obviously not true. It is nice to have a clear statement of a requirement, but that doesn’t mean that the feature is easily implemented.
Sometimes complexity can be explained by showing the design that will be necessary to implement the feature. It is management’s job to push on you to make sure the company’s resources are not being wasted by too relaxed a project schedule. It is your job to push back with information and facts to demonstrate that you are making wise use of your project budget.
Some of the graphical tools discussed in Chapter 13 can help describe the magnitude of some of the changes that are being requested. You’ll have to hold your ground against “simple” changes that threaten to derail the entire effort due to hidden complexity. Expose the complexity to the Change Control Board, and describe the costs of the change request accurately, in time, resources, and money.
The Importance of Testing
When people want to push a schedule, the first place that is considered for cuts is testing. Professionals understand just how important it is to have a complete test cycle. Issues are much more easily addressed when they are discovered during testing than if they are only discovered after the product’s release into production.
Your team may also be a part of this dynamic. Programming tends to attract personalities who are eager to move on to the next challenge, not look back to fix minor errors in what they did yesterday. Preach the importance of quality within your team, and the importance of testing to achieving that quality.
Leave adequate time for testing. Push back on management or even your own team when necessary. If a schedule change is needed, it would be better to postpone a feature or bring on more people than to eliminate testing.
Testing As a Way to Measure Quality
One of the main benefits of a good testing program is that it will provide a solid quality metric. Once you get a handle on which team members need help to meet your quality goals, you will know where to focus your time and efforts.
As with many other things in the workplace, you get more of what you measure. If you measure quality, you will get more quality.
Every Requirement Gets a Test Suite
Every listed requirement needs a defined test suite to verify that the end product meets the requirement. Some methodologies even specify requirements in terms of the tests that are used to validate them.
Software engineering maps user requirements to functional requirements to code to tests. Every line of code should be able to be mapped back to the user requirements that demand it, as well as being able to be mapped forward to the test suites that validate those user requirements.
Programmers are optimistic people. They need to be that way to believe that they can create something out of nothing. Software developers believe that what they write works, otherwise they would never have written it.
Just as management can sabotage a testing program by starving it of time and resources, developers can kill a testing program by neglect.
The importance of thorough testing needs to become engraved in your team’s DNA. Testing is part of your overall emphasis on quality from start to finish. Poorly written tests are a sign of laziness or inattention. Mentor team members who tend to be more prone to skipping “unneeded” testing. Teach them how to test thoroughly, and then measure their quality directly. Pride is a powerful motivator, and measuring and recording defects will encourage more careful testing during the development process.
Many other technology teams manage or build tangible capital assets. Unfair it may be, but senior management can view their contribution as being more valuable than a software team’s contributions because it is easier to list those contributions on a balance sheet.
A software team’s contributions are only valuable if they deliver more tangible value to the organization than the cost of running the team. Make sure that you have a business case to support your activities. Then make sure your business cases are in a well-publicized share that is available to management.
Unlike your peers in other technology areas, the products of a software development team are not visible until they are available for testing. For management, a software development team looks like a black box that consumes cash with no tangible output.
Make sure that management understands your project plan, and that they have a way to measure your progress toward completion. Communicate out your testing results, for unit tests, integration tests, and acceptance tests. These test results can be a way to demonstrate tangible progress toward the end goal.
For projects using prototyping methodologies, prototypes can also be tangible reminders to the project sponsors of why they are spending money on the project. One of the advantages of prototyping models is that management is less likely to lose faith in the project because they have a way to view tangible work products that show a clear progression toward the project goals.
If your team is using a diverse set of tools, team members will not be able to help each other out when questions about those tools arise. And when they are troubleshooting a problem, it may be harder for different team members to reproduce the problem in the same way.
There is always some space for personal preference, but a software development team needs to be using a standard tool set. If one does not exist for your organization, part of your challenge will be to define one for your team.
Make sure to get the best tools you can arrange. Cost is always an issue, but skimping on tools is a false efficiency. Figure out how much more quickly your people can work on good tools versus crappy tools, and figure how much it will cost the company to have the software delivered that much later.
As with any other management challenge, discuss the issue with your team. Explain the problems that can arise from having different people using different tool sets. Foster a discussion of the pros and cons of the different tool choices. Then make a decision what the standard will be and get on with building the piece of software.
There are some processes that you will revisit over and over throughout the development process. Code builds, deployments to a higher environment, database refreshes, and ETL (Extract, Transform, Load) tests are all examples of such processes. These should be handled in a defined, repeatable way.
If you take the time and thought to build the tools to support these processes, it will save you time on any project of significant size. If you look at the amount of time to do a database refresh, multiply by the number of times you have to do it, and then multiply by the number of developers idled by a database refresh, you will understand just how much it is worth your while to nail these processes down.
And if you can script and standardize your code deployment process, you will eliminate entire classes of problems, such as the problems caused by failing to upgrade a single module during the upgrade process.
If you don’t have a standard naming convention for objects, you are likely to end up with multiple distinct objects having the same name, or with team members spending more time than you would like trying to resolve problems resulting from an incompatible naming scheme.
Come up with a standard and conventions. Circulate these for feedback from the project team, and take the feedback into account. Then publish the naming standard and insist on its use.
Define a version control standard, and make sure there is a way to roll back to a previous version when a new bug is accidentally introduced in a new version. If there is an organizational standard for these capabilities, use that. But don’t let the project get underway without these capabilities being used by your development team.
Track bugs and reported issues in a standard, shared way. People on the project need to be able to examine bug reports and resolutions. It is your job to make sure that they have a standard tool and process for reporting and tracking bugs and issues.
There are a ton of software methodologies on the market, and each has its adherents. Each methodology solves the age-old problems of software development in a slightly different way. The core problem is to deliver useful tools to the organization in a timely way.
It is important to pick a standard approach so that you can take advantage of tools and templates that are available to support that approach. If the organization has a standard, the tools and templates are probably already in place and should be able to be adapted to your circumstances.
Standard software development methodologies include training, tools, and templates that would be hard for you to reproduce. You may not want to use every tool or template for every project, but having a well-defined, well-known methodology can give you a leg up on creating a rhythm within the team.
A lot of the new Agile software development techniques are focused around delivering prototypes quickly. The Agile conceptual framework uses iterative cycles within defined time windows to promote the interactions between the end-user and development communities in a structured way. By treating software as an evolutionary process rather than a large, monolithic development waterfall, Agile methods aim to accelerate a software lifecycle process that is sometimes too slow to keep up with the shifting demands of an ever-changing user community.
The pace and the order of operations may be different, but the end goal is always the same. Deliver useful capability to the business in time for the business to be able to take advantage of it.
No two software development situations are the same. An organization needs to develop a rhythm that fits the organization itself, not the organization that spawned the methodology.
From a management point of view, the key is to have a methodology that works in this organization. Pick a methodology that works for your environment and your project. Use ideas that work in your environment, and don’t be afraid to apply different rules to different projects if the extra overhead makes sense.
Summary
Managing software teams is both the same as and different from managing other technical teams. A lot of the challenges are the same.
But there are also important differences. Software development is a profoundly creative enterprise. Management’s challenge is to unleash the creativity while at the same time steering it in a direction that will maximize business value.
Do not allow your development projects to be hijacked. If the effort is redirected, make sure it is only after a clear-eyed assessment of the benefits and costs of the change, and with buy-in from an established change control process.
Emphasize quality, and measure quality directly with a rigorous testing regime based on a clear understanding of requirements. Use your quality measurements to find ways to improve your team’s contribution to your organization’s bottom line.
Discussion Questions
- Describe the development methodology in place in your organization. Describe the ways in which this methodology helps your team add value to the business. How does it hurt your team’s efforts? What changes to the methodology might improve your development process?
- What tools do you use to emphasize the importance of quality? What additional tools can you use?
Further Reading
Berkun, Scott. Making Things Happen. Sebastopol, CA: O’Reilly, 2008.
Medinilla, Angel. Agile Management. New York, NY: Springer, 2012.
Stellman, Andrew, and Jennifer Greene. Applied Software Project Management. Sebastopol, CA: O’Reilly, 2006.