Skip to content

Watch: A collaboration guide to adapting with Agile practices in diverse team dynamics

                                                            Guillaume thumbnail

The word agile means something different in almost every organisation that uses it. When you arrive as an independent professional and assume that your understanding of scrum or kanban matches your client's, you are taking a risk that shows up quickly in missed expectations and misaligned delivery.

In this session, agile transformation coach Guillaume, with over 25 years of IT experience, cuts through the jargon and helps independent professionals understand how to read a client's agile environment, ask the right questions from day one and avoid the most common traps.

Watch the full recording here:

What you'll take away from the session:

  • The core differences between scrum, kanban and lean, including what questions to ask a client to understand which they are actually practising

  • How scaled agile frameworks like SAFe and Spotify model shape the collaboration and communication norms you should expect on an engagement

  • The difference between estimating in hours and estimating in story points, and why the choice affects how your work will be managed and evaluated

  • The key questions to ask any new agile client before starting, including what their definition of done is, what they expect at the end of a sprint and how they handle work that is not completed on time

  • How to navigate fixed-price contracts within an agile context, including risk management, estimation transparency and the value of early releases

  • The most important dos and don'ts for independent professionals working inside agile teams, from speaking up about problems to helping teammates outside your immediate lane

This session is practical, interactive and built around real scenarios. If you have ever walked into a client and felt slightly out of step with how they work, this session will help you understand why and what to do about it.

Hit play and learn how to read any client's agile environment before it reads you.

What is the practical difference between scrum and kanban, and how do I know which one my client is using?

 Scrum organises work into fixed cycles, typically two-week sprints, with a defined goal and a review at the end of each cycle. Kanban operates as a continuous flow, where work items move through a series of stages and are delivered as they are completed rather than at the end of a fixed period. To understand which your client is using, ask whether they work in sprints, what they expect to deliver at the end of each cycle and whether they track work in stages or in iterations. The answer will tell you far more than the label they give their approach. 

What should I ask a new client at the start of an engagement to understand how they work?

 Guillaume recommends four questions as a starting point. What cycle or sprint length do they use? What do they expect from you at the end of a sprint or delivery period? What is their definition of done, meaning what criteria must be met before work is considered complete? And what happens when work is not finished by the end of a cycle? The answers to these questions reveal the practical reality of how work is managed, how performance will be judged and where the pressure points are likely to be. 

What are the biggest red flags when working inside an agile client environment?

 Three stand out from Guillaume's experience. First, the expectation that you commit to delivering a specific set of items in every sprint regardless of what emerges during the work. This is a misreading of agile that creates unnecessary conflict. Second, risk discussions that happen in closed management meetings without the delivery team present. Risk assessment is most valuable when everyone contributes, and being excluded is a warning sign. Third, working so close to individual tasks that no one is maintaining visibility of the overall programme. If you cannot see the big picture, raise it. 

How do you manage a fixed-price contract when the client claims to be using agile?

The honest answer is that a fixed-price contract with a fully specified scope is not really agile, regardless of what the client calls it. Guillaume's practical advice is to treat it as a traditional project management challenge while using agile methods internally for your own efficiency. Be transparent with your client about estimates using both best-case and worst-case scenarios, involve them in estimation sessions so they understand complexity, insist that any new scope request displaces something already agreed and push for an early release or technical milestone at the midpoint of the project to de-risk the second half of delivery. 

 
, ,