Category
Courses

Search

Trending blog posts

What Is a Safe Product Owner?

The Scaled Agile Framework® (SAFe®) is, in the words of Dean Leffingwell, Creator of SAFe: “a knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using Lean, Agile, and DevOps.”  © Scaled Agile, Inc. Using SAFe, the process of scaling Agile across a large-scale enterprise can be streamlined. SAFe details out organizational workflows that enhance productivity and employee engagement and ensure customer delight through quick deliveries of quality products.  A key role on a SAFe team is played by the Product Owner. In this blog, you will understand the role of a SAFe Product Owner, and how it relates to that of a Scrum Product Owner. You will also understand the SAFe Product Owner’s role with respect to that of a SAFe Product Manager.What is a SAFe Product Owner?The SAFe Product Owner is the member of the team who works as the voice of the customer. He or she liaises with Product Management and other POs, besides other stakeholders, to define and list out stories in the Team Backlog and order them as per priority.  In an ideal situation, the SAFe PO is in the same office as the rest of the team. However, with today’s distributed teams, this does not always happen. One PO can support up to two Agile teams, at the most. The SAFe PO works with the SAFe Product Manager, who maintains the overall product vision. Key Role & Responsibilities of a SAFe Product OwnerThe main responsibilities of the SAFe PO extend across the team, and even beyond that to participate in Product Management events, where he or she will help to plan and create the Program vision and refine the Program Backlog. The following are the main responsibilities of the SAFe PO: 1. PI PlanningThe PO plays a significant role as a member of the larger Product Management team and has to participate in the events during Program Increment (PI) planning. The activity of program backlog refinement also requires every PO’s participation and close involvement. Before the event, the PO will keep the team backlog updated and will contribute to creating the vision and charting out the roadmap.When the planning event is in progress, the PO should be at hand to give clarity wherever needed. The entire SAFe team will work to map out the team’s PI objectives for the upcoming PI.2. During the IterationDuring the iteration execution, the PO holds extremely critical responsibilities:The PO builds, updates and maintains the team backlog, with updates from all stakeholders and the team. Reviewing and ordering the team backlog as a precursor to the Iteration Planning event is the responsibility of the PO. For this, they may need to coordinate dependencies with other POs.During the Iteration Planning event, the PO gives clarity of user story details, and is around to ensure alignment and concurrence on a final iteration plan. While the team elaborates on the backlog items and creates stories, the PO keeps track of the flow and maintains priorities. POs work with the team to flesh out each story, adding acceptance criteria and acceptance tests, applying Behaviour-Driven Development (BDD) practices. As the work progresses, the PO will work closely with the team to agree on the completion of accepted stories. and see whether they meet the Definition of Done and quality standards that have been laid down. The PO does not need to be a technical expert but should be able to understand the scope of the work that is coming up. He or she should collaborate with the engineers to assist in making decisions and sequencing the technological infrastructures that will enable the business functionality. During team demos, the PO coordinates between the team and stakeholders who are present.   They also participate in events such as the Iteration Retrospective and the Agile Release Train’s Inspect & Adapt workshop, providing the customer’s perspective on the work progress.3. During the Program ExecutionDuring each PI, the PO will connect with other POs to check and coordinate other dependencies, ensuring smooth work progress without any hiccups. They will sync up typically during weekly events. Additionally, POs play a valuable role in creating the System Demo for all the stakeholders involved in the program value stream. 4. Inspection and AdaptationThe Inspect and Adapt (I&A) workshop is held to address any large impediments to smooth progress. During this event, the PO works across teams to see how best to improve processes and increase team velocity and quality. During the I&A workshop, the PO participates in and holds the PI system demo for program stakeholders.SAFe Product Owner vs Scrum Product OwnerBefore we get into the differences in the roles and responsibilities of a SAFe Product Owner and a Scrum Product Owner, we need to also understand a third and more prominent role on a SAFe team: that of the SAFe Product Manager. The SAFe Product Manager is someone who works with several SAFe teams, typically two to four, and owns the Program Backlog—which gives him or her an overall view of the entire project (or the big picture).  The table below talks about the differences in the roles played by a SAFe Product Owner and a Scrum Product Owner.SAFe Product OwnerScrum Product OwnerBacklog ItemsA SAFe Product Owner undertakes the responsibility for the Team Backlog. This lists all the requirements (Backlog items) for the team.A Scrum Product Owner undertakes the responsibility for the Product Backlog. This is a prioritised list of all the requirements for the product.Number of teams they supportA SAFe Product Owner can serve, at most, two teams.A Scrum Product Owner can work with two or more teams.Vision and roadmapA SAFe Product Manager, not the SAFe Product Owner, defines the features and owns the vision and roadmap. A SAFe Product Manager is someone who works with two to four SAFe Product Owners. He or she will have an overall view of the entire program. As such, the SAFe Product Owner exerts less authority than the Scrum Product Owner.Scrum Product Owner defines the features and owns the vision and roadmap. So, as we can see, the Scrum Product Owner undertakes responsibilities that combine those of the SAFe Product Owner and the SAFe Product Manager (but to a smaller scale as the project is typically smaller).Who has the final say on the product?A SAFe Product Owner does not have a final say on what must be done for a certain Product. This is done by the SAFe Product Manager, who is the final authority and owns the vision and roadmap on a SAFe project.It is the Scrum Product Manager who has the final say on what needs to be done for the product.SimilaritiesJust like the Scrum PO, the SAFe Product Owner is also a core member of the team.  He or she is the customer proxy on the team, ensuring that the vision is always kept in focus.They have the responsibility of the Backlog- the Team Backlog in the case of the SAFe PO, and the Product Backlog in the case of the Scrum PO.Both POs work on prioritising the tasks that the team will take up next, guiding them on the relative importance of the stories.Again, both the SAFe PO and the Scrum PO work toward maximizing the product value.They keep an eye on the goal for the next iteration.They participate in reflections and inspect and adapt during and after each iteration.The two roles take part in the Planning, Retrospective and Review of an Iteration in SAFe/ Sprint in Scrum in a similar way.Can one person do both roles in SAFe; that of the Product Owner and Product Manager?The PO and the PM roles are completely distinct in SAFe, and each comes with its own set of responsibilities.There is a different focus for each role: The PM’s role is cantered on the benefits to the customer and the organisation. He or she is also the person with whom the business owners and members of the ART (Agile Release Train) connect. POs always have the needs of their own Agile team in focus.  Product Owners and Product Managers work together collaboratively to understand the customer’s needs and work toward fulfilling them. The flow of information is from the customer to the PM, and then down to the POs and their team members. The POs and PMs meet up at all ART or PO planning and sync up events and stay aligned with the same set of overarching goals. As we have seen, one person cannot undertake the roles of the SAFe Product Owner and the SAFe Product Manager at the same time. POs and PMs must at all times be connected, and work in tandem to deliver a successful product; however, having one person playing both roles is a sure route to disaster!  The last word… The SAFe Product Owner plays a role that is at the core of SAFe, setting up the product strategy, getting deep into customer requirements, and prioritizing the features as per their importance. They hold the responsibility of ensuring customer delight, even as they keep a pulse on the economic value that is to be derived from the product.  In the end, SAFe is all about giving the larger enterprise a framework for scaling Agile — to build better products, respond to volatile markets, and keep in step with emerging technologies — and without the Product Owner’s expertise, all this will fall short. 
What Is a Safe Product Owner?
KnowledgeHut
KnowledgeHut

