The process of stakeholder engagement is about how people roles connect to the value stream, with everyone focusing in the product final result. As opposed to their isolated place in a production pipeline.
It’s important to have a clear vision statement from the beginning. This will allow us to focus on gathering the relevant market and domain knowledge we need in order to solve the “problem”, and start thinking of an Architecture. With the Architecture vision in mind we can start to think on how to organize our human resources:
- Who to hire
- How to combine them
- Where to combine them (as in physical location, think Conway’s Law)
The main Architectural goal is to create a firm foundation that will support the product throughout it’s lifetime. So, there are two considerations to keep in mind:
- The Architecture must be able to support change in the long term
- Build the process around the value stream
Having an Architectural structure that is flexible and accurately reflects the domain knowledge is the best support for change and focus on the value stream.
When finally building features, it is crucial to engage the end-users and customers in their own native habitat, with short development and feedback cycles, so that we can quickly adjust the product to the actual needs/expectations of the end-users, including hidden user processes like their usage of post-it, or a notebook, to complement the software functionality.
Capturing emerging and latent requirements early in the process can significantly lower the long-term cost of the project.
This is how we embrace change: We don’t just react to it, we provide the catalysts to accelerate and respond appropriately.
@hgraca 