top
Sort by :

Agile Contracts or Agile Statement of Work - Must-Haves

In IT with the Agile boom, everyone wants to get into Agile Development. Be it the customers, organizations, and even developers, everyone wants to get into Agile Development. Customers want to follow Agile so that they can get to see the Product early and the changes can be incorporated without any cost. In other words, they want fixed price, variable scope. But, organizations need to be cautious in order to define how much variable scope is included in contract clauses. Organizations want to keep themselves up-to-date and follow Western culture blindly. Statements like these often come “Everyone is going Agile, why aren’t we yet?” They have to understand, every environment, every team, and every client is different. We just cannot keep on copying everyone else. Developers, of course, will have “Agile” word in their resumes which will help them grow and find jobs.   The number of agile contracts [by govt] amounts to a coat of agile paint on a giant waterfall HT @RachelProsser https://t.co/IEOPRRFFM5 — (((Dave Moskovitz))) (@davemosk) October 9, 2017 So, in desperation, companies (small or medium organizations) ONLY follow what customers say. What they end up is – with an agreement that has clauses of Waterfall model and they tell clients that we will follow Agile. These clauses might be like having fixed scope or fixed price which will be given by end of phase like requirement gathering or planning or UAT done etc. But we forget, that in Agile, every iteration has these phases and we should be targeting the contract in such a manner that it is win-win for both the parties at end of every iteration. Below figure distinguishes between the Traditional Pyramid and Agile Pyramid. Traditional pyramid has fixed scope while Agile one has the Estimated scope, to be considered while negotiating the contract.   Lawyers and Sales team need to be taught that if we are following Agile, we need to follow the terms and conditions for Agile contracting and not of Waterfall.   #agile contracts, however, are not the silver bullet: few of them delivered the right client benefits. @WC_REFSQ pic.twitter.com/8MSb0okXQ7 — Samuel Fricker (@samuelfricker) March 15, 2016 Apart from including changes like, Product Backlog (instead of BRD), Key roles in Project, the Agile methodology, below are few MUST HAVES that should be mentioned clearly in the contracts and need to be communicated to the customers, during the contract negotiation: 1. Pricing Model: It is unrealistic to expect any development project or product, to be delivered on a Fixed price basis. We all know that there will ALWAYS be changes in scope which will affect the original price. If the customer has a fixed budget, this can be managed within an Agile project by focusing on the development of high-priority items first, allowing the Customer to remove low-priority items from scope. All such issues must be taken into account when negotiating the Pricing Model for the project. Below are a few potential pricing models: a. Fixed Price per user story – Be cautious here, too long user stories need to be broken up.  b. Fixed Price per iteration – Make sure that all iterations range to similar story points. Remember, we have to create win-win for both parties. c. Fixed Price for the agreed number of features – Describe the feature well in advance. d. Time & Material (our favorite) - Customer continues to pay during an agreed-upon time period. The customer pays till a point he sees value being added. In case he sees that no value is being added, the customer stops paying and the contract ends. 2.Spikes for high-risk elements: In case the project has specific, high risk elements, e.g. technical challenges or business issues that are absolutely first timers or have never been solved before, these MUST be communicated up-front. Such Programming spikes where we attack only the riskiest coding in the project must be included in the contract. These spikes give customers a realistic view of the project ahead for the least amount of money and avoid conditions of "Fast failure". The main goal here is to uncover any weaknesses in the proposed development and hence be ready with the new plan and strategy in order to make the project successful. 3. Define Scope, but no need to mention delivery items: Product backlog defined at the high level MUST be attached to the contract as one of the appendices. Though the scope is variable and will change during the course of the project, high-level scope must be included in the contract. Delivery Items will change post discussion with PO on every iteration, but the high-level scope remains the same. Emphasize on process rather than on dates and items. This will keep the team’s mindset collaborative. 4. Settle on Definition of Done at high level: While negotiating the contract, the “Definition of Done” should ideally be defined and attached as an appendix. The clauses for “Definition of Done” that needs to be included are: a. During every Sprint Planning, PO and the development team will review the “Definition of Done” for the items that are included in that particular Sprint. b. In case of disputes, there should be appropriate resolution techniques in place between the parties.   Concluding the article by revisiting one of the values of Agile Manifesto: Customer collaboration over contract negotiation. Contracts matter to those who have signed it. Customers do face problems and you will be able to see them only when you talk to them. Once you see and understand their problems for which they have hired you to provide the solution, you need to COLLABORATE with them and get to it. Despite all the clauses in the contract, the motto should be “LET’S DO IT !!”.  
Agile Contracts or Agile Statement of Work - Must-Haves
Nalini
Rated 4.5/5 based on 3 customer reviews
Agile Contracts or Agile Statement of Work - Must-Haves 321 Agile Contracts or Agile Statement of Work - Must-Haves Agile Management
Nalini Jethwani Jan 30, 2018
In IT with the Agile boom, everyone wants to get into Agile Development. Be it the customers, organizations, and even developers, everyone wants to get into Agile Development. Customers want to fol...
Continue reading

ITIL Practitioner – Things To Be Aware Of

