In order to remain flexible during this large project we chose the agile development process in which we had development cycles (=sprints) of two weeks each. Each cycle consisted of 3 phases and at the end of each cycle a predefined set of features got delivered.
At the start of a development cycle the list of requirements that are not implemented yet (= backlog) is inspected together with the product owners to prioritise the features. Based on this prioritised list the development team picks a number of features that they will implement over the next 2 weeks. The importance of this recurrent exercise should not be underestimated. Large software projects are in no way static in our experience. A few months into the project we realised some of the items in the backlog were no longer high priority or were much more expensive to implement then initially estimated. This allowed us to restructure the backlog in a timely manner.
The second phase is the actual development process in which the developers work on the features. As features are sometimes not as clear to a developer as the project manager thinks and because additional questions sometimes arise during development, it is important that the project manager and a product owner are available for questions. In our experience, and especially when working remotely, it is best to schedule moments on which developers can pose questions to ensure everything is clear to the developers. A popular way of doing this is to have daily stand-up meetings. we noticed that daily is a bit too frequent as we want to avoid interrupting the developers too often. Therefore, we schedule such a meeting 3 times per week at fixed times.
The third phase encompasses the delivery and user testing of the developed features. Delivery is done during a delivery meeting in which the developers demo the features to the steering group and the key users. If the demo is accepted by the steering group and the key users, the features are made available to the key users so they can test them themselves. In order to facilitate this process of regularly delivering features to the key users during the development phase, a continuous deployment process is used. In our case this means that developers directly deploy a feature when they are done developing it. This process is highly automated. It will check the new feature code for consistency and breaking changes. If the feature passes, it becomes available. To ensure the feature meets quality standards, it is made available in a development environment first so it can be manually tested by our QA officer and demoed before making it available to the key users and, later on, in production. This is vital to our development approach as it enables key users to test new features as soon as they are available, enabling them to request changes or additions early on in the development phase. In our experience, having this process in place is particularly beneficial during follow-up projects as it is able to kickstart such project by having an easy way to check and deploy new code, even if developers do not recall how the original code functions exactly.
When managing large-scale projects, you often find yourself juggling expectations of different stakeholders while trying to keep the project on track in terms of time and budget, even when expectations change over time.
The first step in managing expectations is knowing what the expectations are. Usually, people will tell you what they want to be able to do but often people don’t tell you why they want to do it. While a list of things that people want looks great on paper, this might not be the same as what they need. Making sure you also capture the why enables you to better think along with the users and find out their actual needs. A common pitfall is to simply check off a deliverable from the backlog when the users indicate that “it works as expected” without critically critically assessing the work done by your own team. The need for doing this became clear during the project early on when validating the user interface. While the users were happy with the progress and how it got implemented, we realised this was a suboptimal solution because the data they would be working with in real life would be more complex than portrayed in the use cases that were gathered. Even though it would set the project a bit back as the UI would need to be reworked, we proposed an alternative and pointed these issues out. When the stakeholders realised the alternative would indeed be much better in real live, this was added to the next sprint and the results were greatly appreciated.
One example of changing expectations was that during the project, another company-wide campaign set out to move security to the left and incorporate security earlier in the development process. This also included the mandatory use of new tools such as Snyk in the development process. The impact of this on the project was significant as the deployment process needed to be reworked completely, with no examples from other projects available as this was one of the first projects that set out to completely adhere to the new standards. Facing this reality, decisions had to be made in terms of scope and/or timelines. As this system was part of a larger effort to update the data source systems, a delay would push all of this back and as such was no option. This meant the scope needed to be reduced and some features would not be delivered in the first version of the application. This is where the agile approach pays off. Using our prioritised and up to date backlog we asked the steering group and some key users what features they could do without and for which a workaround could work in a first phase. As the users already had hands-on experience with the application, it was easier for them to imagine and suggest workarounds for some features that were on the backlog. Doing so we postponed some features to a follow-up project to keep the timelines realistic.
The project we ran with UCB over the course of more than a year was viewed as a success as the end result was user friendly and catered to the user’s specific needs. We believe that is the case because we did not set out to simply fulfil the list of requirements that was gathered at the start of the project. We use methodologies that allow stakeholders to remain in control and able to change the course of the project during the entire development phase. While this way of managing a project is not always easy and sometimes tough decisions need to be made, in our experience it is the best way to create high quality software that is broadly supported by users and stakeholders as they are at the center of this approach.