How do you manage deviations in SCRUM that don´t work in Real Life?

In some part of the organization they have decided to work agile, and according to SCRUM (without really knowing what it is) Some part of the organization still work in a traditional way of planning and implementing system functionality, in Projects and Projects forms. That leads to a lot of conflicts in how to work according to SCRUM, booth roles, responsibilities and general way of working.

This alone seems dangerous. Employing the agile methods requires a significant shift in mindset from traditional project management methods. Not having an understanding of what agile is or means and the purpose and intent of various frameworks (like Scrum) is not a recipe for success.

SCRUM says that CFO and CEO Don´t have authority over the Product owner. Try to say that to the CEO in our organisation. That´s not in line with how it works in Any large organization. So - Do you advise the Product owner to go his own way?  He will lose his job tomorrow but that what SCRUM says .....

I don't think that is consistent with what Scrum says at all. The Product Owner is responsible and accountable for decisions about how to express and order Product Backlog Items, optimize the value of the Development Teams and ensure that the Product Backlog is transparent to stakeholders. However, at the same time, the Product Owner needs to consider and represent the needs of various stakeholders. These stakeholders include company executives. I would say that the executives must place their trust in the Product Owner to make the right decisions, considering all of the stakeholders, for the continued success of the product and the organization.

The rest of the organization, many many people who have dialog and create plans with other markets, creates detailed plans about exactly When a functionality shall Go Live in a global system. There are many other parties that rely on those planes, other suppliers that shall make sure the system can interact with other payment systems etc. We talk about 20+ integrations that shall be planned and Go Live in about the a time period of 24 hours. But the Development team can "pick what to work on" in the item list for what to develop. The development team may only be 5 people, but hundreds of people wait for a very specific delivery of a number of functionalities that MUST go hand in hand. There is no room for "we didn´t choose to develop the bridge to the WEB interface, so sorry but the global WEB booking will not work" So the question is - They shall work according to SCRUM - but it will not work for the rest of the world. - How to you handle?

The Development Team doesn't simply pick what they work on. The Product Owner is responsible for ordering the Product Backlog. However, as a stakeholder, the Development Team should have input into this - they may see technical dependencies or tradeoffs for doing one piece of work over another that the Product Owner should consider. They may also be able to shine a light on risks and ambiguities, identifying things that are difficult or costly or have a lot of unknowns that need to be sorted out before it makes sense.

Timelines and deadlines can also play a role. The advantage of the agile methods, and iterative and incremental models in general, is that scope isn't fixed. Rather, the scope is extremely flexible as the understanding of the customer needs change. However, if your scope is rigid and inflexible, then perhaps the techniques of many agile methods that are designed to allow the team to receive rapid feedback and adopt to changing environment becomes overhead.

I have worked as a business Consultant for 20+ years, I´m an educated Project manager, and LEAN expert. When Reading about SCRUM, I fully understand the business in taking parts and pieces from Project management and Lean and re-brand it to something new and earn Money on the new "standard". But I really wonder if the designers of SCRUM really have worked in larger organizations with system development? The set-up of scrum work in a 20+ organisation, but in a larger organisation the definitions in SCRUM in only 10% of what you need to know and need to cover working in large organization with maybe 10+ global stakeholders, and billions in investments. What I can see SCRUM is about 50% LEAN and 50% project management but with other naming’s on roles and responsibilities. But the 50% LEAN in Scrum, is only 5% of LEAN in total, and the same with Project management. Let’s say you have a list of 30 areas that a Project manager MUST work with. In scrum you have about 3 of those areas - who shall do the rest of all tasks?

The important thing to understand is that Scrum is a framework. It doesn't address all the problems. For example, it says almost nothing about typical product initiation activities - forming the team, obtaining funding, establishing the underlying methodologies to be used. It's also designed for a single team working on a single product. If you have multiple teams working on a single product or service, then you can look to scaling solutions such as Nexus or LeSS (although it helps to have individual teams being effective with Scrum before you try to scale to 3, 4, or 5 Scrum Teams that must coordinate). And if you have a portfolio of products and teams across the enterprise, you would need to even look to other solutions or develop the capability to roll your own approaches. Scrum is just one tool to give you the foundations that you can use.