ITIL stands for Information Technology Infrastructure Library and it is a set of libraries to help professionals cover different aspects of managing an IT Service project. Whether you provide a service as a vendor company or your product is marketed as a service to the world; in both cases, ITIL framework is suitable. Currently, Version 3 of ITIL framework is in existence and it contains 5 volumes dealing with Service Strategy, Service Design, Service Operation, Service transition and continual service improvement. This existing version known as ITIL V3 came into being in the year 2011. Initially, ITIL framework categorized the professionals into foundation course, intermediate level, expert level and master level. However, in the year 2015, AXELOS introduced one supplementary certification known as ITIL practitioner. This certification is meant to complement the professionals who are already on their way to become an Expert or a Master and in no way is it compulsory for them to clear it.  However, it will add 3 credit points to your journey of becoming an expert if you choose to add this to your profile. And it will add 15 points to your ITIL badge for professional competency development. Must-read primer on the new ITIL Practitioner Guidance via @stephenmann https://t.co/LDb46lcRfp @Joe_the_IT_guy pic.twitter.com/vmM9RX2kUO — Greg Sanker (@gtsanker) March 9, 2016 I am a newbie, please tell me about ITIL Practitioner level By the term newbie, I am considering anyone who has heard about ITIL certification framework, or might have come across some ITIL professionals in their network or official circles but does not know exactly what it entails. First of all, ITIL practitioner level was introduced by the governing council not only to add one stepping stone for the professionals who are familiar with the definitions and technical terms of ITIL Course, but also, to allow them the additional benefit of understanding how to apply these terms and knowledge in the real world. Practitioners are professionals who understand the ITSM [Information Technology Service management] framework, know how it fits the big picture and how to use it. These professionals are the ones who use this knowledge on a daily basis as part of their projects. In order to become an ITIL practitioner, one needs to clear the ITIL foundation exam. However, being practitioner level certified is not compulsory to attempt becoming Intermediate level certified.   What knowledge is contained in ITIL framework in general or for ITIL Practitioner? In version 2 of ITIL framework, there used to be a certification for “ITIL service practitioner”; in version 3, that has been removed and this ITIL Practitioner is different from that one. So do not get confused. Both are different from each other. Additionally, out of the 5 volumes of ITIL framework, Service strategy volume is considered to be the core of ITIL framework and once you develop the understanding of all 5 volumes, I am sure you will agree with me too. In the upcoming post, I will briefly speak about this point. ITIL practitioner exam consists of 40 scenario-based questions that you have to answer in the form of multiple choice questions within 135 minutes. This is an open book exam where you are allowed to carry the ITIL practitioner guide with you. You need to have 70% marks to be certified as ITIL practitioner. Once you subscribe to the course of ITIL practitioner, you will get access to ITIL core library providing you an information about planning to implement service management, ITIL practitioner guide and a toolkit containing existing publication, worksheets, templates, case studies, and scenarios. These resources will not only help you in clearing the exam, but will also prove useful to you in your day-to-day work.     Which job roles are most suited for the ITIL certified and how will it help me and my organization? As you must have understood by now, if you are working in a service-based, information technology industry then this framework is useful for you. But if you are working in any of these job roles then it is highly recommended to get ITIL certified: IT managers or Support staff Analysts Operations Managers Process owners Database administrators Consultants or Architects Service application developers It will help you in two ways: It will help you make informed and educated decisions about process, practices to be followed in your project It will increase the weightage of your resume, leading to better job prospects, especially for the UK-based clients. It will help your clients and company in a way that they will get the confidence that their project is in better hands, they can rely on you to provide a standard way of delivering the “service”. So overall, it helps everyone. How can an #ITIL qualification help you advance your career? #ITjobs https://t.co/CT4aY8MoJf — IT Governance (@ITGovernance) January 25, 2018 Adopt and Adapt – What is it? “Adopt and Adapt” – Sounds like a mantra given by some great marketing guru or a lesson from elite Management class, isn’t it? Well, it could be. But in this context, this is the guiding principle of ITIL. ITIL framework is one of the main proponents of this concept that states that once you understand a new or better practice, whether it is from ITSM library or from industry, then you adopt it in your project. But before doing so, you need to apply your domain knowledge, your existing constraints and your upcoming opportunities, to modify that practice to make it suitable for your needs. Since ITIL does not believe in the concept of one size fits all, therefore, adaptation is necessary. Else you are doomed to failure through the same means that you hoped to use for your success. While adapting, you also need to review your existing strategy, your transition plans, and your existing processes to know if there is a redundancy. And if such redundancy exists then you need to apply your critical thinking or even call for a brainstorming session and merge the processes into a single and a more effective way. This is “Adopt and Adapt” way of working for ITIL professionals. Lastly, what other benefits will I gain if become an ITIL practitioner? First of all, you will learn how to apply the knowledge of ITIL framework to the real-world projects on the ground. So in short, you will gain practical experience. And as we all know, theory and practice differ vastly from each other. One more benefit is that you will be able to help other individuals in your project and company to leverage continually and improve the service through measurements and maximize benefits by taking the right steps. And most importantly, you will be able to integrate well with the ITIL community and will be on a firm step towards your journey of becoming an expert or a master. So should I take this certification and become an ITIL practitioner? Yes, You should! If you are an Information technology professional dealing with service-related projects or products, then you should get ITIL Practitioner certified. KnowledgeHut is a certified and approved knowledge training provider to help you get certified. Contact support staff at KnowledgeHut to get enrolled. All the best!  
ITIL Practitioner – Things To Be Aware Of
Author Image
Rated 4.0/5 based on 2 customer reviews
ITIL Practitioner – Things To Be Aware Of

ITIL Practitioner – Things To Be Aware Of

Abhinav Gupta
ITIL stands for Information Technology Infrastructure Library and it is a set of libraries to help professionals cover different aspects of managing an IT Service project. Whether you provide a servic...
Continue reading

Project Contracts – A Vital Legal Binding

One of the key knowledge areas discussed in the Project Management Professional (PMP®) certification is Procurements Management. As part of project procurements management a project manager is mainly expected to be able to initiate, execute and manage projects based on the project contracts. This article is an attempt to discuss about project contracts, to discuss the importance of such contracts and to give an introduction to types of contracts as a precursor to subsequent articles. Everything you ever wanted to know about contract digital project management. New blog post #dpm #digital #digitalagency #pmo https://t.co/WO7CAbwbHR pic.twitter.com/bWmeCfGbFr — ProjectManagementOD (@ProjectMOD) 22 December 2017 The PMBOK® defines a contract as follows. “Contract represents a mutually binding agreement that obligates the seller to provide the specified products, services or results, and obligates the buyer to provide the monetary or other valuable consideration in return. A contract can also be called an agreement, understanding, undertaking or a purchase order.” (PMBOK® 5.0) Any project involves two or more parties. One main party that is the buyer and the other the seller. In addition to these there can be other 3rd party elements that are not directly involved in the contract but are interested in or are impacted by the same. The contract between the buyer and the seller happens to protect the interests of the two parties entering into the agreement. The seller provides goods or services to the buyer for which the buyer compensates the seller monetarily or through other financial or non-financial means.   A contract is a formal agreement between the two parties and it is a legal binding amongst the two entities. A formal contract must be in written format and can be used even in court of law in the case of either party failing to honour their commitment or in the case of an appeal against any misdeeds. Dishonouring contracts may actually lead to settlements even in court but should ideally be settled mutually among the disagreeing parties, most probably through a mediator called an ‘arbitrator’. Normally in large organizations contracts are managed by a separate contract manager or a procurements manager. The management of contracts are done in 2 separate ways namely; centralized contracting and decentralized contracting. In centralized contracting, one contract manager manages all the contract related matters for multiple projects. This requires expertise in contracting, standardization of contracting practices across the organization and more focused management of contracts. In decentralized contracting, separate contract managers are allocated to manage the procurements for individual projects. This results in full time management of contracts and the contract manager must report progress to the project manager. This results in more focused management of project contracts and with time creates specialized expertise in contracting. However, this may result in duplication of contracting expertise and less standardization of contracting practices across multiple projects in the company. #Passivehouse builder @AdamJCohen discusses the "gold standard" of Integrated Project Delivery contract typeshttps://t.co/rpk6GXV87W — Passive Buildings (@PassiveBldgsCan) 2 November 2017   There are three main types of contracts. They are Cost Reimbursable OR Cost Plus, Time and Material or Unit Price and Fixed Price or Lump Sum contracts.  The applicability and use of these contract types based on the type of project, complexity and the parties involved may decide on variations based on the charges involved in order to ensure that the contract terms are mutually beneficial for the two parties. Hence, these contracts vary based on the cost, time and price.  A cost plus or cost reimbursement contract is a contract in which the contractor is reimbursed or paid all the actual expenses they incur when carrying out the work. In addition to this they are also allowed to charge an extra fee allowing them to obtain a profit. For example a contractor taking up building a contract may claim resource costs as well as any miscellaneous expenses incurred for travel, food, purchases as well as charge an additional amount from the customer in order to make a profit from the tasks carried out. A fixed price contract on the other hand does not depend on the resources utilized or time expended. A fixed amount is agreed upon between the contractor and the customer where the amount is paid to the contractor even if the resources expended is lower or higher than the agreed upon amount. Time & material contract is where the contracting party is paid only for the amount of time or resources spent. For example if there is a software development firm which assigns 4 resources for a project on a T&M basis the company will be paid an hourly rate for each resource based on the amount of time they spend on tasks in the project.  Each contract type has its own pros and cons for both the contracting and implementation party. For example a fixed price contract is suitable for an organization as they would know the amount due before hand and know that they won’t end up paying extra if the triple project constraints are not met. Similarly, a time and material project may be suitable for both parties, as amount will be charged only based on the amount of work done in the project and for the time spent. Advantages and disadvantages of each contract type depend on the context. Thus, it is important for stakeholders involved in projects to negotiate on contracts wisely.
Project Contracts – A Vital Legal Binding
Author Image
Rated 4.5/5 based on 3 customer reviews
Project Contracts – A Vital Legal Binding

