Search

SAFe®️ 4.6 - The Latest Entrant In SAFe®️ Series With 5 Core Competencies

Scaled Agile Inc. (SAI) recently announced the latest version of SAFe®️, SAFe®️ 4.6 with the help of the whole Scaled Agile team and SAFe®️ Contributors. The SAFe®️ 4.6 version has underlined the introduction of ‘Five Core Competencies’ of the Lean Enterprise. The purpose behind incorporating those competencies is mainly to make the SAFe®️ organizations build a truly Lean Enterprise in a Lean fashion.  According to the Gartner report, SAFe®️ 4.5 is delineated as the world’s most widely used Agile framework at the enterprise level.This new way of working with SAFe®️ will open new avenues after the introduction of these competencies. At the same time, these competencies will become the primary lens for understanding and executing SAFe®️ in the organizations. Also, this new way of SAFe®️ working can make a big difference to the organizations that are struggling with their transformations.Here are the names of the five competencies introduced newly to build a better Lean organization in a Lean way. Lean-Agile Leadership Team and Technical Agility  DevOps and Release on demand  Business Solutions and Lean Systems Engineering  Lean Portfolio ManagementBenefits of SAFe®️ 4.6 competenciesHaving these five competencies allows organizations to-Navigate digital disruptionsRespond to the volatile market conditionsMeeting the varying customer requirements and latest technologiesLet’s explore each competency in details below.1) Lean-Agile Leadership:The Lean-Agile Leadership competency focuses on describing how the Lean-Agile leaders steer organizational change by encouraging the individuals and teams to reach their highest potential. The Lean-Agile leaders do this by learning, exhibiting, and coaching the Lean-Agile mindset, core values, principles, practices & features of SAFe®️.Changes made in Lean-Agile Leadership in SAFe®️ 4.6 versionThe SAFe®️ principles have been updated with a redraft of Principle #3 — Assume variability and preserve optionsA new advanced topic article, Evolving Role of Managers describes the changes and ongoing responsibilities of line management in the new way of working.2) Team and Technical AgilityThe Team and Technical Agility competency describe the critical skills and Lean-Agile principles and practices that are required to produce the high-performing teams. These high-performing teams focus on creating high-quality, well-designed technical solutions in accordance with the current and future business needs.Team agility – enables high-performing organized Agile teams to operate with the fundamental and effective Agile principles and practices.Technical agility – provides Lean-Agile technical practices to generate high-quality, well-formulated technical solutions that contribute to the current and future business needs.Changes made in Team and Technical Agility in SAFe®️ 4.6 versionThe new built-in quality practices that ensure that each Solution element meets the appropriate quality standards at every increment. These new built-in quality practices define 5 dimensions that permit quality- flow, architecture and design quality, code quality, system quality, and release quality.The roles in the Agile teams- Product Owner, Scrum Master, and the Development team are updated to reflect the new guidelines and thinking from the Team and Technical Agility competency and their responsibilities in Behavior-Driven development (BDD).Behavior-Driven Development is a test-first, Agile software development approach that has evolved from the Test-Driven Development. BDD provides a built-in quality by defining system behavior.Test-Driven Development (TDD) is a practice for developing and executing the tests before implementing a code or system’s component.3) DevOps and Release on demandThe DevOps and Release on Demand competency confer how the DevOps principles and practices allow the organizations to release value (in full or in part), at any time to meet the customers’ needs. This new competency enhances the in-depth level of guidelines on implementing a full continuous delivery pipeline.Changes made in DevOps and Release on demand in SAFe®️ 4.6 versionThe advanced Continuous Delivery Pipeline includes mapping the current Delivery Pipeline and improving the flow with the DevOps and Release on-demand health radar.The DevOps health radar is a tool to assess the progress and improve a flow of the program value with the help of Continuous Delivery Pipeline. This tool consists of 16 sub-dimensions (as shown in the figure below) programs that are used to assess the program’s maturity. It helps to identify our health-related dimensions (e.g. sitting, crawling, walking, running, and identifying the places where we can improve).4) Business Solutions and Lean Systems EngineeringThe Business Solutions and Lean Systems Engineering competency show how organizations can develop large and complex solutions and cyber-physical systems using a Lean, Agile, and flow-based, value delivery-model. This model makes the best of the activities necessary to specify, design, construct, test, deploy, operate, evolve and ultimately decommission solutions.Changes made in Business Solutions and Lean Systems Engineering in SAFe®️ 4.6 versionIn this competency, they have changed the eight practices for developing large and complex solutions. Following image shows the practices included in the Business Solutions and Lean Systems Engineering.They made changes in the Economic Framework with the following four primary elements:Operating within Lean budgets and guardrailsUnderstanding solution economic trade-offsLeveraging SuppliersSequencing jobs for the maximum benefit (using WSJF)The advanced Roadmap section introduces the multiple planning horizons and the Solution Roadmap that provides a longer-term- multiyear view, showing the key milestones and deliverable s required to reach the solution Vision over time. The roadmap also contains new guidance on understanding and applying market rhythms and events.5) Lean Portfolio ManagementThe Lean Portfolio Management (LPM) competency describes how an organization can implement Lean approaches to strategy and investment funding, Agile portfolio operations, and Lean governance for a SAFe®️ portfolio.Changes made in Lean Portfolio Management (LPM) in SAFe®️ 4.6 versionIn SAFe®️ 4.6, the changes are made in the organizational strategy formulation, the definition of the portfolio, and strategic themes.New Portfolio Canvas describes how a portfolio of solutions creates, delivers and captures value for an enterprise. The portfolio canvas defines and aligns the value streams of the portfolio and the solutions to achieve the organizational goals and provides a process on meeting the vision of a future state.The updated Lean Budget Guardrails ensures the right investments within the portfolio’s budget.Also, the changes are made in the Lean Budgets that provides a guidance on moving from the traditional budgets to Lean budgets, guiding investments by the horizon and applying participatory budgeting.The updated Value Streams includes a section for defining the value streams and a revised Development Value Stream Canvas that aligns better with the new Portfolio Canvas.Top-Level Government in SAFe®️ 4.6Another updated thing in SAFe®️ 4.6 is the SAFe®️ for Government. The top-level Government in SAFe®️ 4.6 describes a set of success patterns that support the public sector organizations in implementing the Lean-Agile practices. The SAFe®️ for Government also serves as a landing page for applying SAFe®️ in the national, regional or local government context. This provides the specific guidelines to address the following things-Creating a basis of Lean-Agile values, principles, and practicesBuilding the high-performing teams of Government teams and contractorsAligning technology investments with agency strategyTransitioning from projects to a Lean flow of epicsAdopting Lean budgeting aligned to the value streamsApplying Lean estimating and forecasting in cadenceModifying acquisition practices to enable Lean-Agile development and operationsBuilding in quality and complianceAdapting governance practices to support agility and lean flow of valueThe passion of always improving the art of software development based on the Lean-Agile best practices makes Dean Leffingwell the world’s foremost authority. The release of the SAFe®️ 4.6 version is an update to the Scaled Agile Framework (SAFe®️) which addresses the challenge of transitioning from the traditional model to the Lean-Agile Mindset. Moreover, the version provides the guidelines on XP, TDD, and BDD, and building a better Lean enterprise in the Lean way!You heard it right! Knowing the Lean fruits of SAFe®️ 4.6 to the organizations, KnowledgeHut is launching the course in the middle of November. Stay tuned to know more. Course arriving soon!
Rated 4.5/5 based on 5 customer reviews

