An Automated Contextual Collaboration approach for Distributed Agile Delivery Vibhu Saujanya Sharma
Vikrant Kaulgud
Accenture Technology Labs Accenture Services Private Limited, Bangalore, India Email:
[email protected]
Accenture Technology Labs Accenture Services Private Limited, Bangalore, India Email:
[email protected]
Abstract—The Agile way of developing and delivering software systems is gaining mainstream adoption due to the imperatives of a quickly changing technical landscape, business requirements and customer expectations. To truly leverage the power of Agile, big organizations need to be able to utilize distributed teams effectively. However, Agile delivery relies hugely on collaboration among team members and this can become a stumbling block among such geographically dispersed teams. Moreover, in such large projects the development and process layer needs to be monitored for any problematic patterns or events that could potentially cause the Sprints to fail. Here, we describe an automated approach which allows for contextual collaboration in such distributed Agile projects. The approach captures important events from the process and the development environment and uses a rule based approach to then automatically create awareness regarding them to appropriate roles in the project. Every team member receives an actionable feed in a MyContext pane which then leads the team member to navigate to an Activity centric context where collaboration specific to that activity can take place. This approach has been implemented in a process guidance and awareness workbench that we are piloting within our organization.
I.
I NTRODUCTION
Agile software development is established as a viable alternative to the traditional waterfall development method. As mentioned in the Agile Manifesto [1], amongst other principles, there is an emphasis on collaboration between all stakeholders of the software project - product owner, end-users, development and test teams - for rapid and iterative delivery of functionality. In fact, success of an Agile project depends on the level of awareness in these disparate stakeholders. Having collocated teams is the best structure since it allows regular face-to-face discussions thereby increasing awareness and collaboration. In typical, large software delivery projects, we observe a different organization structure caused by two factors: •
Often times the application under development is a complex application that is broken in to smaller components. Each component and subsequent integration is delivered in a Agile manner. This results in multiple development teams and business stakeholders, who not only need to collaborate within the boundary of their component but across component boundaries as well.
•
Based on IT services organizational structure, the development teams themselves may be distributed onshore, near-shore, offshore.
This distribution of teams due to technical and geographical factors increases the barrier to team-awareness required for successful Agile delivery. In this paper, we describe a contextual collaboration approach to overcome the barrier and increase team-awareness. While collaboration tools like shared whiteboards, audio-video conference tools, instant messaging tools exist, they provide an ‘out-of-band’ experience. These tools provide solutions to ‘how to collaborate’, but do not answer questions such as ‘when should collaboration happen’ and ‘with whom should collaboration happen’. Unless collaboration is in the ‘context’ of the Agile project, it amounts to noisy communication and may not necessarily increase team-awareness. Our approach provides contextual collaboration in context of an Agile delivery process. We have studied the typical stages in an Agile process, participating stakeholders and their roles, stakeholder information needs and key events that necessitate collaboration and information exchange to enhance awareness. Based on a model of these elements, contextual collaboration rules are defined to direct various collaboration activities. The approach is implemented in a real-life tool called Agile Workbench that is being piloted in large industrial projects. The rest of the paper is structured as follows - Section II we discuss issues around in Agile delivery in more detail. In Section III, our contextual collaboration approach is described in-depth along-with a few examples that motivate the events that trigger the need for collaboration. In Section IV, we briefly discuss the implementation of the approach. Finally we conclude with future work. II.
AGILE D ELIVERY AND C OLLABORATION
Large IT services organizations, depend on various processes, tools and its people for delivering solutions to their clients. There are myriad steps from requirements handover and high-level solution planning to staffing, process mobilization, etc. leading to development or implementation phases, followed by different types of testing and quality assurance steps and deployment. Thus coding and development activities are only a part of the overall chain of delivery which individually have a lot of different stakeholders and activities. Thus ‘Delivery’ is a super set of ‘Development’ in this context. While Agile Development is a relatively well known term to individuals and open source communities, ‘Agile Delivery’ is something that is specific to large projects being delivered by large and typically globally distributed organizations. It is
Fig. 1.
The Contextual Collaboration Approach
in this context that many facets apart from just the artefact development or coding, become important when one thinks of collaborations among teams. Like the development environment, where different tools and repositories can be source of events that trigger collaboration, the process related progress, updates, and uploads themselves become a source of events. Typically, we have seen three vehicles for collaboration among Agile delivery teams. The first one is the use of organization-wise instant messaging systems which allow for impromptu chats or calls among available team members. This approach is non-persistent and adhoc in nature and is ineffective if the teams are in non-overlapping time zones. The second approach is use of emails - this approach lends itself well to non-overlapping time zones, and can be richer and persistent than chat messages, as related documents or links can be manually embedded in emails. But this is again highly un-organized, adhoc and difficult to keep track of. The third approach is to use features in Agile development tools wherein some tools like Rally [2] and JIRA [3], provide persistent feeds or bulletin board or wikis with respect to individual user stories being developed through the tool. This is a better approach when all teams are part of the same tool and allows for an organized way to collaborate on the coding tasks. However there is little or no automation here as well and this approach can’t be used when the context for collaboration is the process itself rather than coding tasks (which are a subset of the process activities). The study in [4] shows that distributed teams may experiences delays due to lower frequency of communication, lack of understanding what distant colleagues are working on, and difficulty in exchanging information. This can be a huge detriment to distributed Agile delivery and hence the motivation for this work. The study presented in [5] presents an interesting perspective wherein it is apparent that ability for agile practices to be used by large-scale teams may be a limiting factor for its adoption in a large organization like Microsoft. When Agile teams are globally distributed challenges involving geographical, temporal, socio-cultural differences emerge and sharing context becomes important [6]. Papers like [7] look at task allocation and task prioritization based on skills, workflow, artifact dependencies, etc. and therefore considers ‘Context’ in Agile development. The work in [8] is of similar nature. Further, the work in [9] featured channels of interactive chat,
notifications of events to create awareness, however, the notion of context was not explicitly supported. The authors present Codebook in [10] which looks as inter-team coordination and awareness based on data regarding source code level events and messages. The work in [11] establishes that context is not just a state, but a part of interactions in a collaborative environment. The building of trust through dissemination of information and context from the development environment has been noted in [12]. Motivated by such work in this area, we decided to look into a practical approach which will gather context from the environment - both from the developmental and process layers, and then using a rule based approach, identify key events that should initiate a collaboration among team members. We describe our approach next. III.
O UR APPROACH FOR C ONTEXTUAL C OLLABORATION
While Agile software development tools allow for some amount of collaboration based upon artefacts being developed, in most cases it lacks any context and automation. Our approach is based on integrating the three dimensions of Role, Context, and Activity in any Agile delivery project. Roles are typical Agile Roles like Scrum Master or Product Owner along with the standard delivery project roles. Activity refers to any of the stages in a typical Agile methodology. Context refers to the set of events and associated attributes and information. Our automated approach treats the process events and updates as a first class entities and basis for triggering collaboration along with auto-captured context from the development environment. For example, a Scrum Master (Role) while performing Sprint Management (Activity) will be interested if there is a Release plan uploaded and who upload it and when (all part of Context). An overview of our contextual collaboration approach is as shown in Figure 1. Here the Event Analyzer monitors data coming from Agile development tools as well as the Agile Process governance asset and utilizes the Agile project related information (which contains role related information for example) to monitor important events. Based on a configurable set of rules, it combines development tool level events with process steps or activities with which they would be associated. Then the Contextual collaboration engine then decides what kind of
notifications individuals receive based on those events and the actionable links in those notification messages. At an abstract level there can be two types of events that could need attention and therefore may be important for collaboration. As we shown with a few examples in Figure 2, events can be process centric, or metric or trend centric. In the former case, the nature of events is more or less instantaneous, while in the latter case, some temporal analysis is needed to ”‘generate”’ the event. There can however be any number of combinations of these two broad classes. The Event analyzer rules are based on combining process and/or metric data and utilizes rules that are of the form: “Subrule AND Subrule ... THEN EventName”, where a Subrule is simply “ ”. An example is “Unit-Test-Coverage is equal-to NULL AND Days-Left-In-Sprint is less-than 3 THEN UnitTestingSkipped”, which looks for a pattern in development data wherein the Sprint is going to end soon, but there has been no Unit testing of the code. These rules are customized for individual projects but we propose to bootstrap the approach with a minimal set of common rules. Note that the event could be as simple as a Process step marked done or a file upload to be complete. Further, Each EventName is associated with at least one activity from the process. For some events related to the process this is automatic, while for events coming from development tools this has to be associated manually. This allows for the event to be used for contextual collaboration in the correct place in the process. The Event Analyzer thus can result in an event with different attributes and this forms an input for the Contextual Collaboration Engine (CCE). The CCE again depends on rules which have the following structure: •
Event
•
Activity
•
Activity Msg
•
Role 1 MyContext Msg
•
Role 2 MyContext Msg
•
...
All the rules with the matching events will fire and result in populating certain Activity Contexts as well as Role specific MyContexts. The message posted may also contain an Action Link if needed. The Contextual Collaboration is triggered as specific roles receive customized messages for each event with an Action Link in their MyContext panes. These messages are tailored for the actions that individuals in those roles can perform. For example, if milestone planning is not complete even as the Sprints approach, the Project Manager receives the message with a Link to the milestone plan page, the Scrum Master receives the information only, and the developer does not receive any message regarding this. At the same time, as both the Project Manager and Scrum Master has access (and roles to play) in the Milestone planning activity, the collaboration is triggered among them in the collaboration pane of that activity. Note that messages regarding certain events reach only certain
Fig. 2.
Event Types
relevant Activity Contexts and thereon everyone who is part of that Activity will be able to collaborate on the same. This approach thus allows relevant stakeholders to collaborate on an event based on their roles and the context of the event and at the same point of time, others are not affected or overloaded with irrelevant collaboration feeds. This is specially important in Agile delivery wherein working versions of the software have to be given out every 3 to 4 weeks, as it allows for quickly and automatically bubbling up relevant events which require collaboration among certain team members which otherwise may not have this awareness or such an opportunity because they might not be collocated. At the same point of time, such distributed team members need not be distracted by lots of noise in the collaboration channel, which otherwise ensues. IV.
A N IMPLEMENTATION OF THE APPROACH IN AGILE W ORKBENCH
We have begun implementing our contextual collaboration approach in an in-house asset call the Agile Workbench. The Agile workbench is a single-window to quickly bootstrap Digital delivery projects using organization-specific methods, metrics and dashboards, intelligent tools, contextual collaboration, and gamification approaches. This is being piloted and it itself has been built (and continues to be extended) in an Agile manner. We have tried to include contextual collaboration is a seamless manner in the Agile Workbench. As soon as a team member logs in, (s)he sees the MyContext on the right hand corner of the process dashboard. As Figure 3 shows, this is a persistent feed of all the messages relevant to her as well as contains the links to perform a relevant action as well as to the Activity Context where the collaboration regarding the said message has been initiated. Upon going to that requisite Activity, (s)he sees the Activity context window on the right (called Buzz), where any further messages can be posted to collaborate with all other relevant team members. This window in our current implementation allows one to tag a message as an Update, request for Help or as Urgent. This is shown in Figure 4 The links that we can embed range from pages that display drill down information regarding the process or metrics (for e.g. Burn down charts) to specific actionable sections of the Workbench (for e.g. Milestone Planning page). In future, we
ACKNOWLEDGMENT The authors will like to thank Garima Mahajan and the development team at Accenture Technology Labs India for developing parts of the prototype implementation. R EFERENCES
Fig. 3.
MyContext in Agile Workbench
Fig. 4.
ActivityContext in Agile Workbench
plan to also include links to development repositories or to tools in the Agile delivery environment. V.
C ONCLUSION AND F UTURE W ORK
In this paper, we described an approach and implementation of contextual collaboration for Distributed Agile delivery. Conceptually ‘distributed’ and ‘agile’ look contradictory. The reduction in quality of team awareness due to a distributed team is a major challenge faced by large Agile projects. Our approach is based on extracting context from the Agile process and activities and then using that to generate specific collaboration feeds. Role-specific context ensures that only relevant information is shown to different stakeholders, thereby increasing the usefulness of information and potential to trigger an action. Currently, the implementation is being piloted in large industrial projects. While the qualitative feedback is encouraging, in the future we will measure the efficacy of introducing our implementation in these projects. Note that our approach is not tied to any specific development tools and is being piloted in projects which use disparate tools. Further, while today we bootstrap the Workbench with a common set of rules based on our discussions with various projects, we are working on a domain specific language for helping project managers, scrum masters etc. define the collaboration and event rules in an English-like language. This will ease the configuration of our implementation for project-specific situations.
[1] “Jira agile — atlassian,” https://www.atlassian.com/software/jira/agile. [2] H. Smits and G. Pshigoda, “Implementing scrum in a distributed software development organization,” in Agile Conference (AGILE), 2007, Aug 2007, pp. 371–375. [3] “Manifesto for agile software development,” http://agilemanifesto.org/. [4] J. D. Herbsleb and A. Mockus, “An empirical study of speed and communication in globally distributed software development,” IEEE Trans. Softw. Eng., vol. 29, no. 6, pp. 481–494, Jun. 2003. [Online]. Available: http://dx.doi.org/10.1109/TSE.2003.1205177 [5] B. Murphy, C. Bird, T. Zimmermann, L. Williams, N. Nagappan, and A. Begel, “Have agile techniques been the silver bullet for software development at microsoft?” in Empirical Software Engineering and Measurement, 2013 ACM / IEEE International Symposium on, Oct 2013, pp. 75–84. [6] E. Hossain, P. L. Bannerman, and R. Jeffery, “Towards an understanding of tailoring scrum in global software development: A multi-case study,” in Proceedings of the 2011 International Conference on Software and Systems Process, ser. ICSSP ’11. New York, NY, USA: ACM, 2011, pp. 110–119. [Online]. Available: http://doi.acm.org/10.1145/1987875.1987894 [7] D. Mak and P. Kruchten, “Nextmove: A framework for distributed task coordination,” in Software Engineering Conference, 2007. ASWEC 2007. 18th Australian, 2007, pp. 399–408. [Online]. Available: http://ieeexplore.ieee.org/xpl/freeabs all.jsp?isnumber=4159640&arnumber=4159692&count=53&index=51 [8] J. Lin, “Context-aware task allocation for distributed agile team,” in Automated Software Engineering (ASE), 2013 IEEE/ACM 28th International Conference on, Nov 2013, pp. 758–761. [9] G. Fitzpatrick, S. Kaplan, T. Mansfield, D. Arnold, and B. Segall, “Supporting public availability and accessibility with elvin: Experiences and reflections,” Computer Supported Cooperative Work (CSCW), vol. 11, no. 3-4, pp. 447–474, 2002. [Online]. Available: http: //dx.doi.org/10.1023/A%3A1021226206564 [10] A. Begel, Y. P. Khoo, and T. Zimmermann, “Codebook: discovering and exploiting relationships in software repositories,” in Software Engineering, 2010 ACM/IEEE 32nd International Conference on, vol. 1, May 2010, pp. 125–134. [11] J. Coutaz, J. L. Crowley, S. Dobson, and D. Garlan, “Context is key,” Commun. ACM, vol. 48, no. 3, pp. 49–53, Mar. 2005. [Online]. Available: http://doi.acm.org/10.1145/1047671.1047703 [12] S. Marczak, B. Al-Ani, D. Redmiles, and R. Prikladnicki, “Designing tools to support trust in distributed software teams,” Workshop on Trust in Virtual Teams, Feb 2013.
