Agile | Knowledgehut Blog Category

What is Program Increment Planning and its importance in SAFe®?

By KnowledgeHut

PI Planning or Program Increment Planning can be said to be the heartbeat of the Agile Release Train(ART). Even more precisely, it sets the tracks for the train to ensure that all rail cars(scrum teams that are a part of ART) travel in the same direction. It is similar to Iteration planning in crum. It is an extension of Iteration planning under a bigger umbrella i.e ART. PI Planning sessions are regularly scheduled activities held during the year where various teams within the same Agile Release Train (ART) collaborate to agree with a common vision, discuss functionality, prepare the roadmap and define cross-team dependencies. It's a fixed timebox for planning , designing, and validating a complete system, showing value, and having quick feedback. When you first follow SAFe, chances are, it will start with PI Planning. This is because it forms the basis for the Scaled Agile FrameworkTM. The PI Planning ceremony is the foundation of your transformation and the driver for SAFe. We will take a deep dive into PI planning in detail in this article and understand its importance in SAFe.What is SAFe®?Before understanding SAFe ,let’s first understand what Scrum is. Scrum is an iterative product creation approach focusing on a regular production cadence. It relies on cross-functional teams, a set of ceremonies, and certain specific supporting roles to help drive these deliveries.SAFe is an extension of Scrum at the larger organizational level. SAFe or the Scaled Agile FrameworkTM is a set of principles and strategies designed to help deliver resilience to all departments and levels of the organization. The system is designed to enhance visibility, coordination and cooperation which will result in improved efficiency , better outcomes and faster delivery.Image SourceIntroduction to Program Increment :PI Planning is particularly useful for agile companies of large scale. Let 's look at some figures, to understand the effect. Some bigger companies , for example, may have 300-400 teams and 5,000 developers. These teams may never have spoken to each other before, in the old way of working until a crucial issue forced them to collaborate.Previously, coordination would have been at the level of the leadership team, and they would have had several levels of managers in between who would trickle down details, but the people on the teams would never speak to each other. There would always be a constant struggle to work on the biggest projects for money, budget, and opportunities.Projects had a habit of overlapping - one team would release something which would then break something in the project of another team. PI Preparation is the first time that many of these very large businesses have joined their teams in a space or on the same call to speak to each other. They are given the opportunity to nut out those crucial talks about who is working on what. When you enter a code or a code repository, you need to know how it can affect another team. You may also need to do some work to allow another team to work first (and vice versa) on their feature.An ART (agile release train) is a shared objective accomplished by the soul of the different teams that work together. In very large companies, there can be three trains working together, and that is the reason why the teams need to step back every eight to 12 weeks and make sure that they continue to work towards the overall vision and company goals.Here’s what PI Planning enforces:CommunicationVisibilityCollaborationAs a result, teams can more easily get work done, deliver more updates in less time, and remain on budget.Executing the PI /Agenda- It is very important to understand the steps involved in executing PI. Let's try to understand the same:1) Preparation: It will cover the prerequisites for successful PI.Organization preparation : PI meetings are supposed to be arranged well in advance, and it is important to call into account all the stakeholders and leaders involved in the program. Usually, large organizations arrange this as a quarterly meeting, which helps to talk about the end of the preceding quarter and to set all in order for the start of the next quarter.Content preparation: For the launch the preparation on the aim and the vision has to be made well in advance. This should be drilled into the team from day one, which is done by the Company owners and the leaders of the projects who are in the best position to do so. Facility preparation: A spacious room that is twice the size of the amount of people should be prepared, where the employees are able to walk around and ask other employees questions.2) Agenda:Setting the agenda is very important and should be mapped out at the outset. Motivational speakers should be called in, who can take time to remember the successes of the last PI. Always provide some time for introductions through ice breaking games. It is important that the teams get to know each other, so that they can work well together. All these can be helpful in work teambuilding and bringing a social aspect to the case.Here is an example of an agenda from ScaledAgileFramework.com. It outlines the critical steps for a successful case.Day OneBusiness Background – The background of the business is provided by a senior management member or a company owner who offers insights on business performance and on how they are able to keep up with market demands and customer needs.Product / Solutions Strategy- The Project management will outline the company vision for the next PI. The salient features that will help achieve these targets will be defined by the company management.Architecture Vision & Development Practices – Next, the Systems Architect or IT department will talk about the systems and architectural vision for infrastructure upgrades that will help increase market time and will affect growth during the upcoming PI. Process changes associated with Agile that would improve speed and communication will be discussed.Preparation Background & Lunch – After this, it is the turn of the Release Train Engineer (RTE) to explain the planning process for PI and what the teams and the general meeting are required to do. The planned results for the meeting will be discussed, and any questions from the Team will be addressed.Team breakouts- Teams will meet around the boards (analogue or digital) to measure their pace for each iteration and look at their backlogs and what needs to be progressed to help the functionality outlined in the vision. They will apply their draft plans to review and provide input to all the teams. They'll need to recognize and mitigate possible threats and addictions.Draft Plan Review- During this time-boxed meeting, teams will deliver their draft plans and receive input from product owners, company owners, stakeholders and other teams. They may use the feedback to fine-tune their drafts before consulting the management. They will also discuss possible issues to be addressed by the management.Review by Management and Problem Solving- Draft plans would also raise problems with design, scale, and people and resource constraints. Only the management renegotiation and future features may often solve these problems. The RTE (Release Train Engineer) organizes this meeting and stakeholders and business owners must come out of the meeting with a new set of goals or features for the teamsDay 2 AgendaProgram Adjustments- At the start of the day, changes or decisions taken at the problem-solving meeting by management and stakeholders will be considered. Teams are apprised of these changes and decisions and priorities may be revisited. These adjustments will be put on the board of the company so that all departments can take a look and reorganize themselves.Breakouts- During breakouts, teams take the changes back to their discussion meeting and come back to the program board with their PI targets. Company owners may assign values to each of the goals and rate them for execution. At this stage, teams will get a clearer sense of their targets in the context of the iterations ahead.Final Plan Review and Lunch- Finally, each team will carry their plans to the front and present them. Threats and dependencies will be listed out at the finish of the presentation. While this is not the time to try and fix those problems, the various plans are posted to allow the teams to review and get inputs from others.Program Risks-All teams listed their risks and dependencies in the preceding phase. Now that all the goals are written, the teams will tackle each risk in turn and decide whether they can be resolved. The risks fall into one of below categories:Resolved- The teams conclude after discussion that the topic is no longer a problem. Owned – Someone on the train takes ownership of the item to work on a later resolution of the issue. Accepted – Certain threats are simply facts or future issues that need to be acknowledged and embraced. Mitigated- Teams will strategize together to mitigate a risk item 's effects. The solution or fix is implemented.Trust Vote – Once all the challenges and targets are discussed and addressed, the teams can vote on their conviction that the target can be achieved in the coming PI. The Trust vote is a quintessential vote, when team members can hold up one to five fingers in a show of hands. Anything that is less than a three-finger ballot should be re-looked at.The team member who has an issue with that particular goal would need to give more clarity, so that the teams can fix it. Once the issue has been resolved, the target of achieving a vote of confidence for the coming PI is again put to vote.Retrospective – The RTE will have a brief retrospective on the PI Planning case at the very end of the meeting to collect input about what was going well for the case, and what needs to be modified or enhanced for the next event.Day 18:00am - 9:00amBusiness context9:00am - 10:30amProduct/solution vision10:30am - 11:30amArchitecture vision & development practice11:30am - 1:00pmPlanning context & lunch1:00pm - 4:00pm Team breakouts4:00pm - 5:00pmDraft plan review5:00pm - 6:00pmManagement review & problem solving Day 28:00am - 9:00amPlanning adjustment9:00am - 11:00amTeam breakouts11:00am - 1:00pmFinal plan review & lunch1:00pm - 2:00pmProgram risks2:00pm -2:15pmConfidence vote2:15pm - X:XXPMPlan rework (if needed)When readyPlanning retrospective & moving forwordThis plan may be ideal for you or you can change it according to the needs of your team. Distributed teams, very large ARTs, and other factors can require the schedule to be modified in a creative way. You will find some sessions require more time, while others may need to be shortened. If it's your first PI Planning experience, try the regular agenda, get input from your team and play with different formats.PI Output- The output which comes out from PI planning is as follows :Smart goals are set by each participating team.The program manager updates the program board based on PI output. The feature list is accepted by each participating team.The new release date for features is aligned between teams.Dependencies of roles (between teams and other ARTs) are set.Milestones are noted down.Planning for PI offers many business advantages including: Setting up face-to - face contact with the stakeholders and all team members – It is critical to keep everybody focused on the event. Establishing the social network depends on the ART – The purpose of icebreakers and team-building games is to help instill trust and collaboration even for remote team members.Matching progress on business goals with the business background, vision, and priorities of the Team and Program PI – Everyone comes together so that they feel like a part of the process and are able to grasp the vision of the organization.Finding similarities and promoting cross-team and cross-ART communication – Many people who have been virtually in touch are now able to put a face to a name. When resolving concerns, dependencies and threats, it's important for everyone to feel comfortable reaching out for support and finding out how the teams can work together.Quick decision making –No need to worry if they have received your text or wait for someone to get back to you when everyone is together. Rather than days or weeks, discussions and decisions take place in minutes or hours.When is PI Planning held?Many businesses think that the correct period of time for an increment is 8-12 weeks (which adds up to 4-6 x 2-week iterations). Some firms keep PI Planning quarterly, for example: Q1 PI: December Q2 PI: March Q3 PI: June Q4 PI: September But timing and duration depend on how long each phase of the program is planned to last. The positive thing about PI Organizing activities is that they happen regularly on a set timetable, so you can plan well in advance for them. That means there is plenty of notice from teams and business owners to ensure they can turn up for the case.What is a pre-PI Planning event and when is it needed?Since the two-day PI Preparation case obviously is just not enough, pre-planning events may be required. These exist for a very good purpose -to make sure the ART is synchronized before PI Preparation is carried out within the wider Solution Train. It's all about synchronizing with the other ARTs to ensure that the answer moves in the right direction, along with the organization. What normally happens is that key people from the Solution Train, along with members from the ARTs and related suppliers get together. Here are some of the people you'll find at such an organizing event : Solution Train EngineerSolution ManagementSolution Architect/EngineeringSolution System TeamRelease Train EngineersProduct ManagementSystem Architects/EngineersCustomersThey'll look at the top Project Backlog, Project Goal, Vision, and Solution Roadmap capabilities. It's a lot like PI Preparation, but at a higher level, through the solution as a whole and not just the individual work. The event begins with each ART summing up its previous increment and achievements in order to set the context. A senior executive would then brief the attendees on the current situation before Project Management addresses the new vision of the project and any improvements from what had previously been discussed.Remote Teams must be engaged and accountableThe Agile Manifesto says, "A face-to - face interaction is the most effective and efficient method of conveying information to and within a development team." Keeping the members of the remote team involved and focused on the planning tasks can be challenging indeed. A range of video conference services are available on the market that allow teams not only to carry out video conferencing with individual members, but also to interact with local teams with cameras. Everyone can see and communicate with one another in the same way as if they were all seated in a conference room together. Applications like Zoom / Web ex / Google Meet /Microsoft Team offer video conferencing facilities for teams and can be used for group sessions for PI preparation. Remote participants can be asked to keep their cameras on so they can be seen.ConclusionWithin the grand scale of today's development environment, teams are often divided across geographies. Team members who are going to be on-the-spot can attend the PI meeting in person, but entire groups might not be ready to participate from the same location. Remote teams should be able to collaborate and give their feedback, in order for SAFe to develop.In such cases, RTEs and company owners need to think outside the box as online technologies evolve. They must prepare to organize and train teams to use these technology resources for effective collaboration. The more frequently the teams use the tools, the simpler it'll be to use them for major events like PI Preparation and alternative iteration conferences and ceremonies. For answers to questions, often teams operating within the same building will profit from providing a remote source of knowledge and a common source of truth within the organization. It can also help to encourage team members to know their stakeholders and product managers, so that at the right time the right people can answer the right questions.Teams who are able to meet this challenge will benefit from the largest pool of skills and expertise, and can get set to reap the highest chance of success in this fast-paced industry.

