10 Jun Agile Customer Projects?
Agile Customer Projects?
There is a strange observation when one wants to apply agile methods in projects for paying customers as profit centers: There is no agile method describing how to do a customer(-facing) project.
OK – some may immediately object here: “Agile is not a method (or family of methods) but a mindset!” Something to be absorbed by the corporate culture, becoming part of the firm’s DNS, or similarly described. Again, an internal thing, more developed for internal initiatives, such as projects.
Whether it is a method or a mindset, or a mindset implemented in form of methods, the word agile has received a sometimes almost religious or ideological character, as the t-shirt in the image shows.Many “agilists” describe the world as black and white, good and bad, agile and waterfall, and hope by insisting on this dichotomy to sell more places in their seminars and sell more books. Leading against an enemy is much easier than solely through common values. One should assume that any black-and-white thinking stands in opposition to agile values, however it is common practice meanwhile in all forms of publication.
Customer Projects with Agile Methods?
Back to the methods. And mindsets. Do they talk about cross-corporate projects at all? The need to address customer projects in agile methods is particularly burning, considering the tendency to agile fixed-price projects. Project management under contract is generally high-risk business for all parties involved, however, combining agile and fixed price comes with existential risks for the contractor.
Apart from the question of profitability and liquidity, there is another task: Developing a dashboard to monitor these key numbers for the project and possibly a portfolio with a multitude of projects for different customers. A contractor must know, where its stands in regards of profitability and outlays for its customers across a portfolio of customer projects. It must know when it needs to send someone rushing to the bank to ask for a credit, and whether it is able to respond to a customer asking for an offer which would require additional outlays to be performed. Even the development of a proposal may be such an outlay.Monitoring cash flow information is as important as monitoring the speed of a car, but also observing the amount of gas left in your tank (or charge in your battery).
Interesting – while know one has developed a software solution for “traditional” project management that helps track profitability and outlays, software for agile approaches is generally even more silent on that. For the latter, it is even more difficult to introduce such a function–most lack just basic cost monitoring functions.
Here is a small selection on agile methods, and what they have in place to do customer projects:
Roles in Scrum are quite simple: A Product Owner, a Scrum Master, and a Developer Team. These roles may work on software or any other kind of product. Another group are Stakeholders, in Scrum strangely defined as the group of people for whom the project is done, and who are interested in the project and the evaluation of its progress steps. In a software project, this commonly includes users and some others.
One may say, that these stakeholders may sit in a customer project on the side of the paying customer. The developer team sits probably on side of a contractor. However, the Scrum master and the product owner’s location remain unclear. Could it be, we need to have two product owners, one on customer side, one on contractor side? Will one Scrum master be enough? And who will take care on contractor side that the project is profitable and that outlays for the customer do not drive the contractor into a state of insolvency?Ensuring profitability of the project and timely payment is not greed, it is need, the lifeblood of the contractor.
Scrum has definitively not been developed for customer projects.
One may discuss, whether Kanban is an agile method at all. Similar methods have been in use in manufacturing shop floors around the world long before the Toyota Production System and in its wake Lean Manufacturing became popular, and with it the name Kanban.
Kanban today stands for an approach to have tangible results repeatedly in form of minimal viable products, that allow for adjustment of the development process based on user feedback, and for early incremental deliveries to provide quick wins to the organization.
However, the paying customer does not show up in the board, and the responsibility to make the customer project a commercial success, on top of the success of the project for the customer, is again not addressed in the method.
SAFe promises scaling of agile methods for large scale applications, and at least the role description promises to allow for more complex project environments.
SAFe is indeed much richer than other agile methods, however, customer projects are still missing. Again, the assumption is, projects are generally performed internally.
The Method Gap
The silence of agile methods on customer projects is astonishing, particularly when one considers that surveys show, that more project managers are in these profit centers than in internal projects, which are generally cost centers (published here).
The Agile Manifesto
The diverse agile methods have in common that they are based on the Agile Manifesto, which has 4 values and 12 principles. Here is the section on the values:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
1.Individuals and interactions over processes and tools
2.Working software over comprehensive documentation
3.Customer collaboration over contract negotiation
4.Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The 3rd value clearly addresses customer projects. However, it seems that no one has developed a method from it. And while one may generally applaud the statement made in the manifesto, implementing that blindly and without consideration by a contractor organization is a direct step on the short way into insolvency.
Agile methods are used in customer projects, however, they have not been made for that. It would be helpful, if such methods would be developed to ensure that all interests are met, including great project results and treatment as a VIP customer for the client, and a commercially viable project for the contractor.
Challenges to develop an agile method for customer-facing projects are described in the second part of the article: Profitability, Liquidity, Agility!
Article written by Oliver F. Lehmann, MSc, ACE, PMP
27th October 2019