4 reasons why pushing Agile as a consultant is a hard(er) job

This is a continuation post to my previous post Agile is not TDD and also somewhat a reply to my good friend @Hammad Rajjoub and his post Agile Discussion – Part 1 of X.

In this post, I’d like to explain why I think it is much harder for consultancy to push Agile to clients without significant effort of raising client’s awareness and more importantly, trust.

1. Meta-Proposal

In the consulting industry, projects are won by proposals and pitch. (Potential) clients typically would like to see what can be build and a dollar figure next to it for total cost of ownership for the next x years.

I think there are 2 ways of looking at this. From the sales perspective, it’s a sales pitch, the key is to define what is included in the proposal and what are not.

From the Lean perspective, it’s a potential waste. Why estimate and plan something that hasn’t been fully worked out yet?

The response to the RFP (Request for Proposal) document will be of little value, unless the document are indeed in the form of User Stories (backlog), so that the consultant can invest their time to further dig up enough context to work out estimates for each of the user stories with the (potential) dev team.

2. The lack of upfront scope and its impact to cost

Continuation on what’s stated on point 1. Is it a real up front scope or a sales pitch? How would you cost it? Are they likely to change in the length of the project?

Agile tend to naturally work in a ‘time and material’ model. I dare to say it works best when executed as a staff augmentation model.

The consultant need to be infused with the business. Looking the problem from their angle. The development cost are therefore manageable by the number of resources allocated to the length of the project, and the number of sprints the clients want to do.

3. ‘Go and build it for me’ attitude

As what I’ve said before. The consultant need to be infused with the business. This also implies business willingness to allow time and more importantly be open and expose their core values to outsiders.

4. Agile invest on people, what happen when the consultants leave?

Unlike other process-heavy methodology (like CMMI level x), Agile invest on the people rather than the processes. It takes time for an agile team to be highly productive. Teething issues will arise, and it’s no surprise that most agile team will not reach its peak until the first 6 months. What happen when a consultant need to leave? Being repurposed to other project? Or even worse, when the whole team needs to leave?

What I’ve seen it work on my previous projects is to blend the consultant team with internal development. If the client are willing to invest on the people, let’s spend some of the investment on their ‘own’ resources. This allows further growth even when the consultant leaves the building.

What’s your experience as a consultant? Do you think Agile works for you?