At the base level the process for managing software products in an enterprise is very straightforward. Senior Management identifies a need for a product and a Product Manager works with Business Process Analysts to begin planning the product. Once an initial vision for the product is well understood, BPAs work with Subject Matter Experts to develop the Operational Concept. As the operational concept becomes clearly defined, Architecture and Engineering identifies a solution and begins iterating to build and deploy the software. During this phase, two key sub-processes are concurrently being executed: Manage User Feedback and Manage Change. These two processes feed into the queue for the iterations by way of the processes for managing the operational concept.
Each of these processes will be decomposed into smaller processes and their constituent activities in future posts. Regardless of the tools used, these processes should be followed. The procedures – the “How” of the methodology – defines the tools used, but for continuous improvement purposes, the process should not constrain a team to a given tool set. If the process is failing, focus on improving the process; if the tools are not enabling the team to properly complete the process, then that is a separate problem to be addressed. Sometimes the tools will force a change to the process, and that’s OK as long as the team is cognizant about the impacts of a change to the process and accept that the benefit of using the tool is worth changing the process.
From this perspective, it looks quite simple. And it really is, it just requires discipline to adhere to the process and self inspection to ensure that the process is meeting the needs of the team. Also, the ability to recognize when an aspect of the process is not adding value and willingness to change or even remove it when these aspects are discovered.