SAFe®️ 4.6 - The Latest Entrant In SAFe®️ Series With 5 Core Competencies

241
SAFe®️ 4.6 - The Latest Entrant In SAFe®️ Series With 5 Core Competencies

Scaled Agile Inc. (SAI) recently announced the latest version of SAFe®️, SAFe®️ 4.6 with the help of the whole Scaled Agile team and SAFe®️ Contributors. The SAFe®️ 4.6 version has underlined the introduction of ‘Five Core Competencies’ of the Lean Enterprise. The purpose behind incorporating those competencies is mainly to make the SAFe®️ organizations build a truly Lean Enterprise in a Lean fashion.  


According to the Gartner report, SAFe®️ 4.5 is delineated as the world’s most widely used Agile framework at the enterprise level.


This new way of working with SAFe®️ will open new avenues after the introduction of these competencies. At the same time, these competencies will become the primary lens for understanding and executing SAFe®️ in the organizations. Also, this new way of SAFe®️ working can make a big difference to the organizations that are struggling with their transformations.

Here are the names of the five competencies introduced newly to build a better Lean organization in a Lean way. Lean-Agile Leadership

  1.  Team and Technical Agility
  2.   DevOps and Release on demand
  3.   Business Solutions and Lean Systems Engineering
  4.   Lean Portfolio Management

