Sometimes asking the right question is enough

Very often I see people falling into a common trap - of trying to solve problems based on personal understanding and interpretation of the problem. Its difficult to put this thought in the right perspective but I will still try....being a consultant for most part of my career I have experienced how easy it is to sit far and away from the problem and give a rational opinion on some things.One of the reasons, I believe, a consultant can do that is because he does not have any vested interest in the success or failure of the project. There are no budgets to manage, there are no political games to be followed, there are no egos to be satisfied and there are no pink slips to be handed out. But one big trap of being a consultant is that you are expected to always provide a solution/answer to a given situation. And this is exactly what I think is not fair. Sometime even asking the right questions is enough. Many times i have seen that a  consultant looks at a situation , analyzes the possible causes, looks at available options to the problem and thats it ...he has a list of potential solutions. But I think that many times even though we do our usual checks to come to a conclusion we should let the client/customer define the solution and pick the options. Presenting the problem without mentioning the available potential solutions is very useful way of driving the customer to solve their issues.Objectively appreciating the situation and constraints is one thing and providing a solution is another. Many times in our capacity we should not really do both the things . Very often we should guide the customer to make a decision and in fact sometimes not even provide him with the answers....Make the problem so obvious to the customer that he chooses the most appropriate solution. This helps in 1) giving customer the authority and confidence that they have made a correct decision and 2 ) let them carry the ownership of the decision and its implementation. Its very easy to provide solution and then help client implement it but then what we are doing is creating / making ourselves as accountable and responsible for customers actions. As long as customer holds consultants accountable for their actions it seems fine but execution should not be a responsibility of the Consultant, in my opinion.

crAgile - Now I know what my first iteration manager meant by that

Currently I am working at a client site which basically invited Thoughtworks consultant to help them improve their testing area as they beleived that they need to "agile up" their testing department / practices. Pretty common concern thrown by clients..."Seem QA needs to be Tidied up"...This is not the first time I have come to the conclusion that usually when an organization wants its testing dept / testing practices to be beefed up its actually something else that is a root cause of the problem. But since Testing usually throws a spotliglight on the problem it itself is considered a problem instead.The place I am working currently we are trying to implement , encourage adoption and preach that developer write acceptance tests for the cards they develop. Needless to say this seems to be the first step of grief for the development team.Initially I was very disappointed that developers had to be justified the need for doing so but really the issue was that the team was being asked to do points driven development. This is the worst form of Agile implementation I have come across yet...It essentially means that no matter what the capacity of your team is in terms of velocity the team still has to complete X number of points every iteration. If that means starting to work before the cards are completely elaborate or if devs have to skip unit tests or acceptance test so be it. As long as by doing so team is able to meet the points already decided by higher ups. I have started calling is "Waterfall in iterations". Given this deadline /drawback there is absolutely no incentive for the devs/BA to write the acceptance tests such that they become a apart of the done criteria. Infact if the estimate on  a card increases if the acceptance cases have to be written it is totally OK to skip that. I have seen many twists of agile principles in the name of agile itself but this twist is absolutely pathetic.I am sure this is just the tip of the iceberg and I will see many more such twists on this project but the start itself is so nightmarish I wonder how bad its going to get further down the road. This brings me to the title of the post crAgile. My first iteration manager used a term called crAgile for all such twisted implementation of Agile projects. This is certainly one of the best crAgile I have come across so far :)