The one million dollar question right!? A real answer is probably worth a couple of millions. 🙂

As often before, I’m “encouraged” by friends to explain better some of my statements. This time by Roy van Rijn. You should also visit his blog.

Let’s assume you are working in a multinational and a traditionally structured insurance company. A business request goes through many departments and it takes ages to get them in production. Business does not trust IT anymore and vice versa. This ends up in “sellling NO” or postponing behavior of IT people or creation of complex IT projects. CIO is a 40-year old guy who just bought a second hand Porsche 911 as a result of his midlife crisis. In other words, he is in the mood of trying out something completely different. He heard about Agile thing multiple times already. It seems that everyone is “doing it”, so he wants it too. Besides, he hears about these amazing stories where speed of delivery and quality have dramatically increased.

There is only this annoying small problem: his organization is a very traditional one, so introducing Scrum seems extremely disruptive or even impossible. As much as he is inspired by stories, changing so drastically seems very unwise. He invites several different “Agile” consultants / coaches and asks for advise. The one with most attractive approach will get the assignment and start with organisation-wide Agile transformation.

The first one is a Scrum / Kanban / XP type of a guy and his message is:

Introducing Scrum requires from you to take difficult decisions, change style of management, and partially restructure your IT department. At the end, it will be definitely worthwhile.

The second guy is an “enterprise world realist” type of guy. His Agile message is:

Scrum is not suited for an enterprise environment. It does not scale well. Besides, even if it did, you cannot suddenly change everything so it fits pure Agile / Scrum mindset. We have something better. It is called SAFe, and it is an Agile framework for enterprises. It is also a good start in right direction. Eventually, you may end up using just Scrum and be really Agile.

From a CIO’s point of view, the second guy seems much more realistic. The first guy does not seem to understand things like portfolio management, programme management, enterprise architecture, annual budget cycles, and so on.

Unfortunately, the same CIO forgot to check that none of the creators of Agile Manifesto are in favor of SAFe and few of them are openly upset about it. He would also easily solve his mid-life crisis if he would start caring a bit more about others. To be more specific: his business. The business does not care about portfolios, projects, enterprise architecture, budget cycles, and so on. They care about real value, preferable delivered yesterday and not quick-and-dirty. The business cares about real collaboration where trust and understanding by means of frequent feedback is most important. Everything else should be in service of these values.

SAFe is a last-gasp relic from a prehistoric waterfall world and just isn’t Agile. It is like saying: We have this big mess of methodologies which impedes real collaboration; and in order to solve it we need a new, bit less messy mess to make a step forward. If someone is addicted to smoking, do not advise him a bit less harmful cigarettes. The end result are some improvements and missed chance of really becoming Agile. Since time is money, this is a step backwards. A more serious problem is that once you call yourself SAFe Agile, it sounds weird when someone suggests removing unnecessary SAFe elements in order to become really Agile. Companies change when they feel pain. Without pain, nothing really changes in complex systems. SAFe acts as slightly less effective painkiller, but still very much bearable.

CIO with his Porsche and SAFe will claim to be Agile, while business is still complaining. Delivery cycle before SAFe was one year, and with SAFe 6 months. In mean time, competitors with real Agile mindset have lead time of couple of weeks or even faster and he is still stuck with his beloved bureaucratic organizational structure. He keeps repeating: “it can’t be done”, while others have already made a real change.

Instead of ranting further about SAFe, which is already done pretty wel by others, I will give answer to few major complaints of introducing Scrum as it is in large traditional companies.

Is Scrum a big bang approach?

It is true that Scrum is a very disruptive new way of working, but this disruption does not happen suddenly. The right approach for introducing Scrum is very context-dependent. In fact, many coaches fall into a trap of trying the same approach from a previous successful introduction. Nevertheless, one thing approaches have in common is a step-by-step approach. It takes a lot of time, knowledge and practice to improve from one year delivery to delivery every 2 weeks and very high overall quality.

Focus on Agile values from the very first moment