Project Contracts – A Vital Legal Binding

Rumesh Wijetunge
One of the key knowledge areas discussed in the Project Management Professional (PMP®) certification is Procurements Management. As part of project procurements management a project manager is mai...
Continue reading

Quality Management And Control Tools

Quality is one of the modern project constraints which lead the project management processes and activates . according to PMI's PMBOK 5th edition there are 3 processes of quality management throughout the project lifecycle . processes are :- 1-plan quality management  2- perform quality assurance 3- control quality  Now we will talk about a group of tools which can be used to manage and control quality throughout the project lifecycle these group of tools called  can be " Quality Management And Control Tools " it consists of seven Tools as following :-   1-Affinity  diagrams : It divide  the ideas in main categories so we can organize the ideas to do something or to solve a problem . as an example when we divide the main deliverables of the WBS into low levels of work until we reach the level of work packages 2- Process decision program charts (PdPc): According to American Society Of Quality (ASQ)  these tool  links between objective and the steps to achieve these objective via using a tree of 5 level which the first is the objective , the second is the main component of the system , the third is the tasks of each component , the forth is the problems that can occur while we do the tasks of the third level  and finally the fifth level is the actions that can we take to avoid each problem of the problems in the fifth level , after that we can choice the suitable actions depending on its cost and time so these tool is very useful in making contingency plans or change it . 3- Interrelationship  digraphs : A problem solving Tool used in moderately complex scenarios , It can links up to 50 relevant items of causes and effects of any problem in the system . each item is represented as a node , the relation is represented as archer from the input node ( the cause) to the output node ( the effect)   .on each node we write the number of inputs and outputs of these node . the node with the largest number of outputs consider a main factor that cause the problem and by avoid it there are a big chance to solve the problem . 4- Tree diagrams: Also known as systematic diagrams . it represent a decomposition hierarchy such as work breakdown structure (WBS) , organizational breakdown structure (OBS) or resource breakdown structure (RBS) . it represent the relationship between the parent node and the child node also we can use it on decomposing the risks to its components as in the risk breakdown structure . it can also used in decision trees . 5- Prioritization matrices : A Prioritization Matrix is a technique that identify which problem is the most important to work on solving it or which decision is the more suitable to choose .the problems or choices are generated from brainstorming or other ideas generating techniques  . then we determine the criteria which are important in measuring the problem and give it a value that show its important between other criteria's that can be used . these criteria can be time , cost , frequency , feasibility or so on  then we take each problem and measure it be each weighed criteria , then determine the total score of these problem , then we reach to the most important problem which have the largest total score   From the previous table problem 2 is the most important problem so we must solve it before problem 1 and 3 . 6- Activity network diagrams: A tool consists of two forms : Activity on Node (AON) and Activity on Arrow (AOA) . These tool used to schedule the activists of the project by linking activities to each others . the main advantages of these method over other scheduling method such as Gantt chart is that it can determine the critical path of the project also it can show the predecessor and successor of any activity so we can use it when we want to rearrange the activity network.  7-Matrix  diagrams: According to PMBOK 5th Edition the matrix diagram is a quality control tool that used in data analysis to show the strength of relationships between factors, causes, and objectives that exist between the rows and columns that form the matrix. There are many types of matrices that all have its own relationship between columns and rows as :  L-Shaped  , T-Shaped  , C-shaped and Y-shaped  . from these relationships we can correlate between cause and effect so we can solve the problem or control its effects . At the end we can say that : each tool of the previous tools  is very useful in some cases but all of them are used in quality management and control  activates throughout all the project lifecycle .  
Quality Management And Control Tools
Author Image
Rated 4.0/5 based on 3 customer reviews
Quality Management And Control Tools

Quality Management And Control Tools

KnowledgeHut Editor
Quality is one of the modern project constraints which lead the project management processes and activates . according to PMI's PMBOK 5th edition there are 3 processes of quality management throug...
Continue reading

The Business Case – A Key Artifact of A Project Managed As Per PRINCE2