What I can see SCRUM is about 50% LEAN and 50% project management but with other naming’s on roles and responsibilities.

It might be better to think of Scrum as a lens which is very good at highlighting organizational problems. Is there an appetite within the organization for dealing with this transparency?

Thank you guise!.  This sentence "SCRUM says that CFO and CEO Don´t have authority over the Product owner. Try to say that to the CEO in our organisation" I based on of the answers in the Open assessment that states that not even the CEO have the final saying about the system but the Product owner. In reality in any large organization, the Product owner in the from the 5th to the 10th manager down from the CEO, and there are other managers between that are fully responsible for e.g. all IT infrastructure, and under that manager that may be 20+ system responsible, what’s called PO in SCRUM. I believe the SCRUM is based on a very specific Software developing phase in the IT Developing from the 1990 where larger systems for Microsoft and the like was developed. If you work ONLY with system development as a core business, it´s a totally different story compared to all those companies working with system developing today. Today the focus for many companies is to make all systems to share data. At my work Place we have data from production in a global environment (production in several markets) that stores important data in more than 39 systems, that shall be accessible for 2000+ other companies in all there CRM systems, planning systems, etc, etc. On top of that you shall have apps, web bookings and other platform connecting to this. I will say Very few of the suppliers work with Agile and SCRUM, they work in traditional Projects, with gates and deliveries. Let’s say that I´m responsible for system A. I will have at least 20+ Project managers, that steer-in requirements, and they all need to have a 6 month delivery plan. I can´t say - sorry but we don´t have a project manager in our organisation, we work agile. If the PO don´t have a Project manager in his organization, it must than be outside the PO organisation, but still act like a part of that organisation. If you have 20+ subcontractors, all working in a traditional Project organisation, they all have gates with defined dates and deliveries. As a system owner you must have a way of working so you can co-operate with the suppliers.  So the summary of this situation is that you have a strong need for the role that a traditional project manager has, to co-operate with the suppliers. But if that role with those tasks (everything from risk-analyses, testing, contract agreements, regulations, ISO standards and many many more areas and tasks) cannot be within the SCRUM organisation - shall it than be Outside the PO organisation?

Answer on: “It might be better to think of Scrum as a lens which is very good at highlighting organizational problems. Is there an appetite within the organization for dealing with this transparency?”

The organization work with LEAN and continuously improvements, and the philosophy is “problems are good – we can´t improve if we don´t know what’s wrong” so the organization work with full transparency on “all” levels of production and in the office.

Gosh what a strange spelling. It looks like when I choose to "automatically correct" the text since I copy from Word, the system mess up the text quite a bit. I will not go for that option next time. 

I Magnus, I live the same (word by word) experience every day. I have a Project Manager, a Delivery Manager (sometimes more than one because as a team we address more than one project at time (with a PO and a single board) :O ), and the stakeholders, all working using Gantt.

Usually a project is assigned to us with: architectures decided by architects, technologies and best practices decided by different chapters leaders (FE, BE, QA...), processes, flows and so on decided by Business Analysts, graphics set by UX/UI, machines an environments made available by, and are under the strict ownership of, DevOps and... deadlines (delivery, go live and so on) already set (more or less).

Then: Ok, you can be agile/scrum within this boundaries. Wow!

Oh, I forgot: the PO is a person that it's not empowered to own the product so (s)he is in a VERY difficult position because she have to match everyone's needs and (s)he has almost no power on what has be done and in which order. 

How is this working? Mhhh, with a lot of difficulties, with a lot of headache, with a lot of frustration, less than optimal results, high costs (in term of money and in term of personal stress). But we try to do our best using Agile/Scrum and trying to explain it and its advantages whenever we have a chance to whoever is interested (and even to those that are not so interested)!

And, despite everything, we deliver! And we deliver good working software (thanks dev team!) but I strongly believe that we would deliver even better products if Agile and Scrum are applied as prescribed. Unfortunately, as stated in other comments above, this require a change of mindset and the will to address many organizational issues and, I believe, that most of the Companies (worldwide) are not ready for that.

The reason? This kind of transformations require changes so radical that for most people are unthinkable.

