Every week, I continue to receive several email from training departments from companies asking:
We are planning to roll-out Agile to our whole organization next week. Can you please provide me with the following information by end of today:
- Detailed course outline to train the whole organization on Agile.
- Detailed course outline to train our internal trainers on advanced Agile topics.
- Availability of a coach who can work with our internal coaches to roll out Agile to our organization.
Also please let me know how much this is going to cost exactly.
This is worst than a fixed-bid project (fixed-cost, fixed scope & fixed time). At least there you have some context based on the thick-spec they give out.
I usually respond saying:
I apologize in advance, my response might sound a little harsh.
I’m sure you can find few people in India who can provide you with the services that you are looking for. But let me give you some context so you understand the nature of the risk you are taking.
Every week, I get at least one such email from a company who wants to adopt Agile method. They want a pre-packaged courseware (in-person or elearning) that can be rolled out to all their employees. And they hope they can get a good coach in India who can guide their organization.
Personally I always advice companies not to go down this road. Very few companies pay attention to my advice. Others go ahead with this approach. They shop around for the best deal they can get. They hire an “Agile” training company. Invest Lakhs of Rs in training. Spent a lot of energy and effort in trying to make this work. Take a productivity hit on projects and so on. And after 6 – 12 months they came back saying: “This Agile thing does not work. We invested so much, but there is no improvement. In fact our organization is worse off“.
Let me explain why this is the most inefficient way to invest money, time and effort. First and foremost, one needs to understand that Agile is not a thing that one can learn in a 2-5 day class. Agile is a very broad & deep topic. Its not about doing a set of practices, nor is it just a process change, its a cultural, organizational change. It changes (or at least challenges) fundamentally how people build software.
Without studying an organization, their pain points, nature of their work, aspirations of the team members, other constraints under which they operate, etc. .i.e. without the knowledge of the organizational context, any training done on subjects like this, IMHO will do more harm than good. Any general, prescriptive advice on this subject is fundamentally wrong. Any overview session is too vague for people to relate to. Guidance on such matters has to be grounded in contextual land.
I touch on some of these points in the following presentation:
Before going ahead with this window shopping approach, my suggestion would be, get a practitioner to spend a couple of days in your organization, do a small assessment of the situation on ground, collaboratively put a small roadmap together about how you want to handle this change, based on that figure out what training (if any) is required, understand how would you position this to the management and the development teams and so on.
BTW, if your organization has excess money in their bank account and have a few years to waste, I can send you a few course outlines, some profiles of trainings & coaches and their per day rates. I have a dozen of those.