What is Program Increment Planning and its importance in SAFe®?

By KnowledgeHut

PI Planning or Program Increment Planning can be said to be the heartbeat of the Agile Release Train(ART). Even more precisely, it sets the tracks for the train to ensure that all rail cars(scrum teams that are a part of ART) travel in the same direction. It is similar to Iteration planning in crum. It is an extension of Iteration planning under a bigger umbrella i.e ART. PI Planning sessions are regularly scheduled activities held during the year where various teams within the same Agile Release Train (ART) collaborate to agree with a common vision, discuss functionality, prepare the roadmap and define cross-team dependencies. It's a fixed timebox for planning , designing, and validating a complete system, showing value, and having quick feedback. When you first follow SAFe, chances are, it will start with PI Planning. This is because it forms the basis for the Scaled Agile FrameworkTM. The PI Planning ceremony is the foundation of your transformation and the driver for SAFe. We will take a deep dive into PI planning in detail in this article and understand its importance in SAFe.What is SAFe®?Before understanding SAFe ,let’s first understand what Scrum is. Scrum is an iterative product creation approach focusing on a regular production cadence. It relies on cross-functional teams, a set of ceremonies, and certain specific supporting roles to help drive these deliveries.SAFe is an extension of Scrum at the larger organizational level. SAFe or the Scaled Agile FrameworkTM is a set of principles and strategies designed to help deliver resilience to all departments and levels of the organization. The system is designed to enhance visibility, coordination and cooperation which will result in improved efficiency , better outcomes and faster delivery.Image SourceIntroduction to Program Increment :PI Planning is particularly useful for agile companies of large scale. Let 's look at some figures, to understand the effect. Some bigger companies , for example, may have 300-400 teams and 5,000 developers. These teams may never have spoken to each other before, in the old way of working until a crucial issue forced them to collaborate.Previously, coordination would have been at the level of the leadership team, and they would have had several levels of managers in between who would trickle down details, but the people on the teams would never speak to each other. There would always be a constant struggle to work on the biggest projects for money, budget, and opportunities.Projects had a habit of overlapping - one team would release something which would then break something in the project of another team. PI Preparation is the first time that many of these very large businesses have joined their teams in a space or on the same call to speak to each other. They are given the opportunity to nut out those crucial talks about who is working on what. When you enter a code or a code repository, you need to know how it can affect another team. You may also need to do some work to allow another team to work first (and vice versa) on their feature.An ART (agile release train) is a shared objective accomplished by the soul of the different teams that work together. In very large companies, there can be three trains working together, and that is the reason why the teams need to step back every eight to 12 weeks and make sure that they continue to work towards the overall vision and company goals.Here’s what PI Planning enforces:CommunicationVisibilityCollaborationAs a result, teams can more easily get work done, deliver more updates in less time, and remain on budget.Executing the PI /Agenda- It is very important to understand the steps involved in executing PI. Let's try to understand the same:1) Preparation: It will cover the prerequisites for successful PI.Organization preparation : PI meetings are supposed to be arranged well in advance, and it is important to call into account all the stakeholders and leaders involved in the program. Usually, large organizations arrange this as a quarterly meeting, which helps to talk about the end of the preceding quarter and to set all in order for the start of the next quarter.Content preparation: For the launch the preparation on the aim and the vision has to be made well in advance. This should be drilled into the team from day one, which is done by the Company owners and the leaders of the projects who are in the best position to do so. Facility preparation: A spacious room that is twice the size of the amount of people should be prepared, where the employees are able to walk around and ask other employees questions.2) Agenda:Setting the agenda is very important and should be mapped out at the outset. Motivational speakers should be called in, who can take time to remember the successes of the last PI. Always provide some time for introductions through ice breaking games. It is important that the teams get to know each other, so that they can work well together. All these can be helpful in work teambuilding and bringing a social aspect to the case.Here is an example of an agenda from ScaledAgileFramework.com. It outlines the critical steps for a successful case.Day OneBusiness Background – The background of the business is provided by a senior management member or a company owner who offers insights on business performance and on how they are able to keep up with market demands and customer needs.Product / Solutions Strategy- The Project management will outline the company vision for the next PI. The salient features that will help achieve these targets will be defined by the company management.Architecture Vision & Development Practices – Next, the Systems Architect or IT department will talk about the systems and architectural vision for infrastructure upgrades that will help increase market time and will affect growth during the upcoming PI. Process changes associated with Agile that would improve speed and communication will be discussed.Preparation Background & Lunch – After this, it is the turn of the Release Train Engineer (RTE) to explain the planning process for PI and what the teams and the general meeting are required to do. The planned results for the meeting will be discussed, and any questions from the Team will be addressed.Team breakouts- Teams will meet around the boards (analogue or digital) to measure their pace for each iteration and look at their backlogs and what needs to be progressed to help the functionality outlined in the vision. They will apply their draft plans to review and provide input to all the teams. They'll need to recognize and mitigate possible threats and addictions.Draft Plan Review- During this time-boxed meeting, teams will deliver their draft plans and receive input from product owners, company owners, stakeholders and other teams. They may use the feedback to fine-tune their drafts before consulting the management. They will also discuss possible issues to be addressed by the management.Review by Management and Problem Solving- Draft plans would also raise problems with design, scale, and people and resource constraints. Only the management renegotiation and future features may often solve these problems. The RTE (Release Train Engineer) organizes this meeting and stakeholders and business owners must come out of the meeting with a new set of goals or features for the teamsDay 2 AgendaProgram Adjustments- At the start of the day, changes or decisions taken at the problem-solving meeting by management and stakeholders will be considered. Teams are apprised of these changes and decisions and priorities may be revisited. These adjustments will be put on the board of the company so that all departments can take a look and reorganize themselves.Breakouts- During breakouts, teams take the changes back to their discussion meeting and come back to the program board with their PI targets. Company owners may assign values to each of the goals and rate them for execution. At this stage, teams will get a clearer sense of their targets in the context of the iterations ahead.Final Plan Review and Lunch- Finally, each team will carry their plans to the front and present them. Threats and dependencies will be listed out at the finish of the presentation. While this is not the time to try and fix those problems, the various plans are posted to allow the teams to review and get inputs from others.Program Risks-All teams listed their risks and dependencies in the preceding phase. Now that all the goals are written, the teams will tackle each risk in turn and decide whether they can be resolved. The risks fall into one of below categories:Resolved- The teams conclude after discussion that the topic is no longer a problem. Owned – Someone on the train takes ownership of the item to work on a later resolution of the issue. Accepted – Certain threats are simply facts or future issues that need to be acknowledged and embraced. Mitigated- Teams will strategize together to mitigate a risk item 's effects. The solution or fix is implemented.Trust Vote – Once all the challenges and targets are discussed and addressed, the teams can vote on their conviction that the target can be achieved in the coming PI. The Trust vote is a quintessential vote, when team members can hold up one to five fingers in a show of hands. Anything that is less than a three-finger ballot should be re-looked at.The team member who has an issue with that particular goal would need to give more clarity, so that the teams can fix it. Once the issue has been resolved, the target of achieving a vote of confidence for the coming PI is again put to vote.Retrospective – The RTE will have a brief retrospective on the PI Planning case at the very end of the meeting to collect input about what was going well for the case, and what needs to be modified or enhanced for the next event.Day 18:00am - 9:00amBusiness context9:00am - 10:30amProduct/solution vision10:30am - 11:30amArchitecture vision & development practice11:30am - 1:00pmPlanning context & lunch1:00pm - 4:00pm Team breakouts4:00pm - 5:00pmDraft plan review5:00pm - 6:00pmManagement review & problem solving Day 28:00am - 9:00amPlanning adjustment9:00am - 11:00amTeam breakouts11:00am - 1:00pmFinal plan review & lunch1:00pm - 2:00pmProgram risks2:00pm -2:15pmConfidence vote2:15pm - X:XXPMPlan rework (if needed)When readyPlanning retrospective & moving forwordThis plan may be ideal for you or you can change it according to the needs of your team. Distributed teams, very large ARTs, and other factors can require the schedule to be modified in a creative way. You will find some sessions require more time, while others may need to be shortened. If it's your first PI Planning experience, try the regular agenda, get input from your team and play with different formats.PI Output- The output which comes out from PI planning is as follows :Smart goals are set by each participating team.The program manager updates the program board based on PI output. The feature list is accepted by each participating team.The new release date for features is aligned between teams.Dependencies of roles (between teams and other ARTs) are set.Milestones are noted down.Planning for PI offers many business advantages including: Setting up face-to - face contact with the stakeholders and all team members – It is critical to keep everybody focused on the event. Establishing the social network depends on the ART – The purpose of icebreakers and team-building games is to help instill trust and collaboration even for remote team members.Matching progress on business goals with the business background, vision, and priorities of the Team and Program PI – Everyone comes together so that they feel like a part of the process and are able to grasp the vision of the organization.Finding similarities and promoting cross-team and cross-ART communication – Many people who have been virtually in touch are now able to put a face to a name. When resolving concerns, dependencies and threats, it's important for everyone to feel comfortable reaching out for support and finding out how the teams can work together.Quick decision making –No need to worry if they have received your text or wait for someone to get back to you when everyone is together. Rather than days or weeks, discussions and decisions take place in minutes or hours.When is PI Planning held?Many businesses think that the correct period of time for an increment is 8-12 weeks (which adds up to 4-6 x 2-week iterations). Some firms keep PI Planning quarterly, for example: Q1 PI: December Q2 PI: March Q3 PI: June Q4 PI: September But timing and duration depend on how long each phase of the program is planned to last. The positive thing about PI Organizing activities is that they happen regularly on a set timetable, so you can plan well in advance for them. That means there is plenty of notice from teams and business owners to ensure they can turn up for the case.What is a pre-PI Planning event and when is it needed?Since the two-day PI Preparation case obviously is just not enough, pre-planning events may be required. These exist for a very good purpose -to make sure the ART is synchronized before PI Preparation is carried out within the wider Solution Train. It's all about synchronizing with the other ARTs to ensure that the answer moves in the right direction, along with the organization. What normally happens is that key people from the Solution Train, along with members from the ARTs and related suppliers get together. Here are some of the people you'll find at such an organizing event : Solution Train EngineerSolution ManagementSolution Architect/EngineeringSolution System TeamRelease Train EngineersProduct ManagementSystem Architects/EngineersCustomersThey'll look at the top Project Backlog, Project Goal, Vision, and Solution Roadmap capabilities. It's a lot like PI Preparation, but at a higher level, through the solution as a whole and not just the individual work. The event begins with each ART summing up its previous increment and achievements in order to set the context. A senior executive would then brief the attendees on the current situation before Project Management addresses the new vision of the project and any improvements from what had previously been discussed.Remote Teams must be engaged and accountableThe Agile Manifesto says, "A face-to - face interaction is the most effective and efficient method of conveying information to and within a development team." Keeping the members of the remote team involved and focused on the planning tasks can be challenging indeed. A range of video conference services are available on the market that allow teams not only to carry out video conferencing with individual members, but also to interact with local teams with cameras. Everyone can see and communicate with one another in the same way as if they were all seated in a conference room together. Applications like Zoom / Web ex / Google Meet /Microsoft Team offer video conferencing facilities for teams and can be used for group sessions for PI preparation. Remote participants can be asked to keep their cameras on so they can be seen.ConclusionWithin the grand scale of today's development environment, teams are often divided across geographies. Team members who are going to be on-the-spot can attend the PI meeting in person, but entire groups might not be ready to participate from the same location. Remote teams should be able to collaborate and give their feedback, in order for SAFe to develop.In such cases, RTEs and company owners need to think outside the box as online technologies evolve. They must prepare to organize and train teams to use these technology resources for effective collaboration. The more frequently the teams use the tools, the simpler it'll be to use them for major events like PI Preparation and alternative iteration conferences and ceremonies. For answers to questions, often teams operating within the same building will profit from providing a remote source of knowledge and a common source of truth within the organization. It can also help to encourage team members to know their stakeholders and product managers, so that at the right time the right people can answer the right questions.Teams who are able to meet this challenge will benefit from the largest pool of skills and expertise, and can get set to reap the highest chance of success in this fast-paced industry.

