I’ve recently noticed a trend: a number of Agile software development consultants, coaches, and thought leaders have been writing about commitment, in the context of management wanting them to commit to dates on a quarterly basis. The general consensus among these folks is that commitment should be on a shorter time line, like their bi-weekly sprints. Don’t ask us to commit to more than we can do in the next two weeks, because we don’t estimate well, or we don’t understand exactly what is needed. Like it says in the Agile manifesto. “We value responding to change, over following a plan.“
Organizations Communicate Via Plans and Contracts
While that’s certainly a positive value, plans are also necessary. Especially for organizations negotiating contracts with customers and suppliers, transitioning to new lines of business, merging, acquiring, divesting, and doing all of the other outward-facing activities common to businesses. A CIO who greenlights a project to replace an ERP expects to be able to quit paying annual service charges to their legacy vendor on some date. A CEO who negotiated financial incentives for her suppliers, based on their utilization of their supply chain management system, agrees to milestone dates. A CFO who needs to merge two general ledger charts of accounts after an acquisition needs to be able to report financial results for a specific quarter. And when those things don’t happen on time, their ability to negotiate the next deal is hampered, much like your credit score is affected when you miss a mortgage payment. The business suffers, in ways great and small, from stock price dips to the cost of capital, to opportunities and jobs lost. The damage may never be apparent to the software development team, but it’s real.
There are few things less beneficial than perfect, too late. Therefore, mature software development teams set a window for requirements changes, announce it to their stakeholders, and deliver based on their understanding of what is required, at that point in time. Mature, quality-driven software development teams understand their tools, their environment, their architecture, and their limitations. They can sketch out a timeline that has a reasonable ability to manage their schedule risks, and they commit to it. Mature software development teams understand that it’s not about them, and it’s not about their processes; it’s about the needs and aspirations of the organization they serve.
Employers Value Business Acumen
PMI recently announced new continuing certification requirements for the PMP and other credentials that emphasize what surveys have identified as employer-desired skills. As PMI puts it, “Employers need project practitioners with leadership and business intelligence skills to support long-range strategic objectives that contribute to the bottom line. The ideal skill set — the PMI Talent Triangle — is a combination of technical, leadership, and strategic and business management expertise.” One of the key components of this skill set is what is commonly called business acumen: an understanding of the business, the marketplace, and the operating environment. It enables the project manager to interpret the strategy set by the leadership team and apply it to the project, thus improving the likelihood of delivering the benefits sought by the decision makers who approved it. If software development professional organizations are taking similar steps, I haven’t heard about it.
A competitive business environment is not a video game; it’s closer in spirit to a track meet, with multiple teams competing in multiple events. At some level, it’s the Olympics; competition on a global scale. If some portion of the organization can’t compete at the required level, that function eventually gets outsourced. And the decision to undergo that kind of painful, expensive disruption won’t be driven by some pointy-haired boss, but by a bunch of Wallys.