For over 20 years, I have started and carried out software development projects for clients. That means a great number of projects! During all these years, I’ve rarely met clients who were very interested in the development process. In fact, to be more precise, they often wish to know if a development process is being used. However, based on my experience, it’s not what is of most interest to them in their decision making process.

I am currently managing Agile development teams. In /studio’s Agile team, our first concerns are to create value for the client and to achieve the business objectives. However, concrete actions of the team members are very varied and may seem not to directly satisfy the objectives. Very often, with equal efforts, it is decisions that we make and the way that we make them that tend to create value, not the single action of developing a software application. Therefore, we pay careful attention to the process which leads us to decision making, and we try to balance it by keeping in mind that we also want to be in action.

What does the client want?

Experience taught me that clients have a profound intention that they are attempting to execute. One must know how to listen to clients and understand their profound intention… Typical clients of Pyxis /studio don’t have a development team and have very little technical knowledge. They have a budget and an idea of what they want (and this idea is often not very clear) and they are looking for someone who will help them develop it.

Let’s talk about our typical client, I’ll name him Roger. His budget is limited and he hates wasting money. Careful! he is not stingy, but he wants to get his money’s worth. Roger likes to know that each dollar spent will produce a good return on investment. He also likes to note that, with each dollar, he is getting closer to seeing his dream, into which he put a lot of energy, become reality. He is very critical of the time that /studio’s experts is spending developing the software solution in which he is pumping money. In daily business, he doesn’t really care about ceremonies, advanced test strategies, continuous integration, self-organization and all activities related to the general principles of Agile approaches. If these activities do not help him, he criticizes them openly. He likes the proximity of the development team. He particularly likes when he feels that this team seems profoundly involved in his project. However, he doesn’t understand well this commitment to Agility. He sometimes thinks that it is simply a process and that some of the steps are somewhat unnecessary.

The problem of the Agile discourse

It is quite obvious that this type of client is not too interested in Agility. In fact, he can explain quite clearly why he chose us. However, the reasons are rarely expressed with words that are used to define Agility. For a businessman who is investing money and taking risks, the Agile principles and values are only speculative and theoretical if not supported by concrete results. You’ll reply that it’s the same for everybody, but, based on my experience, it’s doubly truer for /studio’s clients. When they ask us “What is Agility”, it is quite difficult to answer without giving evasive conceptual explanations that are of no substance for them. They are seeking explanations that are way more pragmatic, a value that is way more concrete, and a very practical efficiency. Therefore, we must talk about Agility to the clients in just the right amounts and focus on respecting the values and principles of Agile methods. Everything we do has a purpose, and we have to demonstrate it every day. We continuously have to prove that what we do generates value for our clients… and it must be reflected in results and objectives achievement.

Benefits of Agility

Right from the beginning of the project, we must be able to list the concrete benefits resulting from the methods we are using. What does Agility really offer to people wishing that we develop custom software for them? For many, it’s their first experience with software development. Therefore, our explanation must transcend experiential benefits and apply to factors with a direct impact on the client’s business. The perfect example: the famous time-to-market. Today’s products and software applications generally have a life cycle that is shorter that it used to be. Thus, it’s imperative to be able to produce results rapidly and to shorten the deadline in order to meet the market’s immediate needs. The one who can do it rapidly has a decisive competitive advantage that is obvious to the client. For instance, being able to tell the client that he’ll get a new working version of his software solution every two weeks is certainly more significant for him then talking to him about continuous integration. For us, the challenge is to find, for each project, how the application of our methods directly meets the different needs of the client and how we will measure them. I believe that this principle can also be applied to all software development teams.

What about providers? Where is their promise?

First of all, who is the supplier? At Pyxis /studio, it’s obvious, since we are providing custom software development services to external clients. However, a client remains a client, whether internal or external. Thus, all software development teams are in fact providers. As a service provider, we must do more than delivering software. We have to make a promise and keep it no matter what. This promise must directly fill the client’s business needs; it must be appealing in order for it to be taken seriously.

The purpose of this post is to repeat the objective of adopting methods that are more Agile, because in some environments, it tends to end up in the shadow of innovative practices. Anyhow, in our environment, we have to remember it daily, because if you forget it, the client will remind us. Agility must be at the service of our clients’ intentions. Nothing less!

Previous post

How many interests and passions can you have at the same time?

Next post

The Silent Leadership Crisis

martin landreville

Martin began his career as a developer. He then focused on client/server development and on building development teams in charge of medium and large scale projects. Furthermore, he provided training on object-oriented programming and client/server development in both Canada and the United States. For the past 15 years, he has been focusing on managing development and application management teams as well as on implementing processes allowing the management of application portfolios.

No Comment

Leave a reply

Your email address will not be published. Required fields are marked *