Ten agile metrics you won't hate

By Deepti Sinha

A long-standing platitude says: “What gets measured gets done”, and in today’s context the phrase is upgraded to “What gets measured gets improved”. Either way, the emphasis is on measurement. In this article today, we will learn some basic agile metrics that can be used by the development teams to access and improve development, and optimize ways of working. With a strong competitive market, there’s a need to stay ahead of your peers, and provide optimal solutions. Here, we will discuss 10 agile metrics that can help teams carve their path towards success.What is an agile metric?Just going the agile way or adopting agile practices won't help much if the output is not measured. Agile metrics help to monitor productivity and quality across different phases during development. Metrics are standards of measurement that help the team to keep the performance in check and help to expose any gaps in performance early.Why should the teams use agile metrics (Benefits)? There are multiple benefits of using Agile metrics. Let’s first take a look at some questions that get answered:What are the problems that need to be addressed?Is the team on track?Is the value being generated out of the efforts invested?Is the team improving?Is the team working on the right things?Are the deliverables abiding by the quality standards?Top Ten Metrics 1. Sprint BurndownThis is one of the basic and most popular metrics used to measure the work remaining during the execution of the sprint. The graphical representation through a chart helps to keep a check on the rate of work completion, and how much needs to be accomplished. The chart comprises of X-axis and Y-axis, where the horizontal X-axis denotes time/no. of days and the Y-axis denotes the total amount of work. The total work can be estimated both in terms of man-hours or story points. The burndown helps in the prediction of whether the team will be able to complete the target sprint goal in the said sprint timeline.Image sourceComponents in the Burndown Chart:Total Estimate – The output of the sprint planning is in the form of work items or user stories that have been broken down further into tasks. Each task has an estimate with the unit in hours. The sum of the estimate from all the work items constitutes the total estimate which is represented in the Y-axis.Remaining Effort – With each passing day in a sprint, the team will be burning efforts on the tool according to the work completed. This creates a slope in the chart as the remaining effort gets decreased towards the end. This is the component that gets tracked in the burndown down the chart.Total Days – When the sprint length is defined, a set number of days are locked as the length. On the chart the total no. of days is represented on the X-axis. If there’s a holiday/weekend, the chart will show a flat line as the team will not burn any effort. This, again, depends on the tool and its customization. Some tools omit weekends and just represent the working days.Ideal Effort – It is represented through a diagonal line cutting across the chart and represents the ideal burning pattern. This is usually an auto-generated line to guide the team.2. VelocityVelocity is one of the powerful metrics in agile which is simple and easily adoptable. It is the sum of units delivered in a sprint, which is usually in story points. For example, if a scrum team commits 30 points in a sprint and delivers 28, then the velocity for that sprint is 28. As the team matures, the average velocity is calculated to predict the future capacity for the sprints. Velocity helps in getting the teams to predict correctly the amount of work that can be completed. If the average velocity of the team is 30, they know they can finish 300 story points worth of work in approx. 10 sprints.Velocity is not the measure of productivity, as it is just an average calculated unit based on the last few sprints. There might be fluctuations in the velocity due to an unstable team, holidays, legacy code, etc. It should be used as a planning tool for defining the work in a sprint. Each teams’ velocity is unique, and no two teams should be compared in terms of velocity.3. Cumulative flow diagram CFDs are stacked area charts that represent the number of work items in each column for a particular period. The lowest layer specifies the number of items in the completed state. The graph provides an essential way to envision project development and supports to visualize any possible difficulties. It represents the count of Backlog items on the Y-axis and maps them according to the state on the timeline represented on the X-axis. The cumulative flow diagram can be customized as per category or as per status.4. Release BurnupThe Release Burn Up Chart shows the current work progress against the total work planned. It also displays the total planned work, and the total work accomplished to date. One of the important aspects of this chart is the scope line which captures the deviation between the release start and the end dates. The horizontal axis (X-axis) represents the time; it can be sprints, phases, or just the timeline representing the completion of a quarter or the project or just a particular period in discussion. The vertical axis(Y-axis) represents the total story points in the backlog. The Burnup charts make it easy to read the total completed work, the scope changes, and their impact on the timeline, and the remaining effort to reach the completion. Along with this, it also helps in forecasting to achieve the release plan.5. Control ChartAs per Wikipedia “Control charts, also known as Shewhart charts or process-behavior charts, are a statistical process control tool used to determine if a manufacturing or business process is in a state of control. It is more appropriate to say that the control charts are the graphical device for Statistical Process Monitoring.” A control chart is used to monitor quality regularly. It helps to measure the impact of process change, or any team composition changes. It supports to evaluate the team’s historical performance and forecast the future work pattern. This helps the teams in setting up the goals. The Control Chart displays the Cycle Time or Lead Time for your project or sprint. It takes the time consumed by a respective problem in a certain status and plots it over a stated period. A Control Chart helps you categorize whether statistics from the existing sprint can be used to govern forthcoming performance.6. Lead TimeLead Time metric originated from the manufacturing method, more specifically from Toyota Production System. It is the total time elapsed from the initial request being made by the customer to the final product being delivered. When talking of software development, it is the movement of a requirement from ‘New’ state to ‘Completed’ state. In simple words, it is the time between the start and finish for any work item. For example, when you stand in a queue to order a burger, the time between when the order is placed and the time when the burger is received is the Lead Time. In Scrum, the lead time is defined as the time it takes from a requirement being added to the backlog to when it’s ready for delivery.7. Blocked TimeDuring the execution of the sprint, there might be situations that block the way of smooth sprint delivery. For example, an environment issue where the test cannot be performed on the code on the higher environment. Or a case where a technical dependency is blocking the way for the development team. The reasons can be countless, but it is important to capture the total time the team got blocked in the entire sprint. The scrum team can either block the task or raise a block card on the system/tool. The management can pull the real-time report on the blocked cards and help the team move forward. This should also be a part of the retrospective discussion for further improvisation. 8. Escaped DefectsNot every product delivered is error-free, as although multiple rounds of testing are done still some of the defects go unnoticed. They are found by the customers after the release date. These are termed Escaped defects. The cost of fixing a defect increases considerably the later it is found. The appetite for RAG(Red/Amber/Green) count/percentage varies across organizations. Getting more than 3 escaped defects can make the report RED for some. It is measured by the number of issues (bugs, defects, etc.) found in the product once it has been delivered to the user.9. Story Completion RatioWhen the team collectively comes up with the work items committed in a sprint during the sprint planning meeting, they come up with a list of user stories to be completed. The story completion ratio is the percentage of the total no. of stories delivered in a sprint against the committed ones. So, if a team commits 10 user stories in a sprint and delivers 9, the story completion ratio will be 90%. Story Completion Ratio = (Total No. of Stories Delivered / Total no. of Stories Committed) * 100This can also be used in the retrospection as a discussion point to identify the root causes and solutions for better delivery.10. Net Promoter ScoreThe Net Promoter Score is an index that measures the readiness of clients to commend a company’s products or services. To calculate NPS, one can ask, “How likely are you to recommend us to a friend or colleague?” and score the answers on a zero-to-ten scale. Based on their rating, customers are then classified into 3 categories: detractors, passives, and promoters.ConclusionMetrics help in building up the organization by analyzing the results and striving to make it better. They provide quantifiable awareness into the team's performance and deliver assessable goals for the team. Metrics helps the team to define a way for a better customer experience and a healthy work environment. The organization should opt for only those metrics that support the systems to flourish and not to counter the individuals or the team.

