So far, we have been advocating the possibility and need of executing software development projects following Agile methods and on a fixed fee agreement. The benefits of Agile programming are well understood, as well as the need of adopting other good practices. Running project in fixed fee is also a consideration to provide greater comfort and de-risk client's financial commitments. Now the question comes, is the client really aware of Agile programming?
Like any other successful projects, Agile methods too require some good deal of client commitments for successful completion. Quite often, the system implementers jump into the Agile bandwagon with a promise of making client's life simpler (read lazier). As a result, when the client contacts are asked to provide their inputs frequently, at times everyday, all hell breaks loose. Similarly, clients are promised with frequent delivery by virtue of continuous integration (read on demand delivery). Sellers, in quest of selling the work, commit all the good things that Agile can bring on the table without uttering a single word on what it takes for a client to achieve that. Once the job is sold, the programmers land on ground, and starts realizing amount of damage been done.
The big ticket question is: how to educate the client on Agile methods? Seasoned consultants know the art of educating their clients with new tools, techniques, and practices; and those still hold good here. Client education cannot be performed though a sales pitch, cannot be performed if it doesn't bring any value to the client. The system implementer needs to first assess whether Agile method is really going to bring any incremental benefits to the client for the project under consideration. If not, which is likely to be a regular instance, let's not try to push for Agile.
Secondly, the involvement need of the client contacts are also to be evaluated. Agile method requires a lot of time and effort commitment from the client contacts, all those hours are to be justified. The point to remember here, hours from the client are not free. Those too get added to the project cost. The system implementer may not need to bear that cost directly, but it's a direct cost to the client for that particular project. So, if a good part of the project progress can be achieved by minimal client involvement, let's not plan for Agile methods there. Instead, taking a monolithic project plan with built-in Agile sub-phases may work wonders here.
Also, the involvement in multiple tiers is important. The traditional project management processes include a need to define the escalation path. In the era of Agile, that is still relevant. When it comes to managing the stakeholders with a varied degree of influences, it may not make sense to bring all of them into a single scrum, that too everyday. Instead, organize multiple scrum-of-scrums. Participants of each such scrum-of-scrums are to be carefully chosen. Also, the format of the scrum-of-scrums may require tailoring. By definition, each participant of the scrum-of-scrums are expected to be represent their own scrum teams. Here, in some cases, that will not hold true. Some of the participants will not be part of any scrum team, rather they will bring their organizational insights to enrich the other participants, increase their own awareness on the project progress, and in certain instances become more aware of the practices of Agile programming.
At this point, the Agilists (and its proponents) will strongly disagree with me, I swear. Scrum cannot be tailored, tailor your organization to scrum; is their dictum. I would humbly submit that I disagree. Organizations cannot change to fit itself into something prepared externally. Organizations can only adopt, articulate, and assimilate that. During this course of adoption organization tailors the external ingredient to fit with it, and over time of adoption it changes itself too, primarily to respond to the market forces. So, tailoring of the format is inevitable, if required, to be done for each client, for each project. During the course of tailoring, involvement of the client is essential. That's the learning point for a client highest intensity.
To summarize, emphasize the benefits of Agile programming with its cost while selling a job to the client. Perform proper assessment to see whether Agile is really needed, if not, don't hesitate to discard it. If you adopt Agile programming for a client project, ensure that right kind of client awareness and commitments are there.
