"Perfection is not attainable, but if we chase perfection, we can catch excellence."
For example, coupled with the benefits of a SaaS solution, ENSEK provides a service that incorporates the core Agile principle of working collaboratively with our customers.
This is to release working software, and ultimately business value, as frequently as possible.
To aid us in this process, we have a myriad of tools in our arsenal to help us deliver software-based solutions to business-facing problems.
Throughout this series of posts we'll take a look at some of our Agile approaches and how they enable the fast, efficient release of satisfying functionality for customers.
In recent decades, requirements documents would resemble nothing less than a Dickensian novel; consuming hundreds of pages with their own plot twists and use of incomprehensible language.
Sure, it would be dense in detail and cover every eventuality of the system-to-be but writing something on this scale comes with its flaws:
As you can imagine, the act of discussing, authoring, reviewing, amending and signing-off a 300-page requirements document takes time.
What felt like a world-first, market-breaking idea at project conception will have lost some its momentum and "edge" once the document has finally been signed off.
During these weeks and months before requirements sign-off, your competitors have had time to make their presence known in the market by delivering functionality that rivals your own.
It is said that the conscious, human brain can comprehend a maximum of 3 to 4 things at once - beyond this, details become fuzzy and we lose our ability to comprehend the bigger picture.
With this in mind, picture being handed that 300-page requirements document and being asked by a senior member of your company:
After spending countless hours sifting through the pages of the document and running various scenarios through your mind, you are pressed for answers and nervously you provide them.
Unfortunately, the odds were always against you. It is highly likely your estimation was weeks out, you'd overlooked an important aspect of the system to prioritise first and the removal of "Feature X" rendered the system useless.
By no fault of your own, the human brain struggles to comprehend complexity on that scale.
Contrary to the document-heavy approach to gathering requirements, practitioners of Agile learn that there is a greater value in delivering working software than there is over taking time producing comprehensive documentation.
In light of this, Agile sees Developers coding against bite-size chunks of a specification known as User Stories.
By their very nature, User Stories are independent pieces of functionality that have been broken down to take no more than three to four days to deliver.
To standardise the creation and understanding of User Stories, the industry standard syntax of using As a…I want…So that… is used. Beginning with As a…, we focus upon the type of user; the person who will derive value from the feature being implemented.
Within the middle of our story, we specify the goal of the requirement alongside the So that… statement. Bringing the story to a close, the So that… phrase gives a reason for the feature to be delivered.
Pull this all together, and we get something like the following:
As an Accounts Manager,
I want a way to find any Account by MPRN / MPAN or Account ID,
So that I can view the activity that has been carried out on any given Account
What we now have is a manageable chunk of functionality that can easily be comprehended by all parties involved in its delivery.
We are focusing efforts on visualising, designing and delivering a single component instead of drowning in a sea of pages and witling out the relevant details.
To be asked those same three questions again with regards to this single User Story, we can respond with a lot more certainty:
What was once a 300-page requirements document is now a suite of User Stories; all small in size, easily estimable and comprehensible.
How does everyone know that a feature has been delivered to a suitable standard? Without considering this question, Development Teams are forever at the mercy of:
In light of these pitfalls, there is evidently a need for a way in which we can describe the conditions that are to be fulfilled for a feature to be considered "Done".
Not only that, these conditions need to be captured in a unified language and understood by all stakeholders. Agile sees the Development Team collaboratively working with stakeholders and customers alike to agree upon Acceptance Criteria.
Unlike the User Story, where we want to capture the user-centric problem that is to be solved by the Development Team, Acceptance Criteria promotes solutionising.
Whilst there is undoubtedly value and a secure feeling of familiarity associated with creating a large requirements document, the approach undeniably comes with its flaws.
In a world where your market competitors are constantly nipping at your heels to deliver more, faster, do you have the time to create that perfect requirements document?
Adopting an Agile mindset and utlising the power of bite-size User Stories empowers companies to deliver faster, adapt to change more readily and remain competitive within their marketplace.
You could spend weeks, if not months, writing a lengthy requirements document. Having a bias for action and delivering value frequently from User Stories will lead you down the path of excellence.
Over the next few weeks and months, we’ll be looking into the breakdown of adopting an Agile mindset.