One of the key deliverables in the process of initiating a project managed using the PRINCE2 methodology is to create the business case document. A project in PRINCE2 is defined as ‘A management environment that is created for the purpose of delivering one or more business products according to a specified business case’. What is a business case document? Why is it important to create one? What are the key decisions made using the business case document when initiating a project? How will the business case help in managing and controlling a project and in ensuring that the project continues to deliver business value? This article aims to address above questions.   Why create a Business Case document? A business case is mainly used to document the justification for undertaking the project, based on the estimated cost of development and implementation against the risks and anticipated business benefits and savings to be gained. It is a justification for an investment based on the costs versus the anticipated business benefits of the solution option selected for implementation.  The business case is a primary mechanism of project decision-making and is a means of assessing alternative and competing investment / solution options.  When should you create the Business Case document? For organizations following PRINCE2, to get to the point of creating a business case document itself involves a big process. Requirement for projects arise from different sources. For example strategic level stakeholders may have strategic objectives that they wish to fulfill which may result in projects. Similarly tactical managers, functional managers and even operational staff may have problems that need to be resolved or business opportunities that they want to take advantage of which may result in projects. The context or the environment that they operate in and the stakeholders involved too may have an impact in creating requirements for new projects. A project mandate would first of all be generated once a business need such as above is identified. The scope inclusions and exclusions of the project should be identified and will help identify solution options to meet such requirements. The initial group of individuals would then be generating solution options to solve the identified problems or opportunities. For each solution option a detailed feasibility study should be done along the four main feasibility study dimensions of operational feasibility, technical feasibility, time feasibility and cost-benefit feasibility. This would help the team identify the advantages and disadvantages of each solution option and help select the most suitable solution option. This analysis must also include an initial assessment of the cost, potential timelines and the risks involved. Creating the Business Case and sections of the document The business case documents the justification for undertaking the project, based on the estimated cost of development and implementation against the risks and anticipated business benefits and savings to be gained. The content for the document is based on the analysis explained above. The sections of a properly formulated business case are as listed below. Executive Summary – Summary of the content of the business case document including details about the organization, business problem  / opportunity, key stakeholders, solution options evaluated and the solution option selected. Reasons for the project – Reasons as to why the project is needed including analysis of the current state, the future state and an identification of the gap. Solution options – The different solution options evaluated outlining the rejected solution options and detailing out the preferred solution option. Feasibility analysis – A summary of the feasibility analysis done on the identified solution options. Expected benefits for the selected solution option with explanations and assumptions. Expected disbenefits for the selected solution option with explanations. Summary of project costs taken from the project plan. If the project plan is not created yet it would be good to have an outline cost for the selected solution option. Investment appraisal – The organization may do an ROI, NPV, IRR analysis to ascertain the potential viability and benefits from the project. Risk analysis listing out a risk log with positive and negative risks along with risk mitigation strategies. Timescales – Outline execution plan that will be detailed out in the Project Initiation Document (PID). Continual assessment of project progress using the Business Case The business case document provides a blueprint based on which project progress can be monitored by the project manager and the project board. It provides a means for continuing to assess the viability of the project. In PRINCE2, the Project Board normally reviews the business case at the project initiation stage, end of each project stage, when any exceptions arise and at stage or project closure. The business case would be the main input to create the Project Initiation Document (PID) for the selected solution option. Some teams put a summary of the business case findings as a section in the PID document itself and use it to make an elevator pitch to the business sponsor and other senior executives of the project board. Once the project is approved, the project manager is assigned and he would create the project charter document with key inputs from the business case. The Project Manager and the Project Board will monitor the ongoing viability of the project against the business case. At the end of each stage or iteration the relevant stakeholders will sit together, evaluate the deliverables related to both the product and the process against the expected benefits identified in the business case to ascertain whether the business value set out to achieve is being met. Decisions to get the project back on track would thus be based on the baseline intentions defined in the business case. Finally, the business case is used to assess whether benefits are achieved when the project is delivered through a post implementation review.  The business case is not a constant. It may change multiple times during the lifetime of the project. Evaluation at the end of each iteration or stage will help the project team and the project board realizes that changes are required in terms of objectives, expected business value, scope or even timelines. Hence, the initial business case may become invalid and thus be required to be updated with the consensus of the key stakeholders.  The discussion above is just an introduction to the ocean of creating business case documents. Hope this will inspire you to further dive into this ocean.
The Business Case – A Key Artifact of A Project Managed As Per PRINCE2
Author Image
Rated 4.0/5 based on 20 customer reviews
The Business Case – A Key Artifact of A Project Managed As Per PRINCE2

The Business Case – A Key Artifact of A Project Managed As Per PRINCE2

Rumesh Wijetunge
One of the key deliverables in the process of initiating a project managed using the PRINCE2 methodology is to create the business case document. A project in PRINCE2 is defined as ‘A management...
Continue reading

Kanban Journey for the Infrastructure Operations Support and Service Teams

In my previous post, I had initially started by explaining why we should implement Agile practices and  then talked about the benefits of implementing Agile practices for Infrastructure Operations Support Teams.  Now when we know that by implementing Kanban, these teams can become more Agile and deliver more value to the customer, the next question that we need to focus on is – How do we implement Kanban for infrastructure operations support and service teams.  In the upcoming series of posts, I will be highlighting step by step the complete Kanban journey for Infrastructure Operations Support and Service teams and explain how to implement Kanban for these teams.  However, before we start on our Kanban journey, we need to initially understand clearly what is Kanban, Kanban is basically a method for organizing, managing and delivering work and in this case – infrastructure-related operations and services support work. Kanban can also be used for a lot of other types of work including software product development but in these series of posts, my focus will be primarily on how to implement Kanban for infrastructure operations support services.  The word “Kanban” can be broken down as “Kan” meaning visual and “ban” meaning card, thus Kanban meaning visual card (in Japanese). Hence, Kanban is a visual indicator that is used to trigger an action or activity. Toyota Corporation introduced Kanban in the automobile sector in relay systems to standardize the flow of auto parts in their just in time (JIT) production lines in the 1950s and subsequently, the method was adopted by other organizations and across other industries. Kanban is basically a Pull System where the customer demand pulls the work item from the upstream processes.  It is a method that is used to help teams work together more effectively. It is a visual system for managing the workflow as it moves through a process and the focus is both on the process (workflow) and the work product passing through that process. The emphasis is on identifying the bottlenecks in the process and address them so that the work can flow through the process in an effective manner thereby optimizing time to market (speed), cost and quality (ensure that the work item is having minimal defects). The Kanban method thus helps to visualize the work and control the workload.  Any method, framework or system has key tenets or pillars that identify and characterize the method. Similarly, in order for Kanban to be implemented effectively, we need to understand the key tenets behind Kanban.  The Kanban method consists of a set of principles and practices that have been proven to be effective for managing the workload and deliver professional services to the customers (external and internal) appropriately. These key tenets have proven to be effective in successful Kanban implementations worldwide. These tenets initially derived from Lean principles were further developed by David J Anderson and the worldwide community of coaches, trainers and practitioners and they were published in 2010.    What is the kanban agile methodology? How can you use it?https://t.co/y4WtbhEoJ2 — HEFLO (@WeAreHEFLO) 30 December 2017 The Key Principles are (also derived from the Lean principles) –  Start with what you do NOW – The focus here is on the present. The main aim is not to disturb the current state of the process and identify, focus and study the existing process and bring in incremental changes to the process to manage evolutionary change. Hence, while implementing Kanban for the service teams, many of the team members initially felt they were not doing any change in their current process and everything appeared to be the same. They felt the changes occurring over a period of time in an evolutionary manner as incremental change is introduced in the process.     Encourage acts of LEADERSHIP at every level – Leadership is a very important concept that needs to be encouraged at every level, right from the team member to the Head of the department. Kanban focuses on building leadership skills at every level of the hierarchy so that decisions can be taken by empowered individuals. This is very important as team members cannot take appropriate decisions even if they are empowered if they are not having strong leadership skills.    Agree to pursue improvement through EVOLUTIONARY CHANGE– Improvements are undertaken in small, incremental steps which lead to the changes being implemented in an evolutionary manner. This leads to very less pain on account of changes and team members embrace these changes as they occur in an evolutionary manner. Evolutionary changes give team members a feeling that everything is the same and there is not much change that they feel in the new process as the change is gradual and it is implemented over a period of time.    Policies control SERVICE DELIVERY – Service delivery to the customer requires strong discipline to maintain a steady cadence of work delivery and it also improves predictability of the service delivered. As there are multiple service level agreements to be met for undertaking different types of service support (e.g. L1, L2, L3, L4) and priority of service (e.g. P1, P2, P3, P4), it is important that key policies are defined very clearly by the team and it is understood by all the team members and the customer. This ensures that the expectations related to service delivery are mentioned clearly before the start of work and the customer and the team members are very clear about the service delivery guidelines and rules. This improves trust and transparency and the team members are able to meet the expectations of the customer in a planned and managed fashion.    Manage the WORK, let people self-organize around it – A key principle which focuses on managing the work and allowing the people to self-organize around the work. Historically, the Managers used to manage the people and ensure that the work is undertaken accordingly. However, in this case, the principle focuses on highlighting that the work needs to be managed appropriately. The people who do the work have the maximum amount of information available about the work and this information is always kept current. Hence, they are in the best position to take a decision regarding the work to be undertaken. This can be possible only if they are given autonomy and they self-organize themselves around the work. This principle is derived from the Lean principle which also focuses on the work and allows people to self-organize around the work.    Understand and focus on CUSTOMER needs and expectations – The focus here is on identifying, building, designing and delivering the right service to the customer. The customer needs and expectations are identified and studied and the service delivery is then designed to match the work capacity and the customer need so that appropriate services can be delivered to the customer.    The Key Practices are –  Visualize – The service/process workflow is visualized on a board and also electronically using tools. The human brain has a capacity to understand visual items better as compared to non visual items. Hence, visualizing the work brings a big change in the minds of the team members and they are able to identify bottlenecks quickly and suggest steps to resolve them. Blind spots which were present earlier when the workflow was not visual are now addressed easily in the visual management tool/board.    Limit WIP (work in progress) – Work in Progress (WIP) is an important practice in the Kanban method. WIP Limits are identified for each step and managed appropriately to deliver work in the shortest time possible. When WIP is more, work output gets delayed and queuing of the work items increases. By working out the suitable WIP limits, the work is balanced with the team capacity and the bottlenecks are removed or reduced substantially. This leads to improved cycle time and lead time for the customer.    Manage Flow – Flow is defined as the complete path in the value stream starting from the customer requirement to the work item being delivered to the customer – i.e. from concept to cash as in Lean methodology. By implementing the above practices, the flow in the process can be maintained as a single piece flow, i.e. only one or more work items (considered as a single piece) moving forward at a particular point in time as per the capacity of the process. This ensures that there are no bottlenecks and the work item moves ceaselessly from concept to cash (till it is delivered to the customer). This reduces delays and improves the lead time to market. Hence, the team is able to service the tickets for the customer in the shortest time possible. Theory of constraints is one of the techniques that is used to manage flow in a process.    Make the Policies Explicit – In order to implement the process changes in an evolutionary manner, the team will need to create the policies governing the process (service level agreement, classes of service, cost of delay, WIP Limits, swim lanes and other factors) explicitly and share it with all the stakeholders so that trust and transparency are built into the process. Making the policies explicit ensures discipline and the team members need to manage the process as per the policies and the governance meetings are also set up to ensure that the policies are adhered as per the requirements. However, the setting of the policies is a dynamic exercise as the market conditions, team maturity, customer expectations, and the work environment keep changing and the policies need to be updated as per these variables so that they are always current and all the changes made to the policies as per the requirement also needs to be communicated to all the stakeholders periodically.    Manage the feedback loops – All Agile methods including Kanban focus heavily on feedback loops to measure and validate the work undertaken and the Kanban method builds in a lot of feedback loop mechanisms which need to be managed appropriately. Examples of feedback loops in Kanban are the policies, WIP limits, Kanban events like daily Kanban meeting and other meetings which validate the work undertaken through feedback. The validation confirms the confidence that the work undertaken so far is verified and is correct.    Improve and Evolve – Continuous Improvement is a part of all the process models/frameworks and methods. In the case of Kanban, the focus is on continuous improvement of the processes over a period of time to improve the effectiveness and efficiency of the process. The emphasis is on constantly improving and evolving the process over a period of time to ensure that the time to market or time to delivery is constantly reduced for the customer.  ​By understanding the principles and key practices underlying Kanban, we are now better prepared to implement Kanban effectively for the Infrastructure Operations Support teams. In the upcoming posts, I will continue to highlight and explain each step in the Kanban journey as we learn how to implement Kanban for the Infrastructure Operations Support and Service teams – both at the team level and at the scale level (when we integrate multiple teams at scale to deliver support services to the customer).  
Kanban Journey for the Infrastructure Operations Support and Service Teams
Author Image
Rated 4.0/5 based on 20 customer reviews
Kanban Journey for the Infrastructure Operations Support and Service Teams

