Academic Posters

The agile manifesto was created in 2001. In the following years, a few agile methods and
frameworks were created. Those methods and frameworks were targeted for small co-located teams. A few examples are Scrum, Extreme Programming (XP), Crystal Clear,
Dynamic Systems Development Method (DSDM). The benefits of using those agile methods and frameworks was seen by the software industry and demand emerged for using them also in multi-team environments. Adopting agile methods in such a multi-team environment introduced more challenges, that were not seen in small scale (or were easy to overcome). A few examples of those challenges are inter-team coordination, creating cross-functional teams, creation of unified requirements backlog, etc. The purpose of this paper is to review the popular large scale agile methods and the challenges in adopting agile in a multi-team environment.

In ever increasing VUCA environment in supply chain, Scrum can play key role in providing solutions. As challenges and uncertainty in supply chain can be better addressed by adaptive planning rather than traditional planning thus making the progress visible and predictable. Adopting Scrum, can help create an environment of planning continuously and delivering incrementally.
Note: This poster is based on article “Scrum is not just for software” in 2009 by Robbie Mac Iver and have been presented from my perspective and experience on this.

As a part of an extensive study focusing on how agile teams respond to requirements changes, we carried out a pilot study to understand the technical responses shown by agile practitioners to requirements changes. To the best of our knowledge, how agile teams respond technically to such changes has not yet been studied. We used a qualitative approach using Grounded Theory. Analysis of the interview data collected from ten agile practitioners in New Zealand and Australia resulted in identifying three stages where agile teams respond to requirements changes technically -- while receiving, developing, and delivering changes. We found that even though agile practices do not recommend comprehensive documentation, in practice, the product owner defining a requirements change in detail was stated by the participants as the most common technical response. Developers conducting a technical feasibility study and negotiations among product owner and team when receiving a requirements change were the other most common technical responses. These show a tendency to deviate from some agile practices in some specific situations.

Note: The poster is based on the short paper presented at CHASE workshop of 42nd IEEE/ACM ICSE'20 conference and the poster was showcased at the workshop but has not been published anywhere.

Preprint of the paper: https://git.io/JLsqw

Reference to the published version of the paper: Kashumi Madampe, Rashina Hoda, John Grundy, and Paramvir Singh. 2020. Towards Understanding Technical Responses to Requirements Changes in Agile Teams. In Proceedings of the IEEE/ACM 42nd International Conference on Software Engineering Workshops (ICSEW'20). Association for Computing Machinery, New York, NY, USA, 153–156. DOI:https://doi.org/10.1145/3387940.3392229

In the context of Digital Transformations (DX), Agile Coaches are hired to help
support the adoption of Agile and Lean ways of working. The scope of DX may be limited to IT, or may involve the entire business.
This research seeks to understand the activities
of AC that help managers transform their areas.
Implicit in this aim is the need for managers to recognise their role in improving their systems of work. It typifies the insight expected of AC.
The questions that will drive this research are:
• What are the competencies and
practices of AC?
• Which of these are actually helpful to
managers?
• How can AC help managers transform their organisation or area?