Respuesta de padres de familia a la entrevista

The Extreme Programming method was designed for software development work, but at Extreme Inc. it was not limited to the development teams. The three product development tribes and the DevOps tribe were supported by sales, marketing, finance, risk and internal auditing functions. The different nature of the work in these functions did not always lend itself to fully fledged application of pair programming or other Extreme Inc. methods, but these stakeholders had adopted the methods to the extent that was suitable for their needs. Their understanding of the methods and the culture that fostered face-to-face collaboration amongst all the members of the organisation ensured that the business stakeholders at Extreme Inc. were very tightly integrated into the daily operations.

However, the tight integration did not mean that all business stakeholders were in constant collaboration with the development teams. The organisation had devised a role of business managers, who held the responsibility of ensuring that the business stakeholders and the teams were aware of information relevant to their work. These business managers were embedded into the technical teams and acted as the conduits between the customer requirements and the technical members of the teams. The customer and end user requirements were sourced from the feedback provided by the end user as part of product support and by the business managers themselves who organised feedback collection sessions. In order to disseminate these user needs to the development teams, the business managers regularly participated in the daily stand-ups and other meetings. A developer explained what role the business managers played in the daily collaboration:

We try to work as closely as we can with product management. So, as part of developing our work, we have to include them in our reviews and stories. Which is, our task should be represented as a user needs or something that provides value to the business. So our product management will join us and talk about their need and what their priorities are. Represent our end users as well. It is bit like a negotiation between resources. Then things are prioritised, we’ll give a lot of technical input to make sure that the prioritisations really stick…And occasionally every week depending on what type of project it is and how many different streams, sometimes you need more prioritisation.

However, the role of the product managers was not to bridge boundaries between the business stakeholders and the development team. This responsibility was equally distributed amongst the whole organisation. The development teams were responsible for their own work as part of self-organising and committed teams. When a situation arose where they were required to obtain information from the business stakeholders, the responsibility to collaborate was not transferrable to the product managers, but the developers had to work with the business stakeholders themselves. Similarly, if the business stakeholders were to collaborate with the development, the initiation of the collaboration came from the stakeholders. The organisation had fostered a culture and designed premises that made such collaboration easy. The business stakeholders, such as marketing or sales, were located on the same premises and used visualisation tools such as sales pipelines on walls that resembled the Kanban walls of the developers. The sales manager explained how pairing and walls had been applied in the sales department:

They effectively pair up with ... who’s responsible for maintaining and managing their pipeline. At least in the beginning. So they have weekly meetings around how their [sales] pipes are going or not going. So we can quickly

see if someone’s like falling behind and try to understand why that is so and redress the problem. We have monthly targets that we set for ourselves.

Figure 7 illustrates the very flat and open structure of Extreme Inc. collaboration. The product tribes and the

business stakeholders were tightly knit, sharing understanding of the Agile values. Business stakeholders praised the developers for their proactivity when it came to requirements clarification or other collaboration. The arrows illustrate the collaboration channels between the different stakeholders.

Figure 7. Extreme Inc. Stakeholders

The development teams were very accommodating towards the product managers, testers or any other stakeholders. For example, in one of the teams, a product manager felt that the information on the wall was not clear enough. A delivery lead described what happened at the time:

We changed our board to more like Kanban style. That was mainly after a request from our product manager, he had been reading a lot about Kanban and he felt he could get a better picture if he had a Kanban board. He could see what’s in progress, where do you need to put stories in.

In a similar example, a test lead wanted to improve the collaboration capabilities of the objects. He explained:

We’ve done quite a bit of work in process improvement. So we redesigned our whole Kanban wall. Previously it was a very static wall that didn’t tell anything except ‘we are working on this’ and that was it. There was nothing more. So we redesigned it so that we have pipeline visibility from sales…It is extremely useful when we are talking to the sales team and when we are talking to the management. We can actually tell a story.

The organisation was open to new initiatives that would improve the integration even further. In the established and strong organisational culture of Extreme Inc., these improvements were often small and gradual, but had a significant impact. One of the examples mentioned was the physical location of the product managers. Previously, the managers had been located in one table amongst each other but in recent months, they were moved to sit next to their teams. Interviewees said that this relocation had made communication between the developers and product managers even more effortless.