Category

Courses

Search

Trending blog posts

Why Do We Use Fibonacci Series for Estimation

In this article, my focus is on sharing my experience as a Trainer/Mentor/Coach to Agile teams with respect to Agile estimations; and on using the Fibonacci sequence as scale to size the Story. What will you learn in this article? Agile practitioners mostly use Story points as a measure for estimation, typically using the Fibonacci scale. In this article we are going to understand the top reasons why we use the Fibonacci series for estimation, and how it works in practice. Before we get to the details, let us try to understand some of the fundamentals. Why do we need to estimate?Estimates help the project team to: Identify the time & effort required to arrive at the project schedule Identify the right number of people required to do the work Arrive at the budget by rolling up the cost of all activities required to complete the work; and Prioritize the work in conjunction with the value that will be delivered. Some software developers fear to provide effort estimates as they are accountable to complete their work within the time.  Hence, they take so much time to get into the details to make sure they have enough information to provide the estimates. This sometimes may not be possible during the beginning of the project as the team may not have enough information on hand to provide the effort estimates for all the tasks to be performed. Hence the order of magnitude (ROM, Budget or Definitive) will be applied at various stages during the project based on the available information to predict the effort needed to complete the activities. Agile Estimation  Typically, in traditional project management, effort estimations may or may not be agreed upon by the entire team. Estimates may either be given by the Project Manager/Tech Lead to the team or the developers/testers may estimate for the piece of work that they have been assigned. This way of estimating a project does not provide an opportunity for the team to collaborate. There may be a difference of opinion with the team members in the effort that need to be spent on an activity. The way the estimations are done within an Agile team is little different. It is just not about the measure used to estimate the effort (for example Story Points), but ensures that the team collaborate among themselves, thus providing an opportunity for knowledge sharing. This helps the accuracy of the estimates when compared to doing individual vs group estimates as the team members come from different backgrounds and roles (developers, testers, quality analysts, business analysts). An Agile team effort estimate focuses on relative sizing of user stories and does not focus on the duration; hence it is faster. The team learns to size the story relatively and accurately over a period of a few iterations (sprints), thus improving the predictability (arrived through establishing consistent velocity over a period of few iterations) as well.  Planning Poker is commonly used as the planning exercise for the team to collaborate and size the stories. Planning Poker uses Fibonacci sequence to assign a value to the epic/feature/story. What is Fibonacci Series?  According to Oxford dictionary, Fibonacci Series is : “ a series of numbers in which each number ( Fibonacci number ) is the sum of the two preceding numbers. The simplest is the series 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 etc” The formula to arrive at a Fibonacci sequence is: Xn = Xn-1 + Xn-2 This sequence will be slightly modified when used in Agile estimations: typically, it will not have values beyond 100 and may have 0, ½, 1, 2, 3, 5,8, 13, 20, 40, 100. Some teams limit the highest value as 21 and use 0, 1/2, 1, 2, 3, 5, 8, 13, 21. Top 3 Reasons Why Using the Fibonacci Sequence Will Make You Better at Estimating Tasks  1. Weber–Fechner law: “The Weber–Fechner law refers to two related hypotheses in the field of psychophysics, known as Weber's law and Fechner's law. Both laws relate to human perception, more specifically the relation between the actual change in a physical stimulus and the perceived change. This includes stimuli to all senses: vision, hearing, taste, touch, and smell” Applying the law to Numerical Cognition,  “Psychological studies show that it becomes increasingly difficult to discriminate between two numbers as the difference between them decreases. This is called the distance effect. This is important in areas of magnitude estimation, such as dealing with large scales and estimating distances. It may also play a role in explaining why consumers neglect to shop around to save a small percentage on a large purchase, but will shop around to save a large percentage on a small purchase which represents a much smaller absolute dollar amount”  (source: https://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law) The Fibonacci sequence very well corresponds to Weber’s law. The values in the Fibonacci sequence are about 60% higher than the previous value, and hence applying relative sizing is much easier. It is very challenging to distinguish the size of two numbers which are adjacent to each other, by just looking at the objects. Let us take an example of a football and cricket ball. The approximate diameter of a cricket ball would be 2.8 to 2.86 inches whereas the diameter of a football would be 8.66 inches. It is easy to distinguish the relative size of these two (i.e., approximately the diameter of a football is 3 times that of a cricket ball). However, it is very challenging to distinguish between two cricket balls that vary 1 inch in diameter, unless you measure both. If you look at the Fibonacci sequence, the relative size between two adjacent numbers is more than 60% and this helps us to be able to size them accordingly.   2. Reflect Uncertainty The smaller value assigned from the Fibonacci sequence to a user story usually means that the story is well understood, and the user story follows INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) guidelines. Whereas the largest value denotes the story is not well understood or it needs to be broken down further. Smaller stories can be confidently estimated by the team in detail. A general practice from matured Agile teams is that the Fibonacci sequence is restricted up to 21 (0,1,1,2,3,5,8,13,21) and any story which is of size beyond 21 will have to be broken down further. This ensures that the team is not giving any room for greater uncertainty and good practice for the team to write better stories under the INVEST guidelines. 3. Comparison Though it is not mandatory to use Fibonacci sequence for story point estimations, the sequence is easier to understand and adoptable by the team. Individuals are better at comparison than estimation.  The easy sequence and distinguishable values of Fibonacci sequence helps to estimate by not measuring the objects but by comparison. How Does Fibonacci Agile Estimation Work in Practice?  When do you think is the right time for the Agile team to estimate user stories that are prioritized by the Product Owner in the product backlog? In my experience, I would say that the estimates (story point sizing) should happen during the Iteration/Sprint backlog grooming sessions. This gives the team the time to go through the user stories in detail, collaborate and mutually agree using the Planning Poker exercise.  Then what do we do in Sprint Planning? – This ceremony should be used to pick the stories from the product backlog (fulfils Definition of Ready), that can be completed within the iteration/sprint and then breakdown the stories into tasks and do one more level of estimation which is effort estimation denoted in hours. Let us say a team is assigned a task to estimate a reporting module to be developed: The team would agree that it is a difficult task to provide an effort estimation and it would take a longer time to complete; but how long will it take? Using Simple, Medium and Complex categorization would simply mean that the estimate falls into the Complex category; but how complex is it? Breaking down the requirement into granularized tasks, getting to the minute details and then arriving at an effort estimation would be a complex process and time consuming as well. Can the team take linear sequence (1,2,4,8,10,12,14,16….) and size them for a high-level estimation? Is it possible to size between 50 and 52? What can be defined as the highest scale? Using Fibonacci series helps the team to size the stories which have a distinguishable value and as discussed earlier, matured Agile teams use modified Fibonacci series and have highest scale of 21 to size a story. As discussed above, the Fibonacci numbers are 60% above than the previous number, and that helps in relative sizing. Summary There are various methods to estimate user stories, like T-Shirt sizing, Dot voting, Affinity Mapping etc. Story points is the widely used measurement for sizing the user stories. Fibonacci series helps the team to compare between two stories; and its very nature of distinguishable values helps them to fit the story into the right size that reflects uncertainties, which further helps the team to refine the story to remove those uncertainties. Hope this article was useful to you.
Why Do We Use Fibonacci Series for Estimation
KnowledgeHut
Rated 4.0/5 based on 13 customer reviews

Why Do We Use Fibonacci Series for Estimation

In this article, my focus is on sharing my experience as a Trainer/Mentor/Coach to Agile teams with respect to Agile estimations; and on using the Fibonacci sequence as scale to size the Story. What will you learn in this article? Agile practitioners mostly use Story points as a measure for estimation, typically using the Fibonacci scale. In this article we are going to understand the top reasons why we use the Fibonacci series for estimation, and how it works in practice. Before we get to the details, let us try to understand some of the fundamentals. Why do we need to estimate?Estimates help the project team to: Identify the time & effort required to arrive at the project schedule Identify the right number of people required to do the work Arrive at the budget by rolling up the cost of all activities required to complete the work; and Prioritize the work in conjunction with the value that will be delivered. Some software developers fear to provide effort estimates as they are accountable to complete their work within the time.  Hence, they take so much time to get into the details to make sure they have enough information to provide the estimates. This sometimes may not be possible during the beginning of the project as the team may not have enough information on hand to provide the effort estimates for all the tasks to be performed. Hence the order of magnitude (ROM, Budget or Definitive) will be applied at various stages during the project based on the available information to predict the effort needed to complete the activities. Agile Estimation  Typically, in traditional project management, effort estimations may or may not be agreed upon by the entire team. Estimates may either be given by the Project Manager/Tech Lead to the team or the developers/testers may estimate for the piece of work that they have been assigned. This way of estimating a project does not provide an opportunity for the team to collaborate. There may be a difference of opinion with the team members in the effort that need to be spent on an activity. The way the estimations are done within an Agile team is little different. It is just not about the measure used to estimate the effort (for example Story Points), but ensures that the team collaborate among themselves, thus providing an opportunity for knowledge sharing. This helps the accuracy of the estimates when compared to doing individual vs group estimates as the team members come from different backgrounds and roles (developers, testers, quality analysts, business analysts). An Agile team effort estimate focuses on relative sizing of user stories and does not focus on the duration; hence it is faster. The team learns to size the story relatively and accurately over a period of a few iterations (sprints), thus improving the predictability (arrived through establishing consistent velocity over a period of few iterations) as well.  Planning Poker is commonly used as the planning exercise for the team to collaborate and size the stories. Planning Poker uses Fibonacci sequence to assign a value to the epic/feature/story. What is Fibonacci Series?  According to Oxford dictionary, Fibonacci Series is : “ a series of numbers in which each number ( Fibonacci number ) is the sum of the two preceding numbers. The simplest is the series 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 etc” The formula to arrive at a Fibonacci sequence is: Xn = Xn-1 + Xn-2 This sequence will be slightly modified when used in Agile estimations: typically, it will not have values beyond 100 and may have 0, ½, 1, 2, 3, 5,8, 13, 20, 40, 100. Some teams limit the highest value as 21 and use 0, 1/2, 1, 2, 3, 5, 8, 13, 21. Top 3 Reasons Why Using the Fibonacci Sequence Will Make You Better at Estimating Tasks  1. Weber–Fechner law: “The Weber–Fechner law refers to two related hypotheses in the field of psychophysics, known as Weber's law and Fechner's law. Both laws relate to human perception, more specifically the relation between the actual change in a physical stimulus and the perceived change. This includes stimuli to all senses: vision, hearing, taste, touch, and smell” Applying the law to Numerical Cognition,  “Psychological studies show that it becomes increasingly difficult to discriminate between two numbers as the difference between them decreases. This is called the distance effect. This is important in areas of magnitude estimation, such as dealing with large scales and estimating distances. It may also play a role in explaining why consumers neglect to shop around to save a small percentage on a large purchase, but will shop around to save a large percentage on a small purchase which represents a much smaller absolute dollar amount”  (source: https://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law) The Fibonacci sequence very well corresponds to Weber’s law. The values in the Fibonacci sequence are about 60% higher than the previous value, and hence applying relative sizing is much easier. It is very challenging to distinguish the size of two numbers which are adjacent to each other, by just looking at the objects. Let us take an example of a football and cricket ball. The approximate diameter of a cricket ball would be 2.8 to 2.86 inches whereas the diameter of a football would be 8.66 inches. It is easy to distinguish the relative size of these two (i.e., approximately the diameter of a football is 3 times that of a cricket ball). However, it is very challenging to distinguish between two cricket balls that vary 1 inch in diameter, unless you measure both. If you look at the Fibonacci sequence, the relative size between two adjacent numbers is more than 60% and this helps us to be able to size them accordingly.   2. Reflect Uncertainty The smaller value assigned from the Fibonacci sequence to a user story usually means that the story is well understood, and the user story follows INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) guidelines. Whereas the largest value denotes the story is not well understood or it needs to be broken down further. Smaller stories can be confidently estimated by the team in detail. A general practice from matured Agile teams is that the Fibonacci sequence is restricted up to 21 (0,1,1,2,3,5,8,13,21) and any story which is of size beyond 21 will have to be broken down further. This ensures that the team is not giving any room for greater uncertainty and good practice for the team to write better stories under the INVEST guidelines. 3. Comparison Though it is not mandatory to use Fibonacci sequence for story point estimations, the sequence is easier to understand and adoptable by the team. Individuals are better at comparison than estimation.  The easy sequence and distinguishable values of Fibonacci sequence helps to estimate by not measuring the objects but by comparison. How Does Fibonacci Agile Estimation Work in Practice?  When do you think is the right time for the Agile team to estimate user stories that are prioritized by the Product Owner in the product backlog? In my experience, I would say that the estimates (story point sizing) should happen during the Iteration/Sprint backlog grooming sessions. This gives the team the time to go through the user stories in detail, collaborate and mutually agree using the Planning Poker exercise.  Then what do we do in Sprint Planning? – This ceremony should be used to pick the stories from the product backlog (fulfils Definition of Ready), that can be completed within the iteration/sprint and then breakdown the stories into tasks and do one more level of estimation which is effort estimation denoted in hours. Let us say a team is assigned a task to estimate a reporting module to be developed: The team would agree that it is a difficult task to provide an effort estimation and it would take a longer time to complete; but how long will it take? Using Simple, Medium and Complex categorization would simply mean that the estimate falls into the Complex category; but how complex is it? Breaking down the requirement into granularized tasks, getting to the minute details and then arriving at an effort estimation would be a complex process and time consuming as well. Can the team take linear sequence (1,2,4,8,10,12,14,16….) and size them for a high-level estimation? Is it possible to size between 50 and 52? What can be defined as the highest scale? Using Fibonacci series helps the team to size the stories which have a distinguishable value and as discussed earlier, matured Agile teams use modified Fibonacci series and have highest scale of 21 to size a story. As discussed above, the Fibonacci numbers are 60% above than the previous number, and that helps in relative sizing. Summary There are various methods to estimate user stories, like T-Shirt sizing, Dot voting, Affinity Mapping etc. Story points is the widely used measurement for sizing the user stories. Fibonacci series helps the team to compare between two stories; and its very nature of distinguishable values helps them to fit the story into the right size that reflects uncertainties, which further helps the team to refine the story to remove those uncertainties. Hope this article was useful to you.
Rated 4.0/5 based on 13 customer reviews
Why Do We Use Fibonacci Series for Estimation
Blogs
5898
Why Do We Use Fibonacci Series for Estimation

In this article, my focus is on sharing my expe... Read More

PRINCE2®Agile vs PMI-ACP®: What’s Best for You?

Changing industrial trends and the mass adaptability of agile practices have transformed the way organizations work. Over time, a number of project management methodologies have cropped up to suit different industry needs, and today’s business leaders have a wide array of frameworks to rely upon. This has led to the inevitable need for skilled project management professionals who are well-versed in different frameworks. When it comes to the widely popular Agile methodologies, the presence of multiple certifications in agile / agile project management methods can seem overwhelming to aspiring professionals. This article will give you a comprehensive overview of PRINCE2®Agile and PMI-ACP® (Agile Certified Practitioner) certifications to help you make an informed choice. Project leadingWhat is a Project? Due to the accelerated pace of change, today’s enterprises have to cope with the complexities of emergent requirements over the course of a project. Strategic business decisions are often made after taking stock of competitors’ actions, technological advancements, regulatory changes, ongoing business developments and so on. In order to compete and thrive in the future, existing ways of working must be aligned to adapt to these evolving needs. Example: Today every bank across the globe offers innovative banking products and services like mobile banking applications, ATMs etc. These changes have been adopted to cater to the evolving expectations of customers while adapting to the latest technological advancements. Projects are the means of introducing change. A collective effort from different stakeholders needs to be pumped into the project initiatives to deliver the products and to accomplish the objectives within definitive timescales. Example: The Ministry of Health & Family Welfare of a country is planning to design, build, roll-out and implement a Health ID card system for its citizens within a year. This project will benefit the government and its citizens in various ways. Different organizations such as government, health ministry, hospitals, technology providers have to work collaboratively to implement the product within the identified timescale, cost and quality. Project Manager planningWhat is Project management? When different stakeholders come together to deliver a unique product within an estimated timescale and cost, there should be someone who needs to be accountable and responsible to manage the different aspects of the project.  Project management broadly revolves around key activities such as plan, execute, monitor and control. Management of projects is an art which includes skills like leadership, domain knowledge, interpersonal skills, people management, powerful communication, stakeholder engagement, conflict management, business acumen etc.,  Example: A central library run by a private firm is looking to launch a digitized version of its books. A Project Manager is identified to manage the scope, cost, time, quality, risks, resources, stakeholders, communications etc., from the beginning to the end of the project.  Project managers and their organizations can choose to apply the right methods, tools, techniques, standards, guidance, good or best practices to run their projects.  Why agile in project management?  As digital transformation is catching up with many organizations, business demands are also increasing, and the requirements for products and services is continually evolving as well. To meet the demands of businesses today, project-driven organizations should look for ways to increase the speed of product delivery while upholding quality. Agile project management is an iterative approach to delivering a project throughout its life cycle. The Agile framework helps project managers to stay on top of emergent requirements and adapt to change more readily, delivering products that are better aligned with customer expectations. With agile methods such as Scrum being widely accepted and used in today’s organizations for software development projects, more agility is seen in the delivery teams. Product development in Scrum teams occurs in shorter iterations/timeboxes (2 weeks to 4 weeks). This is because the goal is to deliver minimum viable products (MVP) or a feature/functionality within shorter sprints. Example: As a part of digital transformation, a school wants to launch a mobile app. In the beginning of the academic year, the first section of the app was ready and launched for use. During the launch, it only had a login and a digital diary feature. In the second month, they added a few more features such as timetable, attendance tracker. In the third month, new enhanced features such as progress card, online payment options were added. By the end of six months, the app had varied features to suit the needs of the school, teachers, students and parents and it added value to all categories of stakeholders iteratively.  The Contrast of Waterfall Vs. Agile ways of working:The Contrast of Waterfall Vs. Agile ways of working:The reason for agile’s popularity is because of its ability to address the new demands being placed on the project team.  Prince2 ProcessesWhat is PRINCE2®? PRINCE2® (PRojects IN a Controlled Environment) is widely considered the leading project management method. It is a unique, light weight, scalable, flexible, highly tailorable, principle-driven, agile enabled framework to run your projects.  PRINCE2 revolves around the concepts of principles (value statements), themes (focus areas to run the project) and processes (steps involved to accomplish project objectives).  Let’s get introduced to the PRINCE2 elements: Principles: Continued business justificationBusiness valueLearn from experienceLessons are sought, recorded and acted upon; continuous improvementDefined roles and responsibilitiesAll stakeholders representedManage by stagesProvides management control and realistic planning horizonsManage by exceptionAuthority delegation for directing, managing and delivering within tolerancesFocus on productsQuality-centric approach to planningTailor to suit the projectTailor to suit project environment, size, complexity, importance, risk, etc.Themes:Business CaseWhy?OrganizationWho?QualityWhat?PlansHow?, How much?, When?RiskWhat’s the impact?ProgressWhere are we now?Where are we going?Should we carry on?Processes:Starting Up A ProjectVerify whether the project is worthwhile and viable.Directing A ProjectDecision making, allocation of resources and estimating expenditure.Initiating A ProjectSetting up a firm foundation (controlled environment) for the project.Managing Stage BoundariesPreparation for management review including stage planning.Controlling A StageDay to day management of the work, issues and risk.Managing Product DeliveryProduct creation, delivery and acceptance.Closing A ProjectFinal delivery, acceptance and project evaluation.PRINCE2® Process Flow Diagram:PRINCE2® Process Flow Diagram:Processes are at the core of the PRINCE2 framework. Application of themes, principles and tailoring of the processes makes it easy to adopt and adapt which reduces the bureaucracy of project management. At the same time, it provides the proper governance to keep the projects justified.What is covered in PRINCE2 Agile™?Project EnvironmentIf PRINCE2® is already agile, what is PRINCE2 ® Agile? PRINCE2® Agile guidance is all about tailoring PRINCE2 to incorporate Agile methods. PRINCE2 is a neutral project management framework which can support both traditional waterfall projects as well as agile or adaptive or iterative projects.  To provide guidance on how to integrate high velocity models or practices into the existing projects for both IT and non-IT industries, PRINCE2 Agile considers Scrum, Kanban, Lean approaches. The intention is not to explain all the agile frameworks in detail; but rather is to show practitioners how to amalgamate PRINCE2 with other agile practices. PRINCE2 considers agile as a collection of behaviours, concepts, frameworks and techniques.   In a nutshell, PRINCE2® Agile is basically a marriage between PRINCE2 and Scrum practices.  PRINCE2’s core concepts of principles, themes and processes are tossed up with agile concepts, techniques, behaviours, practices which fuels more velocity into the existing framework.Certification: PRINCE2® Agile has two levels of certification (Foundation and Practitioner) Foundation Exam: Multiple choice 50 questions 1 hour to complete the paper Achieve 28 or more out of possible 50 marks (55%) to pass the exam Closed book exam Practitioner Exam: Multiple choice 50 questions based on project scenario 2 hours 30 minutes to complete the paper Achieve 30 or more out of possible 50 marks (60%) to pass the exam Open book exam. You can use the “AXELOS® PRINCE2 Agile™ guidance book”.  Certification Scheme: Prior project management experience is not required to take up the certification.  What is covered in PMI-ACP®? The Project Management Institute’s Agile Certified Practitioner is a credible certification which provides thorough knowledge to project managers using agile methodologies.  There are many agile practices other than Scrum that are widely used in the industry such as eXtreme Programming, DevOps, Test Driven Development (TDD), Behaviour Driven Development (BDD), Feature Driven Development (FDD), Crystal, Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Dynamic Systems Development Method (DSDM), Kanban, Lean Product Development etc., Most of these practices revolve around the core concept of iterations with other variations. Most of these practices are ‘IT-only’ frameworks.  Agile mindset and principles play a vital role in executing the projects in a different way as compared to the traditional ways. Right from covering the concepts of agile values, mindset, practices, terminologies, most of the above-mentioned agile models are covered in a greater detail in this program.  Concepts and techniques like agile contracting, agile risk management, earned value management (EVM), cumulative flow diagrams (CFD), estimation techniques, relative prioritization, work in progress (WIP) limits, Kano analysis, product backlog grooming, personas, user stories, story maps, wireframes, product road map, minimum marketable feature (MMF), definition of done, continuous integration, burn charts, stakeholder engagement, leadership, building agile teams, coaching, osmotic communication, timeboxing, planning poker, release planning, problem solving, lead time, cycle time, defect rate, control limits, throughput, velocity, variance and trend analysis, value stream mapping, continuous improvement, retrospectives, learning cycles etc., are imparted as a part of this certification course.Certification: 120 Multiple choice questions 3 hours to complete the exam Closed book exam Prerequisite: Secondary degree 21 contact hours of training in agile practices 12 months of general project management experience within 5 years.  8 months of agile project management experience within the last 3 years. Differences in these certifications:ParametersPRINCE2 AgilePMI-ACPTopics coveredIt is a blend of  PRINCE2® and Scrum.Spans across many approaches of agile.Governing bodyAxelosProject Management InstituteExam bodyPeoplecertPearson VUEExam modePaper-based test, computer-based test and Online proctored examOnline proctored examPrerequisiteNo prior project management experience is required. PRINCE2 Foundation or PRINCE2 Agile foundation certification is a prerequisite for taking up the practitioner exam.Secondary degree21 contact hours of training in agile practices12 months of general project management experience within 5 years.  8 months of agile project management experience within the last 3 years.Training4 days of training from an Accredited Training Organization (ATO) by Axelos3 days of training from a Registered Training Partner (REP) by PMICost of training & certificationApproximately Rs. 40,000 to 50,000Approximately Rs. 40,000 to 50,000Maintaining the certificationFoundation certification has a life time validity. Practitioners need to earn 20 continuing professional development (CPD) points every year.Earn 30 professional development units (PDU) every three years.Merits and demerits of both these certifications: Merits of PRINCE2® Agile:  PRINCE2 Agile provides a good governance model to run the project with guidance on how to incorporate any agile model.  It does not favour one agile approach over any other although Scrum is taken as a reference to explain the concept of tailoring.  It can be applied to any type of project and can easily be implemented alongside specialist, industry-specific models.  Demerits of PRINCE2® Agile:  It does not touch upon the various project management tools or techniques which are essential for project management. Merits of PMI-ACP®: It prepares the project managers to become versatile with different types of agile project management practices. Coverage of different types of tools and techniques polishes one’s ability to manage scope, cost, time, quality, risks, resources, stakeholders, communication etc. Demerits of PMI-ACP®: It does not have an exclusive body of knowledge (BOK) like PMBOK® guide. Reference to different literature and books may be essential. This means a structured way to agile project management is missing in its approach.  The best-suited certification: How to pick the right one? PRINCE2® Agile can benefit the existing PRINCE2® community, PRINCE2® Practitioners, anyone who is using agile in Project Management. Even organizations and individuals outside the PRINCE2® community, having experience with agile can benefit from this certification. It is also ideal for total novices. If you fall under any of the categories mentioned above, you can pick this certification as your first step in the project management world. This is also the right choice for professionals and enterprises that serve clients based in UK, Europe and Australia. PMI-ACP is a one-stop solution for project managers and agile teams keen on expanding their skill-set to manage various agile projects. If you are ready to dedicate at least 2 hours every day for 1 to 2 months for exam preparation and earn a globally recognized certification, go for it.  Conclusion: Every practice has its own strength and weakness. Ultimately, it is up to the organizations and practitioners to choose the right project management methodologies to suit their needs and business/career goals.  
Rated 4.0/5 based on 22 customer reviews
PRINCE2®Agile vs PMI-ACP®: What’s Best for You?
Blogs
5926
PRINCE2®Agile vs PMI-ACP®: What’s Be...

Changing industrial trends and the mass adapta... Read More

How Does the Product Owner Manage Various Stakeholders?

As you know, Scrum has the 3 most important roles, which are Product Owner, Scrum Master, and the Team. Apart from these core roles, we have involved stakeholders. It is very important to manage various stakeholders to let the project go in the right direction. Now, when it comes to the Product Owner, one of the most important roles and responsibilities is to manage stakeholders. Managing their requirements, their areas of interests, areas of conflicts, and a lot more.  This article is going to talk about the Product Owner roles and responsibilities. Furthermore, It gives you insights about who all are the stakeholders, what does it mean to manage the stakeholders, what should be the process, and the further best tips to manage stakeholders. Let’s get started with understanding the basics first. Stakeholder ManagementA stakeholder is anyone interested in the product or we can say who is influenced by the product or involved in the product.This can be anyone who has a certain type of interest in the project, be it financial interest, someone who has invested, or it can be someone who is going to use the product, which could be customers. We will understand the various types of stakeholders in the coming section of this article.Now, coming to stakeholder management. Stakeholder Management plays a vital role in project success. It is basically about maintaining good relationships with the stakeholders, or we can say manage them to make them respond positively towards the project. We will understand various ways to implement this in the coming sections of the article.Let us first understand the roles and responsibilities of a Product Owner before we dive deep into managing stakeholders.Stakeholders and Product Owner Product Owner Role and ResponsibilitiesThe product owner is the most important person, who “owns” the product. This person is responsible for the Product Vision.A key decision-maker and responsible for the ROI of the businessResponsible for understanding the end customers and creating the product backlog requirements accordinglyResponsible for product backlog management (Prioritizing and Managing it)Responsible for reviewing and checking the potentially shippable product increment deliverable at the end of the sprintProviding feedback to the team at the regular intervals to make sure the product development is moving in the right directionRefining the product backlog, based on the feedback and changing market needsAnd not to forget, managing stakeholders!Now that we understand the Product Owner deeply and it’s responsibilities, let us understand the Stakeholders.Understanding the Various StakeholdersStakeholder A famous “Chicken” and “Pig” story in Scrum is one of the very good examples that explain how “Chicken” represents the stakeholders who are merely “involved” and “Pig” represents roles like Product Owner, Scrum Master, and the team, which are not only involved but “committed”. Someone who is not part of the team but still has an interest and involvement in product or project development and it’s progress. However, someone who would be affected by the project or product development.  This can include:Directors, Decision Makers at the organization End Users/End Customers Product Sponsors Marketing team Legal entities Etc. It is very important to take care of these Stakeholders and fulfill all their requirements during and after product development. Now, when we see Stakeholders, this will contain different sets of people and with different roles. This can include some really good stakeholders who would always encourage the team and provide constructive feedback. However, on the other hand, this can include some challenging stakeholders, who don’t support or provide any feedback. This is where comes the need for management of stakeholders. However, if we go with the management, it’s like managing people, because stakeholders would include people with different roles.  However, we will look at the larger picture here and see how to manage stakeholders. Let’s have a look at it by putting our feet into the Product Owner’s shoes.  Reviewing Stakeholder Management Process  As we got an idea that Stakeholder could be someone who would either support or someone who would either oppose. The process of managing these stakeholders is Stakeholder Management Process. It involves managing their expectations, communication, requirements, etc. It involves 4 different steps which will talk about:1. Identifying the StakeholdersIdentifying StakeholdersThe very first step that comes in the Stakeholder management process is “Identifying the Stakeholders”. This can be anyone who is involved in the project or is affected by the project. Let us have a look at different aspects for identifying the stakeholders:Someone who has an impact on the project Someone who has an opinion or a point of view on the project Someone who has a decision making power Someone who would like to see your project successful Someone who would like to see your project fail Someone who has an impact over your team Someone who can help resolve conflicts or remove challenges Someone who simply have an interest in the project Once, we list down and identify the stakeholders, it is easy for us to categorize them based on different aspects. This whole process is identifying the stakeholders. Once we know them, it is easy for us to manage them.2. Analyzing the StakeholdersAnalyzing the StakeholdersThere are several ways to analyze stakeholders. We will have a look at the two most important ones. The first one is Power-Interest Graph. Power-Interest Graph Power-Interest GraphHigh Power, High InterestThese stakeholders are mostly the decision-makers or the key-players. They can impact in a way that can make the project successful or fail. They are very easy to identify. Now, when it comes to communication, they should be actively engaged! These stakeholders are highly powerful, so we must try to meet their each and every requirement, otherwise they can even cancel our project if not satisfied.High Power, Low InterestThese stakeholders again have decision-making abilities but they are not so much interested. A lot of communication can make them disinterested in the project or product. They lack interest and therefore, they should be kept satisfied!   Do whatever it takes to keep them satisfied.Low Power, High InterestThese stakeholders are the ones who have less power over the project but they are keenly interested in what’s going on. They might impact the project, so it is important to keep them informed!Low Power, Low InterestThese stakeholders are the ones who are merely present and don’t expect to be involved much. They might not be interested and might not be expecting any sort of communication. It is important, you just monitor them!Now that we saw the Power-Interest Graph, another interesting way is the Stakeholder SWOT Analysis. Let us have a look at that one as well.Stakeholder SWOT Analysis. Another way is to analyze the stakeholders based on their Strengths, Weaknesses, Opportunities, and Threats. What will be their Strengths and Weaknesses? What will be the opportunities and threats they would bring to the project? This will help analyze them better. SWOT Analysis 3. Prioritizing the StakeholdersFor a product owner, prioritization is like an ongoing activity. Just like they need to prioritize the backlog, a similar way, they need to prioritize the stakeholders. After the successful identification and analysis, once they are prioritized, they can be taken care of accordingly. This way, product owners can develop the communication plan and can further deliver the right message to the right stakeholder at the right time.4. Engaging the Stakeholders This is the last step where execution takes place. Now that we have identified, analyzed, and prioritized the stakeholders, this is where we will implement the communication plan. Determine different action plans, whether are going to have one on one conversations, meetings, or going to communicate through emails. We define and execute our plan accordingly and keep the stakeholders engaged as required. Thus, managing all their expectations.5 tips for the Product Owners to manage stakeholders effectively   By now, we know how to identify the stakeholders, analyse them, and different steps of the management process. Let's have a look at some of the best practices which Product owners can follow to manage stakeholders effectively: Don’t treat Stakeholders same. As we have seen the matrix above on identifying, analyzing and prioritizing the stakeholders. It is very important for the Product Owners to treat them accordingly. Based on our analysis, we categorize them and then based on our categorization, Product Owners need to treat them. Act like an Owner. Being a Product Owner is a great responsibility. It is the person responsible for the ROI of the business. With responsibility comes the authority. It is very important you act like an “Owner”. This not only gives you the power over stakeholders but also helps manage them more effectively. Communicate Upfront. Never hesitate to say “No” to the stakeholders. Being a product owner, you know what is good for the project and what is bad for the project in order to make it successful. As and when needed, for certain decisions and for the benefit of the project, feel free to say “No” to the stakeholders and be upfront in doing so. Set Expectations. It is very important that being a Product Owner, you set all the expectations with the stakeholders. Understanding what they need to know and what they are expecting out of the project. Further, You should be communicating with them in terms of their expectations only. Involve Scrum Masters. We know that Product Owner is responsible for managing the stakeholders, but this is not mandatory that Product Owner should do it all alone. Have your Scrum Master besides you to support you with all sorts of process questions, which can eventually help you manage the stakeholders more effectively.  These were some of the best tips to manage stakeholders effectively and efficiently.   To conclude, we discussed several types of stakeholders and we looked at the process of managing them. The major takeaway from this article is understanding the stakeholders. For understanding and managing them, Remember the 4 key points, which are Identifying, Analyzing, Prioritizing and Engaging the stakeholders. For engaging with the stakeholders, which involves the execution, we have provided you with 5 tips for the product owners to manage stakeholders effectively. Stay tuned for more such articles!
Rated 4.0/5 based on 13 customer reviews
How Does the Product Owner Manage Various Stakeholders?
Blogs
9020
How Does the Product Owner Manage Various Stakehol...

As you know, Scrum has the 3 most important roles,... Read More

Understand the Importance of Having the Product Vision in a Scrum Team

Stories abound of products launched with much fanfare and failing miserably in the market. What does it take to build a software product that sells? Would the best technology, the best architecture and the best brains guarantee a product that will sell?A lot of energy is spent by the Engineering teams on building the product right – bug-free, scalable, reliable and secure. Throughout this journey the teams also need to be confident that they are building the right product – usable (fit for use), serves the purpose (fit for purpose), solves the customer’s problem and delivers value.A popular representation of this relationship is given belowA Product Vision is a well thought through “future state” of the product that serves the customer’s needs as well as furthers the organization’s product strategy. The product vision serves as the “guiding light” that the teams constantly refers, consults and steers towards.This article is about how a good product vision paves the way for scrum teams to build a good product. It is not the only step but definitely one of the first steps to build a product that will sell.Components of a Product Vision  A well thought through and finely articulated Product Vision includes the following components Purpose and Intent – Why are we building the product and what value it brings to the Customer? What problems is the product going to solve for the Customer? Target Market – Who is the Customer(s) / Market Segment that the product is meant for Business Goals – By building this product how are we aligning with the organization’s strategy and goals in the market. Every product offered by an organization should align with the larger goals and strategy so that it fits well with the organization’s product portfolio. Differentiating Factors – How and what features are we offering that is a differentiator in the market and which sets the organization apart from its competitors. Many a product fails to see the light of the day or serve the purpose of the customer if it has failed to justify on any one or more of the above components.  Creating the Product Vision Anyone who is connected to the Product can contribute to the Product Vision. Organizations usually have idea boards and forums to welcome innovative ideas from all employees. But the ownership of defining, communicating and nourishing the product vision lies with the Business Group or Product Management Group. Usually the vision is created through a Workshop involving the right stakeholders who have the expertise to contribute. The stakeholders represent Business, Engineering, Marketing, Sales, Support, Training etc.  Various techniques such as Brainstorming, Affinity grouping, Dot Voting can be employed in the workshop to come up with the final Product Vision. Prior to the workshop findings from Market research on target customers, competitors, information on Personas are made available to the participants so that they are well informed and bring the best to the table. Product Vision Formats The Product Vision board as recommended by Roman Pichler, leading Product Management Expert. The Product Vision Board A Simple template first introduced in the book Crossing the Chasm by Management Consultant and author Geoffery More.Communicating the Product Vision  A great Product Vision will not get realized into the final product unless it is communicated well, not just once but multiple times, to all the important stakeholders – the Senior Leadership, the Engineering teams, Sales, Marketing, Documentation, Training and Support. It is the responsibility of the Head of the Business (e.g Director of Product Management) to introduce and explain the Product Vision to the rest of the organization before the product development is started. A Kickstart All-Hands meeting usually happens when a new Product Vision is ready. The road map and strategy for the immediate future (every Quarter/Release) to realize the vision is also shared in this meeting. It is important that all stakeholders who are participating in building the product gets to hear the same information at the same time from the Head of Business. This All-Hands happens at a defined cadence (every Quarter /Release) where the changes to the product vision, strategy and road map for the next quarter /release is communicated. The Heads of Engineering would also present their plans for the Quarter /Release to further the product vision.  Heads guiding the team It should not be an open and shut communication for a day, but the Product Managers and Owners need to constantly refer and draw from the vision when interacting with the Scrum Teams. When requirements are refined into Epics and User Stories and prioritized the Scrum Teams need to be able to relate them to the Vision. Changes in the Product Vision  So is a Product Vision written on stone never to change? No, because that would defy Agile Principles of continuously seeking feedback, embracing and adapting change.  A learning organization has a pulse on the market and actively seeks feedback. It adapts the product vision according to the changing market, competition and customer feedback. It has a constant sense of Urgency to Fail Fast, has the Courage to Pivot when required and Persevere on the right track as part of the Organization culture.  There are stories of many organizations that have imbibed and practiced this culture and succeeded. Significance of Production Vision within the Scrum Teams A journey without a destination sounds exciting but not practical and not always fruitful. R&D engineers would not have any dearth of imagination to build products that are beautiful and perfect. But would these products serve the customer’s needs? Understand the Larger Purpose: Scrum teams need to understand the big picture and the larger purpose of their everyday work – for whom are they building, for what and most importantly why. During Backlog Grooming sessions, the Product owners can act as ambassadors for the Product Vision helping the teams to refine user stories with end goal in mind. The questions to be constantly asked and validated include  “Are we solving the customer problem?” , “Are we adding value?”, “Are we building the right product?” Product Strategy and Vision to Plan your roadmap Contribute in Product Strategy and Roadmap: Scrum teams can contribute effectively to the product strategy and roadmap if they know and understand the product vision.  Understanding the Priorities: Understanding the Product vision helps the team to identify with the priority put forth by the Product Owner. The Product Owner and the teams can make use of the product vision in the Sprint Planning and Backlog refinement meetings to streamline user stories.  Influence in Sprint Execution: Having the product vision in the back of their minds plays an important role in the story writing, refinement, acceptance criteria, coding and testing.  Knowing the customer problems and target market helps teams to build “just enough” and stop from over engineering and manufacturing unwanted imaginary requirements. Unwanted code is a waste that can cause unwanted testing, bugs and needs to be avoided. Knowing the target Customer / market, purpose and the problems that need to be resolved, helps the teams to  Refine and write better Epics and User Stories . Helps to identify the ‘Must Have’ and ‘Good to Have’ Acceptance Criteria. Helps to architect and design better knowing the immediate priority and the upcoming roadmap. Helps to code incorporating enough customization for reuse and extensions in future. Define and formulate the appropriate test scenarios and data Collaboration: Multiple teams come together to build a product. Having a common Product Vision to refer to improves their collaboration and serves as a good point of reference to manage conflicts and dependencies.  Alignment with the Organization’s Goals: There is also another very important piece of information within the Product Vision - How the Product Vision aligns to their organization’s overall strategy. This is definitely of interest to every employee of the organization. An engaged employee always is curious about how the product he is helping to build today fits and aligns with the organization’s goals. The fact that he/she is contributing towards furthering the Organization’s goals does instil a sense of pride and confidence. Adapting to Changes in the Product Vision: The changes to the vision has to be constantly communicated to all the stake holders especially the Scrum teams who are building it. The teams need to also be told why there has been a change in the Product Vision. Only then would they appreciate and embrace the changes. Tips for your Product Vision: Ideas can come in from unlikeliest of places. Inputs should be encouraged and accepted from all stakeholders and funnelled into the Product Vision creation workshop. Prior to the workshop, sufficient Market research has to be conducted to get information on target customer, personas and the competitor landscape. A vision not shared well remains only that and does not become a reality. Communicate at every opportunity – kickoff meetings, through posters and through dedicated ambassadors -Product Owners , Product Managers , Line Managers. Seek feedback and gauge the market continuously to adapt Do not fear to pivot if needed and change course. Failing early and fast is better. Do not try to address all the “How” and “When” in product vision, but the “What” and “Why”. In conclusion, a Product Vision plays a very important role in the working of a Scrum Team providing the larger purpose of what is being built by them everyday. Only through constant communication about the vision and about the changes to it can the Scrum Teams keep relating to the vision and make the vision a reality - a good product that sells. 
Rated 4.0/5 based on 13 customer reviews
Understand the Importance of Having the Product Vision in a Scrum Team
Blogs
7059
Understand the Importance of Having the Product Vi...

Stories abound of products launched with much fanf... Read More

Agile Project Management: Best Practices and Methodologies

Agile is an iterative and incremental solution development methodology that focusses on delivering value to the customer by seeking customer feedback, embracing and adapting to change and striving for improvement continuously.  The Agile Manifesto along with the Agile Principles are at the heart and in the spirit of the various Agile Frameworks which are being adopted increasingly by Enterprises as their Project Management Framework. Agile Project Management Agile Project Frameworks Scrum, Kanban, XP, SAFe are some of the Agile Frameworks that are have replaced traditional waterfall and predictive approaches of Software Project Management. Long standing philosophies such as Lean and practices like TDD, BDD, Pair Programming etc are leveraged into these frameworks.  Scrum and Kanban are the most popular Agile Frameworks used today with Scrum being used in almost 58% of Agile Projects as per the Annual State of Agile Report 2020. Scrum uses a time-boxed iterative approach to develop incremental products and solutions with each iteration spanning 2 /3/ 4 weeks. Kanban does not have time-boxed iterations and focusses on establishing flow of work by controlling WIP (Work In Progress) and is well suited for maintenance, support or Helpdesk projects. In this article we will discuss about Agile Project Management using Scrum. Before looking at the Scrum framework briefly, we need to understand two very important aspects in which Agile Project Management is different from traditional Waterfall – Scope and Estimation. The Iron Triangle Unlike traditional projects, in Agile the schedule and the cost involved for a project is largely fixed. The scope is the variable entity and is adjusted as per the latest information and feedback from customers. The focus is on delivering value rather than following a rigid and detailed plan laid out at the beginning of the project. In Scrum for example, every Sprint runs for a fixed time-box and changes to agile team composition is not recommended. Iron TriangleEstimation – Relative Sizing Agile recommends “relative sizing“of work items that enables predictability rather than complex estimation techniques striving for accuracyAgile EstimationIn the Image 2 above people on the road looking at the buildings would most likely converge on the fact that Building A is the smallest of the three, Building B is twice that of A , Building C is the tallest – almost 3 times that of Building A. This can be done quickly at the first glance. In contrast if they must estimate the actual height of the building in metres it is prone to error and there are going to be a lot of differences. The power of relative sizing lies in the fact that we do not strive for accuracy (in the example the height of the building in metre) but focus on sizing the work and achieving predictability over the course of time. Instead of complex effort estimation in man days/hours, High level Epics /Features are usually estimated by the T-shirt sizes (Small, Medium, Large, X-Large) and Stories are estimated and given “Story Points” that follow the  modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) Brief overview of Scrum Framework The Scrum framework comprises of the roles, events and artifacts and describe how these entities interconnect with each other in order to implement the framework.   Scrum follows an iterative approach where development cycles are 2 /3/4 weeks long. At the end of every iteration an incremental version of the product/solution is ready to be shipped. Each event /artifact/role in the scrum framework serves a purpose and furthers the goal of Agile project development. Let us go over each of them in detail. Scrum FrameworkRelease Planning Although Agile does not recommend detailed rigid plans laid out well in advance, it does not altogether forego planning. There is a high-level Release Planning at the beginning of the release and shorter detailed Sprint planning events at the beginning of every Sprint. Having short planning phases throughout the project implementation helps to adapt to changes and course correct at responsible milestones. For large organizations where multiple scrum teams work towards developing a solution, planning and timing a release is very important. The organization might choose to time the release as per Customer(s) demand or at an established cadence (e.g every quarter) or in alignment with certain events (e.g tradeshow/ compliance deadline etc). The release planning is a look ahead planning with an objective of arriving at the scope of the release considering the schedule and budget as fixed components of the iron triangle. The two important inputs required for this event is a prioritized product backlog and the velocity of the teams participating in the release (historic data for teams running on agile and an informed guesstimate for the new teams.) The teams will roughly plan out their upcoming sprints (if a release spans 12 weeks there can be 5 sprints of 2 weeks each followed by a 2 week “hardening sprint”). At the end of this planning event there is a list of prioritized features that can be accommodated in the release and a high-level plan for each sprint.  Scrum Roles  The Scrum Master, Product Owner and the development team form the “3 Amigos”. There is a good amount of trust and a healthy relationship amongst the people playing these three roles. Healthy conflicts and disagreements between these three entities is expected and bound to occur. At these times the teams are guided by the Scrum Values of Respect, Courage and Openness. At all times the scrum team practices commitment and focus to achieve the Sprint Goals and further the Agile Values and Principles. The Three AmigosResponsibilites of Each RoleResponsibilites of Each RoleScrum Artifacts Product Backlog: A Product Backlog consists of all the new features, changes to the existing features, technical requirements such as infrastructure upgrades or architectural requirements that might become a part of the product. This is continuously refined by the product manager, product owners and the scrum teams. The purpose of the refinement is to prioritize, split and detail the contents of the backlog so that the first set of items in the backlog are ready to be picked by the teams during their Sprint Planning. Sprint Backlog: The items picked from the Product Backlog and committed by the team for a Sprint constitutes the Sprint Backlog. It is unlikely to change during the course of the Sprint/iteration. A product owner could introduce changes in consensus with the team. Multiple changes to the sprint backlog within the Sprint timeframe should be discouraged and root cause analysis has to be performed during retrospective meeting if this happens often. Product Increment: The work items ready to be delivered at the end of a Sprint is a Product Increment. It has to be in a potentially shippable condition and meet the definition of done as defined by the team and has to be accepted by the Product Owner as complete and ready for release. Scrum Ceremonies / Events EventFrequency of OccurrenceDescriptionBacklog RefinementContinuousEpics and features are estimated and broken down to Stories. Stories are broken down and acceptance criteria are added. The Backlog is prioritized and ordered.Sprint PlanningOnce at the beginning of a Sprint lasting up to 4 hours for a 2-week SprintThe top priority stories that are refined and ready for the team is picked. The teams estimate the stories and load the sprint up to their Capacity. The historic Velocity and the current capacity (leaves and holidays adjusted) are taken into account for loading the Sprint.SprintCan be 2 /3/4 weeks longNot recommended to change the Sprint duration often. The cadence once set has to run for at least 3 to 4 Sprints to collect data for becoming predictable.Daily Stand upEvery day for 10-15 minutesThe Scrum Master facilitates the event and the team shares the happenings of previous day, strategize and plan for current day. Impediments /concerns are raised.Sprint ReviewOnce at the end of the SprintThe working software is demonstrated to stakeholders. Based on Sprint Review and outcomes, inputs and changes are done to the Product BacklogSprint RetrospectiveOnce at the end of the SprintThis is the "sacred time of learning" for the entire team. Issues and problems faced during the Sprint are discussed, root cause analysis performed and team arrives at solutions to resolve and prevent in future. The team identifies areas of improvement.Scrum ceremonies or eventsScrum Values  Courage - Every team member feels safe to fail and learn, to seek help, to say ‘no’ and question something that is going wrong. Commitment – Commits to the Sprint goals as a team. Does not overcommit.  Focus - Aims to complete what is started and steer away from distractions and unprioritized / "shoulder tap" work. Limits Work in Progress. Openness - Seeks and values feedback and opportunities to learn. Makes impediments, failures and learnings visible. Respect - Team collaborates and acknowledges the work and achievements of every member. Builds trust. Quantitative Metrics Organizations can collect and measure various metrices. The below metrics are most likely to be captured by most of the projects and add value. Burn Down Chart: The Burn down chart is a run chart of the rate at which the scrum team completes work within a sprint in terms of number of Story points completed per day.  Velocity: Velocity is the number of story points completed and accepted by the Product owner within a Sprint.  Collecting data on velocity enables teams, releases and projects become more predictable. Other than the absolute velocity, another important perspective of velocity data is % of story points delivered against total story points committed by the team. Velocity cannot be used to compare the efficiency of teams since 3 story points for one team is different for another team. Quality related Metrics: Quality related metrics like number of defects reported in production after release, number of defects in Integration testing are captured to understand the level of Quality. Armed with quantitative data the teams can come up with ways to improve Quality.  Quality related MetricsAgile Projects at Scale While the scrum framework prescribes the guidelines to run an Agile team, the same can be extrapolated and mechanisms can be put in place to scale it to multiple teams. SAFe and Nexus offer frameworks to scale Agile in large Enterprises. Large projects in Enterprises involve multiple teams and dependencies with other functions, divisions and with third party partners, suppliers and vendors. The complexities of large solutions and programs require Governance, Compliance, Stakeholder Management, Streamlined Communication, Conflict and Risk management. The Agile Program Management Office takes care of establishing Agile at scale with the help of Senior Leadership, Agile Coaches and Change Agents (who could be the Agile Project Managers and Scrum Masters). Role of the Agile Project Manager The Agile PM plays an important role when doing Agile at scale in large enterprises. While working towards a seamless project release by interfacing with the multiple scrum teams and various stakeholders, the Agile PM also plays a key role in the Agile transformation journey of the Enterprise.   Agile at ScaleAgile Project ManagerScrum Master and Agile PM Roles Agile Projects at scale requires the role of a Scrum Master for the internal functioning of the team and the Agile PM for aligning multiple teams and orchestrating the activities of a Release. Agile PMScrum MasterTakes care of the facilitation, risk management, conflict management, handling of impediments that span multiple teams and external stakeholders.  Engages closely with Senior Leadership, Product Managers, Product Owners, Scrum Masters to ensure smooth implementation of the current release, forward plans for the subsequent release and co-ordinates the Post production activities of the previous release. Facilitates the Scrum of Scrums synch meetings at a regular cadence (every week).  The Agile PM guides the scrum masters to resolve risks and impediments within the team if and when escalated. Takes care of these activities within the scrum team. The Scrum Master focuses on the current sprint and current release. Facilitates Scrum Ceremonies. Participates in the Scrum of Scrums and updates if the team is on track to meet the Sprint Objectives and if there is any change/ risk foreseen. During this meeting the Scrum Masters raise any impediments /risks/concerns they are unable to resolve and need help with. Release Management Continuous Integration and Deployment: With incremental versions of the product after every iteration from multiple teams early continuous integration is the need of the hour. Investing in an automated Continuous deployment into the Staging or Production environment is encouraged so that the latest version of the product is release ready. Enterprises are increasingly using toggle configurations to switch on/off a set of features so that the release can be done for a particular market segment or can be timed with an important milestone like a tradeshow. By separating the deployment and actual release, there is a lot of risk avoided. The actual product release can be announced at the right time – as per Market demand/ after a robust Beta has been done and feedback incorporated/timed with a compliance deadline or important milestone like tradeshows. Post-production Support: Releasing working software at regular intervals is not the end of the road. Customer Support, training and customer documentation where required is necessary and these activities should also come under the purview of an Agile Working environment.  Beta and Canary Release: Large Enterprises engage with Beta customers to get focussed feedback on the product before a wider market release. Solutions and products can also be released to a particular market segment or a subset of users alone. This is called a “Canary Release”. This phased approach rather than a big bang approach will ensure the risk level is reduced and the quality of the product and credibility of the Enterprise is maintained.  How is an Agile PM different from the Conventional PM  The roles and responsibilities of a conventional Project Manager is now distributed amongst the Scrum Teams, Scrum Master, Product Owner and the Agile Project Manager. But the most important but subtle difference between the Conventional PM and Agile PM is the mindset.  The Agile PM is a Servant Leader who wants to create a self-empowered self-organized team. He/she creates an agile environment where everyone is accountable, there is no fear of failure but the willingness to learn and continuously improve. The Agile PM avoids the traditional Command and Control approach where decisions are taken for the teams. .  There is also a conscious effort to decentralize decision making so that decisions are taken closer to where work is done. There is always an emphasis for visualization of work and transparency. Go-to Traits for a Successful Agile Project Self-Organized Teams: Self-organized teams that are empowered and largely self-sufficient is an important facet of Agile. Teams are used to conventional ways of working where they look up to their superiors for decision making. Decentralized decision making will help largely to create empowered teams Responsive to Change: creating empowered teams enable them to respond to change responsibly with minimum red tape. Quick Feedback Loops: Agile thrives when there are quick feedback loops established so that teams can adapt to change based on informed decisions. Continuous Improvement: Learning from the past and resolving not to repeat mistakes is an important facet of Agile teams. Retrospection at end of every iteration and release is highly recommended. Business Agility: It would not be enough if engineering teams are agile and churn out software seamlessly. “Building the product right “is not sufficient and the teams should “Build the right product”. Solutions and products have to meet the customer needs and solve Customer Problems.  All functions such as product management, marketing, sales HR have to come into the purview of Agile Principles and Values to achieve the kind of Business Agility that is required to be Customer Centric and deliver value. In conclusion, Agile is a paradigm shift from the phased traditional waterfall methods which run on detailed plans laid well ahead. Agile Project Management is the need of the hour considering the rapidly changing market scenario, disruptive technologies and the ever- growing competition.  Before embarking on Agile projects organizations have to invest the time and effort to create a conducive Agile Work environment. The bare basics of Agile training and creation of small Agile teams (5 to 9 members recommended) with the vision to make the teams self-organized need to be in place. Agile Coaches and Change agents have to be identified to ensure the Agile transformation starts and keeps pace with small strides and does not die a natural death with teams, business and leadership falling back to traditional waterfall methods in the name of agile. 
Rated 4.0/5 based on 13 customer reviews
Agile Project Management: Best Practices and Methodologies
Blogs
6653
Agile Project Management: Best Practices and Metho...

Agile is an iterative and incremental solution dev... Read More

Key Insights from the 2020 State of Agile Report

How are agile businesses changing in 2020?  Digital.ai, the creator of the industry’s first intelligent Value Stream, recently published its 14th Annual State of Agile Report, along with a survey addendum to reflect the current 2020 landscape. The report took a look into the enterprise, what Agile techniques companies are implementing, their benefits, and what’s trending. The report provides the most comprehensive data in the world to benchmark your Agile practice and plan your next wave of expansion. The survey documents the experiences of more than 1,100 business and IT professionals across a range of industries and roles worldwide.  About 40,000 Agile practitioners, consultants, and executives have shared their insights to make this the longest-running and largest report of its kind. For the first time, it revealed insights beyond the general results by filtering the results along the demographic lines. The analysis indicates a correlation between the time practicing Agile, the ability to manage the changing priorities, and improved time to market.  In this article, we give you the complete lowdown on the state of Agile in 2020 including the COVID-19 impact and what’s next in Agile. Agile in numbers Let us explore the top responsesto the survey in numbers. Respondents answered their top reasons for implementing Agile techniques, which techniquesand methodologies they employ the most, what tools they recommend most, and the top benefits of using Agile. Top five reasons for adopting AgileTop Five Reasons For Adopting AgileTop five reasons for adopting AgileRespondents were asked why their teams adopted Agile methodologies and techniques. These were the most responded benefits:Accelerate software delivery (71 percent) Enhance the ability to manage changing priorities (63 percent) Increased productivity (51 percent) Improve business/IT alignment (47 percent) Enhance software quality (42 percent)  This year, the reasons for implementing Agile were more about reducing project risks as opposed to reducing project costs.Top five Agile techniques employedThese are the five most used tactics that help teams adhere to the twelve principles of Agile.Top Five Agile Techniques EmployedThe Daily Standup was the most common Agile technique used in organizations. The most notable changes from last year was a decrease in Release Planning (51 percent this year as opposed to 57 percent last year) and an increase in Product Road Mapping (49 percent this year as opposed to 45 percent last year). Top five benefits of adopting AgileTop five benefits of adopting AgileWe see that the top five benefits of adopting Agile are built around speed and adaptability. Project Cost Reduction was last on the list with only 26 percent of the respondents considering it to be the benefit of Agile implementation. Top five Agile methodologies Top five Agile methodologiesThe survey shows that Scrum and its variants are the most common methodologies used for Agile implementation. 3 percent of the respondents didn’t have any idea of the methodology used by their organization.  Top five Agile project management toolsTop recommended project management toolsRespondents were asked if they would recommend the tools on the basis of their experience. Atlassian JIRA and VersionOne were the most recommended tools. Five critical takeaways from the 2020 State of Agile Report Many organizations still learning to adopt Agilepercentage of teams using AgileThe survey showed that only 18 percent of the organizations implemented Agile for all the teams. 77 percent of the organizations had still not implemented Agile in all the company’s teams. With 5 percent of the organizations yet to adopt Agile, there is clearly plenty of area for growth. Agile maturityWhile 95 percent of organizations have some form of agile process in place, practice maturity and adoption remain a work in progress. Around 50 percent of respondents report that less than half of their teams are using agile, and 84 percent acknowledge that their organizations are below a high level of competencies.  Areas other than software development yet to take advantage of AgileAreas of organization practicing AgileAgile practices are not limited to software organizations. The survey data showed that while Software Development continues to be the major area for Agile adoption, other areas like IT and Operations have also started adopting the methodology. Other areas in the organization are yet to take advantage of everything the Agile approach has to offer. More business outcome KPIs, fewer metrics As per the respondents, accelerated delivery speed is the most critical measure of the success of Agile initiatives. Next is improved quality, followed by reduced risk and increased customer satisfaction. Reduced IT costs is low on the spectrum with just 39 percent considering it as important for measuring success.  How success is measured in Agile transformationsAgile success and metricsWhen asked how organizations measure success of Agile transformations, the top measures of success were consistent with those reported over the last few years. Outcomes, customer satisfaction and business value, ranked higher than outputs like on-time delivery and productivity. The survey results for this section remain consistent over the past few years. There might be some ups and downs. But overall, Customer Satisfaction and Business Value are at a higher rank than productivity and on-time delivery. How success is measured in individual Agile projectsHow Sucess is Measured in individual Agile projectAs with Agile transformations, business value delivered, and customer or user satisfaction remained the top two cited measures of success within for individual projects.  Scaling Agile faces culture challengesMethods and approaches of scaling AgileAbout one-third of respondents are applying the Scaled Agile Framework, roughly another third are using other scaling frameworks, and another third stated they didn't know/other. There appear to be several common challenges scaling agile as over 40 percent of respondents cited six different challenges/barriers with adopting and scaling agile practices. These included: resistance to change, lack of leadership participation, inconsistent processes, misaligned organization versus agile values, inadequate management support, and insufficient training.    Challenges experienced when adopting and scaling AgileEnterprises are adopting the framework at a remarkable rate that shows that companies want to get the benefits of a structured framework included in the Lean/Agile BoK of SAFe.  The lack of qualified professionals also remains one of the common challenges with insufficient leadership participation (46 percent) at number 2 and lack of experience or skills with Agile methods (41 percent) at number 6.  The report also shows that culture is at the primary target of change as it affects the thinking and working of the organization. Agile organizations slowly adopting DevOps DevOps practices are a strong partner to agile methodologies, and 69 percent of survey respondents stated that DevOps transformation was either important or very important to their organization. But adoption of DevOps practices lags its important with only 55 percent employing continuous integrations and 41 percent continuous delivery. Only 36 percent practice continuous deployment. The top two benefits targeted are accelerated delivery speed (70 percent) and improved quality (62 percent). But respondents are tackling quality first with 67 percent implementing unit testing and 58 percent coding standards, even higher engineering practices over the 55 percent on continuous integration.  More than half of the respondents reported that their organization was already implementing Value Stream Management (VSM) or have plans to do so. VSM is a combination of people, technology, and processes that maps, measures, optimized, visualized, and governs the business value flow using a heterogeneous enterprise delivery pipeline.  Each level of automation requires investment and additional work to prove its robustness. There are seven prerequisites before improving release frequencies, and that requires investment in aspects of these seven DevOps practices. Even so, there are questions DevOps teams should answer before increasing deployment frequency. Summary of key insights Currently, the Agile approach is predominantly implemented in the software or information technology sector. The benefits an organization can reap once Agile is implemented in other areas as well would be tremendous. Here is a quick summary of key insights from the report: Cost reduction is not anymore one of the primary reasons to adopt the Agile approach. Identifying technical risk before deployment is considered very valuable by 34 percent of the respondents, which was 22 percent last year. Greater Agile maturity is correlated to the time of practicing Agile. The length of time since Agile adoption is also related to the increased ability to manage the changing priorities and improved time market. Organizations that have practiced Agile for more than 5 years have a greater percentage of DevOps initiatives and interest in Value Stream Management.  Companies with 20,000 or more people are more likely to have been using Agile for 5 or more years. Companies with less than 1,000 people correlated to a higher percentage of all their teams implementing the Agile approach.  More than half of the respondents stated their companies are either implementing VSM or have plans to do so.  Risk and compliance increased by 54 percent to be the top value to identify and measure technical risk before the deployment begins. SAFe is the most popular scaling method, increasing 5 percent over the last year. There was a shift in Agile techniques as release planning decreased by 11 percent while product road-mapping increased by 9 percent. This change can be attributed to the increase in CI/CD and better program increment planning. Currently, Agile is mainly confined to software development, operations, and the IT sector. However, it is expected that by next year, the organization will expand agility into areas beyond developing, deploying, and maintaining software solutions. The COVID-19 impact and what’s next in Agile The COVID-19 pandemic has triggered a health emergency worldwide. Leaders across industries are moving promptly to protect employees and build resilience, as the impact of the crisis continues to mount. In mid-May 2020, Digital.ai conducted a brief supplemental survey of respondents to learn more about how the COVID-19 pandemic has affected their Agile adoption. Supplemental findings reveal that: 55 percent say their company plans to increase the use of Agile in the next 12-14 months. This is an increase of 13 percent over the original survey completed just five months ago. 43 percent of organizations say their momentum for Agile adoption has increased over the past 90 days, with 15 percent saying it has increased significantly. 33 percent say they increased or expanded Agile adoption in the last 90 days to help manage distributed teams. In summary, forecasters continue to predict how long the COVID-19 crisis will last, but it seems inevitable that many organizations will be working remotely for the foreseeable future.Implemented correctly, an agile approach can help remote teams function effectively and build resilience for the future.  Following the pandemic, working from home more frequently (perhaps 2-3 days per week) may become an accepted norm for many companies, as this could realize cost efficiencies and prove that an agile, remote working model is productive.
Rated 4.0/5 based on 16 customer reviews
Key Insights from the 2020 State of Agile Report
Blogs
7113
Key Insights from the 2020 State of Agile Report

How are agile businesses changing in 2020?  Digit... Read More