The Pros and Cons of the Scaled Agile Framework

By Dileep Rajkumar

“When you walk to the edge of all the light you have and take that first step into the darkness of the unknown, you must believe that one of two things will happen. There will be something solid for you to stand upon or you will be taught to fly.” ― Patrick OvertonThe Hurricane effect: In 2005, the US Government declared a state of emergency in Florida and a few neighbouring coastal areas. They were preparing for what was going to be one of the most devastating natural forces in modern history – Hurricane Katrina. The situation was chaotic with millions of people being evacuated from their homes, shelters running out of supplies and weather forecasts reaching new levels of unknowns. However, there were two people who were attempting to do the unthinkable. A reporter from a leading broadcasting company and a scientist from NWS were planning to understand the phenomenon better. They were preparing themselves to capture footage and data, by entering the inside of the ‘Eye’ of the hurricane; something unthinkable given the hazards of being at the epicenter of such a huge storm. The benefits though were remarkably crucial, with the data captured to be used for important scientific analysis and research, to help prepare better for such hurricanes. However, the big question was, would they survive? Much like the above scenario, SAFe® (Scaled Agile framework) is a modern-day IT storm that has hit the industry. When SAFe was introduced in 2011 not everyone was prepared for its landfall moment, but as more niche versions came out and the flexibility to apply it at various levels was rolled out with improvement of business agility at its core (the eye), many organizations have started to realise the benefits. However, the big question in this scenario is, how many of us have managed to get a peek inside the eye of this storm? Have we managed to utilise SAFe to realise potential business agility? In this article, we will be exploring exactly this along with the pros and cons of applying SAFe framework at your organization. What is SAFe? – a brief introduction SAFe is a way of taking any iterative Agile way of working (normally restricted to a few teams) and scaling it up at various levels of the organization, whilst applying a mindset of Lean manufacturing. SAFe feeds on the factor that there is an enormous need for adaptability in the industry, especially for large enterprises which are bogged down by legacy processes and outdated technological hierarchies but somehow need to stay relevant in the market, unable to respond to a rapidly changing customer need. If applied correctly, SAFe will empower businesses to compete in today’s marketplace and help them thrive in what is already a chaotic era of digital transformation. It is to be noted that since its launch, SAFe has had many versions rolled out, with the latest being SAFe 5.0, which is a significant update from the framework perspective itself. This version handles key guidance over several core competencies that will ultimately transform an organization into a Lean Enterprise and achieve Business Agility. Image sourceBeing an Agile enthusiast myself, I quite often get asked about when and why should we start using SAFe? Will it really work? etc. Hence the main purpose of this article is to is to bring out some general Pros and Cons (For and Against thoughts) that are out there in the public. This article will focus only on SAFe and will not be used to compare it with any other scaling framework. Pros of 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). Although there are numerous benefits of properly implementing SAFe, below are some of the key Pros which we will be highlighting in this article. Scalability at various levels – Beginning from Essential SAFe right up to Full SAFe, the framework caters to all organizational levels trying to scale agile. As part of this, it broadens the core idea of the agility mindset beyond just projects/development teams and extends it right up to executives/CXOs, who must prepare for enterprise level uncertainties. So, it provides valuable enterprise level scaling insights that executives will find useful while having to tackle any of these uncertainties/risks. PI planning & Dependency management – According 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 brings 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. 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. teams have to run 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 and 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.Image sourceImproved Time to Value – The great philosopher Aristotle once said “The whole is greater than the sum of its parts.”. Imagine a republic day parade where there are several regiments of the army, navy, and air force, along with their bands, all marching in synchronization. Regardless of whether you are a foot soldier, a wing commander or the president of India or somewhere in between, everyone is following the same process, protocols, creating a unified collaborative event. Much like this, in SAFe almost all parts of the organizations from scrum teams, ARTs, portfolio teams and C level executives, collaborate at an enterprise level by marching to the same drum beat, towards a unified set of goals. What this does is, it helps with a unified planning & execution, repeatedly, whilst incorporating timely feedback at all levels and thereby delivering value faster. Image SourceA customer story from Scaledagile.com website has a quote from a leading financial services company’s Agile coach – “Our time-to-value has gone down using the SAFe process. If reaching production would normally take 1 1/2 years, now it could be eight months with the new processes and approach.” A wonderful achievement indeed. Isn’t it? End User driven ideology – Having an empathetic mindset towards product design, build execution & delivery is a critical factor for the success of any product. SAFe proposes a primarily research driven, customer centric enterprise, focusing on producing empathy maps prior to the design phase to exactly understand how the end user will be impacted for any decision the enterprise makes. This also helps the organization to better understand market rhythms and stay ahead of the hype cycle, tapping into important unexplored areas giving the much-needed edge. Alignment to business goals – What SAFe does (and does beautifully) is, it breaks some of the silos between business and technology. It actively encourages business stakeholders to interact / brainstorm with the relevant IT product delivery teams. The stakeholders also help to quantitatively prioritise initiatives/work items by assigning each item a business value, thereby aligning the business and technology in terms of the enterprise level goals, values and ultimate vision. The interaction mostly happens through various events that are embedded in the framework itself like PI planning, system demos, scrum of scrums etc. Remember the last thing that we do not want to happen in an enterprise-wide transformation is a total misalignment between business strategy and IT delivery. Enterprise Business Agility – At the end of the day, whichever framework an organization uses to scale agile, it is of no use unless it helps the organization to thrive in this chaotic digital era wherein the key lies in the time taken to respond to market changes and dealing with ambiguous yet emerging opportunities. As mentioned in the above point, SAFe helps in aligning the business and IT strategy, making sure that there is a growing hierarchical structure running in parallel with an entrepreneurial network. This kind of a customer centric framework helps in offering both efficiency and stability served with a hint of innovation. Cons of SAFe: Too many jargons/terminologies to remember – SAFe does have a heavy usage of terminology. To name a few, they sound like this - release trains, Program Increments, runways, guardrails, enablers, spikes etc. Phew !!! let’s just take a breath eh?! Also it has its own way around things, when it comes to Agile terminologies. SAFe has managed to modify some of the common agile terms & processes in order to fit into the "framework" that they prescribe. For e.g. a sprint is referred to as iteration, story points come with prescriptions and spikes get estimated. Why would someone need to estimate and size Spikes? Can seem more like a Push rather than a Pull (top-down approach) – This is another seemingly un-intentional drawback of the SAFe framework, mainly because of multiple layers of administration and co-ordination. There are specific roles at each layer which tend to take away some of the obvious freedom from developers (unlike Scrum) and limit the flexibility to experiment. Not only does it take away the limelight from the self-organised teams but also almost makes them extinct when it comes to decision making. Image sourceThe Hardening sprint – A notoriously misused phase within the SAFe framework is the Innovation or IP sprint. Although it has a fancy name, teams or enterprises often use it as a hardening phase for the increment, mainly for bug fixing, pipeline issues stabilization etc. I have often seen hardcore agilists rant about this and question the very purpose of this phase. According to some, where incrementing features is fundamental to Agile and Scrum, this framework completely bypasses the same. This can occur in organizations who do not have a robust DoD (Definition of Done) both at team levels as well as enterprise level and are often overlooked at the retrospectives for the sake of meeting deadlines. Not for start-ups – Since SAFe is predominantly a large enterprise agility scaling framework, it may not suit a situation like a start-up, especially if the whole set up is less than say 30-40 people strong-- typical of any start-up company. Applying SAFe techniques in such a scenario may reduce the flexibility to react quickly in a volatile market. May seem Anti-Agile? – Ken Schwaber himself, has had a dig at this, questioning some of SAFe’s strategies, like the necessity for turning it into a product and licensing it, charging people to use it, adhoc tooling partnerships, etc. A few other agile practitioners believe that the SAFe framework is just too ‘complete’ to help the Agile culture of a company thrive, regardless of its size; unlike Scrum, which sticks to the true values & principles of agile and is left intentionally ‘incomplete’ in order to allow opportunities to adopt new values. In a way SAFe can hamper the “Individuals and Interactions” aspects. Conclusion:If your head is spinning right now, don’t worry, it's absolutely OK to be in that mind state for a moment, considering that implementing SAFe is a major decision for any organization and should not be taken lightly. It will involve a significant amount of effort, training time and of course cost. Understanding SAFe may prove to be a gargantuan task, but it is a necessity to understand the framework correctly. My suggestion is simple. If you want to implement SAFe, please go ahead, but do not rush it. Take it one step at a time and follow the SAFe implementation roadmap. This roadmap (depicted in the diagram below) is a very useful strategy and charts out some critical moves which are needed in order to achieve organizational change. Image sourceAny major decision like whether to implement or not to implement SAFe is almost likely to be very contextual. I am sure the adoption of SAFe is only going to increase as enterprises turn to something that is readily available to adopt and will definitely open up their cheque books for SAFe and its partners. However, the key would be in trying to understand and measure what impacts it is resulting in. Measuring some of the key aspects & business outcomes (like cycle time, release frequency, NPS, key business metrices like customer retention etc.) will be critical along with the adoption of SAFe. Remember, similar to the hurricane effect, SAFe is a storm in the current industry climate and is sure to take us all on a whirlwind tour. The trick is to be smart and have a peek into the eye of the storm, in order to reap the benefits and lay out strong foundations for the future of agile scaling at enterprise levels. 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.

