Category

Courses

Search

Trending blog posts

ScrumXP

This article briefly talks about popular Agile methodologies Scrum and XP, and how both these frameworks have been merged into ScrumXP—giving you the best of both worlds!  Scrum Scrum is the leading Agile framework practiced in the industry today. It 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.  Scrum prescribes events / ceremonies and specific roles within the team in order to achieve alignment and agility.  Sprint Ceremonies /Events Sprint Planning at the start of the Sprint Daily Stand-up during the Sprint Sprint Demo and Review to showcase the incremental working software developed in the iteration Sprint Retrospective at the end of the Sprint Scrum Roles Product Owner – Responsible for the product that is being developed. Is the representative of the Customer and Business. Scrum Master – Facilitates and orchestrates the various Scrum events, guides the team to align with Scrum values and principles. Team Member – Focusses on achieving Sprint goals, continuously strives to improve. 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 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. Extreme Programming (XP) XP is one of the earliest ,most successful and proven Agile Methodologies.  It is very specific regarding the practices to be followed. XP is recommended to be used when the Customer is fully committed to deep involvement with the development team. XP teams rapidly produce software in short(mostly one week) iterations taking immediate feedback from the Customer. XP Values Communication – Communication within the team is as important as communication with the Customer Simplicity - Building a system that is easy to revise and maintain. Trying not to engineer too many and too much and only do what is required at that time. Feedback – Continuously striving to obtain feedback and acting on the feedback from Customer, Team and the Product. Courage – Courage to persevere and do the right thing. Respect – Respect for fellow team members and all stakeholders. XP Core Practices XP mandates certain core Engineering practices that distinguish this Agile methodology from the others. These practices take care of different aspects of agility and are interconnected at the same time.  They are grouped as below. Fine scale feedbackWhole TeamAll the contributors to a project – Developers, Testers, Analysts, Coaches etc who are part of the Project are part of the “Whole Team” that is centered around the Customer.Planning GameThe Customer presents the desired features and lays out an initial plan for the project. XP teams revise the release plan regularly.During Iteration Planning, the Customer presents the features desired for the next two weeks. XP teams build software in two-week “iterations”, delivering running, useful software at the end of each iteration.The total involvement by the Customer during Planning is an important practice of XP.Pair ProgrammingAll production code is touched by two team members. This ensures there is already another “reviewer” at work as the code is getting produced. This practice largely avoids bugs and coding errors.Test Driven DevelopmentTest before code is religiously practiced. Before a single line of code is written, a test for the same has to be written and run. This immediate and short feedback loop immensely helps to avoid waste, like bugs and wrong code.Customer TestsAcceptance Tests are defined by the Customer to validate if the features that are being introduced are fit to the purpose. The team automates these tests and builds a suite of such tests to run whenever required and to get immediate feedback from the system to check if all is well.Continuous processContinuous IntegrationContinuously integrating the code avoids the major problems that creep up when it is done  just before the release. Testing on a fully integrated system helps to detect critical bugs that might otherwise stay undetected for long.Design ImprovementDesign Improvements and Refactoring happens at healthy intervals to ensure system is cohesive and loosely coupled. This ensures the system can be easily extended with new features, scaled when required and maintained in good health.Small ReleasesWorking Software is delivered to Customer at the end of every iteration – either for actual use or evaluation and to obtain feedback.Shared understandingCoding Standards are practiced so that there can be collective ownership and any team member will be able to understand the code.Pair Programming and Coding Standards ensure that code is not owned by one single person and is the responsibility of the team.Design is kept simple and continuously improved and revised to cater to the current functional demands. Design is not done up-front but done at regular intervals.XP teams use a common system of names to ensure a common understanding of the system.Programmer welfareSustainable PaceXP ensures the team members work at a pace that can be carried out for a very long time.  The system avoids situations where the team members are left wanting for work at times and then have to scramble to finish deadlines.Scrum and XP – What is common and different. Scrum and XP are two popular Agile Methodologies having the same larger goal of delivering to the customer incrementally and iteratively. Both the methodologies lay great importance to customer centricity, feedback mechanisms, continuous improvement and building sustainable empowered teams.  There are few differences in the implementing mechanisms of these methodologies.  Iteration Duration: Scrum Iterations last for 2 /3/ 4 weeks. XP iterations are usually very short – one week long or at the most 2 weeks. Role of the Customer: XP and Scrum have Release Planning and Iteration Planning sessions. But unlike Scrum, in XP the Customer drives the planning and schedules the Release.  The Customer continuously interacts directly with the Teams in XP, while in Scrum the Product Owner represents the Customer and Business. The XP teams ensure to deliver a working bug free system at the end of every iteration. Customer chooses to evaluate and provide feedback or Release to the end users. Scrum teams deliver working software at the end of every iteration. The Product Owner with the input from teams decides on the right time for General Availability (GA) Release depending on the Market Readiness, Customer input etc. Practices: Scrum recommends using Engineering Best Practices like TDD, Pair Programming, Code Refactoring etc. but XP takes it to another level by mandating these Engineering Practices. Scrum recommends that items planned within a Sprint are unchanged until the end, but in XP, teams accommodate a sudden change of priority even during the iteration, by swapping items if work has not started on it. Roles: Scrum has dedicated Scrum Ceremonies whereas XP does not prescribe it per se. Scrum has a dedicated Scrum Master who facilitates these events, but XP does not have a Scrum Master.  XP teams get guidance from Agile Coaches.  ScrumXP- Using the best of Scrum and XP Practices When there are two great practices, there is always a tendency to combine both and get the best of both the worlds. “Lean-Agile”, “Scrumban”, “ScrumXP” are some examples of hybrid terms that have become increasing popular by combining two philosophies (e.g Lean and Agile ) or two methodologies (e.g Scrum and Kanban / Scrum and XP). ScrumXP is a hybrid practice making the most of both Scrum and XP. XP has laid out some very effective Engineering practices that teams practicing Scrum can greatly benefit from.  Many teams practice Scrum as their process framework and include the very effective and efficient core Engineering XP Practices in their way of working. This gives rise to the highly productive ScrumXP hybrid model of working. Mostly the ScrumXP teams retain the Scrum Master and Product Owner roles within their teams to take care of the required orchestration and facilitation. ScrumXP and SAFe “Team and Technical Agility” is one of the key competencies of SAFe. By following  ScrumXP the SAFe teams take care of the team Agility through Scrum Practices and Technical Agility through XP Practices.  The robust Engineering practices of XP ensures the product being built is of very high quality, easily extendable, maintainable and sustainable. In conclusion, ScrumXP provides the best of both worlds. Teams can begin with Scrum and continuously improve by including the robust core XP Engineering practices like TDD, pair programming, code refactoring etc— not because it is mandated but because they find it effective. Although, interaction with the Customer is through a Product Owner, the Scrum teams can borrow the Customer Centric approach of XP to remain aligned with Customer expectations. 
ScrumXP
Radhika
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. 

