The XP customer team: A grounded theory

The initial definition of XP resulted in many people interpreting the on-site customer to be a single person. We have conducted extensive qualitative research studying XP teams, and one of our research questions was “who is the customer”? We found that, rather than a single person, a customer team always exists. In this paper we outline the different roles that were typically on the team, which range from the recognized “Acceptance Tester” role to the less recognized roles of “Political Advisor” and “Super-Secretary”

Are Product Owners communicators? A multi-method research approach to provide a more comprehensive picture of Product Owners in practice

Product Owners have an important role in the agile and hybrid software development process. While this role is supposed to maximize the value of a product, there seem to be several scattered results on how they achieve this, as well as what actually constitutes this role in practice. To consolidate current research results and to further analyze the key attribute of Product Owners, we conducted a multi-method research approach spanning a systematic mapping study and a consecutive case study in a hybrid development environment. The results of the mapping study states that Product Owners are communicators. We further investigated on this and used the shadowing technique to observe three Product Owners' communication activities. The results support that statement, as the gained data reveal that Product Owners spend 65% of their time in meetings. But rather than just providing the team with the necessary requirements for the product under development, Product Owners need this time to synchronize and align their work, streamline the agile process of large-scale Scrum, discuss team-based topics, and to solve upcoming issues addressed by the team. These results contribute to draw a more comprehensive picture of the important but yet complex role of Product Owners in practice. © 2020 John Wiley & Sons, Ltd

Supporting the tailoring of the product owner role to hybrid development environments

Product Owners have an important role in the agile software development process. While the description of the Product Owner role heavily depends on its particular agile framework, the application of a single development framework is seldom in practice. In fact, customized hybrid development approaches, where frameworks/methods are tailored or combined with others, are state of the art. Although it is common knowledge that processes need to be tailored to project needs, as they become, otherwise, a project risk - the tailoring of the Product Owner role has been neglected in research so far. Consequently, there is a lack of knowledge about how to tailor the Product Owner role to hybrid development environments. As this knowledge gap can put projects in a hybrid environment to a risk, the goal of this thesis is to close this gap. To achieve this, a knowledge-base of Product Owner peculiarities needs to be established and consolidated with knowledge from the area of Software Process Tailoring. To generate the knowledge-base of the Product Owner peculiarities, a number of case studies as well as a systematic mapping study was conducted to identify Product Owner tasks, characteristics and structures in hybrid development environments. This resulted in the identification of 13 frequently conducted tasks, 6 favorable characteristics and 12 different structures of Product Owners that apply in hybrid development environments. From the area of Software Process Tailoring, 14 influencing factors on the Product Owner role were extracted along with its respective action items. The consolidation of this knowledge results in a catalog which combines the influencing factors, the Product Owner tasks, characteristics & structures as well as the respective implications on the Product Owner role according to the research results of this thesis. Based on this catalog, any project environment can be assessed and distinct recommendations for a tailored Product Owner role can be deduced. Overall, this thesis generated 84 different recommendations on how to tailor the Product Owner role to a particular hybrid development. With this, so far missing knowledge was gained to systematically support the tailoring of the Product Owner role to hybrid development environments and thus, to support projects to complete successfully. To share the gained knowledge to other researchers as well as practitioners, this thesis also provides an expert system in the form of a proof of concept web-application. The so-called Hybrid Product Owner (short: HyPrO) Expert System represents the research results of this thesis. Its user-friendly interface enables the user to assess the project environment and displays the respective recommendations. The HyPrO Expert System validated the results of this thesis, as it surpassed human experts by providing more comprehensive recommendations in a comparative case study

Proposta de um conjunto de competências para um Scrum Master

