The last couple of years has seen a wholesale shift in development methodologies among the Fortune 1000 companies from Waterfall to Agile. It is not an exaggeration to say that the Agile revolution that has been brewing in small companies, startups and web companies for the last decade and a half has finally arrived in the development shops of mainstream corporate America. At ArgonDigital we experience this shift daily. Almost all of our current customer base has made a shift to Agile in the last year or so. And every conversation I have been in, with prospective customers in the same time period, has been around moving to Agile.
As a practicing consultant, I get to experience this transition first hand. I work on a team for a customer who is transitioning to Agile after spending the last two and a half decades (yes you read that correctly, decades) as a Waterfall shop. And every team we interface with is making the exact same transition as we are. The old staples of the Waterfall world like the Business Requirements Documents, Software Requirements Specifications and Functional Specification Documents have been replaced with Agile Requirements Documents, Epic Stories, Backlogs and User Stories.
Of all the artifacts created to assist the Agile development process, the one that stands out above all others is the User Story. User Stories are ubiquitous. They are on everyone’s lips. Project Managers want to know when the stories will be ready for a sprint, analysts are writing them, scrum masters and product owners are prioritizing them, developers are consuming them and testers are desperately trying to understand them so that they can evaluate what is being delivered to them. User Stories have replaced requirements as the lingua franca of the development community.
As this transition takes place from traditional requirements statements to User Stories and Acceptance Criteria, there is one fundamental misunderstanding of User Stories that I see in almost every team I have seen in action. User Stories are treated exactly like requirement statements by the people creating and consuming them. Stories are written, loaded to the requirements management system, prioritized, pulled for development, tasks defined and taken up for work. All of this is as would be expected in any Agile workflow. But there is one thing that is consistently given short shift is a critical and integral part of the User Story – the conversation.
A User Story is at its heart, a promise to have a conversation. The conversation is what gives context to the story and the acceptance criteria. The conversation takes the place of the detailed requirements statements that were created to support Waterfall development efforts. The compartmentalized nature of Waterfall development necessitated very detailed requirement statements that were the means of communicating at a granular level exactly what needed to be built. In Agile, we eschew the effort it takes to create detailed requirements and replace it with just in time communication that clarifies for the developers the pieces that are not explicitly detailed in the User Story. If these conversations are not taking place continuously throughout the development process, then Agile will not work as well as expected.
This is part of the growing pains of shifting to Agile for traditional Waterfall shops. Continuous ongoing conversations about the software being built is simply not part of the DNA of these organizations. Requests for clarification are misconstrued as criticisms of the quality of the User Stories written by the analyst. This leads to a desire to write more ‘detailed’ User Stories. Similarly offers to explain the User Stories are misunderstood by development as an inability to understand the requirements implied in the User Story or blamed as poorly written documents. Conversations are an integral part of the User Story without which the benefits of shifting to Agile cannot be realized.
Leaders who are at the forefront of transforming their organizations’ development practices by implementing Agile must pay careful attention to this problem and ensure it is addressed. Everyone must understand that conversations must happen and are an inherent part of a User Story. There must be no stigma associated with having to explain a User Story or asking for clarification. This is expected behavior and not an indication of incompetence on the part of either the analyst or the developer. These conversations should be encouraged and people must be rewarded for engaging in them. It is also essential to train people on how to have these conversations in a productive manner around the User Stories. An inordinate amount of time is spent on training people to write ‘good’ User Stories but almost none on how to have conversations around them. It is impossible to write User Stories that do not need conversations. Simply put, a conversation is the most important part of a User Story.