Kanban Journey for the Infrastructure Operations Support and Service Teams

Badri N Srinivasan
In my previous post, I had initially started by explaining why we should implement Agile practices and  then talked about the benefits of implementing Agile practices for Infrastructure Operation...
Continue reading

Tips For An Effective Retrospective Meeting

The sprint retrospective in Agile is the scrum ceremony that allows team members to see how well the sprint went in terms of adopting and adapting a defined process. Even in change driven agile projects it is important to define a process that can be agreed and followed by all the team members in order to deliver value in a continuous manner without hindering progress. Thus, checking whether this process was really effective and whether it actually contributed to the effort of continuous delivery is an important activity for any agile team.   The bottom of the pile However, the sprint retrospective is often given step-motherly treatment among all the scrum ceremonies. Retrospective meetings often happen at the end of the sprint or before commencing the subsequent sprint. Sometimes, the retrospective happens along with the sprint review that is carried out to evaluate the product or solution as to whether it meets the acceptance criteria. Teams often neglect the sprint retrospective or just quickly go through it just for the sake of holding a retrospective meeting. Purpose of the Retrospective? One major reason for ineffective retrospective meetings is the miscommunication or misunderstanding of the purpose of retrospective meetings. It is important that the Scrum Master informs the entire team about the purpose of the retrospective meeting. The primary reason for a retrospective meeting is to identify areas of improvement for the process being followed. Hence, the analysis is on the expected process, the actual process followed and an analysis of the gaps identified along with a set of ideas for improvement. <iframe width="560" height="315" src="https://www.youtube.com/embed/EHwpxgZFc_k" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe> Below are a few approaches commonly used to document findings from a retrospective meeting. The team has the freedom to define whatever approach works well for them. Working, Not working, Puzzling Start, Stop, Continue Good, Problematic, Significant What went well, What went wrong, What needs to change, Mad, Sad, Glad Liked, Learnt, Locked, Longed for  Most team members complain that retrospective meetings are monotonous, non-value adding or boring and that they consider it as a waste of time. Below are some tips on how to make the retrospective current and engaging.   Shared Responsibility  Normally in agile projects, the Scrum Master who is the protector and coach for the process has the most interest in carrying out the retrospective meeting. But it is not a must that the Scrum Master needs to be the one organizing and facilitating these sessions. It is always good to hand over this responsibility to a team member and to challenge them to come up with innovative ideas to make the retrospective innovative and engaging.  Retrospective meetings are normally presided by the Product Owner or client stakeholders as well. It may be them who are holding back or limiting project progress through their actions. In order to facilitate freedom of speech, a neutral facilitator can be assigned on a rotating basis and the scrum meeting can be carried out as a ‘Round Robin’ or even a ‘Pencil & paper’ brainstorming session. Set the Context It is always important for the facilitator to set the stage for the meeting. The facilitator must define the purpose and ground rules for the meeting along with the expected outcome. Ice Breaker speeches, Motivational videos, Collaborative games etc. can be innovative ways to ease everyone into the meeting and to get them to share ideas without any inhibitions. It is also important to revisit findings from previous retrospective meetings in order to ascertain whether remedial action has been implemented properly in order to ensure that findings do not recur. Gamified Retrospectives  One drawback at most of the retrospective meetings is the lack of participation. Limitations with culture, communication, as a result of respect or even through fear of punishment people refrain from contributing at retrospective meetings. Thus, the usual set of findings pop-up at each retrospective meeting.  The facilitator must play a key role in running the meeting as a time boxed game where he can encourage participants to generate ideas, write them on sticky notes and post them on walls. Fish bowl meetings, Motorboat meetings etc are some more techniques to encourage participation. Identify enablers which makes the process work and any distractors which hinder the process. Once enough ideas are generated, the next step would be to generate insights, group them into themes and to assign possible action items. Generate Insights & Action Items The facilitator may use affinity technique to group ideas to common themes or categories. Some categories may be communication, collaboration, leadership,  trust, understanding of process etc. This will help the team grow on those ideas in order to generate actionable ideas. It is important to also look at the progress of action items from past sprints, and to analyze any ideas or action items that may be repeating. Repetitions may actually mean gaps that the team has not been able to successfully address and needs urgent attention. Value Everyone’s Opinions Facilitator must ensure that the team values the inputs of everyone. No mud slinging, finger pointing or blame games should be tolerated. One way to increase collaboration is to stress on the positives and commend on accomplishments of team members.    The Wrap Up One important aspect that the facilitator and the team miss out on is to wrap up retrospective sessions properly. The findings and action items from the meeting must become the motivators for the team on how they are going to perform during subsequent sprints. Thus, it is important to get the team to act upon findings from the sprint and to make necessary changes to the processes. So, let’s make retrospectives work. Let’s make them the catalyst for continuous improvement of agile teams.  
Tips For An Effective Retrospective Meeting
Author Image
Rated 4.0/5 based on 20 customer reviews
Tips For An Effective Retrospective Meeting

