Bizzomate’s practices

Bizzomate’s IT consulting - and - developing practices needed to be investigated to evaluate the similarities of those derived from academic research and to evaluate the possibility of applying DT elements to these practices. The results of this section were divided into two parts: one regarding the perception of core - and envisioned practice and the other with respect to the execution in their current practices.

4.1.1. Perceived core - and envisioned practice

Prior to investigating what was standard practice and how it was executed, the organization’s perception of its core practice was investigated. Furthermore, it was analysed how this perception related to its envisioned practice. Every respondent was asked to describe Bizzomate’s core practice.

Although there were different viewpoints, returning aspects included that Bizzomate primarily builds software and includes a consulting attitude in the process. Bizzomate does not only provide “hands”

that build software, but all employees take on an advisory role to help clients with their IT-related issues and to help them grow in today’s dynamic world. The respondents characterized Bizzomate as a young and modern organization with an open and transparent approach, both internally and externally.

Many respondents mentioned that Bizzomate’s practices are in transition: “What has been going on for almost a year is that we are also helping more and more companies in the preliminary phase. By coming into contact earlier we can, for example, help companies to formulate problems or to help with strategy and vision. There can be, for example, gaps between the identified strategy and the vision where we can help draw up plans, implementing the vision and carrying out canvas sessions. On the one hand we then strategically support the organizations and on the other hand we build software that can help with the implementation”.

This quote regarding the transition of the practices reflects the vision of Bizzomate’s management for the upcoming years. Management wants to include more business consulting projects next to their existing IT consulting projects. The former consulting practices include strategic consulting, whereas the latter includes technology consulting. Through the business consulting practices, Bizzomate

36

management envisions becoming a “trusted advisor”, supporting their clients in their strategic and visioning plans, through which Bizzomate can offer their IT consulting - and developing practices.

However, this would require to come into contact with clients in quite an early phase. Earlier then when the clients start searching for a solution supplier: “Actually, if you look at the problem identification process [of clients], you can draw a linear time line from 0% to 100%. At 100% in this process time line, the solution is clear and can be built and implemented. … Suppliers [like Bizzomate]

are only involved after 57% in this process. At this stage the customer already knows what the problem is and how to solve it. … And do you know when a project will be launched or when they decide not to continue? This is within 33% in the process. Clients then have not contacted any suppliers and do not know what the suppliers can do for them. Consequently, there are a lot of projects we did not even know they existed. What if we try to get into contact with them around 20-25% in this process? First of all, we can help to define the problem and secondly, we can work out the different options for solutions.

This will really make us a trusted advisor“.

4.1.2. Execution in current practices

This section analysed how Bizzomate employees evaluated their current practices. This includes investigation of what is standard practice and what the respondents perceived successful and poor practice.

4.1.2.1. Standard practice

In a linear process, from first contact to software development, clients first get in contact with the new business developer and the account manager. The new business developer is responsible for campaigns to reach potential clients. Until recently, the campaigns were about automating and digitalizing businesses: “Our offering to clients mainly includes the application of Mendix to their business processes. … And we offer business consultants who can investigate their processes to help them further in their IT-related issues”. Mendix is a software development platform in which software is developed by assembling modular items. In this pre-sales process, the new business developer functions as a connector of people who need to be involved in order to close the deal. The account manager is primary responsible for closing the deal and has to check with the factory leader for resources to run the project. The pre-sales - and sales process in principle do not involve paid services.

The business consultants are business analysts and bridge the gap between business and IT. They outline solution designs and Avola models. Avola is decision software that Bizzomate developed, in which decision tree models are created that automate the decision process.

The Mendix consultants and Scrum master are involved in the software development project which follows agile Scrum methodology. Mendix consultants advice clients how to apply Mendix in their business IT, to resolve the problems stated in the Scrum sprint kick-offs. The Scrum master guides the Scrum process and teamwork. Scrum projects are sliced into sprints of 4 weeks, where the developers are working in Mendix for 60% of their time. The remaining time is spend on communicating with each other and clients regarding the functionalities of the software in development. The Scrum master is especially focussed on the evaluative sessions with the software development team.

Further roles include IT support and management. The management team include e.g. the two executives, the “factory leader” and “happiness officer”, who are responsible for transformation, commercial, operational and financial management, human resource activities and account management.

Clients do not come and go. Multiple projects are conducted within clients’ organizations and each project can take one to five years. Example projects are a Mendix project within DEKRA Belgium, in

37

which Bizzomate develops a new claim processing system, or an Avola project within BAM Infra Telecom, in which Bizzomate developed a decision model, automating the payroll processing system.

4.1.2.2. Successful practice