Benefits of SAFe®️ 4.6 competencies

Having these five competencies allows organizations to-

  • Navigate digital disruptions
  • Respond to the volatile market conditions
  • Meeting the varying customer requirements and latest technologies

Let’s explore each competency in details below.
SAFE for learn Enterprises
1) Lean-Agile Leadership:

The Lean-Agile Leadership competency focuses on describing how the Lean-Agile leaders steer organizational change by encouraging the individuals and teams to reach their highest potential. The Lean-Agile leaders do this by learning, exhibiting, and coaching the Lean-Agile mindset, core values, principles, practices & features of SAFe®️.

Changes made in Lean-Agile Leadership in SAFe®️ 4.6 version

  • The SAFe®️ principles have been updated with a redraft of Principle #3 — Assume variability and preserve options
  • A new advanced topic article, Evolving Role of Managers describes the changes and ongoing responsibilities of line management in the new way of working.

2) Team and Technical Agility

The Team and Technical Agility competency describe the critical skills and Lean-Agile principles and practices that are required to produce the high-performing teams. These high-performing teams focus on creating high-quality, well-designed technical solutions in accordance with the current and future business needs.

  • Team agility – enables high-performing organized Agile teams to operate with the fundamental and effective Agile principles and practices.
  • Technical agility – provides Lean-Agile technical practices to generate high-quality, well-formulated technical solutions that contribute to the current and future business needs.

Changes made in Team and Technical Agility in SAFe®️ 4.6 version

  • The new built-in quality practices that ensure that each Solution element meets the appropriate quality standards at every increment. 
  • These new built-in quality practices define 5 dimensions that permit quality- flow, architecture and design quality, code quality, system quality, and release quality.
  • The roles in the Agile teams- Product Owner, Scrum Master, and the Development team are updated to reflect the new guidelines and thinking from the Team and Technical Agility competency and their responsibilities in Behavior-Driven development (BDD).
    • Behavior-Driven Development is a test-first, Agile software development approach that has evolved from the Test-Driven Development. BDD provides a built-in quality by defining system behavior.
  • Test-Driven Development (TDD) is a practice for developing and executing the tests before implementing a code or system’s component.

3) DevOps and Release on demand

The DevOps and Release on Demand competency confer how the DevOps principles and practices allow the organizations to release value (in full or in part), at any time to meet the customers’ needs. This new competency enhances the in-depth level of guidelines on implementing a full continuous delivery pipeline.

Changes made in DevOps and Release on demand in SAFe®️ 4.6 version

The advanced Continuous Delivery Pipeline includes mapping the current Delivery Pipeline and improving the flow with the DevOps and Release on-demand health radar.

  • The DevOps health radar is a tool to assess the progress and improve a flow of the program value with the help of Continuous Delivery Pipeline. This tool consists of 16 sub-dimensions (as shown in the figure below) programs that are used to assess the program’s maturity. It helps to identify our health-related dimensions (e.g. sitting, crawling, walking, running, and identifying the places where we can improve).

Devops And Release on Demand4) Business Solutions and Lean Systems Engineering

The Business Solutions and Lean Systems Engineering competency show how organizations can develop large and complex solutions and cyber-physical systems using a Lean, Agile, and flow-based, value delivery-model. This model makes the best of the activities necessary to specify, design, construct, test, deploy, operate, evolve and ultimately decommission solutions.

Changes made in Business Solutions and Lean Systems Engineering in SAFe®️ 4.6 version

  • In this competency, they have changed the eight practices for developing large and complex solutions. Following image shows the practices included in the Business Solutions and Lean Systems Engineering.
    Changes made in Business Solutions and Lean Systems Engineering in SAFe®️ 4.6 version
  • They made changes in the Economic Framework with the following four primary elements:
    • Operating within Lean budgets and guardrails
    • Understanding solution economic trade-offs
    • Leveraging Suppliers
    • Sequencing jobs for the maximum benefit (using WSJF)

  • The advanced Roadmap section introduces the multiple planning horizons and the Solution Roadmap that provides a longer-term- multiyear view, showing the key milestones and deliverable s required to reach the solution Vision over time. The roadmap also contains new guidance on understanding and applying market rhythms and events.

