Not everyone sees or thinks of things in the same way, and this has become alarmingly obvious when a group of colleagues and others discuss the Agile umbrella of IT methodologies. This is a fundamental risk we need to deal with in order to demonstrate our corporate culture, professional excellence, consistent project approach, and platform for marketing to clients.

In this case, Agile Development, not only are we talking about a set of methodologies under an overarching set of principles, each method has its respective theoretical pros and cons as well as what the professional and individual experiences of our staff have been, with any one or more approaches. No doubt there will be divergent opinions, but that is why we need a core position that we can then at least tweak on a project basis. In our business, experience is everything.

One avenue to aid this problem, might be to have a corporate taxonomy for our company that we all agree on. This would include the definition of terms, how techniques/process relate to one another (or not), and any crossovers. The natural extension would then to be to draw out the "best practices" or some working model that we believe would form the core approach for our company, given the type of projects we typcially undertake in Capital Markets.

Based on other feedback, it sounds like we need a hybrid model that also factors in real client needs as well as the best blended approach that might have a chance of *actually* working on client sites. Either way, we need to have a common language and "corporate view"that we can all adhere to before, during and after client projects. Perhaps a corporate Wiki is what we need.

This is from someone inside our client base who has also tried to sell & manage Agile projects….
The issue with selling (and managing) Agile projects is maintaining the balance between rapid delivery and controls. Traditional projects that businesses are used to following expect a roadmap, milestone dates, dependency dates and anticipated ends with expected functionality. With Agile methodologies, requirements are developed as you go and the end state is less predictable. Keys to success include tightly managing expectations and setting guidelines for each iteration. Selling these types of programs are difficult because they don't fit within the traditional framework - if you can walk through a project lifecycle and build the predictability by setting tight guidelines for estimations, time spent on an iteration, level of detail spent on each component at any given time, building a working end-to-end system albeit "rough" functionality in the first few iterations I think you can demonstrate the benefits of the methodology and mitigate the risks.
Also, large companies and large programs will worry about the forecasting of key dependencies on integration points with other systems. You will need to accout for that as well.
In the end you will create a hybrid traditional/Agile methodology to enable you to gain the speed and agility of rapid iterations with the controls, planning and forethough of integration.

I suspect this will be the first of many entries here, so here goes with the can of worms: How do you sell an agile approach to delivering projects, factoring in the needs/issues/barriers of the folks in the client: PMs, CTOs, vendor mgt, legal, CFOs ?

We can create the nice glossies and presentations talking about this, that and the other benefit of agile methodologies (whichever one or combination you prefer), but there is more to it than this.

My take on it is more to do with the classic ‘Solution Selling’ approach: block & tackle question model whereby there are three main lines of questioning : diagnose, explore impact and visualize capabilities, each with a subset series of questions: open, control, confirm… (btw - this Solution Selling is probably another blog entry for the future). The point is that you need to understand the business problem and pain (or latent pain), and then apply your judgement (and agility) as to how you can solve their problem quickly and effectively. I think this is a pragmatic and experiential sell - you need to know your stuff, but be able to iteratively work out the right approach for the problem - sound familiar ?

Others have blogged about the legal side of things, which I think requires a shifting of the mindset on the side of the clients’ legal/vendor mgt. It almost like you have to disprove the status quo and show that they business NEVER gets it right first time, and that quick meaningful deliverables (production quality) is actually what the business wants.

As I said, this was just to open up the can of worms. Any first hand experience of others in selling agile approaches to non-buyers would be appreciated …

colleague of mine sent this link about styles of management required to run agile projects effectively .. interested to get some opinions on this ..

http://www.mountaingoatsoftware.com/articles/SituationalLeadership.pdf

How horrible are people at managing projects ? Create a plan, let it gather some dust while you do something different , then bin it. This is one of the biggest problems today in IT.

One thing I want to do is to derive some risk management best practices for the types of projects we tend to do in Capital Markets, based on some of the experience out in the marketplace for agile development and other alternate approaches. The other area I want to evolve is the role and experience of our project leads in these projects — are they domain experts, converted PMs, upgraded BAs, maturing techies ….. ? Stay tuned on this one.

From a vendor's perspective, I have found that a formalized status meeting of both sides is key — bi-weekly being a good balance between not intruding on people's time and staying on top of things. The focus is not so much on measurement and control (M&C), but on risk and issue management, as well as general performance feedback. A couple of main reasons, I see, for this: a) it is the client PM's job to do the M&C as well as our own team lead (in terms of his team's tasks), b) I have to trust my guys and not to micro-manage them (not my style anyway), and c) it is the big ticket items, politics and barriers that will screw the project, and not so much the minor implementation or functional details.

That said, too many times project-based consultants get treated like the staff-supplementation folks (and that's not just our people that feel this), resulting in the client PMs (micro) managing the tasks of our folks. This is an uphill battle, but a fight we need to stick to in order to ensure we don't get sucked down a rathole and away from the project in hand.