It has always been said that customer engagement is a key issue in a project development. We know and confirm it by our own experience. As a matter of fact, the Agile Manifesto reflects it in one of its four core values, and even goes a little bit further:
"We value customer collaboration over contract negotiation."
And if we consult two of its twelve principles:
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
"We welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
Just a useful reference, but please be clear we are not here to discuss about the Manifesto, which speaks for itself. We all have in mind a client with whom we have had to deal with, and had made us to think about what type of client we are or have been. I am sure some of us remember the typical impertinent, even sometimes might seem, incomprehensibly, external to the project or interested in complicating it. Conversely, sometimes we enjoy a restless client, which is literally on top of us but also difficult, slow or perverts our project velocity. Who has not sometimes stated that... "If the customer does not bother us so much, we may deliver his work sooner".
Probably most would opt for a customer to move between these two extremes, as humans we are when we have a thing we thing in the other and vice versa. Indeed, the ideal client should be aware of the project main issues but also properly know the work methodology we play. And therefore respect the Agile process from start to finish. It sounds very easy, but the most difficult thing in an Agile adoption.
Although sometimes it may seem, the fact that the client make noise to the development team when he feels like it is not always their fault. In other words, we have much to do to educate, and preferably avoid or minimize this noise on their part, and we are referring only to the aforementioned customer impertinent. Imagine dealing with one educated, empathetic, intelligent, but we simply have not explained our work environment, our Agile philosophy, or the development team features. In this case, much more common than desirable, this would be a customer who wants results and value as is normal, but do not care about anything else. Well, that is not final, but it is better that we all know, as a whole team and as such, each role we play.
For instance, supposing you have a project with an actual external client, which communicates with the internal team of an organization through the Product Owner. - Note this clarification because there could be cases where the internal client itself takes the role of Product Owner. As well we have mentioned before, the customer is a fundamental part of the course and future of our project. So we have to help him to be agile, make him feel agile. We must educate from the beginning of the project, from its origin which is the main character to negotiate with the Product Owner, in the requirements gathering, in the Product Roadmap building or Release Planning definition.
Let's go to a specific scenario. If we were using Scrum or XP methodology in our project, the client should already be clear about all these points before the start of the first iteration:
• For any questions related to the project the contact is the Product Owner and not the development team.
• The customer should know and accept their changes or new requests are welcome, but they will be implemented in future iterations or sprints, never in the course of the current, and taking into account the priority is defined in the Product Backlog.
• He must have clear and continually review these project priorities, informing the Product Owner at any time in order to prioritize the Backlog. The team will convert this work in value making short and continuous deliveries to the customer.
• Will be in the Demo or Review, once the iteration finished, when the customer is able to participate, provide feedback and ask for new functionality, then the Product Owner will translate all that into prioritized tasks for subsequent iterations.
• In general, he must be aware and believe in the game, understand the team velocity or pace, and what is more important, and I repeat, respect the methodology above all.
And let me another aside, about this "respect the methodology" because here lies the real trouble. This may be another case in which it is said: "Yes, of course we're agile" or "Sure, we are also using Scrum, XP , Kanban ..." but this could be nothing more than an attempt that is not being (correctly) accomplished. If the client does not understand, does not want, does not believe or does not use the agile methodology in the right way, understanding their values and principles and holding it, we are in one of those scenarios in which we ask "But are we really agile?" Or something likes "Well, I do Scrum but it does not work". Of course Scrum is not just sticking pieces of paper on the wall. Being Agile means not only that and/or holding stand up daily meetings. In fact, it is completely impossible to fully apply Agile with a client who is not truly committed, without participating in the process as it should be required.
You also need to consider the type of client and professional you are dealing: more or less technical, closer or more distant, more or less patient ... It is absolutely different to see a technologically skilled manager or a financial expert. In any case, what is really important is to know, and speak the same language, and I do not mean just the words.
This commitment, negotiation and daily contact with our client is far from taking place in the traditional Waterfall, where we rely on the dates and in the diagrams whose long-term targets are really complicated to achieve over time, especially in the changing world of IT. In Agile we are boosting this relationship between the client and team, and making it closest, more human. It is for this reason that we place special emphasis on strengthening. And here we might review the Agile Manifesto and its four values. It would even be preferable that this relationship went beyond the professional, and this way know the client's interests, hobbies and how he copes with life, problems, or concerns.
However, it often happens that we see him as an enemy, but treat the customer as a friend is a direct guarantee of success. Suffering disputes, discussions and other problems leads precisely to waste, distrust or lack of concentration, and this only create a precedent in future. We must all go in the same direction, inevitably applying the theory, and thus we even pamper sometimes, not only between team members, but starting with the customer or also for end users of our product, and generally in all project stakeholders.
In conclusion, I hope I humbly force reflect on more than one customer that you know, have or have had, and how he has behaved or have dealt with them in one or other way. Similarly, my dear customers, always longed at the beginning and often questioned later, perhaps are the ones who best give their opinions about Agile framework. And, of course, the whole Agile Community which I am proud to belong, from where I welcome any comment.
Richard is a PMI-ACP, PSM certified software engineer who started his professional career as developer but very soon introduced in Agile Project Management. His international experience includes business in Spain and United Kingdom. At present, he is working in Toronto as Agile Coach and Principal Consultant for Valueinnova Canada as well as Project Manager for Cysnet Software, company he manages with other associates.