I have a long-standing directive for whatever work must be done, whether it be research, a problem to solve, a hypothesis to test or a product to develop: purpose before process and process before tools. To move from your process into your tools, you must follow these steps, in this order: simplify, standardize and systematize.
Understanding Your Purpose First
Before you begin any effort, you should first define why are you doing it and for whom you are doing it. In the pre-Agile world, the first things rookie managers would ask about were cost and schedule. Experienced managers would ask about the benefits and the customers because without understanding those, cost and schedule didn’t matter.
In an Agile world, expressing and ensuring a common understanding of both the product’s and backlog item’s purpose is a clearly defined responsibility of the Product Owner. It underscores the importance of having a well-articulated and communicated product vision.
From Purpose to Product: It’s All in the Process
In Agile, the process is the domain of the development team. One of the early questions asked during the process is “build or buy?” Should you develop the software in-house or buy it? Should you build the hardware in-house or should you OEM it? The “build or buy” question is an important one, but it’s usually addressed in terms of costs and tradeoffs.
“Is the product (or feature) expected to deliver a competitive advantage?”
If the answer to this question is “yes,” then you’re on the build path, subject to a TCO-oriented cost and benefit analysis. If the answer is “no,” you’re on the buy path. It would be hard to imagine anything that would change that circumstance.
Purchased Solutions Won’t Result in Competitive Advantage
I must make this clear: no solution you can buy will be a carrier of competitive advantage. If you can buy it, so can your competitors. During my CIO days, I remember someone stating that by implementing SAP, we would realize a competitive advantage.
The fact is, we may have been at a competitive disadvantage by not having an ERP system, but implementation was not going to provide an advantage.
Focus on Architectural Fit
Another aspect of process that is too-often neglected is one of architectural fit. Often, organizations neglect architecture altogether, or merely give it lip service. Should your organization be among those enlightened enough to give architecture priority, complete with rules and a real-world approach, you need to define a solution process for your product’s development.
It must ensure architectural fit or push the state of the architecture forward. Otherwise, you’re in a position of evaluating the TCO-oriented cost and benefit of compromising the product to achieve architectural compliance or compromising the architecture to accommodate the product.
Only after following these steps can you move forward to the last step in the path from process to product: tools.
You Must Simplify, Standardize and Systematize
If you take one thing from this message, let it be this: to get from the beginning to the end, you must simplify, standardize and systematize. You must start with a purpose, then move forward to the process followed by your tools. To learn more about Agile and the importance of purpose, send us a message.