Non-Functional Requirements

By Krishnakumar Kuppusamy

In this article, we will see what non-functional requirements are, and how they are elicited and captured in agile projects. You will understand the concepts through a few examples, and get to know the difference between functional & non-functional requirements. The impact of non-functional requirements in solution development is discussed, together with the implementation approach. Understand the concepts of non-functional requirements through a few examples, and their impact in solution development What is Non-Functional Requirement? “In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behaviour or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements” Source: https://en.wikipedia.org/wiki/Non-functional_requirement While functional requirements define “what” the system should do, non-functional requirements define operational capabilities and constraints that enhances the functionality and “how” the system should do it. They specify quality attributes of a system. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide v3) describes non-functional requirements as requirements that “do not relate directly to the behaviour of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have” (p. 16) How to Elicit Non-Functional Requirements? When the business analysts elicit requirements from the stakeholders on the functional aspects of the system, they also should understand from the stakeholder what attributes the system should provide in order to meet their business goals. For example, the website must be able to load within 0.5 seconds. Eliciting a non-functional requirement is more challenging than the functional requirement, as the stakeholders/users are good at articulating the functional requirements well; while they may not be aware of, or good at explicitly stating non-functional requirements. Business analysts will have to get these requirements from stakeholders by asking the right questions. NFRs are implicit by nature, meaning that people assume them to exist without being asked. Some of the questions to be prompted that may help the business analyst to ask stakeholders how they want their system to function include the following aspects: Performance – speed of the system e.g., response time, throughput etc Availability – what is the impact if the system is not available for the customer? Security – ensuring unauthorized access to the system Data Retention - how long should the data be retained in the system for reference? This could be a regulation from the government/country. Usability – easy access for the customer/user while using the system Stability – code/system stability when dynamic changes apply due to business needs Compliance – understanding compliance needs by local laws/regulations Reliability – probability of system performing without failure Recoverability – ability of the system to recover from failure Serviceability – ease of system service when necessary Data integrity – accuracy and correctness of data maintained in the system Scalability – ability of the system to scale when more resources are added Capacity – how much the system can store information Accessibility - how easily people with the widest range of capabilities can use the system. Non-Functional Requirements in Agile A common challenge for an Agile team is dealing with capturing non-functional requirements in a user story. The non-functional requirements can be written as a user story and made available in the product backlog or sprint backlog. For example, “As an ecommerce website user, I want the website to be available for 99.99999%, so that I purchase products whenever I feel like” NFR can also be included as Acceptance Criteria in a user story. For example,for the following user story, “As an ecommerce website user, I want to search for products, so that I can purchase them”. NFR as acceptance criteria would be “application responds to search request within 5 seconds from the time request is received”. Examples of Non-functional requirements Some of the typical non-functional requirements considered during system development are: Performance – funds transfer transaction should not take more than 0.5 seconds Availability – the system should be available for the users to use the system anytime of the week they need Security – payroll data is not visible to all the employees in the organization. Only the authorized personnel should have access to the data Data Retention – all healthcare data should reside in the system for 7 years. Older data can be archived and should be accessible when required Usability – the system navigation is easy for the end user and provides a seamless journey while accessing the system Stability – the code/system is stable when new changes are applied due to dynamic business needs Compliance – HIPAA compliance should be adhered when dealing with patients’ data in USA Reliability – website users should be able to access the system 99% of the time without any failure Recoverability – In case of any major failures, the system should be restored within 48 hours Serviceability – the system should be serviceable immediately when there is a failure Data integrity – the system should not allow phone number to be entered in the data field Capacity – the system should be able to store 1 million records of basic customer information Scalability – the system should be scalable to support unlimited growth of the employees Accessibility - The system shall be accessible to people with disabilities in accordance with the Americans with Disabilities Act Confidentiality – The system shall not display the bank account number in full. It should display only the last 4 digits of the account number while others can be masked Efficiency – The interface between the system and user should not take more than 2 seconds Portability – The system shall be developed for both windows and Mac operating systems platforms Functional vs Non-Functional RequirementsS. NoFunctionalNon-Functional 1Defines ‘What’ of the customer requirementsDefines ‘How’ of the customer requirements2Elicited by business analysts, specified by the customerDefined by technical team like architects, developers etc3Documented as the requirements document by the business analystDocumented as the technical document by the team4Defines the functionality in the systemDefines quality attribute in the system5Captured as a user story in agileCaptured either as a story or part of acceptance criteria of a user story6Customer tests and validates the functionality as specified by themCustomers cannot test these quality attributes, however, can experience while using the system7Customers find it easy to define theseIt is hard to define by the customer8Defines the product featuresDefines the product propertiesThe Impact of NFRs on Solution Development  The business analyst and the project development team understand the customer requirements and expectations well and they are comfortable in converting the requirements into a finished product. Customer also validates the functional part of the requirements and signs off on successful implementation. However, the project success is dependent on the non-functional requirements as they define the quality attributes of a system. Some or all of the types of non-functional requirement that is described above contributes towards the successful implementation of the system. For example the system should be available all the time with minimal or negligible downtime, security is not compromised, maintaining confidential data/information, not allowing unauthorized users, scalable while the customer business is growing, having enough capacity to maintain product data considering future growth etc. Failure of any of these quality attributes will leave the customer unsatisfied. Implementation Approaches  In general, the focus of the project team is to provide the functionality that the user has given. The non-functional requirements are looked into towards the end of the project after the customer UAT is complete. The team then focusses on the non-functional quality attributes, and sometimes may not be able to fulfil them as the design of the system may not accommodate the respective implementation. It is good to see the trade-off between the quality attributes during the requirements and early in the design stage of the project. Defining the non-functional requirements needs thorough analysis and creativity in the early stages. It is recommended to consider this during the development life cycle of the software development, rather than leaving this to be discussed at the later stage of the project. As seen earlier, the elicitation of the non-functional requirements can be carried out by the business analyst by using the prompt list and added as part of the requirements document in the traditional project management. These requirements can be specified either as a user story or part of the acceptance criteria of a user story, which enables the team not to miss any of these during the development stage, without leaving it to the end of the project life cycle. Conclusion Successful implementation of a system depends on the non-functional attributes and their behaviour during the lifecycle. It is important to elicit or identify these quality attributes at the beginning of the system development cycle.

