Organización de la tesis

The stakeholder configuration in the PrecautionCorp program was established to ensure that different stakeholder groups had the means to collaborate with other parties, even if the collaboration was not necessarily directly between the individuals. All parties had assigned boundary spanners who were responsible for information distribution across the boundaries between the organisations and the different teams and streams. These boundaries between the parties existed for several reasons: the technical teams had different goals and the teams differed by the expertise needed for different types of work and by their means of engagement, virtual or physical; the teams consisting of business stakeholders came from different parts of PrecautionCorp and it was important to provide them with accessible contacts to ease their collaboration with the technical teams, teams they usually would not have much to do with.

There were several types of collaboration arrangements between the teams. The offshore development was arranged according to the task breakdown of the development project: the front-end development team – the team responsible for the visuals and usability of the product – was collaborating with the Chinese partners; the back-end teams, split into several streams, were working on the integration of the product, feature configuration and data migration, and predominantly collaborating with the Indian partners. Neither team was working in isolation: the work of the front- end and the back-end was interconnected. The iteration managers paid special attention to coordination efforts that ensured that the dependencies between the teams did not turn into hindrances. The stream dependencies were regarded as crucial discussion points and significant time was spent in discussing these dependencies during the Scrum of Scrum meetings. Iteration managers and the business teams were also supported by the Agile coaches, who acted as boundary spanners between these two groups. The Agile coaches ensured that the Agile methods were understood by the business stakeholders and monitored the application of the methods in the technical teams. The interviewees had mixed feelings on the boundary spanner collaboration model. The iteration managers were mostly well-informed on the program events and knew where to get information if needed, but the business analysts and testers were unclear on what was happening in the other streams. On the other hand, they thought that the information they were given was sufficient and their product owners were accessible if they had any business requirement related issues. One of the iteration managers explained how her team’s product owner was the main conduit for the information from the business stakeholders:

…we have our product owner. Basically, she is our middleman to engage all the business people, so she has to transfer the information to us, but at the same time, I know that in release one, we got a lot of feedback that when the system is rolling out, and then they have no clue how the system work, and looks like it’s hard for them to what they’re supposed to, like that. Normally, they would on the spot. They would give the feedback, and then we’ll capture them, so within we’re able to make it, we will raise a tag, and then make the change. If we are unable to do it, our product owner will explain it to them {the business stakeholders}.

The business stakeholders were satisfied with the level of information they were given through their iteration manager. Their main concern was around balancing their own stakeholders and getting the required information from the departments they represented. One of the business stakeholders explained his role:

My job is to look after the investments on a day-to-day basis for the pension trustee. Basically, that involves being the product owner on the investment side, so the go-to person. I do regular reporting to management and to the trustee on the underlying assets of the pension fund. I do the relationship management with investment managers who manage the money. I do research on new investment strategies, do recommendations based on demand, or advisor feedback et cetera on new strategies for the fund.

The vendors had a similar boundary spanner arrangement in place as well. The teams that were more involved with the product development had stronger connections with the vendor organisation. One of the iteration managers explained how her team was collaborating with the vendors:

We have someone from the vendor, who’s got a lot of product knowledge. He’s embedded in our stream as well and he sort of acts as a BA, as whatever we need him for. As well as configuring the things within the product that we need him to do, say enabling the triggers for the {client} comm{unication}s {in the product}, extracting the XML files, doing a bit of ... that sort of stuff.

.

The boundary spanner stakeholder collaboration model of PrecautionCorp is illustrated in Figure 18. The boundary spanners – iteration managers, business iteration managers and product owners – spanned the boundaries between the PrecautionCorp business stakeholders and the PrecautionCorp development teams. The technical teams and the boundary spanners affiliated with the technical work are marked in green. The business stakeholders, non-technical members of PrecautionCorp, who also worked on the program deliverables, are marked in blue colour. The other two stakeholder groups – the vendor and the coaches – are marked in red and purple respectively