KnowledgeHut

Author

KnowledgeHut is an outcome-focused global ed-tech company. We help organizations and professionals unlock excellence through skills development. We offer training solutions under the people and process, data science, full-stack development, cybersecurity, future technologies and digital transformation verticals.

Posts by KnowledgeHut

What Is a Safe Product Owner?

The Scaled Agile Framework® (SAFe®) is, in the words of Dean Leffingwell, Creator of SAFe: “a knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using Lean, Agile, and DevOps.”  © Scaled Agile, Inc. Using SAFe, the process of scaling Agile across a large-scale enterprise can be streamlined. SAFe details out organizational workflows that enhance productivity and employee engagement and ensure customer delight through quick deliveries of quality products.  A key role on a SAFe team is played by the Product Owner. In this blog, you will understand the role of a SAFe Product Owner, and how it relates to that of a Scrum Product Owner. You will also understand the SAFe Product Owner’s role with respect to that of a SAFe Product Manager.What is a SAFe Product Owner?The SAFe Product Owner is the member of the team who works as the voice of the customer. He or she liaises with Product Management and other POs, besides other stakeholders, to define and list out stories in the Team Backlog and order them as per priority.  In an ideal situation, the SAFe PO is in the same office as the rest of the team. However, with today’s distributed teams, this does not always happen. One PO can support up to two Agile teams, at the most. The SAFe PO works with the SAFe Product Manager, who maintains the overall product vision. Key Role & Responsibilities of a SAFe Product OwnerThe main responsibilities of the SAFe PO extend across the team, and even beyond that to participate in Product Management events, where he or she will help to plan and create the Program vision and refine the Program Backlog. The following are the main responsibilities of the SAFe PO: 1. PI PlanningThe PO plays a significant role as a member of the larger Product Management team and has to participate in the events during Program Increment (PI) planning. The activity of program backlog refinement also requires every PO’s participation and close involvement. Before the event, the PO will keep the team backlog updated and will contribute to creating the vision and charting out the roadmap.When the planning event is in progress, the PO should be at hand to give clarity wherever needed. The entire SAFe team will work to map out the team’s PI objectives for the upcoming PI.2. During the IterationDuring the iteration execution, the PO holds extremely critical responsibilities:The PO builds, updates and maintains the team backlog, with updates from all stakeholders and the team. Reviewing and ordering the team backlog as a precursor to the Iteration Planning event is the responsibility of the PO. For this, they may need to coordinate dependencies with other POs.During the Iteration Planning event, the PO gives clarity of user story details, and is around to ensure alignment and concurrence on a final iteration plan. While the team elaborates on the backlog items and creates stories, the PO keeps track of the flow and maintains priorities. POs work with the team to flesh out each story, adding acceptance criteria and acceptance tests, applying Behaviour-Driven Development (BDD) practices. As the work progresses, the PO will work closely with the team to agree on the completion of accepted stories. and see whether they meet the Definition of Done and quality standards that have been laid down. The PO does not need to be a technical expert but should be able to understand the scope of the work that is coming up. He or she should collaborate with the engineers to assist in making decisions and sequencing the technological infrastructures that will enable the business functionality. During team demos, the PO coordinates between the team and stakeholders who are present.   They also participate in events such as the Iteration Retrospective and the Agile Release Train’s Inspect & Adapt workshop, providing the customer’s perspective on the work progress.3. During the Program ExecutionDuring each PI, the PO will connect with other POs to check and coordinate other dependencies, ensuring smooth work progress without any hiccups. They will sync up typically during weekly events. Additionally, POs play a valuable role in creating the System Demo for all the stakeholders involved in the program value stream. 4. Inspection and AdaptationThe Inspect and Adapt (I&A) workshop is held to address any large impediments to smooth progress. During this event, the PO works across teams to see how best to improve processes and increase team velocity and quality. During the I&A workshop, the PO participates in and holds the PI system demo for program stakeholders.SAFe Product Owner vs Scrum Product OwnerBefore we get into the differences in the roles and responsibilities of a SAFe Product Owner and a Scrum Product Owner, we need to also understand a third and more prominent role on a SAFe team: that of the SAFe Product Manager. The SAFe Product Manager is someone who works with several SAFe teams, typically two to four, and owns the Program Backlog—which gives him or her an overall view of the entire project (or the big picture).  The table below talks about the differences in the roles played by a SAFe Product Owner and a Scrum Product Owner.SAFe Product OwnerScrum Product OwnerBacklog ItemsA SAFe Product Owner undertakes the responsibility for the Team Backlog. This lists all the requirements (Backlog items) for the team.A Scrum Product Owner undertakes the responsibility for the Product Backlog. This is a prioritised list of all the requirements for the product.Number of teams they supportA SAFe Product Owner can serve, at most, two teams.A Scrum Product Owner can work with two or more teams.Vision and roadmapA SAFe Product Manager, not the SAFe Product Owner, defines the features and owns the vision and roadmap. A SAFe Product Manager is someone who works with two to four SAFe Product Owners. He or she will have an overall view of the entire program. As such, the SAFe Product Owner exerts less authority than the Scrum Product Owner.Scrum Product Owner defines the features and owns the vision and roadmap. So, as we can see, the Scrum Product Owner undertakes responsibilities that combine those of the SAFe Product Owner and the SAFe Product Manager (but to a smaller scale as the project is typically smaller).Who has the final say on the product?A SAFe Product Owner does not have a final say on what must be done for a certain Product. This is done by the SAFe Product Manager, who is the final authority and owns the vision and roadmap on a SAFe project.It is the Scrum Product Manager who has the final say on what needs to be done for the product.SimilaritiesJust like the Scrum PO, the SAFe Product Owner is also a core member of the team.  He or she is the customer proxy on the team, ensuring that the vision is always kept in focus.They have the responsibility of the Backlog- the Team Backlog in the case of the SAFe PO, and the Product Backlog in the case of the Scrum PO.Both POs work on prioritising the tasks that the team will take up next, guiding them on the relative importance of the stories.Again, both the SAFe PO and the Scrum PO work toward maximizing the product value.They keep an eye on the goal for the next iteration.They participate in reflections and inspect and adapt during and after each iteration.The two roles take part in the Planning, Retrospective and Review of an Iteration in SAFe/ Sprint in Scrum in a similar way.Can one person do both roles in SAFe; that of the Product Owner and Product Manager?The PO and the PM roles are completely distinct in SAFe, and each comes with its own set of responsibilities.There is a different focus for each role: The PM’s role is cantered on the benefits to the customer and the organisation. He or she is also the person with whom the business owners and members of the ART (Agile Release Train) connect. POs always have the needs of their own Agile team in focus.  Product Owners and Product Managers work together collaboratively to understand the customer’s needs and work toward fulfilling them. The flow of information is from the customer to the PM, and then down to the POs and their team members. The POs and PMs meet up at all ART or PO planning and sync up events and stay aligned with the same set of overarching goals. As we have seen, one person cannot undertake the roles of the SAFe Product Owner and the SAFe Product Manager at the same time. POs and PMs must at all times be connected, and work in tandem to deliver a successful product; however, having one person playing both roles is a sure route to disaster!  The last word… The SAFe Product Owner plays a role that is at the core of SAFe, setting up the product strategy, getting deep into customer requirements, and prioritizing the features as per their importance. They hold the responsibility of ensuring customer delight, even as they keep a pulse on the economic value that is to be derived from the product.  In the end, SAFe is all about giving the larger enterprise a framework for scaling Agile — to build better products, respond to volatile markets, and keep in step with emerging technologies — and without the Product Owner’s expertise, all this will fall short. 
What Is a Safe Product Owner?
Blogs
9262
What Is a Safe Product Owner?

