Jump to content

Chaitanya Shankar Nemani

  • Posts

  • Joined

  • Last visited

Everything posted by Chaitanya Shankar Nemani

  1. 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. 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. A LSS Project Leader follows DMAIC framework to accomplish improvement projects. Define Measure Analyze Improve Control John Paul Kotter is the “Konosuke Matsushita” Professor in the division of Leadership & Emeritus, at the Harvard Business School. He is an author and also the founder of Kotter International, a management consulting firm based in Seattle and Boston. He is one of the best thought leader in business, leadership, and change. While writing a book namely, In Leading Change (1996), and later in The Heart of Change (2002), Kotter defines an eight-stage model of successful change. The eight stages or rather steps include: - 1. Create sense of Urgency – Discuss about the problem and communicate the urgency to solve it 2. Build Guiding Coalition –Identify the supporting team members to obtain the data and start measuring the problem 3. Form a Strategic Vision – Analyze the risks & challenges. This sow the seeds of achievable vision. 4. Enlist Vision Buy-in and form an Army – Start thinking “how” the future model eliminates the current problem and form a solution building team. 5. Enable Actions by removing barriers – Understand the barriers and fix it early before advancing. 6. Generate Short Term Wins – See the low hanging fruits and quick fix them. 7. Sustain Acceleration – Stay motivated with quick fixes and accelerate the achievements of long-term goals. 8. Institute changes – Communicate the improved/improving changes to the entire organization and bring the culture of continuous improvement. Below picture demonstrates, how the Kotter's 8 steps change management process fits at various DMAIC stages :-
  4. Data visualization contains graphical representation of the data. This is most usual way of addressing the progress or performance of a process or a unit or a whole CoE. They are presented in the form of Time-series, Ranking, Part to whole, Deviation, Frequency distribution, Correlation, Nominal Comparison, Geographic/Geospatial. Power BI & Tableau are the 2 most used tools for data visualization. Power BI is Microsoft Product, and the Tableau was an independent provider, later acquired by the Salesforce (2019). Feature Tableau Power BI Volume High data processing capacity with high performance Limited data processing Good for Whole Visualization Data Points Visuals Support Excellent Customer Service Support Customer Support provided to paid Users and the response delayed for free users Learning Requires some understanding and time consuming in learning the Tableau because of its vastness Very easy to learn. Mostly drag & drops functions Reporting Embedded reporting is tough Embedded reporting is easier compared to Tableau Cost High Low compared to Tableau AI Integration Difficult or not possible to integrate AI, though there is provisioning of Python & R Programming Completely Provisioned to integrate with Python & R programming to breed AI models Data Size Unlimited data file Size Acceptance & Processing Data file acceptance can be 1 GB (max). Power BI cannot process beyond it. Storage Server Storage Designed for reporting and analytical visuals, no storage provisioned
  5. Code Refracting is all about the improving or simplifying the designs of existing codes or code components without changing/impacting any external functional behavior. Usually, team does the refactoring in the below instances :- 1) Slicing a large technique to simpler & smaller focused techniques 2) Rewriting the names of variables & parameters to make it clearer & more meaningful 3) Moving the responsibilities towards more appropriate of class or division from the existing one 4) Introducing new interfaces or changing exiting interfaces Refactoring is also an important principal technique for controlling technical debt. These are 3 types 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 Additionally, there are 3 more methods to avoid technical debit which also avoids code refactoring -Managing the accrual of technical debt by using good technical practices -Making the technical debt visible by using a defect-tracking system -Servicing (repaying) technical debt by remodeling the infrastructure and code development practices often as per the latest standards Code Refactoring cannot be 100 % avoided. It will be part of Software development. However, those who follows the industry expertise, proves on its minimizing and always stands first at producing the acceptable software product.
  6. Visual Management is one of the lean strategies used specifically as “See to Act”. Here, “Act” can be any action or a response to the visuals (to Stop, Adjust, Inspect, Direct/Instruct, Locate – Finding/Keeping things at right place, etc.). Visual Control is derived from Visual Management, and it is to ensure the correctness of the action based on the Visuals. In the below items, we can see the indicators and their control mechanism description or the purpose it serves to act appropriately. Indicator Control Mechanism Description Color Coding Status Communication/Process Performance Measurement Sign Boards & Signals Commute Directions (halt, go & navigate) Markers & Logos Locate/Place Items Tags Conditioned Items Andon Flag To Stop until further notice (or to work after rectification) Floor Lining To avoid Slip Trip & Fall Placing the visual indicators are just not enough to control the events/outcomes (or to stop undesirable). To have the visual control mechanism function well, the users/viewers/everyone must be oriented by the premises expert about the indicators, and they must be familiarized about the right actions to be taken for the displayed indicators & changes.
  7. 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.
  8. In Human Centered Design, understanding/perceiving the human emotional experience is the core element to discover a product or solution or a service. Many times, the Product/Solution designers are not hesitant to attend themselves living in the problem along with the people. This will help them to design “exactly what is needed and acceptable”. Most of us know about the history of Uber which was successful because of its human centered design. Let’s look at another example of an individual from an Indian Middle class family, born and brought up from remote areas of the country. As not much accessible to school, but skilled to code logically and likes to travel. Discovery time began between 17 to 20 years of age when he stayed in more than 100 hotels, guest houses and tasted various foods. A college drop out and just twenty turned entered the young entrepreneur’s club in the country. He is Ritesh Agarwal founder of OYO Rooms. Through OYO he offered good quality and affordable budget hotels. OYO presence is more than 23000+ hotels across 800+ cities in 18+ countries around the world. Ritesh Agarwal’s concept is a kind of Human Centered Design. Empathy ignites the creators to make “exactly what is needed and acceptable” with a deep desire to do meaningful. “Empathizing” what others feel or need and “Desire” to do something meaningful to solve, leads to Human centered Design.
  9. Making an estimate before beginning to work on any kind of project/projects is the priority of the respective project leads or managers. Estimate is just not to throw the count instead it is a calculative homework to result in accurate estimations. Interestingly some techniques are available to perform these estimations (Cost Scope Time etc.). The prominent one is “3 point estimate” due to its simplicity & uniqueness. These are often said OPR, where O “stands for “Optimistic Estimate”, P as “Pessimistic Estimate” and R as “Realistic Estimate” (or M as Most Realistic), respectively. While analyzing we may find some aspects which helps to accomplish in shortest time or lower cost. Also, some lead to longer duration and higher cost. The estimate leading to shortest or lower achievable component is an Optimistic Estimate and the longer or higher one is a Pessimistic Estimate. Realistic Estimate is resulted when Optimistic & Pessimistic estimates are averaged. Alternatively, estimations can also be concluded using graphical or visual diagrams such as PERT (Program Evaluation & Review Technique). 3 Point Estimation is part of PERT. Again, the objective of this technique as well is to find the way to accomplish the tasks in shortest duration with lower cost. For example, to construct a 1 km road, the lowest pricing will be around 5 Crore rupees and the maximum cost will be around 7 Crore rupees. 3 Point Estimate :- O = 5 P = 7 R = 5+7/2 = 6.5 (or M = 6.5) Realistic Estimation to construct a 1 km road is 6.5 Crores. PERT Estimate :- (O+4M+P/6) 5+(4*6.5)+7/6 = 6.33 PERT Estimation to construct a 1 km road is 6.33 Crores.
  • Create New...