Some key points to consider when its time to decide about the project implementation approach;
- Team Awareness: User Story / Use case and how it's different in structure than a traditional FS.
- Team's Responsibility: Requirements when translated into User Stories / Use Case have to be verified by the entire project team. Dev, QA, UI/UX Designer, BA, Business Architects, Technical Architect. Once the user story is understood, carefully analyzed, and verified to be complete by the entire team then it's submitted for client approval.
Have you ever thought of sharing this responsibility with technical members of the team? - Team Culture: Fail Fast or Blame Fast:
- Blame Fast: Typical Waterfall approach mindset is based on using RS and FS documents as basis for development and if anything goes wrong we pin it on these two artifacts to be at fault.
- Fail Fast: In Agile / Scrum and other frameworks, the common element is the evolution of the idea and rational. In Sprint-1, you will have to work on Use Case/User Stories that may set a happy path or a basic functional flow, without any clear set of validations or edge case definition. During testing, these are explored by failing the build(release), and these observations are documented, analyzed, and prioritized and then added to subsequent iterations / Sprints.
- Note: An important precursor for this mindset is to have recognition of the responsibility of verifying the user stories for completeness.
- Note: An important precursor for this mindset is to have recognition of the responsibility of verifying the user stories for completeness.
- Client Availability: Some time clients are not available due to their core job duties and assignment and cannot be part of the testing (Failing) phase.
The only option is to have a Client BA or internal BA or QA fail the built / release. - Client Readiness: Most time clients without understanding what Agile is and what to expect, set the tone with PMO that they don't want "piece meals" and will be able to test once the release is mature. At this stage, PMO and leadership need to pick a side -
Go with different Agile methodology then scrum or go back to Waterfall (smaller sets). - Hybrid Mess: In order to keep the ball rolling we at times make some process changes to standard of Agile and User stories which have implications like; poor quality and massive iterations and blame game. It is important for everyone to understand how the new hybrid approach will be executed and how the new responsibility matrix will be defined and what will be the acceptable failure rate (fail fast) and its related actions.
- Requirement Management & Traceability: There are various tools and cloud solutions out there to use and TFS (old) DevOps, Jira, Confluence, Asana are some of the names that I have seen business users in love with and each one has its own limitations and usage context.
Business users working daily on e-commerce tickets and enhancement requests routed to internal team members or to vendors use ticketing systems like Jira with a combination of confluence for documenting designs.
Software Vendors working on different projects tend to go with Github / TFS or Azure DevOps and this pick is made based on the ease of build management and what the legacy approach to documentation is (Word documents or Excel sheets) and Teams or Skype for communication. - Starting with Change: At times you have to make the tough call at the beginning of the project and set expectations and demand clearly the level of effort you would need from the team on adaptation and utilizing a tool.
How you pick your tool (Jira + Confluence / Azure DevOps with Teams);
* Who will be swayed to adopt
* Why do they need to change
* How will you help in the learning process
* How will they easily use it
This will decide the level of adoption and fulfillment of responsibility displayed by each team (Business Users or Software Vendor).
My preferred Requirement tools; Microsoft Azure DevOps or Asana were two options that I have been fond off; but this doesn't mean it should sway me away from other tools.
Glossary:
RS: Requirement Specification document
FS: Functional Specification document - with frontend design
Dev: Development Team member
QA: Quality Assurance Engineer
UI/UX Designer: User Interface and User experience designer
Author: https://www.linkedin.com/in/faiqwyne/
