Caveats of Agile Methodology in Real-life

noreply@blogger.com (Faiq Wyne) — Thu, 14 May 2020 15:47:00 +0000

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.
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/

Program #Your #Brian | Sticking to a #Routine

noreply@blogger.com (Faiq Wyne) — Thu, 02 Jan 2014 12:16:00 +0000

Charles Duhigg has reveled a neurological coding method through his recent blog; "Got a New Year’s Resolution? Here’s how to make it stick!" . Now this is a great way of making yourself stick to a routine and get results. The implementation for this is not only limited to #New-Year resolutions but could also help people with busy schedules and odd routines to cross out an entry on their #To-Do-List; by actually get some things done.

Its like teaching your Kids to do the Right Thing by rewarding them with an extra Bar of #Chocolate or a Pack of #Cookies. Except here we are talking in a broader sense and can use this method on ourselves as well for;

Getting a Professional Certification that we have been planning for the last year
Loosing those extra pounds from the love handles & Thighs

It doesn't Matter if you’re a; Busy #House #Wife / #Mother of 3 Kids managing house chores, or a Corporate Executive having travel plans / back-2-back Tasks & meetings. This flow chart will help you unlock a secret of managing your #Personal & #Professional #Lives.

Do share your comments after adopting this technique!

Personal & Professional Development

Caveats of Agile Methodology in Real-life

Program #Your #Brian | Sticking to a #Routine