How to Create Documentation for Optimal Delivery of Working Software
The second value in the Agile Manifesto re-calibrates our focus on value to be delivered to the business.
The idea here is that the best way to gauge value to the business is through actual Working Software.
Not that there is no value in documentation but rather that the documentation is a means to get to working software, with all the implicit characteristics and quality. It does not amount to business value by itself, but rather supports the delivery in various ways and aspects.
It is not a matter of black or white - "either we are traditional so we focus on precise description of the project deliverables in document artifacts described by specific methodologies, or we're Agile and hence we don't need any documentation!".
It is a matter of the self-organizing team focusing on continuously fine-tuning and evolving their needs for just-enough, and just-in-time, fit-to-purpose artifacts.
The use of these artifacts is fundamentally different now - where they are meant not to convey the information in its entirety as part of the functional hand-offs - from business to BAs, from BAs to architects/designers/developers, from these folks to the testers, etc., etc. These artifacts are meant to support the collaboration happening inside the cross-functional team, and between the team members and other stakeholders.
Contemplate for a second the change in terminology - we're dealing not with business requirements but with user stories. "Stories"?!?!? We're a serious development shop here, we don't have time for stories!" - one could argue. The issue is that written user stories are to support the conversations required for all parties to understand what's to be built (see the concept of 3 C's around user stories).
We should also extend the similar concept to other artifacts - after all, the user stories only describe what we need to build. Not the how! So the team will be preoccupied with architecture, design artifacts, test cases, etc., etc. One should not discount these under the banner - "we're agile, so we don't need these artifacts". Rather, the team should bring these up for discussion and clarify how best to move forward while still covering all the technical aspects of our day to day work.
For example, a tester joining an agile team should have the safety, trust and courage to bring up in a team retrospective the topic of how best to support the testing of working software before it is declared Done, as per the DoD. Part of that discussion, the team can unpack the process to be followed, the pressure of confirming the required quality just-enough (as per the acceptance criteria in the user story), and just-in-time (before the user story at hand can be declared Done!), the tasks required to validate quality. Other questions would be how to line up testing to the user story definition/specification - e.g. some teams define acceptance criteria, spec by example, or simply test definitions as needed/decided with the testers that will execute these tests either manually or automated.
One of the major and relatively common fallacies of "hybrid" models is that the constraints around exact requirements in a BRD are relaxed, but not replaced with the discipline required around the constant communication, collaboration and maintenance of full transparency and clarity of the scope of each user story.
The outcome is missed, misunderstood or flat out wrong implementations that do not meet the expectations of the end-user and/or customer.
Once we realize agility is not a silver bullet/magic wand, but rather a reinstatement of common sense beyond artificial processes/methodologies/constraints back to the real need for the technical folks to really, deeply understand what is required and expected of them, things then fall into place quite nicely. Not to say this is an easy state to achieve - it takes a lot of things to happen concurrently, and a lot of effort and energy to be spent to get there (this is to be detailed in a future post!).
The idea here is that the best way to gauge value to the business is through actual Working Software.
Not that there is no value in documentation but rather that the documentation is a means to get to working software, with all the implicit characteristics and quality. It does not amount to business value by itself, but rather supports the delivery in various ways and aspects.
It is not a matter of black or white - "either we are traditional so we focus on precise description of the project deliverables in document artifacts described by specific methodologies, or we're Agile and hence we don't need any documentation!".
It is a matter of the self-organizing team focusing on continuously fine-tuning and evolving their needs for just-enough, and just-in-time, fit-to-purpose artifacts.
The use of these artifacts is fundamentally different now - where they are meant not to convey the information in its entirety as part of the functional hand-offs - from business to BAs, from BAs to architects/designers/developers, from these folks to the testers, etc., etc. These artifacts are meant to support the collaboration happening inside the cross-functional team, and between the team members and other stakeholders.
Contemplate for a second the change in terminology - we're dealing not with business requirements but with user stories. "Stories"?!?!? We're a serious development shop here, we don't have time for stories!" - one could argue. The issue is that written user stories are to support the conversations required for all parties to understand what's to be built (see the concept of 3 C's around user stories).
We should also extend the similar concept to other artifacts - after all, the user stories only describe what we need to build. Not the how! So the team will be preoccupied with architecture, design artifacts, test cases, etc., etc. One should not discount these under the banner - "we're agile, so we don't need these artifacts". Rather, the team should bring these up for discussion and clarify how best to move forward while still covering all the technical aspects of our day to day work.
For example, a tester joining an agile team should have the safety, trust and courage to bring up in a team retrospective the topic of how best to support the testing of working software before it is declared Done, as per the DoD. Part of that discussion, the team can unpack the process to be followed, the pressure of confirming the required quality just-enough (as per the acceptance criteria in the user story), and just-in-time (before the user story at hand can be declared Done!), the tasks required to validate quality. Other questions would be how to line up testing to the user story definition/specification - e.g. some teams define acceptance criteria, spec by example, or simply test definitions as needed/decided with the testers that will execute these tests either manually or automated.
One of the major and relatively common fallacies of "hybrid" models is that the constraints around exact requirements in a BRD are relaxed, but not replaced with the discipline required around the constant communication, collaboration and maintenance of full transparency and clarity of the scope of each user story.
The outcome is missed, misunderstood or flat out wrong implementations that do not meet the expectations of the end-user and/or customer.
Once we realize agility is not a silver bullet/magic wand, but rather a reinstatement of common sense beyond artificial processes/methodologies/constraints back to the real need for the technical folks to really, deeply understand what is required and expected of them, things then fall into place quite nicely. Not to say this is an easy state to achieve - it takes a lot of things to happen concurrently, and a lot of effort and energy to be spent to get there (this is to be detailed in a future post!).
Comments
Post a Comment