Posts by Radhika Subramoniam

ScrumXP

This article briefly talks about popular Agile methodologies Scrum and XP, and how both these frameworks have been merged into ScrumXP—giving you the best of both worlds!  Scrum Scrum is the leading Agile framework practiced in the industry today. It 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.  Scrum prescribes events / ceremonies and specific roles within the team in order to achieve alignment and agility.  Sprint Ceremonies /Events Sprint Planning at the start of the Sprint Daily Stand-up during the Sprint Sprint Demo and Review to showcase the incremental working software developed in the iteration Sprint Retrospective at the end of the Sprint Scrum Roles Product Owner – Responsible for the product that is being developed. Is the representative of the Customer and Business. Scrum Master – Facilitates and orchestrates the various Scrum events, guides the team to align with Scrum values and principles. Team Member – Focusses on achieving Sprint goals, continuously strives to improve. 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 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. Extreme Programming (XP) XP is one of the earliest ,most successful and proven Agile Methodologies.  It is very specific regarding the practices to be followed. XP is recommended to be used when the Customer is fully committed to deep involvement with the development team. XP teams rapidly produce software in short(mostly one week) iterations taking immediate feedback from the Customer. XP Values Communication – Communication within the team is as important as communication with the Customer Simplicity - Building a system that is easy to revise and maintain. Trying not to engineer too many and too much and only do what is required at that time. Feedback – Continuously striving to obtain feedback and acting on the feedback from Customer, Team and the Product. Courage – Courage to persevere and do the right thing. Respect – Respect for fellow team members and all stakeholders. XP Core Practices XP mandates certain core Engineering practices that distinguish this Agile methodology from the others. These practices take care of different aspects of agility and are interconnected at the same time.  They are grouped as below. Fine scale feedbackWhole TeamAll the contributors to a project – Developers, Testers, Analysts, Coaches etc who are part of the Project are part of the “Whole Team” that is centered around the Customer.Planning GameThe Customer presents the desired features and lays out an initial plan for the project. XP teams revise the release plan regularly.During Iteration Planning, the Customer presents the features desired for the next two weeks. XP teams build software in two-week “iterations”, delivering running, useful software at the end of each iteration.The total involvement by the Customer during Planning is an important practice of XP.Pair ProgrammingAll production code is touched by two team members. This ensures there is already another “reviewer” at work as the code is getting produced. This practice largely avoids bugs and coding errors.Test Driven DevelopmentTest before code is religiously practiced. Before a single line of code is written, a test for the same has to be written and run. This immediate and short feedback loop immensely helps to avoid waste, like bugs and wrong code.Customer TestsAcceptance Tests are defined by the Customer to validate if the features that are being introduced are fit to the purpose. The team automates these tests and builds a suite of such tests to run whenever required and to get immediate feedback from the system to check if all is well.Continuous processContinuous IntegrationContinuously integrating the code avoids the major problems that creep up when it is done  just before the release. Testing on a fully integrated system helps to detect critical bugs that might otherwise stay undetected for long.Design ImprovementDesign Improvements and Refactoring happens at healthy intervals to ensure system is cohesive and loosely coupled. This ensures the system can be easily extended with new features, scaled when required and maintained in good health.Small ReleasesWorking Software is delivered to Customer at the end of every iteration – either for actual use or evaluation and to obtain feedback.Shared understandingCoding Standards are practiced so that there can be collective ownership and any team member will be able to understand the code.Pair Programming and Coding Standards ensure that code is not owned by one single person and is the responsibility of the team.Design is kept simple and continuously improved and revised to cater to the current functional demands. Design is not done up-front but done at regular intervals.XP teams use a common system of names to ensure a common understanding of the system.Programmer welfareSustainable PaceXP ensures the team members work at a pace that can be carried out for a very long time.  The system avoids situations where the team members are left wanting for work at times and then have to scramble to finish deadlines.Scrum and XP – What is common and different. Scrum and XP are two popular Agile Methodologies having the same larger goal of delivering to the customer incrementally and iteratively. Both the methodologies lay great importance to customer centricity, feedback mechanisms, continuous improvement and building sustainable empowered teams.  There are few differences in the implementing mechanisms of these methodologies.  Iteration Duration: Scrum Iterations last for 2 /3/ 4 weeks. XP iterations are usually very short – one week long or at the most 2 weeks. Role of the Customer: XP and Scrum have Release Planning and Iteration Planning sessions. But unlike Scrum, in XP the Customer drives the planning and schedules the Release.  The Customer continuously interacts directly with the Teams in XP, while in Scrum the Product Owner represents the Customer and Business. The XP teams ensure to deliver a working bug free system at the end of every iteration. Customer chooses to evaluate and provide feedback or Release to the end users. Scrum teams deliver working software at the end of every iteration. The Product Owner with the input from teams decides on the right time for General Availability (GA) Release depending on the Market Readiness, Customer input etc. Practices: Scrum recommends using Engineering Best Practices like TDD, Pair Programming, Code Refactoring etc. but XP takes it to another level by mandating these Engineering Practices. Scrum recommends that items planned within a Sprint are unchanged until the end, but in XP, teams accommodate a sudden change of priority even during the iteration, by swapping items if work has not started on it. Roles: Scrum has dedicated Scrum Ceremonies whereas XP does not prescribe it per se. Scrum has a dedicated Scrum Master who facilitates these events, but XP does not have a Scrum Master.  XP teams get guidance from Agile Coaches.  ScrumXP- Using the best of Scrum and XP Practices When there are two great practices, there is always a tendency to combine both and get the best of both the worlds. “Lean-Agile”, “Scrumban”, “ScrumXP” are some examples of hybrid terms that have become increasing popular by combining two philosophies (e.g Lean and Agile ) or two methodologies (e.g Scrum and Kanban / Scrum and XP). ScrumXP is a hybrid practice making the most of both Scrum and XP. XP has laid out some very effective Engineering practices that teams practicing Scrum can greatly benefit from.  Many teams practice Scrum as their process framework and include the very effective and efficient core Engineering XP Practices in their way of working. This gives rise to the highly productive ScrumXP hybrid model of working. Mostly the ScrumXP teams retain the Scrum Master and Product Owner roles within their teams to take care of the required orchestration and facilitation. ScrumXP and SAFe “Team and Technical Agility” is one of the key competencies of SAFe. By following  ScrumXP the SAFe teams take care of the team Agility through Scrum Practices and Technical Agility through XP Practices.  The robust Engineering practices of XP ensures the product being built is of very high quality, easily extendable, maintainable and sustainable. In conclusion, ScrumXP provides the best of both worlds. Teams can begin with Scrum and continuously improve by including the robust core XP Engineering practices like TDD, pair programming, code refactoring etc— not because it is mandated but because they find it effective. Although, interaction with the Customer is through a Product Owner, the Scrum teams can borrow the Customer Centric approach of XP to remain aligned with Customer expectations. 
ScrumXP
Blogs
5367
ScrumXP