Tips For An Effective Retrospective Meeting

Rumesh Wijetunge
The sprint retrospective in Agile is the scrum ceremony that allows team members to see how well the sprint went in terms of adopting and adapting a defined process. Even in change driven agile projec...
Continue reading

A Practical Perspective On Addressing The Pitfalls During Scrum Adoption

Scrum is a roadmap that guides you to perform in project management with remarkable excellence as expected by all the stakeholders. Scrum master holds the responsibility to ensure that Scrum theory, rules and practices are enacted with perfect understanding. The high expectations of the Product Owner, Scrum team members, and organization make the Scrum adoption more challenging even for the experienced project managers but great results never come on their own; you need to do something different. Here, I share 5 major pitfalls identified for putting barriers to smooth performance of projects and Scrum Masters are:    1.Pitfall: Resistance to Recommended Changes: The resistance to change organizational culture and philosophy is the very first pitfall you come across on your Scrum journey. Sometimes, the extra efforts to fit Agile elements into the non-Agile framework make the task more complex. Accepting change is difficult and uncomfortable for the most; you see many stakeholders keeping distance from it. In other words, the majority of Scrum team members or the people concerned with the project in one way or the other poses rigidness when their comfortable routines are disrupted. Also, some experienced team members have a mindset “this is the way we have always done it and succeeded”.  Solution: The Practical Perspective:  So, change is the fundamental requirement for Scrum adoption; because you wouldn’t be planning for Scrum adoption if the changes were not required to improve. And, all the concerned members must be willing to accept the changes to improve the collective performance. As an efficient Scrum master, you must be able to perform as the change agent being proactive in resolving the resistances to change. The following 6 steps will help you overcome the resistance to Scrum rollout:  Explain the importance & need for the suggested changes  Actively listen to the members and incorporate their feedback into the process changes Highlight the benefits for winners and losers both while defining roles Use the key influencers to make the messages clear and accepted Measure the outcome & share the success to inspire the team members Identify and isolate the stubborn detractors    2.Pitfall: Lack Of Scrum Training Having trained and efficient project team is essential for successful Scrum adoption because Scrum is not a pre-scripted methodology; instead, it is a suggestive approach that delineates the processes and practices to keep the team members on the right track. The lack of training results in lack of commitment to Scrum adoption. The team members not comfortable in Scrum rules implementation tend to shift to old practices; they love to work in their own areas without much concern with others; such knowledge silos put diverse hurdles to your Scrum transition journey.    Solution: The Practical Perspective:  Scrum training should be a part of Scrum adoption strategy; especially, if it is being introduced in the organization first time. Giving the team members deep insights into Scrum methodology is a must for smooth scrum transition. Schwaber, in his book Enterprise and Scrum (2007), states that limited size maximizes the speed, content accuracy and communications; and the ideal team size is nine people. As a Scrum Master, you are responsible to help the team members hit the goals fixed in sprint meetings. To plan for the role specific Scrum training, you need to fix the following three parameters:  Numbers of people for Scrum training  The specific roles Requirement of certification On-site video training or classroom training      3.Pitfall: Distributed Team Scrum allows the team members to work from different locales but the distributed Scrum teams face certain major issues that retard the project’s progress:  Conflicting working hours and different time zones impair effectiveness and collaboration. Delay caused by lack of zero gap communication  Cultural differences & language barriers create confusions and misunderstanding  Team members have divergent preferences for technologies.  Solution: The Practical Perspective: As a Scrum Master, you need to assemble the distributed team for building trust and respect for each other. Try the following three experienced based hacks to solve the problem:  Make the communication fast, transparent and understandable to all despite the difference in working hours Give the team members ownership of their work to improve their commitment & motivation levels  Organize the camps to crush the boundaries of cultural and language differences    Present the clear picture of tooling, standards, and architecture design to keep everyone on the same track    4.Pitfall: Changes In Team To Manage Resourcing Problems Some organizations on the first time journey to Scrum adoption make massive changes in the team to manage the resourcing problems because of not knowing the hidden pitfalls. Although Scrum team members are trained to face the changes, still, frequent changes break the rhythm by disrupting the team’s velocity. Every member needs stability to perform; when the frequent role changes are applied, even the performing members quit. The replacement of old member with new member poses new problems for the other team members during the settling period. Assuming changes as the best feasible solution for improvement is a big pitfall in the journey of Scrum adoption.   Solution: The Practical Perspective: As a Scrum team leader, it is your responsibility to help and train every team member to speak the same language. How?  To retain the members, make sure every team member has Scrum training The required changes in Scrum team should be discussed with senior members but you need to have valid reasons  Keeping right person at right position is the responsibility of Scrum Master; it makes the individual’s performance evaluation more important   The task of making changes doesn’t end just by adding new member; you also need to track the cooperation between the new member and old members     5.Pitfall: On The Demand Tasks and Outcomes of Old Practices  Handling the unexpected urgent requests thrown by the client or the technical support team is one of the biggest challenges for the Scrum Masters. The other unexpected problem often faced by the Scrum Masters is the outcome of old practices even before they came into the picture. Some of such issues can be put into the backlog but many of these are needed to be handled at top priority. It harms the efforts to protect the team members from any interruption to let them drive in the secluded environment.  Solution: The practical perspective: Iterative product development is the part of Scrum approach. Respect the new demands and urgencies as the opportunities to test your capability. Whatsoever kind of problems you may face in managing on the demand tasks and bugs of old practices, you are expected to do it and you must do it the deliver the quality product ensuring 100% satisfaction to the client. Try the following 3 tricks to ease down the pressure:  Take the Bugs and urgent requests as the stuff for the superhero; and, you are indeed.  As Robin was important for Batman; you too need Robin to be called in for action.  Allocate sufficient time and resources separately to manage Bug Backlog and Product Backlog.   Conclusion:  On the way of Scrum adoption, you need to make several changes at diverse stages. Deep insights into Scrum principles, learning from problems, zero gap communication, effective team building and optimized use of tools/technology etc are the core strengths of successful Scrum Master to lead the team. The Certified Scrum Master (CSM) Certification and Professional Scrum Master (PSM) courses, separately designed for class room and team/corporate training modules give you knowledge, practical experience and confidence to get the best from Scrum adoption by incorporating the changes as the acceptable working culture transformation.   
A Practical Perspective On Addressing The Pitfalls During Scrum Adoption
Author Image
Rated 4.0/5 based on 20 customer reviews
A Practical Perspective On Addressing The Pitfalls During Scrum Adoption

