Agile: First Contact with a New Client
Our recent whitepaper Advanced Agile: Five Ways to Accelerate Delivery, Improve Flexibility, and Reduce Waste (Available through our Contact Us form) summarizes five of the key insights Rangle has acquired doing Agile software development projects for a diverse group of clients.
In this article, we would like to talk about another: how to handle first contact with a new client, and in particular, what needs to happen at the start of the first project that two groups do together.
In our experience, that first encounter must focus on governance and definitions. Who decides what the project's scope is, what process will be followed, and how deadlines are set? Who is responsible for following through on those decisions? Do the two differ, and if so, why?
A key question here is, "Who owns this product?" In practice, this turns into, "Who is responsible for aligning development priorities with business objectives?" The Product Owner identified by the client is responsible for this, but they are usually (and rightly) a proxy for a range of internal and external stakeholders. Particularly if they are new to this role within an Agile project, our first objective has to be to help them identify these stakeholders and ensure that they have a clear understanding of the project vision. This may seem like Project Management 101, but as in all aspects of software development, the tool shapes the hand: what Agile can deliver can and should influence what goals are set for the project.
A corollary insight is that these decisions should not be made just once and then frozen. Instead, like every aspect of an Agile project, they should periodically be reviewed to ensure that they are always the best answer from the business point of view. We often use an exercise called Clarity Canvas to do this review, both to elicit knowledge from the team and to spark self-awareness of choices that may have been made without anyone consciously realizing it.
Through engagements with multiple clients we've learned that this meta-level project management is where it's critical to adapt to a company's existing culture rather than trying to impose new practices. Every organization distributes authority and responsibility differently; changing this usually takes much longer than updating or developing an application, and must be done with rather than to the people involved. While we believe that most aspects of business could be more Agile, we also believe that being a good example is more likely to change people's minds and get them to adopt the practices that are most immediately relevant to them.
With contribution from Greg Wilson