The respondents were asked what they perceive as successful in their current practices. These successes were divided between non- development successes and ASD successes. It was mentioned that in general there is a great sense of commitment and people start to think more about the added value for the client. These aspects are true for the development teams as well. Additionally, the operations within Bizzomate are practiced ad hoc, which was perceived flexible and successful as well.

ASD is considered a success due to the flexibility and responsiveness. Defects are quickly noticed due to the experimental approach. It does not include endless refining, recording and elaborating on assumptions made, but rather the testing of the assumptions. Additionally, clear goals result in faster and more customer-oriented software development. Moreover, not only the methodology, but the overall work culture was perceived a success as well. Agile methodologies require development teams with high autonomy, which seems to correlate to job satisfaction: “The most important thing about the agile way of working is that the software developers take responsibility. The responsibility lies with the team itself, and therefore the commitment of the team is enhanced. This is much more effective than what you see in more traditional methods, where someone gets a requirements document pushed into their hands with a three week deadline. Project estimates have never been correct and therefore these are always estimated favourably, and otherwise the project is cancelled. You just know that you are not going to achieve this whole requirement document in the given time. This is demotivating. Plus, someone has already designed the framework and you only have to fill it in. Your individual input is not desired and you are just a pair of executive hands. That does not work. The freedom and responsibility in agile working results in a much more pleasant way of working”.

The agile way of working is not only restricted to software development, as it could be adopted throughout the organization: “A company as a whole should adopt business agility. It is a management philosophy that a business should continuously adjust to the changing circumstances. If you cannot do that nowadays, you will not get anywhere as an organization. We call it the ‘triple agile’ organization, in which it is agile in all three layers. The first layer is business agility: the culture. … It is a way of life, you have to breathe it. You can start tomorrow by applying the second layer ‘decision agility’. … That is when you structure and record all operational decisions within an organization. When you make a strategic decision you can ‘click, click, click, click’, turn the buttons and it's operating … Then the third layer is IT agility, because the IT systems must also be able to handle it [the responsiveness of decision making]”.

4.1.2.3. Poor practice

The respondents were asked what they perceive as poor practice too. These results were divided between non- development practices and ASD. The most mentioned practices that were poorly executed relate to challenging the clients’ point of views and gaining understanding of what is truly hidden behind certain problem statements. These failures occurred in a few projects, where the client and product owner were not challenged or the requirements were wrongly perceived. This lead to misdirection in the software development process or even project cancellations: “For a client, who is no longer our client, a project had failed completely. The product owner was also the operational director of the client and he had all sorts of plans that actually did not work within the company and we kept on building on his ideas. In the end, his employees did not agree with the system and they could not carry out their work within the new system. What we had made was unusable, no matter how well we built it. We had only listened to the operational director who had mentioned things based on all kinds of assumptions and we just built it. It was really a shame because it was a very good and

38

qualitative product. That is the difference between ‘building things right’ and ‘building the right things’:

something can be built ingeniously which ultimately has no value”.

Furthermore, communication is not always at best, as is the estimation of project durations. At times Bizzomate is too ad hoc. Approaches are not structured and everything is operationalized from scratch.

Additionally, it was perceived that a lot of the top professionals are allocated to one project, where in other projects relative inexperienced developers are left on their own. Bizzomate is short on employees and especially developers. Consequently, since there are not enough resources for the prospects, the added value of the sales force is relatively low. Furthermore, management believes that there is too much focus on selling Mendix, instead of selling solutions and trust.

It was perceived that agile methodologies are difficult to adopt. It requires a certain work culture which is not present in the environment of the clients, or difficult to adhere to. It is difficult to sell the approach to clients as well, as the light planning might be inconvenient. Agile methodologies are difficult to plan as the understanding and functionalities are developed gradually during the process itself. Therefore it is difficult to plan ahead and to sell the approach without clear planning and destination. For developers it is difficult to truly understand the mechanisms of the methodology as well, as many only perform a trick they learned to do. Within Bizzomate, agile has a certain connotation that could result into a conflict between the agile purists and those who think it is a hype. ASD should be embraced by all team members, for it to have successful outcomes. However, next to the inability of clients to adopt the methodology, it is not always the appropriate methodology. When user requirements are not involved and only technical connectors should be linked, it does not make sense to refine the requirements every few weeks. The most crucial pitfalls that were mentioned were regarding the role of the product owner and Scrum master. When the Scrum master is following the rules too strictly and with the wrong perception, the methodology becomes useless and when the product owner cannot translate the needs of the users it represents, the software becomes useless:

“If you allocate someone without a vision or understanding of the method, you often see that you are not building a solution, but a bundle of separate features. If you have a bundle of separate features, you do not have an application yet. We see it happening with a client. The product owner calls for something different every time. The big picture is missing. It results in very nice stand-alone functionalities, but I no longer understand the application. I cannot imagine how the user will easily click through it”.