The Scaled Agile Framework® (SAFe®) is, in the... Read More

How To Define Features in Agile Methodology?

Agile projects are known for their simple, iterative approach to cutting through the complexity. Even the most ambitious of Agile projects is taken one step at a time and breaks down complex work packages and tasks into low-level subtasks. Features and capabilities that are needed in the finished product are listed out, and then broken down to manageable chunks which are taken up and completed, one at a time.In this article, we will talk about Features in an Agile project. What are the characteristics of features and how are they applied? How do you build a feature list, and what are the advantages of breaking down features into user stories? Read on to find out!Agile projects are known for their simple, iterative approach to cutting through the complexity. Even the most ambitious of Agile projects is taken one step at a time and breaks down complex work packages and tasks into low-level subtasks. Features and capabilities that are needed in the finished product are listed out, and then broken down to manageable chunks which are taken up and completed, one at a time.In this article, we will talk about Features in an Agile project. What are the characteristics of features and how are they applied? How do you build a feature list, and what are the advantages of breaking down features into user stories? Read on to find out!What is a feature in Agile methodology?A feature is a service or function of the product that delivers business value and fulfils the customer’s need. Each feature is broken down into several user stories, as it is usually too big to be worked on directly. A user story is an informal, short description of a part of a software feature that is written from the user’s perspective and talks about how this particular bit of the feature will offer something of value.Why use features in Scrum and not only user stories?A feature is something that is sizeable enough to deliver measurable value to customers and creates a large chunk of functionality. Features are used to describe the functionality at a macro level, and they are required to create schedules and plan the high-level release of the product.Scrum works on the premise of short development cycles called Sprints, which usually last between 2 weeks and a month but not longer. One feature is typically completed over several sprints. In one sprint, only several user stories can be completed and not, perhaps, an entire feature.What’s the difference between features and epics in Agile?The product backlog is usually detailed into three levels of complexity with respect to tasks. Epics are large quantities of related work that can be broken down into features. A feature, as we have seen, is a service or function that delivers value to the end user. Each feature is broken down into a number of smaller and simpler tasks known as user stories. Do note that for a smaller project, with only around 8 to 10 people on the team, the product backlog may be divided into just features and user stories. Epics come into the picture for large projects with multiple teams who are working over a duration of several years.Who writes the features in Scrum, and what are the steps involved?The Scrum Guide, considered to be the Bible for all things Scrum, does not lay out any guidelines for the use of features.However, Scaled Agile, Inc. indicates that the Product Manager is the owner of the Features, which is to say, he or she finally decides what goes into the feature and what is its priority on the Backlog. The features are not necessarily written by the Product Manager, however, and this could be done by others on the team.On many teams, the Product Manager and the Product Owner are one and the same.There are several steps in the definition and writing of features. Define the WHY, or the benefit hypothesis: What is the functionality that the users gain from the feature? What are the benefits to be gained from implementing this feature? Calculate the business value: Keep in mind the number of users, how often each of them uses the feature, what is the timeframe within which the feature must be released for it to be useful, and how much effort goes into developing this feature. All these together will help to determine the ROI of the feature and ultimately whether it is worth the effort and cost. Features that bring in the most benefit at least cost will be prioritised. Describe the feature: What is the context and how will it be used? What is the need for the feature? Try to include technical details and any information that is important from the Product Manager’s point of view. Write down the acceptance criteria: What are the conditions under which the feature can be deemed to be done? This will help to reduce any ambiguity and mark work progress. How big should the product features be?While there is no hard and fast rule on this, and it is left largely to the convenience of project teams, it is generally agreed that it should be possible to complete a feature within a maximum of three months. When using SAFe, a feature is released in one single program increment. Teams that are working with investor funding and are getting the funds at regular cycles should be able to showcase a completed feature during each investment cycle, in order to demonstrate that they are progressing on track. What are feature points?Feature points represent the amount of the work complexity, effort taken, and knowledge required to complete one feature. They are the same as story points, but in the context of a feature rather than a user story.What are features called in different Agile Methodologies?A feature, while essentially having the same definition, could be called by different terms in different Agile methodologies. In Scrum, a feature is often referred to as a Backlog Item.   In XP, features are called Stories. DSDM terms a feature as a requirement. This could club together several system features. Agile UP defines features in the form of requirements and use cases.What are the characteristics of features?To be effective, a feature should always Offer measurable business value,   Contain enough information to allow for estimation of the work involved, Be small enough to be completed within a program increment or maximum of three months,   Be testable by the scrum team and the product management team.Feature breakdown structure (FBS)When getting into the nitty gritty of detailed planning, agile development uses a feature breakdown structure (FBS) approach that breaks down each feature into smaller, more manageable units of work. This allows easier communication between the customer and the development team, where both can understand each other well in a way that leaves no room for ambiguity. It also helps to track the progress of work against the value that is created. Over time and as the work progresses, the larger features can be broken into smaller features, instead of doing this breakdown all together in the beginning. This way, details are not fleshed out until the time when they are actually needed for design and delivery. Building an initial feature listAt the very start, before the release planning and iteration planning can happen, the team must sit together and list out as many potential features for the system as possible at this stage. Feature requests can come from many sources, and one person should be allocated to collate all these requests. While this could be the product manager, it could also be a customer proxy, a business analyst or someone who is responsible and accountable to the team. The team should refine these requirements, weeding out duplicate items, features that are not possible to implement, and requests that are very vague. As the features are identified, they are added to the list so that they can become a part of the planning processes. This initial feature list can be considered to be a preliminary outline that can be used as input to chart out the release and first iteration. It is not required to wait until all features are defined before getting started on the actual work, and it is also understood that the original list, descriptions, and priorities will evolve over time. Instead of waiting for everything to get detailed out at the outset, the team can get to work with the initial list without wasting any valuable time. As new features which could be critical get identified, they are simply added into the evolving release plan and will get delivered during a subsequent iteration. As the project progresses, the work adapts itself to accommodate new priorities, additional information from stakeholders, and the changing industry dynamics.Advantages of breaking down features into smaller user storiesUser stories, as we have learnt, represent smaller chunks of work while features represent fully formed functionalities of the product. There are many advantages to breaking down the features into functionalities, and the main ones are these: Stories narrow down the focus: Stories are small, doable portions of the work that do not overwhelm the developer. They represent an entire piece of functionality, however small it is, and so can measure incremental progress. Stories fit into a sprint: Features are too large to be completed within a sprint, but stories can be finished within this duration. This allows more efficient scheduling and planning of sprint tasks. Stories capture both intent and outcome: A product manager (who is not required to be technically fluent) can easily describe the outcome of a story to the developer, so that he or she can understand the intent. Stories mitigate the risk: As big stories come with a lot more complexity, they also involve more risk. When features are broken down into smaller stories, this risk is mitigated. Anny erroneous assumptions can be curtailed within a few days rather than several weeks into development. Feature vs. task planningFeatures come into play at a macro level of planning, and it is essential that at a later point they will need to be broken down into tasks and estimated. This is done during sprint planning and release planning.Feature planning and estimates help to schedule releases and iterations. Task planning and estimates help to allocate resources and plan the tasks within an iteration.Since the nature of agile project plans is always fluid and not very precise, feature estimates need not exactly map to a number of task estimates, but there should be a rough approximation between the two.
How To Define Features in Agile Methodology?
Blogs
7351
How To Define Features in Agile Methodology?

