"Perfection is not attainable, but if we chase perfection, we can catch excellence."
-Vince Lombardi
Using technology to solve business problems isn't that difficult.
With enough time and effort, anything is achievable. To remain competitive within the marketplace however, time is quite often not on your side and if you're going to assert an effort, how do you know it's being invested in the right thing?
It is due to these dilemmas that more and more companies are embracing an Agile mindset. Not only to ensure they are building "it" right but building the right "it".
We too have been striving to adopt Agile ways of working.
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.
How consuming a 300-page requirements document could be considered a challenge
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:
Requirements go stale before delivery
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.
Document complexity inhibits comprehension
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:
- How long will it take to deliver this project?
- Which order should we build the individual components of the system to ensure an efficient delivery?
- If we decide to remove "Feature X" from the final requirements, what impact would it have on the rest of the system?
Providing timelines and promises to requirements documents
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.
Agile Developers break requirements down into User Stories
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.
As with any good story, there is a beginning, middle and end to User Stories
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
Working with manageable functionality
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:
- "I believe it will take X number of hours to deliver"
- "This feature is independent of any other aspect of the system. Technically we can start work on it as soon as you wish, based upon your priorities and when you wish to realise the business value associated with it"
- "Give me half an hour please. I just want to review the User Stories that relate to this particular feature and then I'll let you know"
What was once a 300-page requirements document is now a suite of User Stories; all small in size, easily estimable and comprehensible.
Understanding the Acceptance Criteria and expectations
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:
- QA churn. Constantly having work returned to them from Testers, Product Owners and stakeholders as new functionality doesn’t meet expectations or assumptions
- Overengineering solutions. Developers will happily carry on coding until the cows come home; it's in their nature to do what they enjoy and deliver the perfect solution. Perfection, however, is the enemy of productivity. We need to ensure business value is released as soon as possible
- Ambiguity. Business domains are riddled with acronyms and in-house terminology. What Client A may refer to "Widget X", Client B will call "Gizmo C". When Developers are being tasked with delivering solutions to complex business problems, uncertainty of what the customer is actually asking for can burn valuable hours and take them down dead-end paths
How do we know when something is complete?
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.
The benefits of adopting an agile mindset, compared to requirements documents
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.