Expert Tips to Crack the Safe Agilist Exam in 2021

By Jim Stewart

What is SAFe®? Traditional Agile has always had an assumption of small teams. In recent years, several approaches (Large-scale Scrum (LeSS), Scrum @ Scale and Scaled Agile Framework (SAFe®) have evolved. The Scaled Agile Framework (SAFe®) is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices. SAFe® promotes alignment, collaboration, and delivery across large numbers of agile teams. It was developed by and for practitioners, by leveraging three primary bodies of knowledge: agile software development, lean product development, and systems thinking. According to the 2020 14th Annual State of Agile Report, “SAFe® is again the scaling framework of choice, leading with 35% of the respondents. This is up 5% from last year.” So, it would seem wise for any agilist or project manager to receive SAFe® certification. Scaled Agile, Inc. provides a variety of certifications from the foundational Leading SAFe® to SAFe® Advanced Scrum Master to SAFe® for Government. The full list is here: https://www.scaledagile.com/certifications/which-course-is-right-for-me/ This article will discuss the specifics around receiving the Certified SAFe® 5 Agilist certification. SAFe®- Lean-Agile Principles SAFe® is based on ten immutable, underlying Lean-Agile principles. These tenets and economic concepts inspire and inform the roles and practices of SAFe®. Take an economic view Apply systems thinking Assume variability; preserve options Build incrementally with fast, integrated learning cycles Base milestones on objective evaluation of working systems Visualize and limit Work in Progress (WIP), reduce batch sizes, and manage queue lengths Apply cadence, synchronize with cross-domain planning Unlock the intrinsic motivation of knowledge workers Decentralize decision-making Organize around value Key areas of competency As of this writing, the current version of SAFe® is 5.0. It is comprised of seven areas of competency, all under the heading of Business Agility: Enterprise Solution Delivery Agile Product Delivery Team and Technical Agility Lean-Agile Leadership Continuous Learning Culture Organizational Agility Lean Portfolio ManagementExam & Certification Details According to Scaled Agile Inc., a Certified SAFe® Agilist (SA) is a “Scaled Agile Framework® (SAFe®) enterprise leadership professional who is part of a Lean-Agile transformation. Key areas of competency: Apply SAFe® to scale Lean and Agile development in the enterprise Apply Lean-Agile Mindset and principles Plan and successfully execute Program Increments Execute and release value through Agile Release Trains Build an Agile portfolio with Lean-Agile budgeting Exam prerequisites Take the Leading SAFe® two-day class. Classes are mandatory as the course provides access to all the study materials and the exam.  5+ years’ experience in software development, testing, business analysis, product, or project management Experience in Scrum. the most popular type of Agile. The Leading SAFe® class, which is two days in duration, is provided by Scaled Agile, Inc. business partners and can be found on their site. Due to COVID-19 restrictions, many are currently being done remotely but there are some in person. Shop wisely as prices can range from $750 - $1195 USD. The exam format is a web-based, closed book multiple choice timed exam. There are 45 questions on the exam and once the exam is started it must be completed within 90 minutes. The passing score is 77% or 35 correct out of 45 questions. The exam is provided in English. Candidates cannot reproduce, use, or disclose any exam or test content in any form (digital, print, verbal) to anyone before, during, or after testing. Exam cost – First exam attempt is included as part of the course registration fee if the exam is taken within 30 days of course completion. Each retake attempt costs $50. Exam study materials Course materials – You will receive a Leading SAFe® workbook which covers the theory and practice of SAFe®. Study guide – The exam study guide is similar to the Project Management Institute’s PMP® handbook. It does not have tips as such but is an overview of exam preparation and the breakdown of study areas from which questions are derived. Practice test – According to the Scaled Agile, Inc. website, “the practice test is designed to be predictive of success on the certification exam and it has the same number of questions, level of difficulty, and time duration. It can be taken an unlimited number of times at no cost.” This is not the actual exam and passing it does not guarantee success on the certification exam. Sample Questions – A web-enabled, flashcard style version of the sample questions can be found online and in the study guideWhat you get Certified SAFe® Agilist PDF certificate. Certified SAFe® Agilist digital badge to promote your accomplishment online. The digital badge will allow people looking at your LinkedIn profile, for example, to verify your accomplishment. 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 including case studies and videos. Learning journey: checklist Decide on a learning path whether Scrum Master, Release Train Engineer, DevOps, etc is the right option for you at this point in your learning journey. There is no “best” certification. It is a matter of what gaining understanding and then deciding what role you want to play. Research and schedule the course related to the exam. Study the course materials. Take (and retake) the practice exam. Sit the actual exam. Note - While there are books on the market about SAFe®, there are no real commercial study guides we are aware of outside what Scaled Agile, Inc. provides. Attend the course The Leading SAFe® course has a duration of two days and is a mixture of lecture and interactive exercises. It is crucial to learn and understand the Scaled Agile framework, as not only is it key to understanding SAFe®, but it also fundamental to the exam. In addition to lectures, an exercise you might do in class, for example, is to use your team to simulate Program Increment (PI) Planning. PI Planning is a key element of SAFe® and is a “cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train, aligning all the teams on the train to a shared mission and vision.” The course will provide Professional Development Units and Scrum Education Units as shown below: PMI CertificationTechnicalLeadershipStrategicTotalPMP®6.006.003.0015.00PgMP®6.006.003.0015.00PMI_RMP®0.006.003.009.00PMI_SP®0.006.003.009.00PMI_ACP®0.006.003.009.00PfMP®0.006.003.009.00PMI_PBA®0.006.003.009.00Study and learn A common mistake many test-takers make is to put the books away after class, reasoning either that they are ready to take the exam or should take some time to relax. That is never a good idea and in fact the best way to approach studying is to see the class as the beginning of your studies. The information you received is fresh in your memory and the longer you wait to start studying, the more you will start forgetting what you learned. Set time aside every day (or at least five days a week if possible) to review the workbook and study for the exam. It’s best to space your studying out evenly and not cram at the last minute. If possible, find a “study buddy” from work or within a network association. You can challenge and teach each other.Take the exam This exam is accessed and delivered through the web on the SAFe® Community Platform after course completion. This is a “closed book” exam which means no outside materials (including the SAFe® website or training materials) or assistance can be used during the exam. (NOTE – this is an honor system as there is currently no proctor.) As mentioned previously, once the exam is started it must be completed within 90 minutes. There are 45 questions which allots 2 minutes per question on average. This does not mean that you must take 2 minutes on each question. But since you are being timed it is greatly advantageous to keep track of your time on every question. Never take more than 2 minutes. If you aren’t sure you can come back later or take your best educated guess. The exam does not use negative marking, meaning you are not penalized additionally for answering a question incorrectly. Exam retake policy Second attempt on exam (first retake) can be done immediately after first attempt. Third attempt requires a 10-day wait. Fourth attempt requires a 30-day wait. Generally speaking, it is the rule in standardized testing that the test organization makes you wait increasing amounts of time. This is due to the fact that they feel you are not ready and need more time to prepare. Continue the learning journey Once you are certified, it is important to keep up with your profession and with the SAFe® community. You can do this by being an active member of both the online community and other communities of practice; by refreshing your knowledge periodically and by getting involved in SAFe® implementations. Tips to Pass Your SAFe® Exam and Get Certified Treat your preparation for the exam like a project. Determine when you want to take it and then set up a schedule of study that will get you there and then stick to it. Take the exam as soon as possible after the class. Some may be ready right away, especially if they’ve been working with Scaled Agile, Inc. For most people it will be no sooner than two weeks from the course. For others 30 days is an appropriate amount of time. Scaled Agile, Inc. is sending a clear message by saying that the price of the exam will be included if you take it within 30 days. Clearly, they feel that is the optimal time and are incentivizing that behavior. Determine when is the best time of day for you to study. Some people are very sharp and very focused early in the morning; others can work just as well later in the day. Play to your strengths. If it’s noisy or distracting where you live and there is an open library where you can safely study, consider doing that. Libraries are very conducive to concentrated study. Consider making flash cards for memorization purposes. You can buy these fairly inexpensively and use them to enhance your knowledge. The very act of writing down information is the beginning of learning. There are also phone apps that have blank index cards. Once you’ve mastered an area, move on. You want to shore up your weaknesses. If you get a question wrong on practice exams, understand why you got it wrong. After the exam, questions are highlighted to let you know what you’ve gotten correct or wrong. There is a glossary on the SAFe® site that you are highly encouraged to memorize. Be sure to take the practice exam that is on the SAFe® site as many times as you need to. You want to be in “test mode” when you sit the exam. Maintaining your certification To keep a SAFe® certification in good standing, certification holders need to complete a predetermined number of continuing education hours (professional development units [PDUs] each year prior to renewing the certification. Examples of PDUs include attending a course, going to a conference, attending industry meetings (ex., Meetups), reading books, and reading articles. For Certified SAFe® Agilist, the requirement is for 10 continuing education/outreach hours. SAFe® certifications are valid for one year and include membership in the SAFe® Community Platform Renewal costs vary based on certification. Certified SAFe® Agilist costs $100 USD/yr.Upgrade path The author prepared for version 4.6 of this certification by attending a two-day class and then took the 4.6 exam. When version 5.0 was released, Scaled Agile, Inc. provided study tools and videos to prepare for taking that version. The current version of SAFe® is V 5.0. As of this post, according to the support group at Scaled Agile Inc., “We do not have a timeline currently for when new version of SAFe® will be ready.” Know your exam As mentioned previously, the exam is multiple choice. While there will typically be one answer, some may ask you to choose two or three. Some of the exam questions will offer scenarios; some will be definitional. While many of the questions will specifically be about SAFe®, some will also be from the generic world of Agile and may ask about items such as epics or the Agile Manifesto. Know the exam content Here is a sample question: What is the goal of the SAFe® House of Lean? Respect for people and culture Value Lean-Agile leadership Business agility The answer here is Value. “The goal of Lean is to deliver the maximum customer value in the shortest sustainable lead-time while providing the highest possible quality to customers and society as a whole. High morale, safety, and customer delight are additional goals and benefits.” Scaled Agile, Inc. provides a link to a page that has sample questions from all their exams. You can find it in the link below. This is a very good way to get a feel for the type of questions you might be asked. Note – they are not easy questions and will give you some idea of the type of preparation you will require. https://rise.articulate.com/share/AzITXNj_0Pe_Cm8TogNWBaJ5l4sjm6o3#/ Difficulty of the exam The author has received both SAFe® and PMP® certifications. In his considered opinion, the PMP® exam is one of the most challenging exams as it is very scenario-based, and the answers can be quite similar to each other. By comparison, while the SAFe® exam is difficult, challenging and requires rigorous study, it is not as scenario-based and feels less subjective. The questions also tend to be quite a bit shorter. But make no mistake – it is very challenging, and you must know the fundamentals of SAFe®. Conclusion Agile is here to stay and is slowly outgrowing its roots in software. In order to meet the needs of the enterprise, Agile must scale and SAFe® is the leading methodology to accomplish that. In order to stay conversant with the industry and also to find the best jobs, it is important to have good, marketable certifications. Scaled Agile, Inc. certifications are an important component of any good agilists’ CV.

Career Boost with CSM® Certification

By Manikandan Mohanakrishnan

The ecosystem and landscape around every business is changing drastically. Digital technologies enable entities to develop digital products / services and to conduct their business significantly differently. Example: Physical gift cards are now digital gift cards., like Amazon’s gift cards which can be shared with the near and dear ones during festive seasons or occasions. Customers can quickly buy this digital product online and gift it in a matter of a few seconds. This creates value for the customers and benefits the company that sells this product. Organizations are heavily investing in newer technologies and at the same time focussing on refining their existing processes and working culture. This enables them to increase and improve the speed and quality of the deliverables and also enhance customer experiences. This is why global entities have taken on many best practices to contribute to the success of the interactions they have with different stakeholders. In this digital era, faster turnaround time is seen as one of the important traits of organizations developing and selling digital products. To accomplish this objective, IT organizations are exposed to a gamut of agile development models. Today, “Scrum” (an agile development practice) is widely used as a mainstream practice in software development lifecycles, to create digital products like software. Let’s take a look at the overview of Scrum practices and understand how Certified ScrumMaster® (CSM®) certification can help you and your business. Scrum - an overview:Scrum methodology is based on principles like KISS (Keep It Simple & Straightforward) and progress iteratively with feedback. This practice is: lightweight and implementable model. based on team collaboration. deceptively simple yet difficult to master. based on “just enough” process and documentation mindset. An Analogy: Think about running a ten thousand metre race as a marathon run and slice the same race into some equal segments or sprints. Speed and quality increases when we slice the effort and maintain a constant pace or cadence.Scrum revolves around a concept called as “sprint” or a “timebox”. So, sprint is a timebox of 2 to 4 weeks used to deliver some parts of the complete software in an iterative fashion. A simple sprint structure is expressed in the below diagram. An Analogy: A teacher teaching the principles of abacus to the children divides the learners into four groups. The first set of children are beginners. They are taught to learn the abacus tools from scratch. They don’t have any targets as such. The second group of children know how to use the abacus tools and formulae. They are provided with a set of sums to solve with an upper time limit (for example 10 sets of sums in 10 to 15 minutes). The third set of children are in the advanced level. They are proficient enough to solve seventy to eighty sets of sums using abacus tools in less than five to seven minutes. Fourth set of expert level kids solve hundred plus sets of sums within five minutes with very minimal errors or no errors at all even without having a time pressure. From the above analogy, we can conclude that when we repeatedly practice a simple method many times over and over, we gain perfection, maturity, speed and quality. We can now relate it with Scrum methodology. Scrum operates around simple processes which revolves around the Deming’s cycle (Plan-Do-Check-Act). Let’s get introduced to some of the basic elements of Scrum which revolves around roles, artifacts and ceremonies. Basics of Scrum: Scrum Roles: Product Owner: The Product owner understands business, customer, market and stakeholder needs. This role serves as the voice of the customer who is responsible for maximizing the value of the product or software. Scrum Master :The Scrum Master is responsible for ensuring that Scrum is understood and enacted by all the stakeholders who interact with the scrum teams. Anyone who wears the cap of a Scrum Master has to take up a versatile range of roles such as facilitator, coach, mentor, trainer, enabler, change agent, servant leader etc. Development Team:The Development Team consists of T-shaped professionals who do the work of delivering a potentially releasable increment or a minimum viable product at the end of each sprint. Cross-functional teams who can collaborate and self-organize are capable of delivering the products to the stated quality. Scrum Artifacts: Product Backlog: The product backlog is simply all the things that need to be done within the project. In traditional project management, a product backlog can be referred to as a Requirements Documentation. This document is owned by the Product Owner and the requirements are prioritized based on the business value. Needs are captured in the form of user stories with acceptance criteria. Example of a user story: As a customer of the bank I want to update my latest communication address on my own using the bank’s app So that I can receive all the parcels/documents sent by the bank without missing them.Sprint Backlog: The Sprint backlog is a list of tasks identified by the scrum team to be completed during the sprint. During the sprint planning meeting, the team selects some number of product backlog items usually in the form of user stories, and identifies the tasks necessary to complete each user story. In traditional project management, this is also called as an Activity List. Minimum Viable Product: A Minimum Viable Product (MVP) is the sum of the Product Backlog items delivered during each sprint. Delivering the MVP in each sprint is fundamental to the scrum because when work is divided into simple pieces it can be finished in a short iteration. Example: An insurance company’s software development team is developing a mobile based app to sell their insurance products. In the first 3 sprints, the development team, delivers functionality and features that enable customers to buy insurance products online. Iteratively, the team delivers minimum viable products such as network locator, branch locator, feedback, track/modify policy, e-insurance card and so on. Scrum Ceremonies: Sprint Planning: The purpose of the sprint planning meeting is to estimate and forecast the work that can be accomplished by the team in the given sprint. Sprint backlog is the output of this meeting. Daily Stand-up: The purpose of the daily stand-up or daily scrum is to plan the day, identify risks and ways to mitigate them. Updated sprint backlog and burn charts / scrum board / Kanban board are the outputs of this activity.Sprint Review: The purpose of the sprint review is to showcase or demonstrate the developed feature to the product owner and other stakeholders. This promotes quick feedback. Sprint Retrospective: The purpose of the sprint retrospective is to identify improvements and mature the ways of working in the subsequent sprints.Certified ScrumMaster (CSM) Certification from Scrum Alliance: This is an instructor-led training program designed and crafted to increase the knowledge base on fundamental elements of scrum practices in about sixteen hours. This program will be driven by a Certified Scrum Trainer® (CST®). This certification is apt for professionals who: aspire to become a Scrum Master are project managers who encounter Scrum work with Scrum teams are Business Analysts who interact with Scrum teams are in IT Operations team and collaborate with Scrum teams want to begin their agile journey want to take other advanced certifications offered by Scrum Alliance want to learn the foundations of Scrum Exam: After successfully completing the course, a candidate can take an online examination. 37 right answers out of 50 will enable a participant to earn the CSM certification. The time limit for the exam is 60 minutes. Maintaining the certification : Keeping the certification active is a good way to continue reaping the benefits of being certified. An active certification will help practitioners stay connected with the agile community, share and gain knowledge and help the community thrive. To keep the credential active, a renewal fee of $100 for two years is applicable. One also has to clock 20 learning hours called SEUs (Scrum Education Units®) once in two years towards maintaining the credential. Benefits of CSM certification: helps in improving career prospects helps in marketability of one’s profile helps in demonstrating and improving the credibility of one’s profile Conclusion: In a nutshell, Scrum is a software development framework which supports the value statements of the Agile Manifesto. Roles, artifacts and ceremonies of Scrum encourages “individuals and interaction” promoting a transparent, self-organizing, trustful, collaborative environment, focuses on delivering “working software” or minimum viable product with just enough documentation, promotes “customer collaboration” and infuses a mindset to “welcome changes” based on feedback and business value. Scrum facilitates a disciplined way to develop products in an iterative way using timeboxing as its core mantra. Other agile practices such as Lean, Kanban, DevOps, Test Driven Development, Behaviour Driven Development, Feature Driven Development, eXtreme Programming, can be used alongside or to complement Scrum practices. Scrum can also be scaled up to make it suitable to work with larger sets of teams. Existing project management practices can be tailored to infuse Scrum into their ways of working. Any organization adopting Agile, can kick start the adoption by embracing Scrum as a steppingstone. Although there are many different certifications available on agile practices, CSM is seen as a simple and easy way for professionals to begin their Scrum/Agile journey. As per the data published in www.scrumalliance.org there are more than a million professionals across the globe who are certified in various agile certifications offered by Scrum Alliance. So why wait? Grab your opportunity now!

Category

Courses

Career Track

Data Science BootCamp

Career Track

FullStack Developer Bootcamp

Front End Development Bootcamp

Accredition bodies

Accredition bodies

Career Track

Data Science BootCamp

Accredition bodies

Career Track

FullStack Developer Bootcamp

Front End Development Bootcamp

Search

Trending blog posts

Agile blog posts

What is Program Increment Planning and its importance in SAFe®?

By KnowledgeHut

What is Program Increment Planning and its importance in SAFe®?

By KnowledgeHut

Ten agile metrics you won't hate

By Deepti Sinha

The Pros and Cons of the Scaled Agile Framework

By Dileep Rajkumar

Non-Functional Requirements

By Krishnakumar Kuppusamy

Expert Tips to Crack the Safe Agilist Exam in 2021

By Jim Stewart

Career Boost with CSM® Certification

By Manikandan Mohanakrishnan