Supplying Tools for Your Software Team
One of a software manager’s most important jobs is to supply the tools engineers need to do their best work. Peter Drucker said “knowledge workers have to manage themselves,” meaning that skilled, creative workers (like your company’s software engineers) need autonomy in order to be effective.
But the tools and techniques they’ll use to do their work depend heavily on the environment they’re working in. As I saw firsthand in my early days as a PHP programmer, it’s quite possible to create a lot of business value without using version control. But most companies I’ve worked with in the years since would consider lack of version control a guarantee of immediate disaster. Your software developers likely have similar stories of big differences in what’s considered “normal” from one organization to another. They know firsthand that habits, culture, and environment have a large say in which engineering practices are considered indispensable.
It’s hard to call any particular set of practices right or wrong, just as it’s hard to justify changing any process that’s delivering good results to the business. But if your process is coming up short, and you’re looking for ways to improve your team’s performance, there might be big opportunities hiding in plain sight for a manager to provide valuable tools to the team.
Find the Missing Ingredient
Imagine a software project that’s running over budget because individual features are taking longer to complete than estimated. To call this a common complaint would be an understatement. A lot of the extra time goes to reworking stories to reach clear agreement on requirements after implementation has been partly done based on faulty assumptions.
The use of acceptance criteria is a known technique for solving this problem, recommended by most methodologies. Even without acceptance criteria, you’re bound to reach specificity and clarity about the feature you’re building after several rounds of delivery of the feature for inspection. However, it’s much less expensive to reach that clarity up-front, before implementation begins, by stating the request in the form of objective, testable criteria. This requires a combination of an engineer’s programmatic mindset and a product owner’s knowledge of requirements, so it requires some form of collaboration between the two roles.
If your team isn’t creating clear acceptance criteria before starting, it might be because individual developers and product owners are doing their best with what they’re given, and they’re getting used to “normal” being receiving a feature request followed by several rounds of rejection and rework unaccompanied by acceptance criteria, because that’s the only place your process provides for that collaboration to happen. If this is true in your process, you might have found a place where management can make a very useful adjustment. In a future installment, I’ll discuss making the change and testing your assumptions.