5) Lean Portfolio Management

The Lean Portfolio Management (LPM) competency describes how an organization can implement Lean approaches to strategy and investment funding, Agile portfolio operations, and Lean governance for a SAFe®️ portfolio.

Changes made in Lean Portfolio Management (LPM) in SAFe®️ 4.6 version

  • In SAFe®️ 4.6, the changes are made in the organizational strategy formulation, the definition of the portfolio, and strategic themes.
  • New Portfolio Canvas describes how a portfolio of solutions creates, delivers and captures value for an enterprise. The portfolio canvas defines and aligns the value streams of the portfolio and the solutions to achieve the organizational goals and provides a process on meeting the vision of a future state.
  • The updated Lean Budget Guardrails ensures the right investments within the portfolio’s budget.
  • Also, the changes are made in the Lean Budgets that provides a guidance on moving from the traditional budgets to Lean budgets, guiding investments by the horizon and applying participatory budgeting.
  • The updated Value Streams includes a section for defining the value streams and a revised Development Value Stream Canvas that aligns better with the new Portfolio Canvas.

Top-Level Government in SAFe®️ 4.6
Another updated thing in SAFe®️ 4.6 is the SAFe®️ for Government. The top-level Government in SAFe®️ 4.6 describes a set of success patterns that support the public sector organizations in implementing the Lean-Agile practices. The SAFe®️ for Government also serves as a landing page for applying SAFe®️ in the national, regional or local government context. This provides the specific guidelines to address the following things-

  • Creating a basis of Lean-Agile values, principles, and practices
  • Building the high-performing teams of Government teams and contractors
  • Aligning technology investments with agency strategy
  • Transitioning from projects to a Lean flow of epics
  • Adopting Lean budgeting aligned to the value streams
  • Applying Lean estimating and forecasting in cadence
  • Modifying acquisition practices to enable Lean-Agile development and operations
  • Building in quality and compliance
  • Adapting governance practices to support agility and lean flow of value

The passion of always improving the art of software development based on the Lean-Agile best practices makes Dean Leffingwell the world’s foremost authority. The release of the SAFe®️ 4.6 version is an update to the Scaled Agile Framework (SAFe®️) which addresses the challenge of transitioning from the traditional model to the Lean-Agile Mindset. Moreover, the version provides the guidelines on XP, TDD, and BDD, and building a better Lean enterprise in the Lean way!

You heard it right! Knowing the Lean fruits of SAFe®️ 4.6 to the organizations, KnowledgeHut is launching the course in the middle of November. 

Stay tuned to know more. Course arriving soon!

KnowledgeHut

KnowledgeHut Editor

Author

KnowledgeHut is a fast growing Management Consulting and Training firm that is a source of Intelligent Information support for businesses and professionals across the globe.


Website : http://www.knowledgehut.com/

Join the Discussion

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

Suggested Blogs

Agile Project Management Vs. Traditional Project Management

