Remote Agile: A Digital Design Case Study
The last two decades have seen a rapid digital global development due to the ICT revolution, which is becoming more important than ever, as the world shifts towards a digital society at an increasing pace. The percentage of people using the internet for reading news and gathering information has tripled during the past decade. This demonstrates the importance of an online presence for organizations and this need is even more critical for non-profit organizations. A survey conducted by Mindshare Interactive Campaigns revealed that 62% of adults consulted an organization’s website to find out more information before making a donation, highlighting the need for non-profit organizations to dedicate time and resources to developing an online presence that demonstrates the impact of their work. This case study outlines the agile web development process adopted by Meta-Culture, a Boston based non-profit, whose team is comprised of volunteers and interns.
Harnessing the power of the gig economy
The development of a website for a non-profit organization is vastly different process, mainly due to the lack of funds and resources available. One of the key pitfalls of website development for non-profits is that although volunteers and staff may be able to put together a respectable website, they have limited knowledge about the use of interactive web tools to achieve optimised results. Meta-Culture initially hired an intern to work on website development, however, it was soon realised that the expected quality and level of professionalism could not be achieved with an intern. Thus, the decision was made to hire a professional freelancer. Hiring a freelancer allowed Meta-Culture to choose to work with a professional within its budget range.
Contrary to the orthodox notions about freelancers being unstable workers delivering similar skills at a lower quality and/or price, research has highlighted the benefits of hiring freelancers to fill specific skills gaps while eliminating any costs related to downtime. Furthermore, freelancers boost business productivity by contributing to the diversity of skills and talent within an organization. In the case of Meta-Culture, hiring a freelancer brought additional value in the form of increased flexibility and agility that was much required due to the organization being at the start up stage. This allowed Meta-Culture to eliminate the risk involved with staff growth at the early stage by adopting a variable cost labour model and reduce the risk of accumulating unsustainable labor costs.
Embracing agile methods
The website development brief outlined a loose set of guidelines that described the expected feel of the website, rather than a set of specific features to be implemented within the site. The client described that the key project requirement was that Meta-Culture had “a unique web presence, and that the final product was more than just a standard business/non-profit website in which philosophical elements were translated into visual ones”. The project requirements as described by the client pointed out that traditional project management methods, such as the waterfall method, would be inadequate to manage this project due to the need to adapt to changing requirements. Traditional methods rely on extensive planning and documentation to limit and avoid change. On the other hand, agile project management embraces change and is better suited for projects that require risk, scope and budget management as the project progresses. The core concept of agile project management is to use time and resources to deliver a working product rather than to plan and document. Due the nature of this project that required continual testing with potential users, an agile project management process was deemed suitable as traditional methods make it difficult to monitor progress, react to new knowledge and take action.
Agile project management is well-equipped to manage change as it uses short development iteration phases to split up long projects. Embracing agile project management also allowed the team to test website features and eliminate those of little value to provide a better user experience on the website. Agile project management focuses on customer value by prioritizing product features and lining up product, project and team visions to quickly and efficiently produce quality products. Although this technique resulted in a changing set of requirements, it helped ensure that the final website would provide the best user experience for the client’s target audience.
Choosing the SCRUM framework
Scrum provides a simple “inspect and adapt” framework that brings back concepts of adaptability, flexibility and productivity by focusing on the functions of team members to complete projects in a changing environment. All agile methods are suited to project management in a changing setting, with the core values and principles of most agile frameworks being similar. However, each framework approaches the problems faced during the course of the project from a different perspective. The Scrum framework is well equipped to manage projects that require pure new product development and with a strong Product Owner who has the authority to make independent product and budget decisions. The sole responsibility of the development team, as individual team members and/or the team as a whole was product development work, devoid of any resource levelling or fractional allocation across different projects.
Furthermore, as the website being developed was brand-new and not a revamp, it was expected that the team would face a significant amount of change during the course of the project. It was anticipated that user testing during various stages would reveal new information about the value that the content should provide to the target audience, as well as the various features and user experience that may be expected by users. Additionally, the business model of the website needed to be taken into consideration and there was research needed to identify existing platforms that would help Meta-Culture achieve its business goals through the website. The Scrum framework was regarded to be ideal for this project as this methodology allowed the team to quickly test assumptions, address risks, develop a better understanding of the requirements and adapt as necessary. Scrum’s iterative process sped up the learning process and minimised the risk of offering the wrong features, developing a bad user experience or employing inadequate technologies.
Building and managing a distributed SCRUM team
Agile methods were introduced as a solution to global software development projects, in which project requirements and implementation technologies were uncertain and clear specifications could not be provided to the various parties involved in the project, including outsourced members, subcontractors and partners. However, one of the biggest drawbacks in using agile for global development is the method’s heavy dependence on face-to-face communication, which is hardly ever possible in distributed projects.
The Meta-Culture website project team had members based in Boston, Lexington, and Bournemouth. Although the client was nervous using a distributed team, their primary reason for choosing to work with a global remote team was previous positive experiences working with the team members on other design projects. Working with a distributed team allowed the client to hire freelancers who suited their budget and take advantage of potentially longer working hours due to the time difference.
In order to benefit from agile practices in a distributed setting, a few modifications were made to the standard Scrum practices. Daily Scrum meetings in which team members answered the three Scrum questions (What have you finished since the last meeting? Do you have any problems? What will you finish before the next meeting?) were conducted via email to shorten or even avoid video conferences. This helped better manage the communication challenges involved with setting up meetings over different time zones. In order to overcome the obstacle of finding an adequate block of time that suited all members of the distributed team, it was decided that only the lead-developers, in this case, the Product Owner and Designer or Product Owner and Content Editor would take part in planning meetings.
In order to ensure success using agile methods, it is suggested that the rules of agile management are followed with as few changes as possible. However, agile rules exist to promote communication and feedback. Due to the communication challenges posed by the nature of a distributed team, special attention was given to feedback processes to overcome obstacles and ensure success.
SCRUM roles
The self-organizing Scrum team is usually comprised of a Product Owner, a Scrum Master and the Development Team. In this case, due to the small team size and limited budget, the roles of the Product Owner and the Scrum Master were fulfilled by the same person.
The Product Owner was responsible for overseeing the development process and ensuring that the value of the final product was maximised. Another key duty of the Product Owner was to create and manage the Product Backlog that clearly expressed the Backlog items in a transparent manner that is understood by the Development Team. The Product Owner was also accountable for the direction of the project as he had the sole authority to make project and budget decisions. As the Scrum Master, he also carried out the role of ensuring that the Scrum theory, rules and practices were understood and followed by the team. Combining the roles of Product Owner and Scrum Master resulted in effective Product Backlog management, including arranging Backlog items to maximise product value, helping the team understand the need for clear and precise Backlog items and facilitating Scrum meeting and events as necessary. As the Scrum Master, services to the Development Team involved coaching the team to function in a self-organized manner and removing any obstacles to the team’s progress.
The Development Team was comprised of professionals who worked towards creating potential usable increments of the final product at the end of each sprint. The structure of a Development Team is such that tasks are self-organized and self-managed, thus optimising overall effectiveness. The Meta-Culture Development Team consisted of the Designer/Developer, whose key role was to manage the design and development process of the website, the Content Editor whose main role was to create, edit and proof read website content, and the Creative Assistant, whose role was to assist the other team members in performing their roles by conducting any necessary research. Although the individual team members had different specialised skill sets and areas of focus, the accountability for the every iteration produced at the end of each sprint belonged to the team as a whole.
SCRUM artefacts and processes
Product Backlog: The Product Backlog was the responsibility of the Product Owner who prioritized tasks as needed, starting with the development of content which was simultaneously done alongside UI development. Although content development was prioritized, the amount of content that needed to be produced was a challenge that was addressed by prioritizing content sections during each Sprint. Product Backlog was made available to the Development Team via email.
Sprint Backlogs: As the website was built from scratch, Sprint 1 focused on the user interface and overall look of the website. Therefore, the Sprint Backlog was created and managed by the Designer in the Development Team. Basic information architecture, dummy content and version one of a navigation menu was provided by the Content Editor which was used as the basis for UI design. The Sprint Backlog prioritized tasks in order of the UI design process needed to build a Wordpress website, such as firstly selecting a suitable theme followed by choosing website colour scheme etc. Subsequent sprints focused on the content development and feature addition to the website. Sprint backlogs were created and managed on Trello.
Development/ Work Process: Development work was carried out by team members during pre-defined working hours within their time zones. It was expected that communication set-backs may occur due to the geographical distribution of team members. Therefore, work timings on certain days were synchronised to suit all team members. Team members felt that email communications were sufficient and minimal video conferencing was used.
Daily meetings: A multiple case study analysis of the use of Scrum in distributed agile development cited the use of daily scrum meetings as an important practice used by all case studies. Therefore, although there were difficulties in scheduling meetings within different time zones, daily meetings were carried out via email. Answers to the three Scrum questions were shared via email by 5pm GMT, with each team member reporting on their daily progress, their plan for the day and any obstacles they faced. These were monitored by the Scrum Master who set up and facilitated Scrum meetings if required.
Weekly Reviews: Unlike traditional methods, agile methods rely heavily on feedback to ensure that teams progress in the correct direction. In order to ensure that development moved in the right direction within each Sprint duration, weekly reviews were held between the Product Owner and the team members, to assess the direction of progress and provide feedback.
Iteration Testing: Iteration testing was not carried out after the first four Sprints. This decision was made by the Product Owner who believed that the product was still at an extremely early stage to test. Furthermore, the lack of resources restricted the number of user testing sessions that could be carried out. Therefore, these Sprints were followed by an Iteration Review where the Product Owner and Development Team reviewed the iteration and used their judgement to decide on next steps.
At the end of the 5th, 6th and 7th sprint, the potentially releasable iteration was tested with real users to collect feedback on the user experience and visual appeal of the product. Testing was conducted in Boston and notes were taken to be passed on to the Development Team for review. Iteration testing sessions were conducted with a maximum of five users, as most usability problems are detected after testing with 5 users.
Iteration Review: Following Iteration Testing, participant feedback notes were reviewed by all team members and a meeting was conducted via video conference to discuss the issues that needed to be fixed. Iteration reviews were critical in prioritizing features of the website that everyone agreed were weak, but failed to prioritize earlier. Iteration reviews ended on a note similar to daily meeting emails with team members answering the three Sprint questions about next steps.
Revised Sprint Backlog: Based on the communications of the Iteration Review, a new Sprint Backlog was created. This was maintained by the team member who was most involved with the requirements of the Sprint. For example, Sprints 1 & 2 were largely focused on the user interface and design features of the website. Therefore Sprint Backlogs were created and managed by the Designer/Developer. Backlogs for Sprints 3 & 4 were created by the Designer/Developer, but were managed by all team members, who added and removed tasks on the Trello board as necessary.
Process Review: Following the Iteration Review, the Sprint Process was reviewed with the team. Team members stated any obstacles they faced during the process. These were noted by the Scrum Master to improve upon in the next Sprint. Process Review conducted after the first Sprint revealed that team members would prefer a short Sprint as this would allow more review and testing sessions and thus help create a final product with more value. This feedback was incorporated into the process and subsequent Sprints were shortened to a two week duration. Smaller sprint durations allowed the team to maintain a stable backlog and force group checkpoints leading to solid results.
Project outcomes
The project was completed in a period of three months. A total of seven iterations were released, three were tested and the 8th iteration was finalised.
Project success was measured by two components:
Project Management Success: The successful achievement of project cost, time and quality objectives. In this case, the client considered project cost and quality to have been effectively accomplished. However, in retrospection, the Product Owner inferred that testing iterations from the first Sprint may have accelerated the process and resulted in faster completion. He reflected on the lack of understanding of the effect of a change as one of the key drawbacks of the process that resulted in a longer completion time.
Product Success: This was dependent on the effects of the project’s final product which were considered to be successful by the client.
RECOMMENDATIONS
Scrum as an agile framework is gaining popularity for use by globally distributed teams, and as demonstrated by this case study, can be successfully used by small global teams by adjusting agile practices and using strategies such as email communications and synchronised working hours to overcome the challenge of reduced communication bandwidth.
Based on the outcomes of this case study, the following recommendations are made to be implemented within globally distributed small teams to ensure successful project outcomes using Scrum:
· Ensure that team members understand and adhere to the practices of Scrum.
· Decide on convenient communication methods to allow close working with teams to ensure that they have the necessary feedback to create products of maximum value.
· Attempt to customize the method after attempting a few sprints “by the book” to better understand the processes that work for and against the Scrum Team.
· Ensure that team members are aware of the effect of a change and effectively use the Backlog to prioritize tasks.
· Long sprint durations encourage isolation. Consider shorter sprints to push group checkpoints and accelerate results.
· Scrum methods focus on the team members and leadership. Therefore, conducting at least one brief video conference session with all members early in the project will help facilitate future communications.
· Sprint reviews are critical in helping teams understand and reflect on their progress. Retrospection helps clarify problems and prioritize previously overlooked tasks.