Agile projects are known for their simple, iterati... Read More

What Best Describes a Scrum Team?

We are living in an age where speed is the secret to success, and the one who gets the product out first is the winner. In this digital transformation world, organizations that have adopted Agile will succeed; as Agile is all about adaptability, quick delivery and customer focus.  Scrum, the most used Agile framework is all about addressing complex problems through adaptation and value creation. Scrum teams are at the core of a Scrum project. What best describes a Scrum team? Let’s attempt to answer this question.What is Scrum?A term borrowed from rugby; Scrum actually means ‘to huddle’. It signifies how rugby payers huddle together and work as a team in order to gain possession of the ball. Like its namesake in the sport of rugby, Scrum in Agile software development also signifies a process that brings together a team of individuals who work together under complex circumstances to create a product. The term was first used by researchers Hirotaka Takeuchi and Ikujiro Nonaka in their 1986 research paper, "The New Product Development Game."“Scrum is a framework that encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve”—Atlassian Agile coachWhat is the Scrum Methodology?Scrum is a framework under the umbrella of agile development methodologies, along with Kanban, Extreme Programming, Feature-Driven Development, Crystal, and Dynamic Systems Development Method (DSDM).The Scrum methodology focuses on delivering products of the highest quality through effective collaboration between teams involved.  Scrum is based on the three pillars of empirical process control, which are transparency, inspection, & adaptationThe Scrum FrameworkScrum is an Agile methodology framework that follows an iterative and incremental approach for project management, and breaks down large projects into small chunks called epics and sprints.  Each sprint results in the creation of a product and the cumulative effort of all the sprints adds to the improvement of the overall end product. The Scrum framework encourages high level collaboration among team members which comes in handy in tough project situationsWhat is a Scrum Team?Scrum.org is what best describes a Scrum Team by defining it as ‘a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.’ So, in essence Scrum teams are self-organized and highly productive teams that deliver quality products in a highly collaborative environment.  A Scrum team’s success is based on the Scrum values that they share. These are:Commitment:  Commitment is one of the hallmarks of Agile teams. Teams collaborate and work on a common goal through a high degree of communication and trust between them.Courage: Scrum teams must have the courage to fail. Fail fast is a benefit in Agile and Scrum as this helps them discover hidden faults and recover quickly. Scrum teams must have the courage to try new things, innovate, fail and then learn from their failures to ultimately achieve success.  Focus: Having focus is a mandatory requirement of Scrum teams which ultimately helps them limit the work in progress.  Openness: Transparency and openness is also one of the empirical processes on which Scrum is based. Teams that are open and transparent with one another trust each other more and work better towards reaching a successful end point.Respect: Respect between team members is a must, irrespective of the methodology or framework they use. Respect between Scrum Masters, Product Owners and Development team members will help foster trust and enhance collaboration and co-operation between teammates.What describes a Scrum team?A Scrum team consists of three main roles. These are:Development TeamScrum MasterScrum Product OwnerThe development team consists of five to eleven people including developers, testers, architects and others. The Scrum team has a shared goal and through their collaboration and skills of self-organization and motivation, they reach this goal.What is a Scrum Master?The Scrum Master, also known as the servant leader, helps empower the team and guides them on the use of the Scrum framework. Their main responsibility is to ensure that the development team can perform to the best of its abilities, and they do this by removing obstacles or impediments that may hinder the progress of the development team. The Scrum Master is the agile coach and mentor who helps team members understand Agile and its processes and aids in enterprise-wide agile transformations.The Product OwnerThe Product Owner is the bridge connecting the stakeholders and the development team. They define the product vision and through their skills and intelligence drive the project with help from the Scrum Master and the development team. The product owner maintains the perfect balance between the stakeholder and the development team, helping each understand the other’s point of view. They are also well-versed in agile and scrum values and principles and guide the team and well as the stakeholders on the agile ways of working. Creating stakeholder satisfaction is an important responsibility of the product owner and they do this by ensuring that requirements are met, and the product created meets quality standards expected by the customer.The Development TeamThe development team is the driving force of the Scrum project. This team is empowered by the Scrum Master and the Product Owner to take decisions and be as autonomous and independent as possible. At the same time there is a high level of collaboration and transparency among the team members and between the dev team and the Product Owner. The dev team is balanced and helps the product owner manage the backlog and deliver an acceptable product at the end of every sprint.Why is the Scrum team required for organizations?Any organization that wants to go agile and implement projects using the scrum framework has to do so by getting together an efficient scrum team. Scrum has proven to be extremely successful at team levels and it is the Scrum team that drives the project to success. Scrum teams with their collaboration, self-organization, innovation and collocation are able to drive success and business value.A table that summarizes the Scrum Team’s responsibilities in the various Scrum processesScrum PhaseScrum processScrum Master responsibilityProduct Owner responsibilityDevelopment team responsibilityInitiate1. Create Project Vision------2. Identify Scrum Master and Stakeholder(s)--Identifies Scrum Master--3. Form Scrum TeamAlong with the PO decides dev teamAlong with the SM decides dev team--4. Develop Epic(s)Helps PO in developing epicsDevelops epics and arranges user group meetingsHelps PO in developing epics5. Create Prioritized Product BacklogHelps PO in epic refinementRefines epicsHelps PO in epic refinement6. Conduct Release PlanningHelps PO and dev team with backlog prioritization and determining sprint lengthReviews the backlog and develops release planning scheduleHelps PO with backlog prioritization and determining sprint lengthPlan and Estimate7. Create User StoriesHelps dev team and PO write user storiesWrites user stories and incorporates them into the Prioritized Product BacklogWrites user stories8. Approve, Estimate, and Commit User StoriesEstimates the effort required to deliver the product defined in each user storyApproves user stories for the sprintAlong with the SM estimates the effort for each sprint and9. Create TasksHelps dev team break down the stories into tasksHelps dev team break down the stories into tasksBreaks down the approved stories into tasks and create a task list10. Estimate TasksHelps the dev team create the effort estimated task listHelps the dev team create the effort estimated task listCreates the effort estimated task list11. Create Sprint BacklogHelps the PO create sprint backlogCreates the sprint backlog and lists the tasks that need to be completed in the sprintHelps the PO create sprint backlogImplement12. Create DeliverablesGuides the dev teamHelps dev team if neededWorks on creating sprint deliverables13. Conduct Daily Stand-upArranges and conducts the meetingsMay or may not attend the meetingsAttends the meetings and defines any problems or issues faced14. Groom Prioritized Product Backlog Helps PO to groom the backlogUpdates and maintains the backlog continuouslyHelps PO to groom the backlogReview and Retrospect15. Convene Scrum of ScrumsHelps teams collaborate and notes any impediments that may be hindering work--Mentions their progress or any issues they may be facing16. Demonstrate and Validate Sprint Helps dev team in displaying what it has createdApproves or rejects what the dev team demonstratesDemonstrates deliverables to PO and stakeholders17. Retrospect SprintMeets with dev team to ponder on lessons learnt during the sprint. Documents the recommendations--With scrum master retrospect's on sprint and uses the recommendations for the next sprint18. Ship DeliverablesAlong with other team members ships acceptable deliverablesAlong with other team members ships acceptable deliverablesAlong with other team members ships acceptable deliverables19. Retrospect ProjectGets together with other team members and identifies the lessons learntGets together with other team members and identifies the lessons learntGets together with other team members and identifies the lessons learntSo, what best describes a Scrum team? There are many facets to a Scrum team, but the most relatable description would be a highly interconnected and cohesive unit that works together to solve issues. A well-organized Scrum team can raise the ROI of an organization and ensure long term stakeholder commitment.
What Best Describes a Scrum Team?
Blogs
391
What Best Describes a Scrum Team?