In this fast-moving world, project management has become one of the most important pillars that are helping businesses run without any glitch in their processes. Both small and large scale organizations around the world are exploiting technology and depending on project management systems to deliver the software development project successfully. Whether it is team workflow management or timing, these tools help to ensure that everything is going well without any obstacles. While there are tens of different project management approaches, Agile is considered one of the most practical and flexible software development mechanism that exist today. It is capable of executing a variety of tasks, but what sets it apart from others? Let’s find it out. Here’s a brief comparison of Agile management and traditional project management software:                                                                                                                    Traditional vs Agile Project Management Overview of Agile and Traditional Project Management What is Traditional Project Management? The traditional Project Management (waterfall) approach is linear where all the phases of a process occur in sequence. Its concept depends on predictable tools and predictable experience. Each and every project follows the same life cycle which includes the stages such as feasibility, plan, design, build, test, production, support, as shown in the figure above. The entire project is planned upfront without any scope for changing requirements. This approach assumes that time and cost are variables and requirements are fixed. This is the reason why traditional project management faces budget and timeline issues. What is Agile Project Management? When a traditional system focuses on upfront planning where factors like cost, scope, and time are given importance, Agile management gives prominence to teamwork, customer collaboration, and flexibility. It is an iterative approach that focuses more on incorporating customer feedback and continuous releases with every iteration of software development project. The basic concept behind Agile software development is that it delves into evolving changes and collaborative effort to bring out results rather than a predefined process. Adaptive planning is perhaps the biggest feature of Agile and one that makes it a crowd favorite among project managers. Scrum and Kanban are two of the most widely used Agile frameworks. They are very well known for encouraging decision-making and preventing time consumption on variables that are bound to change. It stresses customer satisfaction and uses available teams to fast-track software development at every stage. The table below shows the major differences between Agile project management and traditional project management.                                                                                Table: Agile project management vs traditional project management Why is Agile Preferred and why not the traditional project management? Agile is preferred by most developers and managers because of a variety of reasons. Let’s have a look at the most common ones: Project complexity Traditional: This method is the best fit for small or less complex projects as it follows linear approach. Sudden changes in the project or any other complexities can block the entire process and make the team go back to step one and start all over again. Agile: This is the best methodology to follow in case of complex projects. A complex project may have various interconnected phases and each stage may be dependent on many others rather than a single one as in simple projects. So, Agile methods are preferred for large complex projects, as they can respond better to such structures. Adaptability Traditional: This approach works with a belief that once a phase is done, it will not be reviewed again. So, it is not adaptable to rapid changes in the work plan. In case if any sudden situation arises or any change in the requirements from the client’s side, traditional approach fails to adapt to the new change. The only choice is to start from the very beginning once again. This wastes a lot of effort and time in the process. Agile: The adaptability factor is very high in this methodology since it is not linear. Complex projects consist of several interconnected stages, where a change in one stage can cause an effect on another. And the project managers can take calculated risks in such scenario, as there is a chance of high adaptability.  Scope for feedback and changes Traditional Each and every process is clearly detailed and defined at the start of the project in the traditional approach. It cannot deal with any big change or feedback that might require a change in the process. Mostly, the project delivery time and budget are fixed, allows change very rarely. Agile There is a high acceptance for feedback and change in this method. The process is very flexible and allows constant feedback that can help to provide better output within the fixed project delivery time. The main reason that managers or developers choose agile direction is for the flexibility it offers. Developers working with Agile management are able to respond to customer requests quickly as they are only addressing small parts of the project at a time and the customer validates each iteration or sprint before finalizing. Some of the important characteristics of Agile development Breaks project into parts Agile divides a project into parts (called iterations) where the release is sent to the customer after every single iteration. Additionally, the success of the project can be easily foreseen through the success of these iterations. This removes the need for upfront planning completely. Self-organized As mentioned above, Agile uses a parallel mode of management. Employees of a company are not managed by a central line of control, but by groups. For example, in Agile, there may be eight teams working on a single project. Each team is managed by itself without external guidance. The teams only interact with each other for project discussion and process linking as they are otherwise not self-sufficient. Generally speaking, an Agile project consists of three parts: The product owner – the expert on the project (for which the product is being developed) and is the main person who oversees the projects The scrum master – this person manages the process involved in Agile. He/she looks after the iterations and its completion The team – individuals who play significant and minor roles in the software development process Customer Engagement In Agile, customer engagement is at the very top. The customer is regarded highly in its frameworks as after every iteration, feedback is generated and acted upon. Overall, Agile is clearly the winner among project management systems. When compared with other traditional approaches, Agile’s features come to the fore and reiterate why it is one of the top software used by companies globally. Can Agile Coexist with Other Approaches? This is a question asked by many project managers, and opinions of experts seem to be divided. While some say it is possible for Agile to coexist with traditional project management systems, they suggest being cautious and using them for different terms. For example, using two different approaches on the same project can be counter-productive and highly explosive. As Agile and most other frameworks are totally contrasting to each other, the projects may go for a toss. On the other hand, some experts believe that it is not possible for Agile and other tools to co-exist because of their contrast. Using them together can cause disorder in the entire company system, making the productivity to go for a toss. Agile vs Traditional- Adoption Growth According to a recent online survey of 601 IT and development professionals, it is proved that Agile is the new typical formula for project success. The majority of projects and development teams are now adopting this methodology, while the traditional waterfall approaches have many flaws.    Traditional organizations vs. #Agile organizations #SALC16 pic.twitter.com/bBgxkQB1fI — Scrum Alliance (@ScrumAlliance) January 20, 2016 Agile was first introduced about 15 years ago as a substitute for traditional software development approaches. Many people considered it as challenging to implement traditional approach practices and Agile adopters stated that this new style of software development improves team collaboration and is more customer-centric.  Though Agile method was present more than a decade ago, the vast majority of organizations have adopted the practice in the last 5 years. Moreover, the survey reported that agile adoption saw an inflection point between the year 2009-2010. As shown in the above figure, agile adoption seems to have slow incremental growth till 2008 and then its growth was accelerated after gaining traction in the market. Reasons for the transition to Agile Most of the organizations who transitioned from traditional to agile project management have listed the following reasons: Improves collaboration between teams- 54% Enhances the quality level of software in organizations- 52% Results in enhanced customer satisfaction- 49% Speeds time to market- 43% Reduces development cost- 42% The Verdict In the traditional software development, the customer involves only before the start of the development process. So, there might be a number of mistakes and a large amount of money needs to be spent to rework on them. Since in the Agile software development, the customer involves at each stage, the corrections can be made once the defects are detected. This helps us in saving cost. As we can see, Agile project management is really in-demand for teams. It helps the team to work on the top priority ones at the right time and allows them to walk through the risks much faster than they would with traditional project management tools.  
Rated 4.0/5 based on 2 customer reviews
1879
Agile Project Management Vs. Traditional Project M...