A Practical Perspective On Addressing The Pitfalls During Scrum Adoption

Shubhranshu Agarwal
Scrum is a roadmap that guides you to perform in project management with remarkable excellence as expected by all the stakeholders. Scrum master holds the responsibility to ensure that Scrum theory, r...
Continue reading

How To Build A Self-Organizing Team As A Scrum Master

The key element of implementing Scrum successfully in an Agile-oriented business is the self-organized team; however, it leads to a misconception that every team member will be loose cannon, working without the ownership and directions for the assigned task; which is just opposite to the actual experience because the self-organized team members work together under the agreed framework of norms, guidelines, and expectations to achieve iteration goal. Most Agile-Scrum organizations emphasize on building the self-organizing team - why?  The 4 Key Benefits of Scrum Self-Organizing Team:   “Individuals in an empowered organization have the knowledge, skill, desire and opportunity to personally succeed in a way that leads towards collective success" (Stephen R. Covey, Principle-centered Leadership). The 4 key benefits that drive the experienced Scrum Master to build the self-organizing team are:  Motivation improves the performance of the Scrum team Innovative & creative environment is conducive to everyone’s growth Everyone learns from the failures and successes to perform the best with self-optimization Improves ownership because each member feels more responsible for the sprint result   Roadmap to Build a Self-organizing team as a Scrum Master:  Who is responsible for building the self-organizing team? Definitely, Scrum Master is primarily responsible for building a self-organizing team ensuring the cohesive working environment for all the team members. Like the job itself, building Scrum self-organizing team is also a complex challenge for the Scrum Masters. The complete task can be simplified by dividing it into three steps:   Step 1. Training:  The problems can’t be solved with same level thoughts that create them; and, we need the motivated trained minds with a zeal to solve the particular problems. Each Scrum team member is expected to have the best level skill set; therefore, Scrum Master must provide classroom or on-the-site task-specific training to individuals. Often, the efficient Scrum masters tend to lead to problem-solving; but instead of solving the problems yourself, it is better to let the trained team members do it. In parallel, behavioural - communication training must be planned to shorten the training period.  Certified Scrum Masters have mostly proved their potential in building such trained teams.  Step 2. Coaching:  Scrum Master must behave as a coach to guide the team members for solving the problems. Some team members may require more guidance at the start but analytical support trains them to crack the nut on their own. After proper Scrum training and coaching, you will experience the team heading for self-organizing but the task is not completed yet. Scrum Master is expected to observe the team members to make further improvements in identified areas.  Step 3. Mentoring: Keeping your team self-organizing is also a challenge because changing the traditional work habits is not so easy. The challenge can be easily managed by behaving like a mentor who helps the team members to perform at the next level. As per Scrum guidelines, the most efficient and capable Scrum team member to solve a specific problem is the one who needs to solve it. The mantra of building a successful Scrum self-organizing team is – “Self-organizing team need task oriented coaching & personalized mentoring not the “command & control”. Conclusion with 7 Tips for the Scrum Masters to Build Self-Organizing Team:  It takes time to make the people willing to take bigger responsibilities. I always say to Scrum self-organizing team members that they should take initiatives on their own instead of waiting for others to take action for problem-solving. This approach of Scrum self-organizing team speeds up the development besides providing more time for the Scrum Master to focus on other important issues. To conclude, I summarize the 7 points to help you build efficient and successful Scrum self-organizing teams:    To touch the extremes of your career as an efficient Scrum Master be honest in “Know your stuff & learn that you don’t” approach.   Assert the influence but without taking over. Suggest new ideas to address impediments; and, authorize the team members to manage the problem in their own way.  Ask complex questions to motivate the members to come up with innovative concepts Support the team members to take actions  Use safe-to-fail tests to let the team members imply learned skills Be available for the team members to let them work in a flow  Be a practical hardliner because your Scrum team needs it  
How To Build A Self-Organizing Team As A Scrum Master
Author Image
Rated 4.0/5 based on 20 customer reviews
How To Build A Self-Organizing Team As A Scrum Master

How To Build A Self-Organizing Team As A Scrum Master

Shubhranshu Agarwal
The key element of implementing Scrum successfully in an Agile-oriented business is the self-organized team; however, it leads to a misconception that every team member will be loose cannon, working w...
Continue reading

Project Quality Management: The Key Indicator of Project Success