We are living in an age where speed is the secret ... Read More

Scrum Software for the Ultimate Project Management

Technology has made our lives easier. The number of tools and devices we have at our disposal has made our lives more productive and our work more efficient. The Agile software development methodology has been adopted by several organizations to improve their adaptability, responsiveness, and productivity.  How can we improve the way we incorporate Agile Scrum into our projects? Scrum tools can be the answer. Just like the other gadgets in our lives, Scrum software and tools help improve the productivity of our teams, keep stakeholders happy and help us deliver better products. Before we jump into the use and needs of Scrum software and tools let us understand more about Scrum roles and how they work.Three essential roles for Scrum successThe Scrum Guide defines three pillars of a Scrum team, which include:The Scrum MasterThe Product OwnerThe Development TeamThe Scrum team is a small unit which is self-organised and works towards achieving the same goal; that is, the development and deployment of the product and customer satisfaction.The Scrum Product OwnerThe Scrum Product Owner is among the most essential roles in the Scrum team and acts as a bridge between the stakeholders and the development team. More involved with the business side of the software development process, the PO represents the customer and can be considered as their proxy.  The Product Owner defines the product vision, and, along with the Scrum Master and the development team works towards delivering a product that matches stakeholder needs.The Scrum MasterThe Scrum Master is the servant leader whose main responsibility is to ensure that the Scrum team can perform to the best of its abilities. They do this by overseeing the day-to-day activities of the Scrum team and removing any impediments that may hinder the productivity of the development team. The Scrum Master facilitates stakeholder collaboration along with the product owner and ensures that teams can handle complex environments and deliver projects successfully.The Scrum development teamThe development team generally consists of three to nine people, according to the Scrum Guide. These would include developers, testers, designers and more. The team is allowed to take decisions and decide the length of the sprint and how they will go about it. The development team collaborates to create a high-quality product increment at the end of each sprint that is as per the expectations of the stakeholders.Scrum ceremonies or eventsScrum has five formal events as defined by the Scrum Guide. These events help to validate the Scrum artifacts and implementing them helps enhance transparency. The events are also called ceremonies and are:Sprint PlanningDaily ScrumSprint ReviewSprint RetrospectiveThe SprintWhat Does A Scrum Tool Do?What would you need a good Scrum tool to do? Make your life easier by making processes more efficient and less cumbersome, help you deliver quality products without making a huge dent on your budget, right?  With Scrum topping the popularity charts for Agile project management methodologies, the need for efficient Scrum tools has risen. There are plenty of Scrum tools available that fit the bill and provide interfaces that help teams seamlessly follow Scrum processes and reap its benefits. These tools help:Increase productivityIn task management, daily scrum management  Increase team collaborationIn progress tracking and risk managementScrum Software for the Ultimate ProjectThere are several Scrum software tools that aid in project development using Scrum; not just in technical environments, but in non-technical sectors as well. Software like JIRA, Infinity, TargetProcess, QuickScrum, Wrike etc provide:User friendly GUICompetitive pricingProduct backlog managementTime tracking and calendar tools for schedulingScrum metrics and chartsSprint planning toolsThird party tools for integrationUser story mappingBurnup and Burndown chartsand many more features that will help Agile teams serve their customers better, improve return on investment, reduce costs, enhance collaboration and ensure stakeholder satisfaction. These tools help team uphold the values of Agile and make implementing the Scrum framework easier.Best Scrum ToolsHere are some of the best Scrum tools available in the market:1. JIRAJira is a popular tool used by large organizations to manage their Scrum projects. It has numerous features including customizable scrum boards, reporting features and more. Here’s how teams benefit from this toolCustomizable Scrum and Kanban boardsRoadmaps to communicate with team and with stakeholdersAccess to tools for Agile reportingView of code and deployment statusEnd to end DevOps visibilityEasy scalabilitySecure deploymentDeveloper tool integrationRich APIs to automate processes2. TargetProcessThis tool has been especially designed for teams that want to scale agile. It offers a number of customizable features that make it easy to work with scrum and agile.  Here’s how teams benefit from this tool(Source: Targetprocess Agile Portfolio and Work Management Tool)IdeationBuilt in reports to analyse data and uncover trendsGather ideas across sourcesCloud hosting and on-premise hostingEnterprise grade securityCollaborate across the enterprise  Collaborate with DevOps tools including GitLab, Azure DevOps, GitHub etc3. VivifyScrumThis tool is marketed as an all-in-one solution to manage projects, collaborate and track. Here’s how teams benefit from this tool (Source: Agile Project Management Software - VivifyScrum)Tools to manage agile projects—organize, manage, track and deliverCollaboration boards to effectively collaborate with team and stakeholdersCreate invoices to track and manage business and clientsManage teams and track tasks4. InfinityThis tool is among the most popular in Agile and Scrum organizations due to the many customizations and features it provides. Its various tools help reduce time to market, ensure better quality, improve collaboration and enable customer satisfaction.Here’s how teams benefit from this tool Source: Infinity | Customizable Work Management Platform (startinfinity.com)How Can Scrum Apps Benefit Your Team?The number of Scrum apps and software available in the market for Scrum projects is mind boggling. Which one you choose depends on the requirements of your team and project, and each comes with its own benefits. Some of these benefits include:They help teams, organizations and the product being createdThey ensure better quality by providing the right framework, support mechanism and the right processesAllow for continual improvement by putting in place a feedback loop and sprint reviews by stakeholdersHelp solve impediments and daily issues by incorporating daily testing and product owner feedback into the development processEnsure upfront documentation and help prioritise high value items in the product backlog, thus decreasing time to market.  Quick feedback also helps improve the product and thus helps in continuous improvement.The faster marketing of products increases return on investment, helps tap the market demand and ensures long term benefits for the customer and thus earns their trust for the organizationThe primary tenet of Agile is team collaboration. Scrum software tools help in high level collaboration between the Scrum Master, Product Owner and the development team. Teams can organise, review, plan and discuss everyday tasks, meetings, impediments and more.How to Pick the Best Tool for Your Team?With so many options available, choosing the right Scrum tool for your team can be a tricky task. What you need to do is go through the features of the best tools and see which one best fits your requirements. While the number of features you get will be directly proportional to the money you are ready to pay for the tool, there are some basic requirements your tool must satisfy.Backlog creation:  The very basic format of a Scrum project lies in the creation of a product backlog which sets the pace for the entire project. The backlog is primarily created by the Product Owner with assistance from the Scrum Master and the development team. The tool you choose should help you create the product backlog so that you can prioritise items, define the sprints and identify sprint goals.Implement feedback:  Scrum projects are based on the Agile values of continuous feedback. Your scrum tool should have features which will make your customer’s feedback and requirements easily accessible to you. This will help you implement these changes at the earliest. This continuous feedback loop will help keep customers happy.Sprint creation:  Scrum is iterative and adaptive and works by breaking down projects into small sized sprints. Your tool must aid you in the creation of sprints and burndown charts. These help you keep track of your progress on the project and are essential components of a Scrum project.The other things your tool should be able to do include:Plan and trackCustomise process templatesCustomise dashboards and reportsHelp in time managementHelp create epics and storiesProvide collab and reporting toolsProvide review toolsAnd just like you will create a product that is user friendly, the tool you use also needs to be user friendly for the team. If your team is happy using it, and it makes your life easier and your projects better, then you have the right tool!
Scrum Software for the Ultimate Project Management
Blogs
312
Scrum Software for the Ultimate Project Management