Managers have to change their way of thinking and working in a way that implies that they have to put in discussion their own essence, their own beliefs and way of "being". Changing at this level, I think that it is like undergoing plastic surgery and, after that, when looking in a mirror not recognizing yourself anymore.

How many people is able to take a step that endanger your own self in this way? Especially when we are speaking about people not very young that has learned their way of working many years ago?

I'm 50 and a Scrum Master since 2 years and I believe that there are many benefits behind Agile and Scrum. Having at least 20 years of working ahead of me, I hope that, sooner or later, I will have a chance to partecipate in a full Agile/Scrum adoption in a Company :) Meanwhile I try to do my best where I'm working now: Agile/Scrum transformation requires a lot of time and patience :)

Some days ago, I read on Linkedin a quote from a manager that said: "In many Companies, Agile it's just a label that they put in their description because it's the fashion of the moment". I think that in many cases this is true, but, on the other side, I think that there are a lot of Companies that really want to adopt Agile/Scrum and that they will be successful.

I think that it's only a matter of choice: in which way would I like to work? Agile/Scrum or traditional one? There is no right or wrong, but being transparent and coherent it's mandatory or sadness and frustration are, at any level, the most prominent results.

Regards.

I fully concur with @Magnus and I have seen the same situation over and over again - Scrum is not "respected (followed through)" as a way of managing projects in general. It may have a localized applicability but in no way it is applicable to medium-large organizations (>5k) but also projects/initiatives which simply cannot follow the iterative approach.

• These stakeholders include company executives. I would say that the executives must place their trust in the Product Owner to make the right decisions, considering all of the stakeholders, for the continued success of the product and the organization

This will only happen to a certain extent, simply because it will take way too much time for the PO to be aware and involved in the decision making process. The market is dynamic and some decisions are taken at a very high and confidential level, and they have to be implemented/changed extremely fast. It is indeed about trust but not in the PO's abilities but in the confidentiality of the information; what usually happens is that the high level mgmt. does not care about how the projects are done and they will simply steer the PO accordingly.

• The advantage of the agile methods, and iterative and incremental models in general, is that scope isn't fixed. Rather, the scope is extremely flexible as the understanding of the customer needs change.

There is a real issue with this statement in a lot of organizations. This translates risk management into "kicking the can down the road". I found myself in stakeholder meetings having to explain what are the risks associated with a certain project and what is my mitigation plan. Telling them that I would have chosen smaller Sprints would have been suicide.

• The important thing to understand is that Scrum is a framework. It doesn't address all the problems.

I truly have a problem with this statement (and as well as many other terms in the Scrum Guide) because to me is seems like the creators of Scrum simply ran out of (new) terms to use. I've worked in 3 different European countries in several companies and framework was always understood as a frame, defined but guidelines, within which one can adapt and change based on needs; Cambridge also defines framework as "a supporting structure around which something can be built". The rough Scrum statement is that "if you don't follow Scrum by the letter than it is not Scrum". I can understand and accept that Scrum doesn't address all the problems but then the terms are way too strict for addressing real-life development, delivery and sustaining complex products.

I do believe that Scrum works. I do believe it has its one area of applicability. What I don't agree with are people who believe it is the answer to all questions and any initiative can be done with Scrum. Changing corporate mentality is a dream; it implies such a massive endeavor that by the time you start seeing overarching results you are either burned-out or on your way out of the company. Self-managing teams is a dream. I have yet to live and see a team who does not need a Team Lead. In this KPI driven corporate life you will always have overhead that will have to either justify their position by dealing with the nitty-gritty aspects (availability, presentations, presence, tasks etc) or they will naturally emerge (or be chosen but the DT) to deal with this.

Scrum is not "respected (followed through)" as a way of managing projects in general.

Scrum is not about managing projects. It's about managing a product or a service. If you have one product with one team, then you can apply Scrum. If you have one product with multiple teams, you can scale Scrum (I've had success modeling my scaled approaches after LeSS and Nexus). If you have multiple products and only one team, it's difficult to achieve the focus that the agile methods require, but you may still be able to apply lessons learned. If you have multiple products and multiple teams, you can choose to apply Scrum (or a scaled framework) per each product.

