Scrum by the Generals

INTRODUCTION

Introducing the Scrum methodology is not difficult. Getting some improvements from it is not so difficult either. Getting the gold and glory the books or advocates are promising has however over and over proven illusive. The question is of course why.

I have been involved in several organizations introducing Scrum and it is actually surprisingly difficult to get the real leverage. On the other hand, it doesn’t get worse either. A worst case scenario is that the outcome is about the same, and with the correct follow up, this can be a good platform to build a really successful Scrum implementation on.

LEARNING FROM THE BOOK

At least historically, most of the Scrum initiatives have come from the development organization without committed support from the higher management. The result is that the proper resources have not been allocated and the rest of the organization is not coordinated. The result is that the change process is driven by people with only theoretical knowledge in the subject, acquired from books, articles and possible seminars. One of the problems is of course that it is a bit difficult to get the full picture from reading a book. The book describes concepts and scenarios. It does however not give a complete picture of the situation. That can only be done with experience, and if the experience is missing on any of the levels in the organization, things will be difficult. Of course it is not impossible to introduce a methodology completely from scratch in an organization. After all, it all had to start somewhere. The problem is that it takes time. Things have to be tested and discarded. Mistakes have to be done and everyone has to come to consensus on how the organization shall work. A book will deliver information but for it to turn into useful knowledge, it has to be synthesized. This comes with experience.

COMMITTING TO CHANGE?

In a situation without any history or defined processes, introducing methodologies like Lean and Scrum is not an issue. It is simply a process of getting the right persons and the right competence in the right place. I have been in the position where we had the opportunity to do that and scrum/agile comes naturally. In an existing organization, it is however not that easy. Decision processes are already in place, and the boundaries of responsibilities are already set. A complete methodology will inevitably change some of these boundaries, and before all other are adjusted there will be conflicts.

In different types of organizations, the challenges will be more difficult. To learn more about the change process in large organizations, I can recommend reading the book Fearless Change.

A TECH-ORIENTED BUSINESS

In a tech-oriented business the product is managed from a technical perspective. There is a huge gap between the development department and the rest of the organization. This is typical for really high-tech companies where the entire company is built around the core of the product. This company may be founded by the inventor of this product and there is a “core clique” of developers that has been in the company a long time. The management, marketing and sales persons often attribute these developers some kind of super-powers, simply because they don’t understand the products enough and the developers will not do anything to take that out of them.

In this type of situations, the tech people in the organization can be quite reluctant to change. They are used to be able to call the shots and are not necessarily happy about having to account for what they are doing. The requirement of working on specific tasks just because they are on the sprint backlog is a restriction. This is a very difficult situation to master and it is important to anchor everything thoroughly in the team. The “senior” people may use a passive-aggressive approach just ignoring directives and the more “junior” or newer staff may be too intimidated to change.

As a product owner, the best way of winning these hard-core tech people is to understand the concepts. Understand the domain and the technology. If you can’t yourself, employ an engineer as business analyst to do support you. Ask the tech people for advice and let them participate in the backlog process. These people are “gurus” in the organization and Scrum threatens their position. It is however very important that this is changed. An organization should not be driven by the tech department.

A SALES-ORIENTED BUSINESS

Another situation is in a sales oriented business. This company is characterized by a strong sales-force. There is not necessarily a tight connection with the customers, but rather a constant stream of new customers and this may be what is supporting the development and product financially. For each contract (presented as the most important ever) there are new make-or-break requirements that has to be added to the product. Typical for a sales oriented product company is also that there are multiple strong sales managers, typically responsible for different areas and that these not necessarily are coordinated.

The problem with introducing Scrum in a sales oriented organization is that the sales force is used to very quick response-times from the development organization, getting functionality implemented or borrowing resources for sales activities. This way of working may be ok for securing short term profit, but there is no strategic planning, which will make the product loose out. Coordinating the development will create friction with the sales department.

This too has to change. An organization should not be driven by the sales department either. The development of the product will be inconsistent and the different requirements will probably not bring the product forward enough. As a Product Owner in a sales-oriented business it is important to proactively negotiate the requirements with the sales department. They are the customers and we must always listen to them, but we also need to figure out the over-all most important issues. The role of the Product Owner is to get the sales force to plan strategically towards a further horizon.

AN ENTREPRENEUR-ORIENTED BUSINESS

Maybe the most difficult type of organization to change is the entrepreneur-oriented. This is a still relatively small organization that has out grown its even smaller structure. The founders are still highly active in the organization and they can still bypass routines and processes.

The problem with the informal stake holders is that they are used to be involved in all decisions and the organization tends to revolve around these persons. As they are (or are perceived as) powerful, it is difficult to create formal decision processes beside these.

In an entrepreneur-oriented business the solution as a product owner is to include founders into the process. Include the original designer in the acceptance testing process and as a product owner, invite the founder or founders for discussions on the road-map.