Technology has made our lives easier. The number o... Read More

What Is Scrum in Project Management?

The adoption of Agile has grown and evolved over the past decade, as organizations seek to adapt to changing industry needs and deliver products with higher quality and greater efficiency. Originally used in software development, Agile has now been adopted across all sectors and industries.As reported in the 14th Annual State of Agile, a whopping 95% of respondents are known to practice Agile development methods, of which the majority (58%) prefer to use the Scrum framework and its variants.What is Scrum Project Management?Scrum is the most popular among all the Agile frameworks. It offers immense flexibility—in fact, Ken Schwaber, the co-founder of Scrum, preferred to call it a framework rather than a methodology, as it simply outlines the delivery structure and leaves it to the team to determine their own best practices.In its simplest form, Scrum is a method of iterative and incremental product delivery that uses self-organizing and collaborative teams, who follow clearly laid out processes and follow prescribed events.In Scrum project management, work is executed in short time-boxed cycles called sprints, and the team holds daily meetings to discuss planned tasks and any impediments that need to be cleared.How does Scrum Project Management work?Usually used in software development projects, Scrum project management works well with small teams and for projects that require rapid development and testing, even with emergent and volatile requirements.Teams work in short sprints that are usually between 1 and 4 weeks in duration. This iterative cycle is repeated with a product incremental value being delivered at the end of each sprint. The cycle continues till the end of the project, when the entire product value has been delivered to the satisfaction of customers and stakeholders.  Since the tasks are reviewed at the start of each cycle, and there is continual seeking of feedback from stakeholders at the end of every cycle, Scrum adapts well to changing requirements.This process is in sharp contrast to traditional ‘waterfall’ methods of software development, where the product scope is fixed upfront, and changes cannot be accommodated till the end of the project.  In waterfall projects there is the need for extensive documentation and analysis before development can start, which often delays schedules. What’s more, feedback is not sought till the end, which often results in low quality products that are packed with features that the customer is unhappy with.The Scrum FrameworkA Scrum project starts with a clearly defined product vision and an outline of the features and functionality it is expected to have. These features are prioritised and listed out in the Product Backlog, which is a dynamic document that is ordered with reallocation of tasks at the end of each iteration (called a sprint).  The sprint is a time-boxed event during which the team will complete a subset of the features and create a product increment that offers value. Sprints generally run for one to four weeks, a duration that is pre-set and is maintained through the project.  At the beginning of the sprint, the sprint planning event is held, and the team commits to developing items from the product backlog that are required to be done first. These items go into the sprint backlog, which is a subset of the product backlog and includes the features and functionality that can be developed during the sprint.  As the work progresses, the team meets daily, checking in with each other to discuss the progress of tasks. They tell each other what was done the previous day and plan the tasks for the day ahead and talk about anything that is holding them back from completing the tasks at hand.  At the end of each sprint, the team demonstrates the product increment to the stakeholders and obtains their feedback. In accordance with this feedback received, the product backlog is ‘groomed’ and the remaining tasks are rearranged according to the new priority. A retrospective meeting is also held where they discuss what went wrong during the sprint, and how they can improve upon this in the next sprint.In this manner, Scrum processes follow the three pillars of Scrum: regular inspection, adaptation and transparency.Scrum RolesThe Scrum Team is a small group of people; typically, between 3 to 9 in number, who work together without any hierarchy. The Team comprises three Roles: that of the Product Owner, Scrum Master, and Developers.    The Developers, also called the Dev Team, are the people who create the product increment during each sprint.The Scrum Master, often referred to as the Servant Leader, is responsible for ensuring that Scrum practices as laid out in the Scrum Guide are followed. Scrum Masters serve the team (hence the name ‘servant leader’) and also the organization at large.The Product Owner looks into the business side of things, and ensures that the product vision is followed. He or she strives to maximize the value of the product and manages the Product Backlog.The Application of Scrum in ProjectsScrum is applied by following Scrum ceremonies, which are events held at specific instances during a sprint.The main ceremonies are the following:The Sprint Planning Meeting is held at the beginning of the sprint and is when the entire team gets together to plan the upcoming sprint and finalise the user stories that will be completed during the sprint.The Daily Scrum is a short meeting, held daily at the same time, when each team member answers the following three questions: what tasks were completed yesterday, what are you working on today and is there anything blocking your progress?The Sprint Review is the event during which the team shows a demo of the work done to the stakeholders and elicits their feedback and the feedback from the rest of the team. This feedback is tracked by the Product Owner and is added as tasks to be undertaken in the upcoming sprints.The Sprint Retrospective is the last Scrum ceremony, which allows the team to reflect on the sprint that has just concluded and find ways of improving the work and processes for the next sprint.Tracking ProgressThe progress of the team’s work is tracked using three methods: the task board, the burndown chart and the Daily Scrum.During the Daily Scrum, as already mentioned above, the team discusses what was done the previous day and what will be done during the rest of that day.The task board typically has three columns: To Do, Doing, and Done. During the Daily Scrum, each team member will move items across the board (either using post it slips, or small chits that are pinned to the board) to indicate the progress of the tasks mentioned on each chit. It is a visual representation of what the team is working on at any given moment.The burndown chart is a visual representation of the progress of work in the form of a chart, with the x-axis showing the number of days in the sprint, while the y-axis indicates the number of hours of work required to complete all the tasks for the sprint. The slope of the burndown chart should, ideally, come down to indicate that zero tasks are left when the time is completed.Together, these three tools give a fairly accurate idea of the progress of the work. The team will be able to determine whether the tasks are likely to be completed on time, what the impediments to progress are, and how the tasks can be planned.Grooming the BacklogIn between the sprints, it is important to carry out a backlog grooming or refinement session. This basically means that the scrum team meets and discusses the product backlog items and the work to be carried out in the next sprint. This helps in keeping the backlog up to date and getting it ready for the next sprint. Grooming helps to keep the product backlog de-cluttered, removes uncertainty and risk associated with the sprint, helps eliminate further meetings that may be associated with product backlog and leads to better sprint planning.Release PlanningRelease Planning, usually done once in a quarter, is done for multiple sprints together. This is a longer-term plan that is undertaken to get a perspective on when the product release is likely to happen and evaluates value and quality constraints against the available time, resources and budget.  The PO presents the list of features that must be completed during the upcoming quarter, and the team provides gross, rough estimates to check whether this will be feasible. The result of the meeting is internal and does not have to be showcased to the customers.Case study on Scrum in project managementWhile Scrum is most commonly used in software development projects, there are many examples of how Scrum has proved to be of great advantage in non-Scrum projects as well.A Scrum.org case study  outlines the journey of a major US Airline with over 4000 employees that leveraged the Nexus+ framework to scale Scrum across more than 10 globally distributed teams. The result was clean, streamlined processes, with a stunningly quick turnaround and improved ROI.This company had earlier used waterfall methods to create and manage their software products, and it would typically take them months or years to deliver a product to market. In multiple cases, by the time the product was ready to ship it was no longer usable due to the huge lapse of time in the interim.  Lola Tech was one of their software vendors, and their Head of Delivery decided to adopt agile across their entire product development suite for this company. Most of them had already worked with Scrum, and Nexus was their obvious choice.  When they started the adoption, they faced challenges in:The capability of building cross-functional teams, so that outside dependencies could be removed  The culture shift: changing from a Project Mindset to a Product Mindset  Being able to apply the Scrum framework effectively in its entirety, not just in partsBuilding psychological safety across teams  Strictly following the Scrum Values in mind and spiritGetting the teams trained was the first and most obvious step. PSTs trained the team members as well as vendors to achieve certifications that included PSM, PSD, PSPO and SPS, getting them aligned with the values and principles embodied in Scrum.  Once the team had their fundamental knowledge in place, they created an Agility Transformation Backlog and roadmap. Each of the challenges was broken down and solutions found—ranging from organizing team events to foster connections between remote teams, to properly understanding how to apply the framework effectively.  There were 5 Nexuses with each Nexus consisting of 5 to 9 Scrum Teams. Together, they worked on a product family made up of an operations platform for handling products sold, and two e-commerce platforms - a custom one, and another one for selling additional goods and/or services. These teams were brought in line to work with shared goals and a common vision and mission.After the first product releases, the results were quite astounding. They were able to achieve:Decreased Time-to-Market - From delivering yearly or twice a year in a waterfall fashion to delivering better software products, every quarter  Increased Profits – Achieving a 100% ROI in just 2 weeks after going live  Faster delivery - From getting the first releasable increment ‘Done’ in 2 months to having a releasable increment after a two-week Sprint  Greater collaboration - From the Dev team having zero interaction with the PO, to all the Developers having daily interactions which increased transparency and accountabilitySlashed Costs - By automating deployments, features and releases they were able to cut costs dramatically.There are many more such case studies at this link.Understanding the Project Manager Role in Scrum – The Scrum Master vs the Project ManagerBoth the Scrum Master and Project Manager are roles that maximize value for projects. While there are similarities between the two roles, the responsibilities of each are quite different.A Scrum Master is the servant leader on a Scrum team, who ensures that the team adheres to Scrum values, and acts as a mentor, guide, leader and facilitator all rolled into one. The Scrum Master works with only the Scrum framework and does not adopt other methodologies.The Project Manager, on the other hand, is a leader who manages one or several teams to plan, execute and deliver projects, maintaining complete control and responsibility over the project in its entirety. A Project Manager is free to choose traditional or Agile methods or choose a hybrid model, based on the approach that is considered most suitable for the project.The Scrum framework helps organizations to address challenging adaptive problems, delivering products of the highest value. Scrum values, principles, and practices have been proven to empower businesses to adapt to volatile conditions, developing products that delight customers in a quicker time, with optimal use of resources.  The Scrum Framework continues to be the preferred choice of agile practitioners. As its popularity continues to soar, with no signs of slowing down, it’s indeed time to go down the Scrum path!
What Is Scrum in Project Management?
Blogs
237
What Is Scrum in Project Management?

