Search

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. 

Agile Project Management: Best Practices and Methodologies

7K
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 TriangleIron Triangle

Estimation – Relative Sizing 

Agile recommends “relative sizing“of work items that enables predictability rather than complex estimation techniques striving for accuracy

Agile EstimationAgile 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 FrameworkScrum FrameworkRelease Planning 

Although Agile does not recommend detailed rigid plans laid out well in advance, it does not altogether forego planning. There is 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 AmigosThe Three Amigos

Responsibilites of Each RoleResponsibilites 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 OccurrenceDescription
Backlog 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 Backlog
Sprint 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 events

Scrum 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 MetricsQuality related Metrics

Agile 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 at Scale

Agile Project ManagerAgile 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 Master

Takes 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 improveThe 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 TeamsSelf-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 aheadAgile 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. 

Radhika

Radhika Subramoniam

author

The author is an Agile Consultant working in the areas of process consultation and Agile coaching and transformation. She has been part of the software product development industry spanning field service, fleet management, telecom billing and network management. 

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

ITIL vs Agile: Make Right Choice for Your DevOps Career

Speed, agility and efficient use of technology has always been a challenge across organizations with complex IT environments. There is an unarguable need to go digital, and to do that, enterprises find that they must scale up and align the scope of their IT services—while at the same time managing to stay on top of the evolving business landscape. Agility and IT go hand in hand. Business agility cannot be achieved without innovative and agile infrastructural support, and organizations must put in considerable effort to upgrade their IT services and boost their tech capabilities. DevOps practices have been proven to alleviate the challenges associated with making IT work to realize business objectives. By integrating processes, people and tech to generate continuous value, DevOps has succeeded in increasing capabilities of delivering high-quality products and services quickly. The  DevOps global market is expected to grow at a CAGR of 18.6 % to reach USD 12.85 billion in the next 5 years (Grand View Research) and DevOps engineers are much in demand across industries and sectors. If you’re seeking a career in DevOps, which certification should you undertake: ITIL® Vs Agile? Let’s find out. What Is ITIL?Source Link: axelos.comTIL (an acronym for Information Technology Infrastructure Library) is a framework that codifies the best practices, processes and mindsets required for a software organization to deliver value through IT services. It deals with an end-to-end operating model that encompasses the creation, delivery, and continual improvement of IT services and products. ITIL has gone through many successive revisions, and the most recently updated version is ITIL 4. ITIL 4 is based on seven guiding principles that include:  Focus on value Start where you are Progress iteratively with feedback Collaborate and promote visibility Think and work holistically Keep it simple and practical Optimize and automate These principles guide all ITSM decisions and actions, and are the basis behind ITIL’s suggested best practices. ITIL 4 incorporates new practices that have been adopted in the decade since the last version refresh; such as Agile, DevOps and Lean IT.What Is Agile?Source Link: invensislearning.comA methodology that is fast growing in popularity, Agile is an iterative approach to project management and software development that helps teams to succeed in the face of volatile markets, delivering quality products and services to their customers. The work is carried out in small iterations, and requirements and plans are inspected and evaluated at the end of each cycle so that changes can be factored in as and when needed. Agile is built upon twelve foundational principles that were first outlined in the Agile Manifesto. These principles encapsulate the thinking behind Agile. They are: The highest priority of Agile teams is to satisfy the customer through early and continuous delivery of valuable software. The customer is at the centre of all processes. Agile teams welcome changing requirements, even if they come in very late in the development journey. Agile processes harness change and can adapt in order to deliver competitive advantage. There is frequent delivery of working software, through iterations that range from a couple of weeks to a couple of months. The shorter timescale is always preferred. Agile emphasizes collaboration, and businesspeople and developers must work together daily throughout the project. Projects are built around motivated individuals, who are empowered with the environment and support they need and are trusted to get the job done. Face-to-face conversation is the most efficient and effective method of conveying information to and within a development team. Progress must be measured and communicated, and working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a consistent pace through the project. Agility enables continuous improvement, with a focus on technical excellence and good design. Agile teams have simplicity at their core. Simplicity is defined as the art of maximizing the amount of work not done and prompts just-in-time development. Teams are self-managed and cross functional. The Manifesto states that ‘the best architectures, requirements, and designs emerge from self-organizing teams. The team sits together at regular intervals to inspect the work done and reflect on how to become more effective. They then recalibrate and adjust their behaviour accordingly. There are many methodologies that come under the Agile umbrella, such as Scrum, Kanban, XP and DSDM. All these methods follow the Agile values: Individuals and interactions (are preferred) over processes and tools  Working software (is preferred) over comprehensive development  Customer collaboration (is preferred) over negotiations  Responding to change frequently (is preferred) to following a plan ITIL Vs Agile – the Key Differences In the DevOps world, the choice between ITIL and Agile has become a topic that is hotly debated. Both methodologies are quite different, even though they have the same end goal: that of creating and delivering value, while optimizing resources.  As ITIL has now transitioned from Version 3 to ITIL 4, it has kept a pace with the speed of today’s businesses. There is, therefore, a visible shift from rigid processes to more flexible, seamless experiences. ITIL 4 has embodied the principles of Agile and offers a more holistic frame of reference to ITSM. The key differences between ITIL and Agile are laid out in the table below:ITILAgileFocuses on processes and practicesAgile is a group of practices based on core values and principlesITIL follows predefined traditionsAgile is innovativeITIL 4 is in sync with Agile practicesAgile embraces and responds to changeITIL does not seek feedback from end usersAgile teams believe in continual feedback, and improve their processes and the product after each iterationITIL requires comprehensive documentationAgile believes in minimal documentation, only when needed and just enoughITIL lays more emphasis on processes than on the customer, and believes that customer value is created by following the right methodology to fulfil SLAs (service level agreements)Agile is customer-focusedITIL creates a stable and sustainable IT environmentAgile has a flexible environment that supports changeHead-to-Head Comparison Between ITIL and AgileITIL and Agile are both essential to the creation of business value. However, while Agile looks at improving the delivery of products or services, ITIL is focused on streamlining processes and practices. Both are complementary components of DevOps, which works to seamlessly integrate the interaction and flow between the two IT functions of development and operations. By blending together the key points of both frameworks, a successful DevOps culture can be built.Can You Integrate Agile and ITIL?As technologies keep evolving and organizations step up to stay ahead of these advancements, IT teams find themselves at the centre of transformations. Technologies like cloud computing, AI and IoT have fuelled innovative ways of working, which require agility in order to embrace the transformative changes necessitated by the industry.  Both Agile and ITIL have always focused on building products or services that meet customer needs and deliver high quality. They believe in keeping processes simple, acting quickly and streamlining value delivery—together offering a blueprint that maximizes the creation of value. With the advent of ITIL 4, the ITIL framework had added Agility to the framework, in a transition that has proven to be a gamechanger. ITIL 4 embraces Agile and DevOps ways of working, and encourages a collaborative, iterative, and customer-centric approach to ITSM. ITIL 4 nudges teams toward a new frame of reference that is customer-centric and adapts more easily to what teams need, and how they work. The most radical change that ITIL 4 has brought about to enable this shift is the concept of the Service Value Chain (SVS), which represents the interlinked set of activities that must be undertaken to create highly valuable products and services that are closely aligned to customer expectations. Along the way, inefficiencies, redundancies and bottlenecks are eliminated, improving delivery speed and optimizing resource allocation. Value and value-based tools are given an overarching emphasis in ITIL 4, with Lean thinking driving co-creation of value. By seamlessly aligning Agile and ITIL to drive DevOps, organizations can pave the way to quality services with quick turnaround times. The Last Word Today’s businesses are in a state of constant change with advancements in technologies also happening at warp speed. This unpredictability needs to be reined in to create stability, while at the same time allowing for enough flexibility in order to adapt to the evolving changes. A combination of ITIL and Agile offers the best solution for business service management solutions. A DevOps approach that merges ITIL’s best practices with the smooth change management enabled by Agile, offers the perfect recipe for business success in an uncertain world. 
9884
ITIL vs Agile: Make Right Choice for Your DevOps C...

