Opinion: The Scrum methodology in solving problems – Opinion

Opinion: The Scrum methodology in solving problems - Opinion



By Tiago Sacchetti (*)

The Agile Scrum methodology has traditionally been used in software development. However, it is generally suitable for projects with volatile or not perfectly defined requirements. The scrum is an agile way of managing projects originally designed for teams of three to ten people located in the same space, which autonomously split the work into short periods of time (sprints – usually two weeks). Scrum, like all agile methods, prioritizes the creation of value for the customer and assumes that the amount of resources and time available are limited. We must maximize the result produced even if it means not producing all the desired result. Taking this new paradigm is not always easy for organizations.

Is this a useful problem solving methodology?

In order to answer this question, it is necessary to relate the method of managing Scrum projects to problem solving and to demonstrate its effectiveness. We can define the resolution of a problem as a temporary (time-limited) effort to create a solution. Now this is also the definition of project. Therefore, there is no doubt that it makes sense to use project management methods to manage problem solving processes.

For example, solving quality problems in the automotive industry is often very demanding from the point of view of speed in protecting the value chain downstream of the problem. Containment actions and risk and impact analyzes are generally urgent and early root cause analysis and verifications follow a frenzy of pressure generally enforced vigorously by the client or the organization's own quality department.

These conditions are precisely indicated for the application of Agile-scrum methodology: expected result not completely defined, limited resources and time and need to maximize the creation of value for the client. I do not mean by this that traditional problem-solving techniques should be overlooked, which I do rather use Scrum to manage the problem-solving process. Depending on the complexity of the problem, simple methods (Ishikawa, 5 why, 8D, etc.) or more complex ones (6Sigma, Shainin RedX) should be used in root-root discovery. The role of Scrum is not to replace these methods, but rather to manage the team, the tasks, the communications and the results.

It is often decided to assign the process management to a member of the problem solving team. Unfortunately this decision usually has unsatisfactory results due to the lack of neutrality that member will have in the team. For the dynamics of the team, it is relevant and undesirable that this element is also an operational leader of a specific area (production, logistics, product engineering, etc.). Potential conflicts of interest that will arise, even if unfounded, will surely undermine the confidence of the team and diminish their performance. Out of curiosity, this conflict is also very common even in software development with Scrum: if a programmer also accumulates the role of Scrum-Master, the value of the generated result usually decreases.

Since resources are limited especially in an organization optimized to manage day-to-day operations, and the number of problems is not expected to be large (they should be the exception rather than the norm), it makes sense to use an experienced Scrum-Master of a flexible business partner that provides such services. The technical content of the problem should continue to be developed by the team and by the specialists in the cause and effect relationships of the product and processes.

On the other hand, there is an unequivocal benefit in delegating organizational tasks: communication with the problem sponsor (or even the client); the organization and prioritization of the work to be carried out (backlog) including preparing, moderating and documenting the meetings of the problem solving team and the results obtained; team focus and protection against external distractions or unvalidated opinions at planning meetings that could direct resources in an uncoordinated way; the promotion of team dynamics of excellence (conflict mediation, promotion of speed in decision making, and focus on delivery of value – eg FedEx "days"). These are typical Scrum-Master tasks.

For the reasons described above, I highly recommend using Scrum in managing problem-solving processes. Its advantages are especially noticeable in optimized value chains and with defect quality policies. Use the Scrum methodology: maintain a backlog, plan sprints, monitor speed with the burn-down chart, and improve your own problem-solving process in retrospective meetings. Whoever does this will develop the problem solution quickly and with less costs for the organization's image and for the customer relationship. As a result, they will be able to demobilize the problem solving team sooner (after all it is a project) and continue with the day-to-day tasks and special projects to achieve your strategic objectives.

(*) Director of Bosch Industry Consulting in Portugal and Spain



Source link