It may have a localized applicability but in no way it is applicable to medium-large organizations (>5k) but also projects/initiatives which simply cannot follow the iterative approach.

Since Scrum is about managing a product or a service, I highly doubt that you have >5000 people working on a single product or service. Scrum will probably provide a starting point for you at that level. However, you're right that Scrum doesn't provide guidance for how to fit Scrum into a broader enterprise, but there are other frameworks for that. Personally, I look toward Disciplined Agile when looking at a broader level and understanding how a Scrum Team working on a product can fit into a portfolio or enterprise. However, there are other frameworks that claim to have similar objectives. All of these enterprise frameworks have pros and cons, positive and negative reviews.

I'd disagree that some projects can't be iterative. I believe that any effort can be iterative. However, for efforts with very low uncertainty, very low ambiguity, and/or very low likelihood for changes to needs and requirements, iterative models will likely add overhead. I wouldn't say that the iterative models couldn't be applied, but there are a class of efforts which which iterative models are inappropriate. However, software development rarely (if every) falls into the category of low uncertainty, low ambiguity, or low likelihood for changes.

There is a real issue with this statement in a lot of organizations. This translates risk management into "kicking the can down the road". I found myself in stakeholder meetings having to explain what are the risks associated with a certain project and what is my mitigation plan. Telling them that I would have chosen smaller Sprints would have been suicide.

Risk management in agile is not about kicking the can down the road. Risk management becomes a central piece of every single activity. If you are embracing extreme visibility and rapid feedback, risks will be seen much faster and the team can take action. The mitigation plan for risk boils down to "put working software in the hands of users to get feedback as quickly as possible". That doesn't mean "deploy to production as fast as possible" or that you neglect design. This is where Product Backlog Refinement, spikes, the lean notion of "decide as late as possible", and the idea of concurrent engineering come in - have conversations with stakeholders, spend additional time on up-front requirements and design if it helps you reduce risk to an appropriate level, build prototypes, and deploy to demonstration environments, and do all of these on iterations of 1 month or less.

Smaller sprints aren't always equal to risk reduction, either. If your stakeholders can't be involved at weekly or biweekly Sprints, maybe monthly Sprints are less risky.

Cambridge also defines framework as "a supporting structure around which something can be built". The rough Scrum statement is that "if you don't follow Scrum by the letter than it is not Scrum".

These ideas are not in conflict with each other.

For example, Scrum doesn't say how you verify that you have built the right thing, but this is commonly accepted as something that is necessary to be done. It does say that all Increments should be "thoroughly tested". Practitioners have found that using techniques such as TDD and BDD support the ability to produce throughly tested Increments within short iterations. A team applying TDD and/or BDD is still doing Scrum. The same goes for a number of other techniques - pair or mob programming, one-piece flow, continuous integration or continuous delivery or continuous deployment, peer reviews.

The statement about following Scrum to the letter means changing the basic rules, not adding on top of them. For example, if you do not hold a Daily Scrum, you are not following Scrum and should not refer to your process as Scrum. Likewise, if you don't hold a Sprint Review at the end of every iteration that involves collaboration between the Scrum Team and stakeholders, you don't have Scrum. You may still end up with a very good, effective process for you, but it's not Scrum.

What I don't agree with are people who believe it is the answer to all questions and any initiative can be done with Scrum.

I agree with this 100%.

I believe that Scrum is a fantastic starting point, or perhaps a first milestone. My preference is toward one of the Kanban Method principles - start with where you are now. We know that Scrum is something that widely works. It's been tried and proven out to improve organizations in a number of contexts when done right, so it may make sense to use it as a model. However, it's not the only model that's out there. Rolling your own process is hard, though, and requires a lot of skill that, quite frankly, a lot of people don't have (or have enough of). So having a bag of techniques that are broadly applicable and useful is helpful to a huge set of people.

Changing corporate mentality is a dream; it implies such a massive endeavor that by the time you start seeing overarching results you are either burned-out or on your way out of the company. Self-managing teams is a dream. 

I don't think anyone will disagree with this. But that doesn't mean that it's not a dream worth following.