This article briefly talks about popular Agile m... Read More

The Spotify model - Agile

Many companies find it hard to scale Agile due to the various complexities that come with multiple teams, locations, time zones and different cultures. Over the past decade, many Scaling frameworks like SAFe, LESS, DAD have been introduced into the Agile world by various Agile practitioners and groups. This article is about one such scaling model called the “Spotify Model”. Origins of Spotify Model “Spotify” is a Sweden based music streaming company founded in 2006. The structure used by the company to scale agile across its various teams located in different locations came to be called as the Spotify Model. This model is becoming increasingly popular due to its flexibility and simplicity. Need for change in Organization Structure Today’s world is constantly changing due to social, political, and economic disruptions. The 2019-2020 COVID is a classic example of disruption in the entire world to the “business as usual”. To keep up with the disruption and competition, companies must be nimble and innovative to respond quickly and stay ahead of their peers. The hierarchical structures and organizational processes that worked well for decades are no longer enough to keep up with this fast-paced world. While traditional hierarchies and managerial processes are still very much required to run the show, the need of the hour is to also have an additional network structure operating in tandem with the traditional norms. The purpose of this network is to continually assess the business, the industry, and the organization, and react with greater agility, speed, and creativity than what has existed before.  There are so many examples around us where Start-up organizations thrive in the network structure and fail miserably when they have to scale, and cannot continue with traditional hierarchy and processes. In equal measure, around us are examples of Enterprise giants collapsing under the weight of the traditional hierarchy alone without the nimbleness and speed of the network structure.  Both the operating structures – the hierarchy and the network, are essential for today’s businesses to thrive. Kotter’s theory of establishing a dual operating system within an organization resonates heavily in the Spotify Model and compels us to draw parallels. In the Model we can see that there are innovative and thriving network structures and at the same time there is space to establish the traditional hierarchy as well. Spotify Model Squad: The Squad is the basic entity of the model which comprises the team that does the work. The Squad does not have a dedicated Squad lead but has a dedicated Product Owner.  The Product Owner tells the Squad “What” has to be done , prioritizes the work and maintains the backlog. Each Squad is self-organizing and can choose to follow Scrum, Kanban, XP or a hybrid of these. Squads are aligned to their mission, product strategy and short-term goals. Each Squad owns the release and delivery end to end. Typically, an infrastructure / DevOps Squad enables them to carry out smooth releases but does not do it for them. The Squad has access to an Agile Coach who runs retrospectives and Sprint Planning meetings. The coaches help the Squads to continuously improve. Tribe: A Tribe is a group of Squads that are related to each other by nature of the work being done by them. for e.g multiple Squads working together on the same product feature or closely related product features/ same product within a portfolio of different products.The number of people in a Tribe is recommended to be 100 in line with the Dunbar number. As per the Dunbar number, most people cannot maintain a social relationship with more than 150 people or so. All the Squads within a Tribe are co-located and physically able to interact in common areas dedicated for this purpose. There is a Tribe Lead who is responsible for creating a productive and an innovative environment for the Squads. The Tribe Lead can be part of a Squad as well.  Tribes meet often to showcase what they have been working on, what has been delivered and their learnings. The showcase could include the working software, new tools and techniques. Handling Dependencies One of the foremost challenges to resolve in a scaled agile environment are “conflicts and dependencies”. These can crop up during the development of a product among the Squads within a Tribe and also exist among Squads in other Tribes as well.   Dependencies could slow down or block the progress. Such dependencies are identified and are handled by reprioritization or through technical solutions. Sometimes innovative ideas could help remove the dependencies.  The end goal is to avoid dependencies between Tribes by making the Tribes self-organizing; and once that is achieved by having minimal dependencies among Squads within a Tribe. Survey for Continuous Improvement: A survey is done for all Squads at the end of every Quarter to understand the pain points and areas for improvement. For e.g multiple Squads having issues with the release process need urgent attention. One of the Squads not getting enough support from their Product Owner needs leadership intervention. Chapter: Certain disciplines/technological areas within the Tribe, like QA, Database Specialists, Front-end developers, Back-end developers, UX Specialists will benefit with regular discussions and interactions. People within these functions across multiple Squads and within the same Tribe constitute the Chapter. Constant communication within the Chapter members is encouraged. Each Chapter meets regularly to discuss their achievements and challenges in their respective areas of expertise e.g QA Chapter, UX Chapter, DB Chapter. There is a Chapter Lead who can guide the various members of the Chapter on “How” things can best be done. For e.g the QA Chapter lead can strategize the End-to-End Functional, Performance and Security Testing to be carried out for the new version of the product in an upcoming release. This will ensure the testers within all the Squads have a common well thrashed out testing strategy for the upcoming product release.  The Chapter lead can also be the line manager of the members in his Chapter, performing the traditional managerial responsibilities like people development, performance appraisals, career growth etc. The Chapter lead is also a member of one of the Squads in the Tribe, making him remain closer to ground realities.x` All the Chapter leads within a Tribe typically could report to the Tribe lead, and the Tribe Lead performs all the managerial responsibilities for the Chapter Leads within his Tribe as well as the next level Squad members of his Tribe.  Guild : A Guild is like a “community of interest” cutting across Tribes throughout the Organization/ Business Unit.  Imagine an Enterprise that has three Tribes each located in three different locations. There could be QA Chapters for each Tribe with respect to the location. There is also a need for QA members of one Tribe to exchange and share processes and learnings with QA members of the other two Tribes. The Guild is an organic structure that serves this purpose.  The Guild cuts across the Tribes spread across the organization across locations. Knowledge, tools, and practices are shared. For e.g the QA Guild includes all the QA Chapter members and in addition can include other members who are interested.  Guilds usually are not focussed on a specific release or delivery but on their area of expertise in a generic way. They have mailing lists, publish newsletters and conduct unconferences once in a while.  Spotify as a “Scaling Agile Model” Many of the foundational elements within the model become the backbone to scale agile in the organization adopting it. Spotify Model recognizes the need for a Network Structure within the organization to make it nimble and agile. The elements within the Spotify model help to establish Agile scaled to multiple teams spread across various locations and areas of work. The Spotify Model recognizes self-empowerment and self-organization, and at the same time aligns the Squads within a Tribe to work in tandem, in order to create complete and usable software products. The Chapters across Squads provide the environment for cross Squad collaboration. The Quarterly Survey in the Squads and handling dependencies within and across Tribes enables agility and continuous improvement. The Guilds help in improving the organizational culture to better adapt to the technological advancements and provide competitive readiness. Unique Benefits of the Model Spotify focusses on Agile Principles rather than mandating specific practices. Squads are autonomous to choose their own agile way of working. (Scrum/XP/Kanban/Scrumban etc. Not all Squads within a Tribe follow the same method) Specific Agile ceremonies and artifacts are not imposed on the Squad. Practices which work well with multiple Squads are automatically adopted by other Squads without the resistance that comes with standardization. This creates a balance of consistency across Squads along with the flexibility needed for autonomy. Though Squads are autonomous and loosely coupled they are tightly aligned by grouping them into Tribes. How Spotify is different from other Scaled Agile frameworks  While SAFe is a heavyweight scaled agile framework having many different flavours like Essential SAFe, Portfolio SAFe, etc, Spotify is more of a lightweight framework.  It might work very well for start-ups that are growing into medium Enterprises or for larger enterprises that are not ready yet for something as heavy as SAFe. The role of the Scrum Master is absent in Spotify, but the Squads have access to Servant Leaders in the form of Chapter and Tribe Leads and Agile Coaches. Conclusion  The Spotify Model has been a popular buzzword due to its unique nomenclature, flexibility and simplicity. It recommends the need for a community-based networking structure within the organization and focuses on the Agile Principles rather than Practices. It is a very unique and liberating Scaled Agile model and requires the practitioners to be extremely mindful and responsible while adopting it, so that it can be tailored for their specific organizational needs. 
The Spotify model - Agile
Blogs
5459
The Spotify model - Agile

Many companies find it hard to scale Agile due t... Read More

Why CSPO Certification Is Important For Your Career

This article looks at how and why the CSPO® Certification is increasingly becoming important for today’s Product Owner (PO). The article briefly discusses on the responsibilities of the PO, how the role is becoming mandatory within the organization in today's Agile landscape, what makes a great PO and about the CSPO Certification.Who is a Product OwnerThe Product Owner is a member of the Product Management / Business team who works closely with and is a part of the Agile team throughout the Sprints/Iterations. The responsibilities of a Product Owner(PO) spans across the aspects of People, Product and Process.PeopleThe PO is a conduit between Business and Engineering teams, acting as the “Voice of the Customer” and “Voice of the Business” to the teams,Is one of the members to create the Product vision and constantly communicates the same to the teams, and Is able to interact and communicate well with all stakeholders (Customer, Engineering , Sales, Marketing, Support etc.)ProductDefines and maintains the team’s Product backlog, Can answer “Why” a requirement has found a place in the product backlog, “Why” it is prioritized and “Why” the Customer wants the features, Can provide insights into what customer problem the requirements aim to resolve, Can provide Customer Journey Maps, User Personas and Real Life Examples, and Can determine the value that the product delivers to stakeholders and identify which product backlog items would deliver the most value.ProcessPrioritizes the product backlog and is able to provide the reasons and justification of prioritization to the teams, Is part of the regular Product Backlog refinements to refine User stories and Acceptance Criteria, Is available to the team throughout the iteration and provides continuous feedback, Seeks continuous feedback from Customers, and Is able to review the features and approve User Stories once they are completed.Significance of the PO roleTraditionally the Business/Product Management teams have suffered with constant shortage of time and conflicting priorities between dedicating time for Engineering teams and Customer facing responsibilities. Usually, the Customer facing responsibilities understandably end up as the higher priority,   leaving very little time for the teams.Earlier, the time dedicated by the Product Manager to Engineering teams was very little and elusive, sometimes limited to only email interactions. The Business teams were located at the customer sites and used to visit the Engineering teams occasionally, interacting with them through email or phone calls. As a result, the product and productivity suffered immensely.With the advent of Scaled Agile Frameworks and industry wide adoption of Agile, the role of the Product Owner has been laid out as a mandate and demands the increase of manpower in Business teams. Dedicated Product Owners are becoming increasingly indispensable and significant within teams. The role of the Product Owner role has come as a big relief for Engineering teams, because they are constantly in touch with the Business stakeholders as well as the team, and can smoothen and streamline communication channels.POs are often co-located with the Engineering teams, attending Daily (Stand up) Meetings, Refinement meetings, Sprint Review, Demos etc. in person with the team. They are also available anytime for quick feedback and queries doing away with time-zone difference and delays. The POs closely work with their Customer facing counterparts in the various customer locations, serving as the liaison between Business Teams and Engineering teams.The PO ‘s role is key for the success of the Agile way of working. It has become a “Must Have” role within the Agile landscape rather than a “Good to have” role. This has created a good demand for the PO role in the Software Industry. With the surging demand for POs in the industry, there are many professionals taking up the discipline of Product Management.  There are professionals from other functions like QA/Project Management/ Development etc. moving into the Product Management discipline as well.Who makes a “Great” PO?Although a PO satisfies all the roles and responsibilities required of his/her role, there are some traits and characteristics that set apart a great PO from the crowd.A great PO has conviction in the Product Vision and knows the priorities of the Business very well, and is able to articulate the same to the Engineering teams. Shows commitment in completing the team’s goals by providing early and timely feedback. A great PO is excellent in communication, able to understand the nuances of the various stakeholders and speaks in each one’s language (Customer, Engineering, Sales, Marketing, Support etc.) Does not take sides but does what is right for the given situation and for the Customers. Is able to say “No” and has the reasons for it.Is not a task master who dictates to the team but a great Influencer who has the answers to “what has to be done” and “why it has to be done”.   Trusts the team to know best on “How” things will be implemented. Negotiates well with the team for the Business but is fair in all interactions with the team winning the team’s trust. Is always curious in terms of the product implementation but does not interfere in the team’s approach of building the product.To really excel at the job, the PO has to constantly upskill and sharpen the tools he/she has to offer. The PO is required to have keen knowledge of the various practices and techniques that are being used by his/her peers in the industry, in order to stay ahead of the competition. The PO needs to be part of a “Community of Practice”, grow his/her network outside the organization and be clued into all the relevant trends in the industry.CSPO CertificationWith the growing demand for the PO role in the market, the Industry naturally creates ways to benchmark standards, uphold quality and nourish promising talent. The CSPO Certification is one such mark of standard and quality. It equips the Product Owner to become better at the job and helps certified individuals to stand out in the crowd. The CSPO course and the CSPO community offers the right environment for the Product Owner to excel in his/her job. The curriculum of the CSPO course is outlined below for your reference.ContentsScrum Basics Understand the Scrum Framework and workflow so that the PO   Agile Principles and Scrum Values Roles and Responsibilities Product Owner role in detail Scrum Master role at high level Team role at high level Product Vision Importance of Product Vision Creating the Product Vision Just enough preparations before creating the Product Vision Qualities of Product Vision Relationship between Product Vision and Product Road Map Estimation Estimation Levels and Techniques Accuracy is more desirable than Precision in Agile Estimation What can go wrong with Estimation   Difference between Estimating and Committing Product Backlog   Understand what Product Backlog is and is not Product Backlog Grooming Prioritization Importance and Benefits of Prioritizing Product Backlog Why everything cannot be Mandatory or Highest Priority Who should Prioritize Prioritization based on Multiple Factors Applying formal approaches to Prioritization   Giving leeway to teams to sequence work after prioritization Release Management Goal Iterative and collaborative Release Planning Quality and Technical Debt Releasing Software early and frequently Measuring velocity and Release Burndown chart Forecasting future releases Sprints Product Owner’s role in Scrum Meetings Collaboration between PO and Scrum Team, between PO and Scrum Master Team Commitment Understand why Sprints are Timeboxed and Protected from other distractions Concept of sustainable paceCareer Prospects and GrowthExisting POsFor people who are already wearing the Product Owner’s hat, the CSPO certification is like one more feather in their resume. Going through this course and certification will fine-tune their skills and help add multiple tools in their toolbox.Aspiring POsIn certain organizations, there might be team members exhibiting and playing the roles and responsibilities of a Product Owner without the role title. They would have acquired all the necessary skill-sets but not the formal official title yet. By attending the CSPO course and earning the CSPO certification they convey their readiness to play the role; and this gives the thrust necessary for their formal recognition into a Product owner’s role.Salary AspectsThe CSPO certification has global recognition and so will result in an increase in the pay package for a certified professional PO.What next for an accomplished CSPO?An accomplished CSPO can further his/her career prospects by taking up the Advanced CSPO course and certification. It will set the stage for the product owner to progress in their career path and play the role in a wider scope. Depending on the Organization type and structure it could be the role of a Product Manager, Product Portfolio Owner/Manager— and for the more adventurous, even the CEO of a startup! Some Product owners might choose to diversify into a Business Analyst role as well.In conclusion, the CSPO has become a benchmark certification for Product Owners in the Software Industry. It will definitely help existing and aspiring POs to sharpen and upgrade their skillsets. It is also a badge of accomplishment and achievement for a Product Owner, not only to set them as a class apart in their own organization, but also in their wider Product Management community.
Why CSPO Certification Is Important For Your Career
Blogs
4275
Why CSPO Certification Is Important For Your Caree...

This article looks at how and why the CSPO® Certi... Read More

Top Learning Outcomes of Leading SAFe 5 Certification

In any organization, the business decisions made by leaders play an integral role in determining its future. Their mindset, actions and strategies influence the functioning of the organization and workforce. True leaders continuously learn and upskill themselves to be on par with the changing times and stay ahead of the competition. This is where adoption of a Lean-Agile Mindset becomes crucial. It serves as an intellectual and leadership foundation for applying SAFe® principles and practices. A Lean Agile Mindset is undoubtedly the need of the hour for everyone and especially for professionals who oversee a company’s destiny.  This article briefly looks at SAFe® 5.0’s main offering – “Business Agility”, dwells on the foundational competency – “Lean Agile Leadership” and finally talks about how Scaled Agile Inc’s “Leading SAFe®“ course  is one of the front runners in providing knowledge and guidance for building SAFe’s foundational competency in an Enterprise.  What is SAFe®?  Enterprises span across multiple geographical locations, cultures and time zones. External stakeholders like Suppliers and Partners further add on to the organizational milieu. In spite of the scale, the enterprise has to be nimble and agile to keep up with ever changing customer needs and tough competition.Practicing Agile in an Enterprise has its very own challenges because of the scale at which it operates and the high stakes involved.SAFe® is an Agile Framework that recommends ways and methods for enterprises to implement, sustain and improve Lean and Agile Practices. SAFe®1.0 was introduced in 2011 and has evolved into the SAFe®5.0 version which was released in Jan 2020.What is new in SAFe®5SAFe®5.0 introduces quite a few things, of which we look at two important ones- Business Agility and the Dual Operating System.   John Kotter , thought leader of Change Management, famously describes the need for a Dual Operating System that combines the entrepreneurial capability of a network with the organisational efficiency of traditional hierarchy. SAFe® 5 recommends organizing a network around value streams, in addition to the traditional hierarchy, to create a dual operating system to achieve Business Agility.  Image source: Kotter’s Dual Operating SystemImage source: SAFe as a second organizational operating systemBringing agility within Engineering teams may not be enough to create products and solutions that are viable and saleable. Everyone who is involved in building solutions and products – Executives, Senior Leadership, Marketing, Sales, Finance, Engineering, Support, IT, Legal, Compliance, HR- has to be brought into the ambit of Lean and Agile Practices to achieve true Business Agility.The responsibility of making “Business Agility” a reality lies largely with the Leaders of the Organizations.Lean Agile Leadership CompetencySAFe® recommends seven core competencies to become a Lean Enterprise and achieve Business Agility.  “Lean Agile Leadership” is one of the foundational competencies of great significance.Without the buy-in, support and complete conviction from leaders in the organization, the SAFe® implementation cannot happen effectively.  Lean Agile Leaders play a key role in introducing, nurturing and sustaining the SAFe® transformation within the organization.What is required of a Lean Agile Leader?Growth Mindset: Leaders should have a realistic bent of mind to acknowledge a need for change within themselves as well as the organization. The leaders with the right outlook believe in the SAFe Core Values, the Lean-Agile Mindset, and SAFe Principles. Leading By Example: As the famous saying goes, “Actions speak louder than words”. So by walking the talk, leaders can influence scores of people to start adopting the Lean Agile practices, Values and Principles exhibited by themselves. Leading Change: Organizational transformation and change is a very difficult and rocky road to take. There are many thought leaders and researchers producing dedicated models, theories and books for bringing about change and sustaining it. A leader who sets himself on this path is aware of the challenges and is ready to lead the change successfully.   Image Source: Lean Agile Leadership CompetencyOne of the tools for leaders at the helm of bringing about change is having deep rooted knowledge, understanding and purpose about the practices they have to exhibit, and thereby influence the other employees in their organizations.Obtaining the Scaled Agile Framework’s “Leading SAFe®” Certification is the perfect way to start for Lean Agile Leaders. By getting themselves trained, leaders can begin the transformation journey armed with the necessary information.Leading SAFe® Course and CertificationLearning OutcomesThe 2 day long Leading SAFe® course results in the following learning outcomes:The knowledge and principles of Lean, Agile, DevOps, Lean Product Development Insights into achieving Business Agility through organizing around value Understanding of Lean Portfolio Management which emphasizes the need for Lean principles and Lean Budgeting The importance of PI Planning events, co-ordinating Multiple Agile Release Trains, establishing team and technical agility Customer-centric mindset and design thinking approach to Agile product delivery The importance of sustaining SAFe® transformation by creating Communities of Practice and fully empowered employees and teams. In short, the SAFe® Implementation Roadmap helps the leaders to chalk out their organization’s transformation journey. Who should take the Leading SAFe® Course? This course is just right for leaders who are in a position to influence employees, organizational structure and the future of products / solutions.  Executives of the organization that decide on the future course of business Business Unit Heads who are responsible for a Portfolio Heads of functions like Marketing/Sales/Product/IT/Engineering etc Agile Program Managers and Project Managers who steer programs and projects, Managers of teams Technology leaders like Enterprise and Solution Architects/ Distinguished Engineers/ Fellows who command a large sphere of influence on teams Leading SAFe® CertificationAttending the 2 day Leading SAFe® course is a requirement to write the exam, and participants will get access to all the study materials and the exam. Once the exam is   successfully completed, the candidate gets the below privileges as per Scaled Agile, Inc. Certified SAFe® Agilist PDF certificate Certified SAFe® Agilist digital badge to promote your accomplishment online One-year membership to the SAFe Community Platform, which includes access to the SA Community of Practice Access to Meetup groups and events that connect you with other SAFe certified professionals A variety of learning resources to support you during your SAFe journey Benefits of taking Leading SAFe®5 trainingEvery change starts with – what is in it for me? The Leading SAFe® course outlines a generic framework that is applicable to any enterprise. For an individual employee it is a learning for life and can be applied to any organization he/she is associated with.  The SAFe® Agilist Course and Certification is one of the prestigious achievements in the individual’s professional life earning him/her respect and recognition within the Agile Community.           A SAFe®5 certified professional is eligible for better prospects within their own organization or in other organizations, if and when there is a need for job change.  According to Forrester’s Q2 2015 Global Agile Software Application Development Online Survey-“The Scaled Agile Framework (SAFe®) is the most widely adopted enterprise Agile approach according to most survey data, with 33% using it”. With more than 70% of US Fortune 100 companies actively employing SAFe®, it is clear that the demand for Leading SAFe® is on a constant rise. Benefits of Leading SAFe®5 Training for the organization:Leadership is the foundation on which the “House of Lean” is built. A strong foundation of Lean Agile leaders, Managers and Executives help to create a learning culture for the organization by exhibiting the Lean Agile Mindset. This, in turn, paves the way for enterprise-wide transformation. Having a strong army of Agilists that are trained and certified helps the organization to sustain the principles of Lean and Agile.Agile ManifestoCorporate training for the leaders of the organization from a reputed Training provider like Knowledge Hut will ensure that all leaders are on the same page, hearing the same message at the same time. The training will become an opportunity for collaboration and the discussions during the training facilitated by the trainer can be tailored to suit organizational needs.   Why KnowledgeHut for Leading SAFe®5 Course?KnowledgeHut is a leading training provider offering a variety of accredited training programs for Corporates and Individuals. KnowledgeHut is a preferred training partner for various corporates.  KnowledgeHut offers training across 70 countries in over 250 industry-recognized courses. This includes a wide range of Courses in Agile and SAFe®.  Scaled Agile, Inc is the only certifying authority for SAFe® and KnowledgeHut is a Silver Partner of Scaled Agile, having trained more than 4000 professionals in various SAFe® certifications.  The Trainers for Leading SAFe® courses are an elite panel of accredited SPCs who also have years of experience as active SAFe® practitioners.  Learning happens through experiential workshops by accredited industry experts who bring in vast real-world experience imparting knowledge through in-class activities and simulations. Please refer here for all the details and the value-added services offered by KnowledgeHut for the “Leading SAFe® 5 “course. In conclusion, Scaled Agile Inc’s Leading SAFe®5 from KnowledgeHut will be a unique learning experience that will set the stage for success in one’s professional life. This credential benefits equally the individual, the organization and the larger cause of increasing the number of Agilists and improving the Agile Community at large.
Top Learning Outcomes of Leading SAFe 5 Certification
Blogs
6660
Top Learning Outcomes of Leading SAFe 5 Ce...

In any organization, the business decisions made b... 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. 
Understand the Importance of Having the Product Vision in a Scrum Team
Blogs
7177
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. 
Agile Project Management: Best Practices and Methodologies
Blogs
6695
Agile Project Management: Best Practices and Metho...

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