Speed, agility and efficient use of technology has... Read More

What Is an Agile Environment? Explained With Example

As more and more companies choose to go the Agile way, there is growing appreciation for the many transformational benefits that this innovative suite of methods can provide.Agile represents a radical deviation from traditional, siloed project management processes. It does away with legacy systems and processes, infusing flexibility and the willingness to embrace change. With a network of cross-functional teams working in tandem to deliver products and services that are closely aligned to the changing expectations from the market, Agile is guaranteed to deliver fast, optimize resources and maximize value. The first step in adopting an Agile operating model is to set the stage, laying a foundation where flexibility, innovation and adaptability can thrive—the Agile environment. How can your organization create a fluid environment that fosters the Agile mindset and easily aligns itself with change? Let’s find out. Being AgileAt its core, Agility is much more than a set of principles and processes; and in order to reap the benefits of this methodology, it’s very important to get everyone on board with the Agile mindset. What this means, is that in order to do Agile, you must first be agile. What, exactly, does this mean? The dictionary defines Agility as ‘the ability to move quickly and easily’. And this is indeed the essence of what being Agile is all about.  Simply stated, Agility in project management is the ability to move quickly, easily and adapt to changing circumstances. When project requirements change, the team must analyse the change and course-correct as needed so that they can keep on top of customer needs.  In order to do all this, they must be on board with the Agile mindset. As Steve Denning, author of the book The Age of Agile, put it: “(Agile) is a shift in mindset from a top-down bureaucratic hierarchical approach to a very different way of thinking about and acting in organizations. If you have don’t have the Agile mindset you are going to get it wrong.” What this entails is a complete shift in the ways we think and the ways we do things. When the team blindly follows processes without understanding and internalising the core Agile values, the Agile transformation is unlikely to succeed. What Makes an Agile Environment? Agile follows four values, which inform and guide all the processes and practices in an Agile environment. These are: Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan As stated in the Manifesto, it's not that the items on the right are not valued! It's just that the items on the left are valued more, and that’s what brings about agility. An agile environment, therefore, is one that fosters and supports a culture that encourages teams to work collaboratively toward achieving goals, while implementing the Agile framework and following its values and principles.  Agile environments help teams to be nimble, accept change and adapt to evolving requirements, thus bringing in innovation and creativity in the development lifecycle. An Agile environment will ensure that Agile values are followed.Characteristics of Agile EnvironmentsFocus on customerAgile approaches have the customer squarely in focus at all times. Customer needs are emphasized and the team’s highest priority is to satisfy the customer through quick, early deliveries of incremental value. Stakeholder feedback is solicited at every stage and is incorporated into subsequent iterations. By keeping all those who matter in the loop, customer satisfaction is guaranteed.Embracing changeAgile is all about embracing change. Even late in the development cycle, if there is a change in requirements or features, the team should retract their steps and accommodate the change, rather than stick to a rigid, predefined plan. The team is required to be nimble, adapt and pivot to embrace new, evolving circumstances.Leaving room for innovation Agile does not apply a cookie cutter method to project management; rather, it allows room for flexibility and innovation. Agile teams work in close collaboration, brainstorming to find solutions and working as a team to come up with innovative ideas. Agile fuels new ways of thinking, and comes up with brilliant, ingenuous products and services that are a cut above the competition. Focus on process improvement Agile methods are a natural choice for projects where high quality is a key focus. Agile techniques help teams to improve their processes in a continual cycle, where they inspect, reflect and adapt themselves at the end of each iteration. Process improvement events such as Reviews and Retrospectives are built into each cycle, and teams enhance and deliver value at every stage. Working in iterations The iterative approach taken by Agile focuses on delivering incremental value in stages, rather than all at once in the end as was the case with traditional processes. Each iteration is timeboxed, typically with 2-week cycles, and there is a release of value at the end of each cycle. The product is therefore successively refined and its quality is continually enhanced. Collaboration Agile teams all work together collaboratively toward a shared common goal. They do this through shared responsibilities and accountability to deliver products of value and high quality, as a team. Right from defining tasks and estimating effort to developing, testing and releasing, the team is closely aligned with each other in meeting the shared objectives.Examples of Agile EnvironmentsAn example of an organization that has successfully adopted the concept of an Agile environment is Google. Google’s Mountain View office houses workspaces that are fluid, with plenty of space for functional collaboration. With less space allocated to individuals and more space designed around collective teams, Google teams have a positive, exciting workspace that is fluid and dynamic and supports creating value together. Communal tables in open spaces encourage stand-up meetings, while project rooms on the periphery have tools for group workshops. Teams can use dedicated team rooms with writable wall surfaces and display areas where brainstorming sessions can take place. Facebook, LinkedIn, Airbnb, Salesforce and other forward-thinking organizations have also recognized the importance of providing their employees with creative, collaborative infrastructure and spaces that will help foster innovation and fuel productivity.How to Create an Agile Physical Environment An organization that wants to go agile can start by offering a conducive environment; one that equips its workforce with the right physical infrastructure and tools. They can do this in several ways:  By collocating the teamA collocated team that is able to hold face-to-face conversations is in the best position to collaborate well. When teams are in the same physical space, trust is enhanced, communication is encouraged, and transparency is the result. A workspace should ideally have no hierarchy at all, with open-plan workstations that allow people to collaborate more easily. They can get clarifications at once instead of waiting for online responses, and can help each other when they find themselves in a tough spot. However, in today’s world collocation of teams is not always an option. Teams that are distributed across geographies and time zones can take advantage of online collaboration tools such as Teams, ProofHub, Trello, Asana and so on to stay on the same page and keep in touch on a real-time basis. Set up a dedicated physical space Teams that are in the same location will perform better when they have a dedicated team room where they can work together in close proximity. One wall can be set up with whiteboards and pin up boards for team collaboration, mapping of tasks and so on. The space can be set up to boost productivity; workstations around the edge of the room and a conference table in the middle will work well. Keep the team safe from distractions Any outside distractions, such as interference from management, consults on other projects, and so on will throw the team off track and greatly hinder progress. It is the Scrum Master’s responsibility to smoothen any and all such obstructions, and some of the ways in which this can be done are listed here: Avoid multitasking Work on one goal at a time Let the team figure out who works on what Block any outside distractors Distractions will drain the team’s focus and result in wasted time, energy and effort.  Equip the team with the right tools There is no dearth of productivity-enhancing tools that can help a team stay on track with respect to schedules, budget and resources. Some tools that will enhance the team’s productivity and boost progress are: Zepel Jira Github Wrike Trello Conclusion As hundreds of organizations have found to their delight, an Agile transformation results in real and lasting positive impact. When done right, Agile can empower organizations to outpace the competition, adapt to changing market scenarios, work on innovative solutions to everyday problems, and continuously maximize value.  
8784
What Is an Agile Environment? Explained With Examp...