In this fast-moving world, project management has ... Read More

Agile Conflict Resolution Hacks You Should Master

A conflict in an Agile team, usually indicates that the members are actively involved in the team. They either try to drive a change accordingly or raise an issue against the actions of other team members. Conflicts help the teams become more mature and effective. However, resolving a conflict between the team members is becoming more like an umpire between two fighting teams. It is the Agile team, who is responsible for making everybody agree to choose a right solution.   The way of handling conflicts is called conflict style. In the year of 1972, Thomas-Kilmann introduced different styles of conflict resolution. At an initial stage, it is vital to understand the different conflict styles before developing strategies for handling the disputes. The five conflict resolution styles introduced by Thomas-Kilmann are Competing, Accommodating, Avoiding, Compromising, and Collaborating.  Conflict can be a positive factor if it is resolved potentially. If a conflict is not handled properly, it affects the project by damaging targets, breaking down the teamwork, and eventually the team members disengage themselves from their work. Resolving conflicts successfully will not only help teams solve many issues, but also offer many benefits that are not even expected at first. The benefits of conflict resolution are as follows:   Increased Understanding: Discussion on resolving a conflict allow teams to know each other, mount up awareness and search the best talent from the ideas coming out from the team members.    Increased team cohesion: After dispute resolution, team members form stronger mutual coordination and increase the ability to work together.    Improved self-knowledge:   Conflict resolution helps members examine the issue deeply, which enhances their knowledge, sharpens the target, and elevates productivity.   But the question is how to facilitate an effective conflict resolution? Following are the possible conflict management techniques, that can help teams manage the disputes smoothly.   1) Engage in personal coaching: Good relationship among team members is important. So always try to treat the members calmly and politely, take efforts in building a mutual respect and always be constructive while separating people and the associated problems. Always pay heed to the root cause. Listen carefully and act. Welcome ideas from the team members to reach to a proper solution.   2. Mentor a team through a conflict resolution process: This conflict resolution technique consists of four steps. Step 1- Set the scene. Initially, you need to identify the recurrent conflict patterns within the team. Guide a team to make them understand that conflict is a common problem and it can be solved by using an assertive approach rather than being aggressive.   Step 2- Gather Information.  Secondly, listen to others’ point of view and always respect their decisions. Gather information from the team, understand the conflict deeply and try to find a solution.   Step 3- Brainstorm to find out a solution. Arrange spontaneous group discussions to share the ideas on any tasks.   Step 4- Confer a solution. This is the last stage in conflict resolution. Through this step, the hurdles may be removed. Follow the “Be calm, be patient, have respect” principle throughout.    Conclusion: Conflicts in an Agile team are considered as the sign of a group of people working in collaboration. Sometimes conflicts are destructive if not handled properly. Positive and assertive approaches help resolve a conflict peacefully, with non-confrontational discussions. Generally, conflicts are resolved effectively when team members try to explore issues and possible solutions and listen carefully to the other members in the team.      
Rated 4.0/5 based on 20 customer reviews
Agile Conflict Resolution Hacks You Should Master