Monografia (graduação)—Universidade de Brasília, Faculdade UnB Gama, Curso de Engenharia de Software, 2014.O Scrum é um framework em que pessoas podem tratar e resolver problemas complexos. Consiste em um time associado a papéis, eventos, artefatos e regras no qual cada componente serve para um propósito específico e essencial para o uso do mesmo. O Guia Scrum e outros artigos descrevem as atividades a serem desempenhadas por cada um dos papéis existentes, dentre eles o do Scrum Master. Entretanto não descrevem em detalhes quais são as competências necessárias para o exercício de cada um dos papeis. Diante disso, este Trabalho de Conclusão de Curso propõe e valida um conjunto de competências para um Scrum Master. Para se obter essas competências foram realizadas uma revisão sistemática de literatura e uma revisão bibliográfica sobre o assunto a fim de se localizar as características inerentes ao papel do Scrum Master. Além disso, o conceito de competência foi caracterizado para que se pudesse fundamentar este trabalho. Dada à importância do Scrum Master dentro do framework Scrum foram detalhadas suas atividades dentro das cerimônias bem como suas responsabilidades sobre os artefatos gerados durante o desenvolvimento. Um questionário foi utilizado para avaliar a importância de cada uma das competências levantadas. Por fim, foi produzido como resultado um ranking de competências pelo seu grau de importância, sendo constituído por 20 competências.Scrum is a framework where people can process and resolve complex problems and consists of a Scrum team associated with roles, events, artifacts and rules where each component serves a specific and essential purpose for using the Scrum. The Scrum Guide and other articles describes the activities to be performed by each of the existing roles, including the Scrum Master, but do not describe in details which are the competencies for this role. Given this issue, this Work of Course’s Conclusion propose and validate a set of competencies for a Scrum Master. To obtain these competencies a systematic literature review and a literature review on the subject in order to find the characteristics inherent in the role of Scrum Master and characterize the concept of competence so that they could support this work were performed. Given the importance of the Scrum Master within the Scrum framework detailed activities were within the ceremonies and responsibilities of the artifacts generated during development. A survey was used to evaluate the importance of each of the proposed competencies and as a result has produced a ranking of competencies by their level of importance, being composed for 20 competencies

Proposta de um conjunto de competências para um Product Owner

Monografia (graduação)—Universidade de Brasília, Faculdade UnB Gama, Curso de Engenharia de Software, 2014.A importância da área de TI cresce cada vez mais tanto no contexto público quanto no privado. A partir da divulgação do Manifesto Ágil em 2001, juntamente com esse crescimento, há a disseminação da utilização de metodologias ágeis em ambos os contextos, sobretudo do framework Scrum, que traz nova logística, atividades e papéis para o desenvolvimento de um software. Um desses novos papéis é o Product Owner (PO), que possui diversas responsabilidades. Porém, para que ele consiga executar suas atribuições com êxito, é necessário que a pessoa que desempenha esse papel possua competências específicas. Este Trabalho de Conclusão de Curso possui como objetivo propor e validar um conjunto de competências iniciais para um Product Owner que esteja alinhado com as responsabilidades que este papel possui e as atividades que desempenha de modo a potencializar os fatores de sucesso e minimizar os fatores de fracasso de um projeto referentes ao PO. Um questionário foi elaborado para efetuar a validação das competências e produziu como resultado um ranqueamento das competências com base na importância dada pelos respondentes a cada uma delas. ______________________________________________________________________________ ABSTRACTThe importance of IT grows increasingly both in the public and private context. From the release of the Agile Manifesto in 2001, along with this growth, occurs the spread of the use of agile methodologies in both contexts, especially the Scrum framework, which brings new logistics, activities and roles for the software development. One of these roles is the Product Owner (PO), who has many responsibilities. However, so the PO can execute his/her tasks successfully it is necessary that the person who performs this role has specific competences. The objective of this Work of Course’s Conclusion is to propose and validate a set of preliminary skills for a Product Owner that is aligned with the responsibilities that this role has and the activities it performs, in order to maximize the success factors and minimize the failure ones of a project related to the PO. A questionnaire was designed to perform the validation of the skills and produced results in a ranking of competences based on the importance given by the respondents for each of them

A case study of agile software development for large-scale safety-critical systems projects

This study explores the introduction of agile software development within an avionics company engaged in safety-critical system engineering. There is increasing pressure throughout the software industry for development efforts to adopt agile software development in order to respond more rapidly to changing requirements and make more frequent deliveries of systems to customers for review and integration. This pressure is also being experienced in safety-critical industries, where release cycles on typically large and complex systems may run to several years on projects spanning decades. However, safety-critical system developments are normally highly regulated, which may constrain the adoption of agile software development or require adaptation of selected methods or practices. To investigate this potential conflict, we conducted a series of interviews with practitioners in the company, exploring their experiences of adopting agile software development and the challenges encountered. The study also explores the opportunities for altering the existing software process in the company to better fit agile software development to the constraints of software development for safety-critical systems. We conclude by identifying immediate future research directions to better align the tempo of software development for safety-critical systems and agile software development

