Like the discovery phase, the development phase also unfolded through iterative interactions between the two organisations. The development team had short daily conference calls to discuss the requirements they had
completed during the previous day, as well as upcoming work and pending issues. The Escapade manager was also present for these meetings, as well as other meetings where the requirements were prioritised or the past sprint was analysed. The Escapade product owner was satisfied with the communication channels:
There are many forms of communication that we have. In terms of running with our general Scrumban type of methodology, we have our daily stand ups, we have prioritising every week, we have retros{spective meetings}. In addition we communicate normally via an online chat tool. We find it is fantastic for what we do. Especially keen on the fact that all the developers, external developer team is located all over the world.
Figure 9. An Example View of the Chat Tool (source: flowdock.com)
The chat tool and the backlog tool were complementary to each other. The chat tool facilitated online discussions between the two organisations, as well as between the developers and designers internally. The discussion with the customers revolved around the requirements in the backlog tool. A manager from Escapade explained the relationships between the backlog tool and the chat tool:
We communicate normally via an online chat tool. The way that we communicate is through threads and we find it is fantastic for what we do... In fact it is more efficient than getting updates in meetings and all that sort of thing…[The backlog tool] is for our backlog management and our general priorities management as well. But we do put communication into [the chat tool] because it is just easier to reference to a feature than within [the backlog tool].
An example view of the chat tool is presented in Figure 9 and the backlog tool applied in the project is presented in
Figure 10.
Figure 10. An Example View of the Backlog Tool (source: pivotaltracker.com)
At the end of each week, the Carmine development team released a new functional version of the system. The customer then reviewed it and provided feedback to the vendor using a more refined version of feedback notes used in the discovery phase: a testing spreadsheet which all the testers had access to and which recorded their feedback. The requirements were then updated based on the customer feedback. In addition to the daily and weekly cycles, monthly iterations consisted of reorganising the larger contours of the project, such as the priorities of wider scope requirements, according to the customer feedback.
From the customer perspective, one of the main milestones was the point when the functioning system itself replaced the wireframes as the main communicative point of reference between the parties. Because the system was updated and released weekly, each new version captured customer feedback more faithfully and accurately than the previous versions. The released versions of the system quickly surpassed the wireframes as a representation of the desired system. Consequently, the wireframes became obsolete and were no longer used as a reference point. The visual designs, on the other hand, were merged with the system and were no longer treated as a separate artefact but an integral part of the system.
During the time I was conducting the first round of interviews, Carmine had just released a version of the product that had most of the functionalities. The Escapade product owner called this the ‘beta release’. The Escapade product management had organised a group of testers who were now digging into the product in search of defects.
Some of these testers had already been involved in the discovery phase and they had seen the product evolve from the wireframes into the functional system they were now testing. A project sponsor from Escapade explained how they were able to follow the development by accessing the product itself:
So it went from the wireframes to a sort of mock up. Then the guys were just building features and then from there, as soon as there was something to show us, we could dib in and dib out and test and have a look and see what is being developed.
Figure 11. The Landing Page of the First Release of the Product
Figure 11 illustrates the landing page of the product during a latter phase of the development. This version was
much more complete in features and functionality than the black and white wireframe.
The product owner had set up an online spreadsheet for the testers, where they could easily log the testing results. The backlog tool could have been applied for testing purposes but a spreadsheet was selected because it was more familiar to the testers, most of whom were not part of the Escapade internal development team. During and after the testing of the beta release, the defects found, emerging ideas, usability improvements and technical specifications continued to bring about further changes. The requirement updates were stored in the backlog tool, which also contained the status of existing and future features. The vendor manager described the constant process of the requirements update, which was actioned via the backlog tool:
If the customer finds a bug, they [the product owner on behalf of the testers] will create a ticket, a bug ticket, in backlog tool. And then that ticket will get assigned to somebody. Our scrum master will assign it, usually based on who was responsible for that piece of functionality. Then that developer will work through that bug. The bug fix is
delivered the same way as a regular piece of functionality. Our customer will get notified when the fix or functionality will be ready for acceptance testing. The Escapade product owner can log in and check the fix or feature. And they can also involve the other testing team people. This communication process is not just for bugs but also feature changes. The product owner can request new features in the backlog tool. And they can have a quick look at it and say if we hit the mark or not with the feature.
A significant part of the development effort was the process of continuous delivery and continuous integration. The code was developed in the development environments and when completed, pushed to the production environment. This process required there to be environments capable of handling the process and monitoring tools that reported any code issues. The development team and the DevOps from Escapade were the main custodians of the environments, but the product owner also had access to the environments and the monitoring tools. He explained why it was important to monitor the status of the systems and react to anomalies:
All that sort of thing is really important, not just for the developers, but for me to understand as well. I’m across what needs to be prioritised in the backlogs and what needs to be pushed ahead because if it’s affecting too many clients, we need to make sure that we’re moving quickly on those sorts of things.
During the first round of interviews, I enquired from Escapade managers what they thought might be the future issues, after the project would be in the stage of a minimum viable product. There were multiple predictions and ideas of where the project would go next, which made me curious to continue with the case. I decided to re-engage with the project a few months later and study what had happened in the time between the interviews. The next section tells what happened after the release of the beta version and the minimum viable product release.