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.