The PMBOK® defines quality as the degree to which a set of inherent characteristics fulfills requirements.  A project is said to be meeting its quality expectations when all the project requirements agreed at the inception of the project are met, and thus the resulting product or service is usable for the relevant stakeholders.  Quality is Subjective  Quality for one individual will not be adequate for another. For example, the youth will consider a mobile phone as being of high quality based on its look and feel, brand name and its specification such as camera quality, memory capacity, screen resolution, ability to connect with other devices etc. and based on the support to run applications on the phone. However, for someone in the age group of 60 and above, the ability to take a phone call or send an SMS and whether this can be done without much hassle alone may define the quality of the mobile phone.  To understand the quality requirements tailored to projects, it is necessary to have an exhaustive Quality Management training such as the Certified Manager of Quality Training. Quality has many faces The definition of quality depends on the context and the business domain. For a service-oriented organization such as a bank, a restaurant, an airline etc. quality of service is identified through the level of customer satisfaction. For a product such as a mobile phone, a vehicle, a computer etc. quality means conformance to product specifications and its fitness for use.  In the context of healthcare sector, mission-critical military activities etc. quality is measured through precision and accuracy. Precision refers to the granularity of measurement and how fine the outcome can be measured. Accuracy simply put is the correctness of the output or being close to the desired value.   Here are the four things #CIOs need to know about quality https://t.co/gRfqoTEUB7 #Qualitymanagement pic.twitter.com/KHMz5iC6RN — CIOReview (@cioreview) January 7, 2018 Quality is everybody’s responsibility  Quality in project management is two-fold. Project Quality and Product Quality. Project quality is to ensure that the project is executed in line with the triple constraints of time, cost, and scope. If the project is within the defined tolerance levels of these three dimensions, then we can say that the project is of high quality. Projects are carried out to develop a solution; i.e. product, service or a result. If this solution meets its specification or meets the needs of the stakeholders then it is said that the solution is of high quality.   Meeting the quality expectations is not merely the responsibility of the project manager, but of everyone involved in the project. Achieving quality involves cost where it is the responsibility of everyone involved in the project to manage the same. Increased efforts and costs can increase the quality of output but a ceiling on this investment has to be fixed. Yes, it is the responsibility of the project manager to manage this ceiling value and to ensure optimal levels of quality within the project but he or she can only do this with the support of his team members. The optimal level of quality can be achieved when the incremental cost of achieving quality is equal to the incremental revenue from such quality improvements.    What digital transformation means for the future of #qualitymanagement: https://t.co/0gyCaHsKtb — Sparta Systems (@SpartaSystems) January 17, 2018 Cost of Quality In order to achieve this, the project will have to incur some cost and this is known as Cost of Quality. This includes all costs incurred over the life of the product by investment in preventing non-conformance to requirements, appraising the product or service for conformance to requirements and failing to meet requirements or in other words rework. Thus, the cost of quality is of two main types- Cost of Conformance – This is the money spent during the project to avoid failures through prevention or appraisal. Prevention costs are costs incurred to prevent errors by the way of training, documentation, maintenance of equipment, quality control etc. Appraisal costs are incurred to assess the quality by the way of testing (quality assurance), inspections, etc. Cost of Non-Conformance – This involves the money spent during and after the project because of failures. Two main types of such costs are cost of internal failure and cost of external failures. Internal failure costs involve rework, scrap costs that are incurred before the solution is released. External failure costs are more critical where these are incurred to rectify damages of products failing once released to the customer. Such costs include liabilities, warranty, loss of business, damage to image etc.   Quality Management is an important aspect of Project Management. PMI® thus has given a central position to the same when defining the knowledge areas in the PMBOK™. It is thus important for project managers and team members alike to understand the importance of quality and to better manage projects to achieve all expectations pertaining to quality.  
Project Quality Management: The Key Indicator of Project Success
Author Image
Rated 4.0/5 based on 2 customer reviews
Project Quality Management: The Key Indicator of Project Success

Project Quality Management: The Key Indicator of Project Success

Rumesh Wijetunge
The PMBOK® defines quality as the degree to which a set of inherent characteristics fulfills requirements.  A project is said to be meeting its quality expectations when all the project requi...
Continue reading

6 Compelling Benefits of (TDD) Test Driven Development

Introduction to Test Driven Development (TDD):  Test-driven development is a balanced approach for the programming perfectly blended with tightly interwoven three activities: coding, testing (writing unit tests) and designing (refactoring).  The revolutionary new age approach emphasizes on test-first development with the primary goal of correcting specification rather than the validation first. In other words, TDD is a smart approach to understand and streamline the requirements prior to writing the functional code in the line of Agile principles.  For most people trying to understand and implement Test Driven Development, the Certified Agile Tester Training has been found to be very much effective.  Two levels of TDD: TDD approach requires great discipline because the common tendency and traditional approaches inspire the programmers to “slip the test” and to write the functional code. To simplify the TDD implementation process, Agile TDD methodology can be categorized into two levels:  1.Acceptance TDD (ATDD): At this stage, you write the acceptance test specifying behavioral specifications, and then write the functionality/code. ATDD also termed as ‘Behavior Driven Development’ (BDD), neglecting the thin separating line over focus area, specifies the detailed and executable requirements for the acceptable solution on JIT- just in time basis.  2.Developer TDD: At this advanced level of TDD in Agile process, you write the developer test prior to writing the production code accordingly. The objective of TDD developer is to specify the detailed and practical design for the profitable solution on JIT basis.  6 Benefits of (TDD) Test Driven Development:  TDD has been the favorite approach of Agile organizations following the time-tested approaches to delivering the best quality product in a shorter period while securing the interests of all the stakeholders. It essentially bridges the gap between Development and Testing.  A survey conducted in 2010 confirmed that 53% Agile teams were following Developer TDD while 44% Agile teams were applying Acceptance TDD (ATDD) method. For the period of 7 years, Test Driven Development is getting massive popularity and the acceptance because of several behavioral and practical benefits; 6 key TDD benefits, driving the Agile teams to follow TDD methodology, are:     1.  The Best Level Acceptance:  TDD implementation helps the developers to understand the requirements from the perspective experience of clients. The test cases are designed without the constraints of architecture design or traditional programming approaches. TDD maximizes the possibility of developing the best quality product fulfilling the communicated needs of all the stakeholders. 2.   TDD - Customer-Centric Agile Process:  TDD process gets fit into the customer-centric agile methodology. The iteration for quality improvement is defined as the incorporation of new functionality against the model set of traditional practices or problem statements. 3.  Prompt Feedback:  The streamlined TDD process helps the project development team members to improve their delivering capability because of providing the immediate feedback on the developed components. The shorter feedback sharing loop squeezes the turnaround period for the elimination of identified defects; and, the outcome is comparatively much better than it is in traditional waterfall methodology.  4.   Extended Modulation for Small Units: TDD helps to create better modularized, extensible and flexible code. Test Driven Development approach drives the Agile team to plan, develop and test the small units to be integrated at advanced stage. Under this approach, the concerned member delivers and performs better because of being more focused on smaller unit.  5. Easy Anticipation & Identification of Voids:   Test Driven Development process provides a comprehensive toolset to test every line of coding; the best part is that the entire thing is checked automatically within minutes. The comprehensive test suite alerts for timely changes to save the efforts, time and cost. Even in case, you inherit the coding of an absent team member or you outsource the coding, TDD allows you to test the practical suitability in the line of specified requirements; provided, you have author code. Fast testing at each step helps you to anticipate and identify the possible voids and to fill up those with modified practices.      6. Programmers Feel More Confident By Continuous Achievement:  Looking at big targets sometimes disheartens the programmers because of involved complications. With TDD approach, every test instills the confidence of moving in right direction. Every test, sub-test and successfully completed component marks the win giving you clear picture of ‘what has been completed and what is remaining to be done?”.    Conclusion:  The scope of TDD benefits goes beyond the validation of correctness by step by step scaling. The organizations following TDD approach can easily make changes to current applications without disturbing the daily operations. The most organizations need to update the software to combat the challenges posed by continuous technology advancement and competitors; and, Agile TDD gives the businesses all the freedom to address new requirements or unforeseen variables.     
6 Compelling Benefits of (TDD) Test Driven Development
Author Image
Rated 4.0/5 based on 20 customer reviews
6 Compelling Benefits of (TDD) Test Driven Development

6 Compelling Benefits of (TDD) Test Driven Development

Shubhranshu Agarwal
Introduction to Test Driven Development (TDD):  Test-driven development is a balanced approach for the programming perfectly blended with tightly interwoven three activities: coding, testing (...
Continue reading

SUBSCRIBE TO OUR BLOG

Share Blog

View All Topics

Follow Us