The adoption of Agile has grown and evolved over t... Read More

Safe Agile Ceremonies - Expert Guide

“Winners take time to relish their work, knowing that scaling the mountain is what makes the view from the top so exhilarating.” ― Denis WaitleyWhat are SAFe agile events (or) ceremonies? – a brief overview:Before we jump into the topic, could I just take you a step back and remind you what SAFe is all about? SAFe is a way of taking any iterative Agile way of working (normally restricted to a team or few teams) and scaling it up at various levels of the organization, whilst applying a mindset of Lean manufacturing. It also deals with scalability at various levels. Beginning from Essential SAFe right up to Full SAFe, the framework caters to all organizational levels of scaling agility. As part of this, it broadens the core idea of agility mindset beyond just projects/development teams right up to executives/CXOs, who must prepare for enterprise level uncertainties. In a sense, it provides valuable enterprise level scaling insights helpful for the executives to tackle any uncertainties/risks associated with a project.As you start applying SAFe in your organisation, it is important for you to understand how each level works in conjunction with the other, depending on how mature your SAFe enterprise is. The key link between these levels is the SAFe specific events which help with smooth value delivery facilitation. The events help with alignment across teams, ARTs etc thus helping in managing risk by providing a level based cadence and synchronization.Essential SAFe - Your First Level of Scaling Using an Agile Release Train (ART). Courtesy © Scaled Agile, Inc. Source: Scaled AgileWhy do we need level-based ceremonies?While it is important to go through your team level events (like the 4 sprint events if you are doing scrum etc.) it is important to have the scaling events that help with bridging gaps and unblocking dependency between teams. The most important part of these SAFe specific events is for ‘Business Stakeholders’ to get a look (demo) at a proper incremental product and thus the value arising out of it. Makes sense? It did for me and let me tell you why.I was once associated with 3 feature teams, who were working towards a common product goal. They all had the same business stakeholders but were working on individual features. Team A was working on developing a Login page, Team B was working on a landing dashboard while Team C was hopping along, trying to provide a search functionality for the user. All of them were applying the Scrum framework and were running their own events. Sprint demos were happening individually and were being represented by the Product owner separately along with his business analysts. All seemed fine but there was a nagging problem. The product owner was worried, because he couldn’t bring any business stakeholder to view the demos, as they were being run in silos and there was no visibility on the incremental product. Well technically there was, but they would have to sit through three or four-hour events individually to get bits and pieces of the product demo. In the real world, it's not a possibility simply because your business stakeholders will not have that much time to spend on multiple demos. It is not a good use of their time either. So, what’s the solution? Simple, it’s SAFe to the rescue! Let’s try and understand how the SAFe specific events help with this.Prescribed PI Cadence for Various Levels of Scaling. Courtesy © Scaled Agile, Inc. Source: Scaled AgileHow do the events (or) ceremonies help to scale up according to the levels in SAFe:SAFe is very relevant and designed to thrive in situations where there are significant cross functional dependencies between agile teams and support / functional teams (infrastructure teams, architect community etc).  Essential Level:   As you start to scale up one level up, you will be working with anywhere between 5-12 agile teams who will all be collectively working towards a common goal which is the program increment or PI. The anchoring catalyst that brings them all together is your ART (Agile release train). Before getting into the events, lets understand the various roles involved at this level because this is the common denominator across all levels of SAFe and across organizations. This is where you need to get it right without which there is not much use in scaling higher. Key Roles involved: Release Train Engineer (RTE) System Architect/Engineer Product Management   Business OwnersPrescribed events on a typical Agile release train (ART). Courtesy © Scaled Agile, Inc. Source: Scaled AgilePI PlanningAccording to me, PI planning (hands down) is THE most significant aspect of executing this framework. This is where all the magic happens. It is sometimes referred to as the heart of the framework as it offers a clear vision of what the program increment needs to be, what the cross-team dependencies are and how they bring together the cultural sustainability much needed within the release trains. It is so important, that if carried out incorrectly it could lead to several ambiguities, development challenges and mostly a disastrous product increment. However, when it works well, the iterative cycle serves to flesh out the crucial elements of the plan and the processes ensure buy in from the stakeholders.Duration: A normal PI planning is a 2-day activity, which is a face to face cultural get together of the various ART teams. However, a new 3-day distributed PI planning has been introduced to help with geographically distributed teams (across various time zones), very apt for the current pandemic situation.“There is no magic in SAFe® except maybe for PI Planning”. – The authors of the SAFe framework.In big organizations with multiple distributed teams across multiple vendors, work streams etc. it is almost impossible to run these teams independently, whilst still having to deliver an incremental program. SAFe via the PI planning exercise mentioned above, helps with sorting out these issues by recognising cross team dependencies upfront, constantly negotiating & visualising them. This doesn’t just stop with the PI planning but the framework also proposes a cadenced way of continuing this via the scrum of scrums. The Program Board is an ideal way to showcase the cross-team dependencies.A sample SAFe Program board. Courtesy © Scaled Agile, Inc. Source: Scaled Agile1. Inspect and Adapt (I&A)An inspect and adapt event is scheduled after every PI. This event is dedicated to aligning to the principles of Kaizen, which simply means to change for the better. The events contain self induced thought processes to revalidate your assumptions that everything is working OK. The I&A event consists of three sub-parts as below:  PI System DemoQuantitative and qualitative measurementRetrospective and problem-solving workshop2. ART Sync Agile release trains tend to apply a cadenced synchronization process to help manage the ability to focus on continuous value delivery. An ART sync will typically comprise of the below sub-events.  Scrum of Scrums: This event is for representatives from all the teams on a release train to come together in a regular cadenced manner, especially on large ARTs. This is normally facilitated by the release train engineer (RTE) and will involve scrum masters of the individual teams and a few selected team members (authorised by the team). The sole purpose of the SoS calls are to understand progress towards the common goal, validate cross team dependencies and unblock impediments that may arise out of them. Duration: The length and frequency of the meeting will depend on a few factors like the size of the ART, the release frequency, type of features being worked on, ability to decouple releases etc. For e.g an ART which releases features into production every 4 weeks might want to have an SoS call every 2 weeks for about an hour. Again, if this doesn’t work for you, just inspect and adapt to what works well for your organizational needs. Just make sure that the SoS is utilised for its sole purpose and not just status updates as depicted in the below comic representation.Scrum of Scrums PO SyncThis event is represented by the Product Owner, business analysts and the product management group. This is used mainly to level up the product backlog refinement and for clarifying PI (Program Increment) scope, reviewing roadmaps and grooming for the upcoming PIs.Duration: Very similar in concept to the SoS, so just follow what works for the group. 3. System DemoAs part of a common understanding towards delivering incremental software, shortly after each iteration in the PI, there is a system demo scheduled. Work completed across all teams from the release train are compiled in a stable environment before it is reviewed by the business stakeholders and other important sponsors who may have a keen interest in the product. This is on top of the individual team level demos that happen after each iteration.Duration: Anywhere between 2-3 hours that will allow time for a demonstration of the program increment in a collative manner, on top of what has been delivered from the previous PIs as well.In case your ART is pretty small, then you may want to have just have some of the events combined into a more generic ART sync, where all roles come together to collaborate towards the program increment. This can sometimes occur if the ART is focusing on a particular value stream, confined to limited business functionality, rather than elaborate features.Solution/Portfolio LevelsAs you scale higher, the processes and events become much less prescriptive. There is a good reason for this because the focus at this level is not just on having repetitive demos that have already happened before but on building thought leadership around business outcomes and enhancing business agility. Which is why we will not be diving deep into that in this blog. But let us look at the events that occur at the macro level.Lean Budget Review  Idea Sharing via Communities of Practice (not a formal event but a collaborative group)Solution DemoPortfolio SyncRoadshowWhat are the benefits of SAFe Agile ceremonies?:The Magic of PI planningWell, the more I talk about this, the more excited I am. A PI planning event when carried out to its truest purpose, gets half the job done. Here is where most of the brainstorming occurs and business value gets determined and, in some cases, gets assigned in a quantifiable manner to user stories and helps with the prioritisation.PI Planning Synchronisation towards a common goalThe events are a constant reminder that all teams are working towards delivering incremental value either on a particular value stream, or feature or program. An RTE and Product Management will help reiterating the need to focus on the larger goal whilst helping sorting out inter team dependencies.Less prescriptiveAs is the framework itself, SAFe events/ceremonies are less prescriptive. An SPC would recommend, apply the principles but inspect and adapt as to what works for your organization. As per the example I provided earlier w.r.t to the duration of the SAFe events, start with something reasonable and then validate its effectiveness. Then leave Kaizen to do the rest.Visualization of incremental value deliveryOpportunity for Business stakeholders and sponsors to have a look at the overall program increment every iteration, thus helping them evaluate the progress and provide timely feedback on market trends. What are the common mistakes?Lack of a shared product visionThings can go wrong if there is not enough representation in the product management group, say for e.g at the PO Sync event. This can lead to a blurred product vision with each team working out of sync. This may ultimately get detected too late, probably at the time of the system demo, and lead to a whole lot of unwanted rework.SoS as a status updateThe Scrum Of Scrum event should be used as an event to unblock cross team impediments or dependencies and not to just update what each team has been doing or is doing in its current sprint. TimeboxingGiven the scale at which these events will be conducted, it is critical that the associated events are facilitated in a timeboxed manner or else the participants could end up sitting and talking for hours. Roles like RTE, SPC Coaches etc will be critical in addressing this issue.Remote facilitationLack of effective collaboration tools could lead to some disastrous situations whilst facilitating the SAFe events. Given that most teams are running virtual ceremonies/events at the moment, its crucial to establish a working distributed model. This will then ensure that the platform is set up for the most effective collaboration and cross-functional work to take place.While you try to scale, as per the implementation roadmap, its essential that you solidify the process around which your ARTs will be functioning. It’s like setting the railway tracks with the correct track gauge matching the configurations of the wheelsets of the trains that will run on them. If not, they will just derail. As your ARTs pass through your set process, they will only benefit by sustaining focus and pace while moving towards a successful incremental product delivery.Thanks for your patience and wish you all the very best in your Agile journey. In case you want me to write about any specific topic, please feel free to comment below and I’ll be more than happy to add them to my ‘Blog Backlog’. If you liked the article, please do share it among your agile community to help spread the word.  Hope to see you soon, with more such interesting topics.
Safe Agile Ceremonies - Expert Guide
Blogs
172
Safe Agile Ceremonies - Expert Guide

“Winners take time to relish their work, knowing... Read More