SAFe: Problems & Solutions
After all, SAFe is essentially “still Agile, only bigger,” so why are certain Agile developers so hard on it? Let’s examine the three primary issues they frequently bring up and how the SAFe framework might help resolve them.
Lack of Operational and Support and Compatibility
Developers came up with agile development. They had a lot of issues with waterfall procedures, so they made it to fix those. Despite their differences, schedule-based planning is essential to both the agile and waterfall methods of project planning.
A company’s information technology, operations, and support teams do not function in this way. Their primary concern is managing day-to-day workloads, which can involve both planned and unplanned activities, as well as juggling numerous projects at once. The amount of time needed for the comprehensive release planning that Agile demands is practically nonexistent.
Support may send an emissary to a release planning meeting, but they seldom participate or show any interest. At this point, they are completely helpless in the face of their work backlog. The people they help out would probably be quite angry if that happened. Support employees are also required to offer continual coverage, frequently around the clock, as opposed to developers who have more leeway in managing their own schedules.
The SAFe Solution
To solve this problem, think about DevOps. It unites development and operations by using programming to automate routine operational processes. Automating tests, using distributed version control, and integrating, delivering, and deploying code continuously are all DevOps methods.
Increased Technical Debt
Technical debt is nebulous and difficult to pin down. Still, the vast majority of us can identify it. For the sake of argument, let’s assume it is the sum of all the problems that have persisted throughout a project but have not yet been fixed.
Problems with technical debt are mostly the purview of upper management in a SAFe company. Certain forms of technical debt, such as those induced by market forces or company rules about the allocation of time, resources, and budget, can be effectively rectified by taking a high-level, top-down approach, which is where centralisation really shines. On the other hand, technical debt that starts at the team level isn’t best handled by centralisation. This kind of debt is caused by very particular things, such development teams who make decisions without thinking about the long-term effects, or by teams that are unstable and have a high turnover rate. In order to resolve such localised technical debt, the organisation’s management needs to step up. A bigger, more intractable debt problem is born and grows toxic if they don’t.
The SAFe Solution
It is recommended to adhere to Agile principles while dealing with this kind of technological debt. Return decision-making authority for solving problems, for instance, to the teams responsible for creating and testing the programme. Allow these groups the autonomy to determine their own due dates and track their own production velocity. In addition to taking ownership of their job, they’ll be resilient enough to handle challenges as they come. The best way to deal with technical debt and similar problems is to foster an environment where people are comfortable being open and honest with one another.
The role of management in addressing technological debt is significant. A clear definition of “done” that is consistently applied across all projects could be part of the standard acceptance and departure criteria. Management should also establish online tools that make all teams’ aggregated data visible.
Story Point Standardisation
There is currently no good way to predict how long it will take to finish a single task. In the past, people have tried to figure out how many workdays it would take to build one user narrative, which would show how much effort it would take for one person to complete a specific activity. For instance, if the project manager thinks it will take one workday, they can split the work between two engineers and finish in half that amount of time. However, the total effort estimate is still one workday.
A frequent grievance with effort-based assessment is that it ignores the intricacy and challenge of carrying out a task. Instead, narrative points—popularized by the Agile community and used by SAFe—consider not only work and difficulty but also complexity and dangers. Values on an abstract scale, such a string of numbers, the sizes of T-shirts (small, medium, big, etc.), or the Fibonacci sequence, are used to represent story points. One such system is to assign one daily of effort to each of the five possible levels, from 1 (easy) to 5 (hard). One story point is thus the amount of work required to complete a task that takes one workday.
Management in a SAFe context is entrusted with the responsibility of defining story points. The outcome, according to detractors, is a less concrete and ultimately meaningless scale for measuring effort. It furthers the perception that individual teams are powerless and unaccountable during development.
The SAFe Solution
Trusting and empowering development teams is a crucial step in fixing this problem. Part of this is empowering kids to take charge of their own performance and set their own goals. Additionally, teams should be educated by management on how velocity is more of a guide than a metric of success or productivity. Management may once again play a significant role by teaching employees how to use Agile project management techniques.
Optimising SAFe for Your Needs
An project by developers for developers, agile development got its start at the grassroots level. The fact that it gave developers more freedom to make decisions and implement them in a way that made sense was a big reason for its quick acceptance.
A centralised approach to project management, coordination, and decision-making was the goal of SAFe, which drew inspiration from the Agile movement. Value stream management is one of SAFe’s several advantages; it helps with knowing what to build and when to release it.
Similar to other prescriptive frameworks, SAFe can be problematic when implemented too strictly without sufficient alterations to meet the specific requirements of each organisation. Finding the best solution for the task at hand is more critical than blindly following the rules of a particular approach.
No Comment! Be the first one.