Jump to content

Chaitanya Shankar Nemani

Members
  • Posts

    9
  • Joined

  • Last visited

Community Answers

  1. Chaitanya Shankar Nemani's post in Multi-voting was marked as the answer   
    Multi voting is one of the effective methods to refine and select the best amongst many or during the situation of multiple available choices/items/ideas/proposals etc.
    There are 3 benefits of multi voting :-
    1)      Sequencing/Ranking the most important amongst all
    a.       Choosing the first & best top items  
    b.       Selecting what goes first and followed by the next (preferably action items)
    2)      Elimination of least priorities
    3)      Categorization or structuring of items to various buckets/units
     
    Multi voting follows 3 steps (AVR) :-
    Agenda – Clearly defining the purpose of voting, selecting the voters, orienting the procedure of voting
    Voting – Choice Selection, Sequencing, Categorization  (based on Voter’s knowledge & Judgment)
    Result – Evaluation Structuring & Execution
    The motto of this technique is to make good decisions to breed satisfactory result/outcome or to prioritize the sequential best actions.
     
    Though multi voting technique has greater significance, it pushes some limitations :-
    -          If the constraints of voting methods not addressed appropriately
    -          If the Voters Judgement & Analysis failed to select/rank the choices
    -          If the committee don’t re-evaluate the outcomes which have some un important/unfavorable choices
     
    Example :-
    The General Manager of a Business Unit was very happy with the Team’s performance and Business growth. GM want to appreciate for the Teams’ contribution and wanted to gift the team. He used multi voting technique to rank the choices amongst them so that team can feel they are recognized and sense satisfactory rewards.
    GM has good amount of budget to gift more than 1 item as per their choice of reward and has a plan to satisfy the team within the approved limit.
    GM opened the voting for all the team members (30 members)
    Apparel Vouchers – priority choice of 8 votes
    Electronic Gift Items – priority choice of 2 votes
    Team Outing in a resort – priority choice of 7 votes
    Taxable Bonus – priority choice of 10 votes
    5 days’ vacation (Compensated PTO) – priority choice of  3 votes
    In the above voting, team members gave their priority of reward in the below sequence :-
    1st = Taxable Bonus
    2nd = Apparel Vouchers
    3rd = Team Outing in a resort
    4th = 5 days’ vacation (Compensated PTO)
    5th = Electronic Gift Items
     
    Thus, GM found a way to reward the team members with rankings.
     
    Other perspectives in the above example :-
    -          The complexity of voting or number of voting round increases if there is,
    a)       Only 1 item must be selected amongst the extensive or a greater number of choices
    b)      Very less budget. (Requires more refinement through elimination of bottom/least choices)
    c)       Reward choice should be highly satisfied by the team members or missing of their desired choice
    d)      Alternate choices allowed
    -          Teams feedback must be taken even after declaring the choice to do well next time while rewarding them.
  2. Chaitanya Shankar Nemani's post in Technical Debt was marked as the answer   
    The Model of Technical Debt was first coined and defined by Ward Cunningham in the Year 1992.To understand the technical Debt, let us dissect the process of Agile software development in a simple way.

     
    Non-Acceptance is a clear raise of Technical Debit. Some examples are :-
    1)      Unfit or bad design
    2)      Defects in Software
    3)      Insufficient test coverage
    4)      Excessive manual Testing
    5)      Poor Integration and Release Management
    6)      Lack of platform Experience
    These are 3 types of Technical Debt :- 
     
    Type of Technical Debt
    Causes
    Methods to avoid Refactoring in Technical debts
    Naive Technical Debt
    Unclear Methods of execution,
    Accidental,
    Ignorance,
    non-Vigilant
    Providing best design pattern,
    documentation and guidelines
    Unavoidable Technical Debt
    Upgrades,
    Newer versions availability in the market,
    Change requests or features addition in Scope during the mid of development
    Future Proofing the Original Designs,
    Codes should be repeatable & often useful to avoid the huge cost incurrence due to scope change
    Strategic Technical Debt
    Missing proper quality code practices,
    Either refactoring too often than usual,
    Or refactoring entirely is missing
    Including PR & Design Reviews,
    Monitoring Standards,
    Sign Off's at each developmental stage
     
    There are also 4 causes of Technical Debt due to poor Management :-
    1)      Pressure to meet the Deadline
    2)      Trying to falsely Accelerate Velocity
    3)      Fales Myth is that, to Test Less or Avoid Accelerating Velocity
    4)      Debts on Debts – Raise of future Debts due to unsolved present Technical Debts
     
    (Here, Velocity refers to the time taken to develop & deliver an acceptable code/software product with minimum user stories and shortest team size)
    Most of the times in real cases the technical debts cannot be avoided, but if we manage then the technical debt will be always low enough to manage all future product development.
     
     
    Method
    Guidelines
    Manage Accrual of Technical Debt
    Use the best Technical Practices
    Use SCRUM framework
    Simple Design
    Test Driven Deployment
    Continuous Integration
    Automated Testing
    Carefully Managed Refactoring
    Strongly defining "done"
    Understanding the Technical Debt Economics
    Visibility of Technical Debt
    Make it Visible at Business Level
    Make it Visible at Technical Level
    Assign SCRUM Product Owner to balance between Client & Development Team
    Servicing or Repaying the Technical Debt
    Clearly Define Servicing & non-Servicing portions of Technical Debt
    Clean Up the Servicing portion immediately
    If the portion of non-Servicing belongs to: - 
    (1) product Nearing end life
    (2) Throw away Prototype
    (3) Product built for a Short Life
    Then, Negotiate and balance/zero the repay methods with Clients
    For genuine non servicing portion repay the technical Debt incrementally
     
    Guidelines for Agile leaders to decide between longer turnaround time and technical debt
    Importantly, along with Agile, DevOps is another methodology playing its crucial role in balancing the longer lead times while managing minimum Technical Debt. It can be managed in 3 ways :-
    1)      DevOps aims to reduce the time between the application of change in system to change in production
    2)      End to End automation of deployment process while connecting Development, Testing & Operations
    3)      Maintaining High Software Quality and support Automation (i.e., Continuous integration – to detect the defects in early stage and act to fix it)
     


     
    What is an acceptable level of technical debt?
    Most of the times technical debt is not accepted by the development teams however in general the acceptable presence of technical debt is at 5 % or less than 5 %.
     
  3. Chaitanya Shankar Nemani's post in INVEST Guidelines was marked as the answer   
    In Agile methodology, iterative development approach is followed and the planning, development, prototyping and other software development phases may appear multiple times. This is flexible and the changes are detected in early stages to ensure the final launch product is 100% acceptable.
    The Product Owner of any Software Development Project will produce user stories (requirements & functionalities in the form of user stories) before the Development team. The User Stories are developed in INVEST format. This criterion was suggested by Bill Wake.
    Independent | Negotiable | Valuable | Estimable |Small |Testable
    Independent
    Negotiable
    Valuable
    Estimable
    Small
    Testable
    The user story should be always independent and have less coupling with other stories to minimize the complexity of estimating, prioritizing, and planning
    To avoid any kind of conflicts the User Stories should be always open for discussions and are expected to be negotiable. This is to ensure the development of the functionality is acceptable by the customer and "not to waste" the Human Innovation efforts contributed by the developers
    The User stories should be value add to the customer and Valuable to the User.
    The Estimates help in designing and developing of the product and hence the user story should be able to provide estimates. This estimate will further help in formation of size of the stories
    Deliverables are achieved in a sprint when the user stories are smaller. This also helps in developing a component/feature faster
    The developed output based on the user stories should be available in Acceptance/Rejection Criteria. In other words, user stories should be feasible for testing
     
    In my opinion the difficulty arises at “Negotiable”, and this is due to the non-alignment on the value features aspired by the customer/ user with the entire team (Product owner, Scrum Master & Developers Team).
    The discussion should be productive, people should be open minded, experimental to develop a viable product/feature and the alterations to the user stories should be welcomed. During Negotiations Product Owner plays an important role in advancing further development while adding vibrancy and collaboration.
×
×
  • Create New...