As the concepts and practices of Agile development are better understood, the nature of Agile onboarding challenges is changing. Here our customer partner Tim Bailey explores how to tackle those issues and prime your Agile projects for success.
There’s always a thrill when we start work with a new client, as we get to know the people and begin the process of immersing ourselves in a new organisation.
As part of the Client Services team, my role is to be an ever-present point of contact for a client during their relationship with software development company Inviqa. I develop an overview of the engagement and help make our work more effective.
A lot of the initial activities we undertake with a client are there to help us to understand each other. This alignment can cover a whole range of areas of our relationship, from the processes and language we use, to the concepts we use and the way we report project finances.
Lost in translation
The largest challenge we used to face with a new client was gaining acceptance for the concepts and practices of Agile development. But as Agile adoption continues to grow, we’re seeing a subtle change in how Agile onboarding issues present themselves.
It used to be that the interactive, just-in-time nature of the process was problematic to clients who were used to Stepwise, linear project delivery (sometimes called Waterfall). There could be significant misgivings about a process that seemed unstructured, decentralised, and without the bureaucratic controls they were used to.
Now, as Agile working is better understood and more widely embraced, we face the challenge that the words we both use, as client and agency, are the same, but may not mean the same thing to both parties.
Sometimes, speaking the same language does not mean we are talking about the same concepts.
Here are two approaches we have developed to avoid this issue:
One of the first things we do with a new client is to carry out activities that are designed to ensure we understand each other.
Typically, this is an interactive session focussed on developing a joint understanding of the language and concepts we need to use during the project. It provides a forum to talk freely about hopes and fears, which starts developing relationships between those involved – relationships that will be essential for a successful project.
We use this as an opportunity for our project team to meet the client's team. The meeting is also the place to identify requirement for additional activities, such as training in the roles that the clients’ staff need to take during the project. We also identify parts of the organisation beyond the project team (typically production IT or security teams) that we’ll need to interact with.
Orientation contributes to developing understanding between those who are intimately involved in project delivery. But there are also stakeholders in the company who can affect the project, but whom we’re unlikely to see unless there are serious governance issues to address.
Senior managers and directors, such as the chief finance officer, need to be comfortable that resource is being well spent and business value realised. For this we establish a monthly steering group where we sit with our direct client and report to the higher-level stakeholders.
We find that once the issue of financial control has been established, and the stakeholders are satisfied that Agile provides for careful monitoring and progress reporting, discussions usually focus on high-level issues, such as risk management. It’s essential for the client organisation to have this strategic view in order for them to sustain confidence in our work.
Mitigating risk in Agile projects
So, aside from communication and language, what other issues can present themselves at the start of Agile projects? Here are three common challenges and ways to negotiate them:
1. Building to specification
This is common for organisations with a tradition of linear project development. It can also be a consequence of a budget-setting process where internal stakeholders have to secure resource or make a business case – sometimes many months ahead of work being commissioned.
Let’s suppose time and money has been invested by a client in ‘getting the specification right’, and that significant political and emotional capital has been spent. This is the point at which we share our experience across the many hundreds of projects we have completed during the last ten years.
PRO TIP: get your technology partner in early to help you size these activities. Save on the cost of creating a detailed specification for something that you might not want in that form.
It’s very rare (indeed unicorn-rare) that we don’t find new requirements during building and testing; there’s too much change, and too many other perspectives for us not to. It’s important not to ignore the specification, but instead to incorporate them into a detailed Discovery process.
Far more than a technical specification exercise, the Discovery is an investigation into the value the project outcomes will bring to the client’s business. When this is clear and understood, it allows a more forensic review of what can be built that delivers this value. Prioritisation is also more straightforward in this framework with decisions made against value.
2. Product owner availability
Product ownership is far more effective where an organisation has appointed a dedicated product owner who can apply their full time and attention to aligning stakeholders and communicating their vision.
But whatever a client’s set-up, we work with them to deliver the project in the most efficient way we can. If the availability of the product owner is a constraint, we acknowledge it and work with it, in the same way we would any other restraint.
The bigger discussion is about the importance of the product owner to the success of a project, and about how the role is a job in itself. Where beneficial, we run training and orientation for product owners, and one of my points of focus is to regularly work with product owners to ensure clear and prompt communication.
Understandably, clients need to feel comfortable about what a project will deliver and how much it will cost. This has been traditionally addressed through a long and exhaustive specification process, that leads to a fixed price, fixed scope project. Though, as we now acknowledge, having a fixed price AND a fixed scope will lead to either a project that misses all of the opportunities for improvement that are discovered, or a change control process, which can be bureaucratic and occasionally combative.
So how do we provide these very reasonable reassurances that clients want? We undertake our Discovery process to:
- Determine the business goals for the project (why are you doing this?)
- Clarify the business value the project will bring to the organisation
- Create a backlog of items to develop that will deliver this value
- Work with client to prioritise the backlog, identifying the items of highest business value for the project
- Create estimates as to the cost of delivering the scope of the project
This creates a scope and a cost estimate. We can then work with the client to either deliver to a capped budget (fixed price, but variable scope) or work purely on ‘time & materials’ to deliver the agreed scope. Of course, the joy of Agile is that this can change as the project progresses and value is delivered to the business. With financial reporting on a week by week basis and strategic oversight via the steering group, the information is available to make timely decisions about the continuing value of a project.
To share an anecdote, we ran a project with a product owner who was very busy running a high-pressure trading desk and ensuring his company was making decisions based on the movements in their particualr market.
While initially enthusiastic, the product owner was hard to contact. However, over time, as each demo showed more functionality, and he was able to comment, amend, and see changes at the next demo, we started to see a little more of the client.
Towards the end of the project, he moved into our office for two days a week, ensuring the developers had easy access to the business. At the end of the eleven weeks’ development and testing, we handed the project over, under time and under budget, providing the business value the product owner had been able to fine tune.
The importance of two-way communication
With imagination and flexibility on both the client and agency side, it’s possible to deliver significant change and business value through a small, rapid burst of development that is focussed on the areas of most value.
The activities we run at the start of a project are focussed on creating and sharing an understanding of the project objectives and ways of working, from the very start. Through listening to each other, as clients, developers, project managers, or any other related role, we start to develop trust that directly contributes towards the success of the project.