As more and more companies choose to go the Agile ... Read More

Planning Poker: An Agile Estimating and Planning Technique

One thing that all Agile teams have in common is their capacity to have fun while they work.  are creative, flexible and think out of the box; and working on an Agile team is a far cry from working on a dreary, process-heavy waterfall project. By building in collaborative team activities and doing away with excessive documentation and rigid mandates, Agile team members are always on their toes and passionate about their work.  One of the innovative ways in which they work is by planning Poker, a consensus-based game that helps to arrive at estimates and work out timelines for releases. Let’s find out how to play Poker!  What Is Planning Poker? Definition and Process‘Planning Poker® is the secure, fun way for agile teams to guide sprint planning and build accurate consensus estimates.’ - planningpoker.com  There’s no doubting it; Agile estimation is very hard. A project in which the requirements are continually changing is definitely going to have volatility in terms of timeframes, budgets and schedules. How, then, can the team chalk out a roadmap and figure out milestones and releases? Arguably the most popular way to estimating schedules on an Agile project, Planning Poker is a technique that allows each team member to weigh in on the planning process for each user story.  Here’s how the process plays out: The team uses a deck of Planning Poker cards which have values printed on one side, say  0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. These values represent the units in which the team will be carrying out the estimation, which could be (for example) story points or ideal days. The Product Owner describes a feature that needs to be developed. The team asks doubts, discusses the feature and gets the required clarity. Each estimator holds a set of Planning Poker cards and selects one card in private. The number on this card will indicate their estimate for the work on the feature. They place the card face down on the table. All the cards are revealed at the same time, so that no one is influenced by another person’s decision. If everyone has the same value, that is chosen as the estimate.  If not, outliers are discussed, and another round of estimation is carried out. This process is continued till the team arrives at a consensus for the estimate. The estimates for subsequent features are taken up one by one, in a similar manner. Common PitfallsThe process is not completely intuitive, and while it is simple it could take a newbie some time to get used to the concept. Teams that are new will, therefore, often fall short of the estimate or go too long. However, with experience they will be able to arrive at more accurate estimates. For a sprint with many features, this process could take longer than expected as each estimate might run into multiple rounds of consensus building. If there is one experienced member who is very dominating, he or she might lead the discussions and quell the opinions of others on the team (who might be saying the right thing but might not be heard). Again, this method does not always work well with distributed teams, as for the process to work well, they should ideally be in a face-to-face session. If the story is not fleshed out well, the estimate might not be accurate.Expected BenefitsThe most significant advantage of Planning Poker is that every team member’s voice is heard. This increases team morale and build the right rapport. The group gets into the rhythm of discussing and collaborating on the project, which will hold them in good stead for the rest of the journey. These discussions help to give clarity on the features to be built, and dispel any ambiguity around the user stories. This ‘game’ builds commitment and accountability. As each team member has contributed to the estimate, they will work toward achieving it wholeheartedly. Last but not least, Planning Poker is fun!  Agile Estimation – Relative Vs AbsolutMost of us are used to absolute estimates. Let’s take an example. If you’re asked, for instance, how long you would take to walk three rounds of a park, you’d probably say that you can walk one round at a brisk pace in 8 minutes. You are not going to tell them your answer in relative terms, for example, you would never tell them that you can walk one round in four fifths of the time it would take X to do the same! In Agile, however, we prefer to work with relative estimates, as this offers more flexibility. Story points are determinations of the effort needed to complete task A, relative to the effort needed to complete task B. As there is a lot of uncertainty around the requirements, and the team does not want to spend too much effort estimating on a task that might change very soon, story point estimation is the perfect way to arrive at a rough and ready calculation of the level of effort needed for a task. When Should We Engage in Planning Poker?Typically, a Planning Poker session will be held just after the initial product backlog is written. It could take up to a few days, and is useful in creating initial approximate estimates that will be used to determine the scope, and plan and size the entire project. In an Agile project, it is only to be expected that product backlog items get added as the project unfolds. It would therefore make sense for the team to hold subsequent agile estimating and planning sessions during every iteration. These sessions can be held a few days before the end of the iteration, or whenever the team feels it is most convenient. How Does Poker Planning Work with a Distributed Team?Planning Poker always works best with a team that can sit across a table and hold discussions. However, this is not always possible, especially when teams span geographies and work across different offices.  In such cases, Planning Poker can work over a conference call or a Skype session. A Product Owner could share a set of items that have to be estimated, and the estimators log in at a prescheduled time and pick and show their cards over the video call, in much the same way as they would in a face-to-face session. There is a moderator, usually the Product Owner, who leads the discussions and makes notes. Does Planning Poker Work?Yes, it certainly does, and teams that use this method report that they are able to arrive at more accurate estimates more consistently than when other methods are used. Averaging individual estimates will always lead to better results.The reason for this is that when team members are all allowed to weigh in on the planning process, everyone’s opinion is heard. This is not the case when estimation is carried out by a project manager who does not take the team’s opinions into account. Since it is the team members who are ultimately working on the project, they will have the best sense of the effort needed to finish each task.Tips for Planning Poker in ScrumPlaying Planning Poker for the first time? Here are some tips from the pros, to help you get your game going! While it is definitely a game, it’s a serious game and not to be taken lightly. Each member must carefully evaluate the feature and calculate the time they feel it would take to complete it in its entirety. If they have any doubts, they should get them clarified. The discussion that ensues will help the team to get going in the right direction during the development phase, as it clears the air and removes any ambiguity. Agile estimates are relative and should not be converted to work hours. This will negate the value of using flexible Agile story points. The estimate is team-level and not on an individual level, as the team drives the work. If your opinion differs from that of others, make sure that you speak up. Your understanding of the feature may be the right one. It’s also important to note that the team should never suppress the voice of each individual; rather they should hear what everyone has to say with patience and understanding. Keep the card sizes small. Most teams like to use numbers smaller than 13, as larger stories will not fit into one sprint. If the story is too large, it should be broken down into a manageable chunk of work. Even if someone on the team is new to Planning Poker, make sure that they are not excluded. The entire team must be engaged. Keep expectations realistic. Point value creep, which is a condition where the estimates of stories inexplicably become larger over time, leads to unrealistic expectations and too much pressure from stakeholders. This causes stress and burnout in the long run. In the End.... As with everything to do with Agile, Planning Poker is a process that sounds easy enough but might take time and experience to get right. Take our tips to heart and be wary of the potential pitfalls that we have listed out, and your team will be able to get the most benefit from this tool! 
9884
Planning Poker: An Agile Estimating and Planning T...

One thing that all Agile teams have in common is t... Read More