To have or not to have a defined software development process in an Enterprise environment

When I started working at TUI Nordic, I was convinced that you didn’t need a specific software development methodology. What I mean with that is that of course you need to know which process is used, but I didn’t think that it mattered if you were using scrum or parts of scrum. You could just pick and choose.

That might be true in a small environment, but it’s not the case in an enterprise environment. If you have one scrum team or perhaps two, a specific number of developers and product owners, you can play with terms and roles, but when you are 50 developers, of which a good number are consultants on longer and shorter assignments and when the de facto product owners are in many cases consultants, it does not work. It’s like working without a domain model. If you are a few, tightly knit persons you can probably transfer the knowledge as it is needed but in large crowd, that simply does not work.

For me, scrum is a framework for how you communicate, in the team, with other teams and to stakeholders. By defining when, who and with which tools, you create rules for one of the greatest success factors for software development. If you to a new employee or consultant can say that you use scrum, that person does not have to learn everything from scratch from another team member. By stating: "we are using one week sprints" or "she’s the product owner", we include a lot of information which with using an ad hoc software development process need so much explaining.

That is also why added roles like "product owner proxy" works so poorly: no one really knows what is means. I like better the solution we’re discussing at TUI: there is only one product owner but during the inspiration phases when we search funding for a project, one person is acting product owner but that role is later transfered to another individual during the implementation phase. The reason for this is that the needed traits of the product owner is very different during the idea phases. This is a form of scaling of the product owner role, where the original product owner works on a higher level and never goes into technical details, you could say he’s a form of product manager.