Produktägarens förväntade färdigheter i Scrumprojekt

IT-branschen är i ständig förändring och agila systemutvecklingsmetoder är det som i allra högsta grad har populariserats, varav Scrum praktiseras av mer än hälften av de som anammar agila metoder. Rollen projektledare suddas ut och produktägaren är personen med störst mandat. Produktägarrollen innebär ansvaret till flera av de traditionella rollernas ansvar kombinerat. Tidigare forskning visar att brist på projektledningskompetens är en fällande faktor inom agila systemutvecklingsprojekt. Syftet med vår studie är att beskriva och förklara skillnader och likheter angående förväntningar på produktägarens färdigheter inom Scrum i praktiken och undersöka om dessa motsvarar teorin. En teoretisk undersökningstabell togs fram på tidigare teori för att sedan göra en kvalitativ undersökning. Fyra semistrukturerade intervjuer med erfarna yrkesverksamma genomfördes och utifrån en analys diskuterades ett resultat fram. Resultatet visar att litteraturen överensstämmer väl med informanternas förväntningar och av de åtta färdigheterna som listas i litteraturen nämns samtliga i empirin. Resultatet visar även indikationer på en nionde färdighet vilket kan vara ett hittills okänt resultat

The Scrum Product Backlog as a Tool for Steering the Product Development in a Large-Scale Organization

Vesiputousmalli ja sen variaatiot ovat olleet laajalti käytössä ohjelmistotuotannossa. Näiden mallien vikojen korjaamiseksi, eli markkinoiden vaatimuksiin mukautumisen kohentamiseksi sekä evolutionististen toimitusten tekemiseksi, on syntynyt ketteriä ohjelmistokehitysmenetelmiä. Näistä eniten käytetty on scrum-viitekehys. Suomen Ericsson on ottamassa scrum-menetelmän käyttöön. Muutoksen tukemiseksi, tämä diplomityö tunnistaa product backlog -tehtävälistan asianosaisia sekä heidän tarvitsemaansa ja tuottamaansa tietoa. Kirjallisuuskatsauksen, tietoliikennealan yritysten vertailun, strukturoimattomien haastatteluiden (n = 6) sekä puolistrukturoitujen haastatteluiden (n = 11) avulla tutkimuksessa tunnistettiin asianosaiset ja heidän toimintansa eri päätöspisteissä. Pohjana tutkimuksessa käytetään yrityksen uutta päätöksentekoviitekehystä. Diplomityö esittelee taulukon avulla asianosaisten toimenpiteet eri päätöspisteissä nimenomaan product backlog -tehtävälistaan liittyen. On oleellista huomata, että eri asianomaiset tarvitsevat eri tietoa. Lisäksi eri vastuuhenkilöille sopivat erilaiset visualisointitavat. Näin ollen, työ esittelee myös viitekehyksen, jonka avulla visualisointia voidaan kohdentaa eri asianomaisille. Tutkimuksessa havaittiin kolme seikkaa, joita tulee kohentaa. Ensinnäkin, useat asianomistajat haluavat oman backlog -tehtävälistan. Toiseksi, tehtäviä ja vastuita siirretään useassa kohtaa toiselle henkilölle. Kolmanneksi, innovaatioprosessi on erillään uuden tuotteen kehittämisestä. Toisaalta, useita kaavailtua tapaa tukevia löydöksiä havaittiin kirjallisuudesta. Esimerkiksi, yrityksen tiimit ovat monialaisia, tuotevastuu on hajautettu useammalle henkilölle sekä uuden ominaisuuden sisältö on rajattu vastaamaan markkinan todellista vaatimusta.The Waterfall model has been widely applied in the software development. However, agile software development methods have emerged to enhance the adaptability to the changing market demands and to utilize evolutionary releases. The most widely adopted agile method is the Scrum framework. Ericsson Finland is implementing Scrum. To support the transition, the thesis identifies the stakeholders of the product backlog and the data the stakeholders demand and provide. With a simplification, it can be stated that the product backlog is a prioritized list of items to be performed to complete a feature. Based on a literature review including a benchmark of other telecommunication domain companies, open-ended interviews (n = 6), and semi-structured interviews (n = 11), the thesis lists the stakeholders and their actions at each decision point. The decision framework, which has emerged in-house, was utilized to structure the thesis. A matrix mapping the actions by each stakeholder at each decision point was formed. The primary data, which the stakeholders require directly and indirectly from the product backlog, are the velocity, work to be done, the date of feature completion, dependencies, costs, and business value. It is important to note that the stakeholders need the data on different levels and for different purposes. Hence, the feasible visualization of the data varies among the stakeholders. In addition to identifying the stakeholders and the requirements for data, the thesis points out three findings regarding areas to be enhanced. First, multiple stakeholders currently demand their own product backlog. Second, multiple handovers are conducted. Third, the innovation process is isolated. However, multiple findings supporting the current organizational thinking of the implementation emerged. For instance, the teams are cross-functional, the product ownership responsibility is shared, and the scope of a new feature is optimized to not to include additional functionality that the market does not demand

