Why my agile transformation is not working?

As a technology manager many times I have worked with teams who are in the process of agile transformation (who is not nowadays) and nothing seems to be working correctly. The sprints get delayed, sought out features get dropped, story point estimation are always wrong, team never ships a working product that makes the customer happy, everybody is frustrated and you can sense an overall apathy towards agile and many old timers commenting this is just another fad and it will be business as usual.  I bet many of you have similar experiences.
Recently in one of the places where I contract, I had a discussion with one of the management team member on the need for proper documentation this case for an API framework the team is building, proudly say "we do not create detailed design documents because we are extremely agile". When I pressed on with the need for a product vision and a the need for a design path for the team his response was since we are agile we create instant solutions (aka seat of the pants) that need not be thought through. I was stunned by the authority and confidence with which the statements were made by this person.
Knowing the team fully and its working where there is no release cadence , where delivering a working software to the client every-time is a monumental effort and there is seldom incremental business value between each iterations, I had no idea how this belief of what is being practiced conforms to agile philosophy gotten into this this person. Something is amiss!.
If 'seat of the pants solution and lack of documentation" is construed as agile then I feel that the agile community has somehow lost its message to the target audience. In this case the senior member of the team does not understand that the agile principle of  giving importance to working software rather than comprehensive documentation involves first building a team that is self aware about producing value in each iteration so that they know what needs to be done. This person does not get the fundamental understanding that the agile recommendation of not needing comprehensive documentation is valid only when the team has an open, transparent, 360 degree communication channels all across the board. This person does not understand that you can only have minimal documentation if and when all team members are working together with close cooperation building incremental value that can be qualifies and quantified in each iteration. In a situation where every information is filtered by layers of organizational entities, where the team and stake holders have no idea of what is coming next, where there is no articulated product vision it is a folly to take umbrage under agile manifesto  and proclaim we are transforming ourselves to an agile organization. This is a specific example I am writing about but there are many such instances where agile is used as an excuse for shirking basic responsibilities of software development.

I always felt that agile transformation is an egalitarian endeavor where team members are stratified by responsibilities and not by authority, the goal is creation of value that has meaning to the team and the customer. Unfortunately lots of companies have embarked on a path of employing agile coaches, buying Rally or Version One, convert requirements to story points verbatim and build software that follows the same path of waterfall but use agile as an excuse to ditch waterfall requirements that was a pain in the first place such as having a detailed design document, development plan, test plan etc.
This leaves team members wondering what is this agile transformation is all about, for nothing has improved and in fact they find that they are in no better position than they were previously and in many cases doing one week and two week iterations in impossible conditions leading them to hate the agile transformation being implemented.
For agile transformation be successful, I feel there has to be a decoupling effect on our minds that agile transformation is not a process driven endeavor but a path driven effort with self learning and self organizing as keystone principles. The team and management needs to embark on a journey to a team strongly rooted in fundamentals and build an environment where there is room for deliberation and decisiveness. Bringing an agile consulting firm or a coach with one week training and buying a agile process software like Rally etc is not going to help you there. What is needed is a basic structure for delivery and execution in the first place. I would even go to the extent of recommending that a team attempting agile transformation should first come out on top of the waterfall process they are following now. The only bottleneck on the waterfall process for the organization should be the time to market factor all other fundamentals of a SDLC process should be working successfully, with out that ability to execute the fundamentals your agile transformation is not going to work.

How to help your business be found on local search using Citations

Recently I read a white paper by The Search Agency a leading online search technology solution provider on using Google Places for small business advertising. There were lots of intersting tips in the white paper on improving local search ranking in Google Places and I found the paragraph on Ciations very interesting to expand and write a post about it.

The post is published in Marketing Matters a site from Dex One for helping small businesses market themsleves.

Check out the post here and let me know your thoughts..

User Story Workshop for Product Managers

In Agile Product Management , when product owners gets introduced to Scrum frame work, most of the time they have difficulty in transitioning from the detailed requirements world of traditional PMI world to the nebulous world of User Stories that are not really complete. But once they get coached on the fundamentals of what a User Story is and how to write them, their natural skill as a product manager accelerates their expertise on writing effective user stories.

Last week I had such an opportunity to conduct coaching sessions for the product owners in our team on writing effective user stories.

User Story Acceptance Criteria: The Art of Satisficing and Bounded Rationality

How many times as a product owner you have heard the developers complining about the user stories not being exhaustive, how many times as a product owner you have faced the situation where you feel the delivered solution is not complete and when you ask the development team what happened? they reply, "we did not get a complete acceptance criteria".