Instead of introducing and focussing on some “better” or “Agile” processes and tools, the focus should be completely on collaboration, faster feedback loops, more real business value. Typical first steps in these areas:

• Revisiting a product vision in a facilitated session where developers, real customer and key users are present.
• Letting teams make estimates and give commitment. This also implies teams better involvement in the existing process of requirements gathering.

These steps are not disruptive at all and give directly some very valuable insights.

All Scrum roles and meetings?

In some cases, usually smaller projects, it is possible to introduce all Scrum roles and meetings in few days. After this, the team starts with its first sprint. At the end of the sprint, a potentially shippable product is delivered (no iteration zero).

In many other cases, meetings are introduced first. For example, team might have a stand-up meeting in front of a board which just contains post-its of everything they are working on currently. This is not yet real Scrum task board, but it does increase transparency. There is no ordered product backlog yet.

A next step could be to bring more focus on items most valuable to business, at cost of items much further from business.

Organizational change –> Cross-functional team(s)

This is probably the only really dramatic change, but surprisingly easy one. It takes only few hours to self-design cross-functional teams. After this, the teams are definitely not behaving yet as real teams and skill set is often limited to coding and testing. Nevertheless, this is a necessary and good enough step to start improving collaboration on this level.

Of course, at this point everything else is very traditional. But, we are moving in the right instead of wrong direction. From the very first moment, we focus on real Agile values instead of yet another process or framework. Even Scrum rules, meetings and roles are secondary.

The missing skills like architecture and analysis are often introduced in later stage. These are still very much waterfall in the beginning. Before organization starts to deal with these, the painkillers are removed. The problems are becoming visible. It is usually a coach who helps to make these visible, and later a Scrum master.

How do we transform traditional IT departments into Agile ones?

You don’t. The goal of Agile Manifesto is not to create some specific optimal organizational structure, but incrementally and iteratively deliver real business value. For this we need cross-functional teams. Each of these teams should eventually be capable of dealing with all necessary disciplines in some way. Existing IT department is still there, but will naturally and gradually change into more lean department that provides help and operational services to teams and business. Obviously, the power slowly and naturally shifts towards people who deliver business value. The people who stood between business and development teams have gradually a more supportive role. Some are called domain experts.

What about portfolio management?

Portfolio management is an expensive word for a product backlog on a large scale. One of the major problems is a huge number of running projects. This creates a necessity for complex processes, roles and responsibilities. A much better alternative is set of practices based on Scrum as described for example in Large-Scale Scrum. There are several other approaches. The good ones keep focus on clear goals, doing the most important things first, work-in-progress limits, and ever faster delivery of value. The bad ones focus on processes, roles and responsibilities.

Portfolio management is usually improved at much later stage of Scrum introduction.

What about IT / project managers, shouldn’t they change first?

Again, Agile manifesto is not about trying to change people, but iterative and incremental delivery and happier customers. Surprisingly, by far the most IT managers actually like and embrace Agile mindset and practices. Why? Because their work becomes more modern, thankful and meaningful. Being a directive manager who makes all important decisions is good for the ego, but increasingly impossible job. The reason is ever increasing complexity of business needs and technical possibilities. A hard problem is bad habits, like unfounded trust in so called “proven” out-of-box methodologies and tools. IT managers are very willing to change these habits, as long as someone provides viable alternative and tangible results.

Organization-wide transformation or a small project / product?

To be honest, I don’t really understand what people mean by organisation-wide transformation. It seems to mean some kind of a top-down Agile introduction. For me, as an Agile coach, this should sound as heaven. Unfortunately, major problem in these introductions is too much focus on practices and frameworks. Even if these are Scrum, Lean, XP or Kanban. I like all of them, but for being truly Agile, these are mere means to achieve a real value. Typically, many departments in a company will choose Kanban, simply because they don’t really have to change anything substantially.

One more time, the goal of Agile software development is not to change organization, follow practices, and definitely not implement SAFe, but to improve collaboration by means of feedback cycles, iterative and incremental delivery, so we make our customer and users more happy.