Self-Organizing Agile Teams: A Grounded Theory

Self-organizing teams are a hallmark of Agile software development, directly a ecting team e ectiveness and project success. Agile software development, and in particular the Scrum method, emphasizes self-organizing teams but does not provide clear guidelines on how teams should become and remain self-organizing. Based on Grounded Theory research involving 58 Agile prac- titioners from 23 di erent software organizations in New Zealand and In- dia, this thesis presents a grounded theory of self-organizing Agile teams. The theory of self-organizing Agile teams explains how software development teams take on informal, implicit, transient, and spontaneous roles and per- form balanced practices while facing critical environmental factors, in order to become self-organizing. The roles are: Mentor, Co-ordinator, Translator, Champion, Promoter, and Terminator. The practices involve balancing free- dom and responsibility, cross-functionality and specialization, and continuous learning and iteration pressure. The factors are senior management support and level of customer involvement. This thesis will help teams and their coaches better understand their roles and responsibilities as a self-organizing Agile team. This thesis will also serve to educate senior management and customers about the importance of supporting these team

The Role of Customers in Extreme Programming Projects

eXtreme programming (XP) is one of a new breed of methods, collectively known as the agile methods, that are challenging conventional wisdom regarding systems development processes and practices. Practitioners specifically designed the agile methods to meet the business problems and challenges we face building software today. As such, these methods are receiving significant attention in practitioner literature. In order to operate effectively in the world of vague and changing requirements, XP moves the emphasis away from document-centric processes into practices that enable people. The Customer is the primary organisational facing role in eXtreme Programming (XP). The Customer's explicit responsibilities are to drive the project, providing project requirements (user stories) and quality control (acceptance testing). Unfortunately the customer must also shoulder a number of implicit responsibilities including liaison with external project stakeholders, especially project funders, clients, and end users, while maintaining the trust of both the development team and the wider business. This thesis presents a grounded theory of XP software development requirements elicitation, communication, and acceptance, which was guided by three major research questions. What is the experience of being an XP Customer? We found that teams agree that the on-site customer practice is a drastic improvement to the traditional document-centric approaches. Our results indicate, however, that the customers are consistently under pressure and commit long hours to the project in order to fulfil the customer role. So while this approach to requirements is achieving excellent results, it also appears to be unsustainable and thus constitutes a great risk to XP projects. Who is the XP Customer? The initial definition of XP resulted in many people interpreting the onsite customer to be a single person. This research has highlighted that a customer team always exists, and goes further to outline the ten different roles that were covered on the team, which range from the recognised "Acceptance Tester" role to the less recognised roles of "Political Advisor" and "Super-Secretary". What are the practices that support an XP Customer to perform their role effectively on a software development project? An additional eight customer-focused practices have been uncovered to supplement the existing XP practices. These customer-focused practices together enable customers to sustainably drive XP projects to successful completion. The practices range from those that specifically focus on interaction (both with the programmer team and the larger organisation) e.g. "Programmer On-site" and "Roadshows" to those that specifically look to the well-being and effectiveness of the customer (e.g. "Pair Customering") to those that highlight the key steps or activities that need to occur along the way (e.g. "Big Picture Up-Front" and "Recalibration")