A conflict in an Agile team, usually indicates tha... Read More

Incomplete Stories & Tasks in an Agile Sprint

Have you ever encountered a situation such as above? I am sure you have and I am sure that you experience this often. So, how do you deal with it? Does the managers in your company make a big issue out of it? Is it a situation probed intensely by the product owner and even the Scrum Master who is the team’s protector? You need not worry. Below is a discussion on incomplete sprints, better known as ‘Spillovers’, and on how to best deal with them. Spillovers & DoD – The definition Simply put, a spillover is a backlog item that has failed to meet the criteria defined in the Definition of Done (DoD) for the project team. It is important to note that the DoD is defined for the entire project and is applicable for any user story. For example a team may decide that the DoD for a user story is for it to be elicited, groomed, analyzed, designed, UI / UX designed, coded, unit tested, functionality tested, integrated and regression tested. Any story not ticking all these boxes may be marked as not done. Well, not always!! The team may decide that some of these criteria is not applicable for certain stories during sprint planning and those should be evaluated accordingly. Trouble with Spillovers? Spillovers normally surface during Sprint Demo & Retrospective meetings and often give trouble to Scrum team members and product owners during sprint planning. It is the responsibility of the PO to mark a user story as done by going through the DoD criteria. Then only should the story be moved to the ‘Done’ column on your JIRA board. Sometimes the POs end up scratching their heads as a result of poorly defined DoD’s or just pass stories on to Done state just ensure progress. Similarly, during planning teams end up spending a lot of time discussing about these spillover stories and do extensive planning for these unfinished user stories. Spillovers are common phenomena for any agile team. But it is important to analyze the root causes for these spillovers if this happens often.  Common reasons for spillovers Below are some common root causes for unfinished work- Problems with DoD – The DoD was not accurately defined, and you find that out later in the sprint. This results in the argument around marking the story as ‘done’. Overestimation of work for the sprint – The team becomes over ambitious and commits to much more than they can handle. Larger chunks of work eating up on time of other stories. – This is actually not a big issue. Story point estimation is a relative estimation and has no link to time needed in hours. Hence, this overrun of time may happen often. Unforeseen scenarios– There may be situations where a team member becomes unavailable due to sickness, other work commitment or personal commitments. Other situations related to team members not be able to access code repositories due to various environmental elements may also cause delays. Change in priorities – PO may decide to change priority of stories mid sprint or stories may even become higher priority with technical limitations. As a result, stories may not be completed and may get spilled over to subsequent sprints. Dealing with spillovers So it is important to devise strategies on how to manage such unfinished work. Below are some recommendations on how to do so. Again, this is not rocket science but the application of some common sense to make things work. It is important to review the process followed by the team during the sprint retrospective session. This session can be used to identify the root cause for spillovers and to discuss options available to mitigate it. It is important to note that the cause for most delays may be common and thus the team must understand the factors related to delivery delays to quickly move on to discuss other aspects important for project success. The team must discuss on the future of the user story that got spilt over. The PO must decide whether the story is still on high priority or not.  If yes, then simply move the story forward to the next sprint. You have already decomposed the story to the most granular level during grooming and it is just a matter of getting it done. Again, if the story was done partially it is important for the team to discuss the amount of work remaining to mark the story as done. This analysis may actually result in the creation of a new user story with a new acceptance criteria, a completely new DoD and a brand new estimation. If not on priority, simply move the story to the bottom of the product backlog. The story will get evaluated for priority during backlog grooming and be moved up or down the backlog as relevant. I previously wrote an article on capacity planning for agile teams. It makes sense for the Scrum Master to understand the availability of the team for the entire duration of the sprint and plan the amount of work that can be taken up accordingly. For more information on capacity planning and how it may help avoid spillovers refer here Some more logical things to do is to dedicate more time for planning. This may be done by defining a proper goal for the sprint and to ensure that all user stories are aligned with this particular sprint goal. The scrum team may also set aside some buffer time for unplanned work which will give the team some breathing space just in case a story runs for more than planned. So in conclusion, spillovers are to be managed properly. You may never be able to completely eliminate it from your projects. But with proper management and planning, you can reduce the number of times it may occur and be able to reduce its impact.  
Rated 4.0/5 based on 20 customer reviews
Incomplete Stories & Tasks in an Agile Sprint

Have you ever encountered a situation such as abov... Read More