Jump to content

Chaitanya Shankar Nemani

  • Posts

  • Joined

  • Last visited

  • Days Won


Community Answers

  1. Chaitanya Shankar Nemani's post in Yamazumi Chart was marked as the answer   
    About Yamazumi Chart
    In general, Yamazumi word was originated from Japanese, and it means “to stack up”.
    In the world of Lean & Six Sigma, the projected process data is seen as stack bar chart (Yamazumi) to understand the process pain parts (or) areas observed slowness (or) for the visibility of unusual steps (or) non-value adding steps.
    Yamazumi charts helps in showing a way to identify unwanted activities. (or) It's another tool to enhance the waste elimination in the process.
    Explanation of Yamazumi Chart with an Example
    In an Organization, The Digital Products Unit, “Director” has raised a concern with the "Vice President" of Procurement Shared Services about the several delays in order delivery by the suppliers. Specially with IT categories.
    Surprising part is that, the budget/cost are getting approved immediately when the scope of work and planning are in place. Few orders are getting On time, and some are delayed for months, and it is impacting the production. Digital unit doesn’t have visibility of any activities after the cost approval of the project. Eventually this has become a bigger complaint on delayed orders.
    VP of Procurement wanted to have a general body meeting with the Director, Procurement Managers, and the Quality Manager to address the issue and narrate the current state of process and possibilities/various areas to improve the efficiency of the process from the IT Need to Delivery.
    Hence, the VP requested the quality manager to look for the historic events of all the procurement transactions with respect to IT needs. Also advised to produce an “Eloquent 1 Page Visualization” of the data with issues.
    The Quality Manager after collecting the historic data, has produced below Yamazumi Chart, and found interesting investigations about the delays of some orders.

    Based on Yamazumi Chart in the general body meeting, below observations were discussed: -
    -        Order delays are only with New Suppliers.
    -       Number of days processing and progressing each step varies for different categories of IT needs i.e. Application Development has less turnaround when compared to Infrastructure & other categories.
    -       Adequate time is required to Securely run RFP/RFQ with potential new suppliers, organizing DEMO’s and selecting the right supplier to fulfil the IT need.
    -       Various Approvals (legal, supplier addition, background checks) are necessary to onboard new supplier to the Company to ensure/avoid/zero any kind of risks & complications.
    Meeting ended with: - The Identified Red One’s in Yamazumi Chart were shortlisted for further study and process standardization.
    The Director and the VP has appreciated the quality Manager for this kind of visualization and enlightening the process activities, days it took at each phase, for various categories with New & Existing Suppliers.
    Thus, The Yamazumi Chart has helped in projecting full picture of IT Procurement from “Needs to Delivery” of all categories.
    Supplementary Details: -
    In the recent days it is observed that the analysis, investigations & projections are expected instantaneously with availability of wide varieties of data.
    Here, Tableau is very helpful in providing the Stack charts/ Yamazumi Charts.
    Below is a sample picture extracted from Tableau depicting the various sales of IT brands and their price categories at various regions.

  2. 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.
  3. 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
    Methods to avoid Refactoring in Technical debts
    Naive Technical Debt
    Unclear Methods of execution,
    Providing best design pattern,
    documentation and guidelines
    Unavoidable Technical Debt
    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.
    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 %.
  4. 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
    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...