My life as a Scrum Master: lessons to be learned from experience in the field

Project scoping: an essential step 

Prior to commencement of the project, the scoping stage enabled the seven participants, including the client, a neophyte, to better understand agility and, above all, scope the budget and time frame.  The following were carried out before the eight planned sprints: 

• A two-day agility training session for all those involved. It helped the Product Owner, members of the Information Systems Department and key users to understand the agile state of mind and the collaborative approach we would be adopting, including each person's role. 
• Several days of workshops addressing the vision, personas and story mapping were conducted to align everybody with the product aims and start building the Product Backlog. These workshops were attended by the Product Owner, the Proxy Product Owner, key users, the Information Systems Department representative, a UX designer and a developer. The presence of the latter two enabled them to gain a lot of information, build a UX Map and discuss technical issues and questions that were already visible. 

The crucial 'Sprint 0' or project preparation stage 

Agility requires proper preparation – known as 'Sprint 0' – before the sprints themselves. In addition to a list of actions to be carried out, this sprint brought to light a number of positive points that later enabled successful completion of the project.   

Carrying out several POCs

The project included several risky technical points: 

• Health data hosting servers: because health data is sensitive, we had to work with servers providing specific features (including limited access, data encryption and separation of data); 
• Connection of the application to our company's Outlook calendar, based on the client's need for its business teams to be able to modify entries in our consultants' diaries; 
• A full redesign of our client's showcase website. 

In order to try to limit risks, and above all to avoid committing ourselves without knowing exactly what they involved, we carried out POCs for the first two points. These POCs enabled us to: 

• Establish the basic source code for the project in advance; 
• Check correct functioning with the Information Systems Department; 
• Level up skills in the development team. 

Concerning the showcase website, it just so happened that SQLI had recently fully redesigned the client's corporate website. We therefore looked at the possibility of reusing its technical basis, while adapting it to our needs: in doing so, we were able to save time and money for the project's "application" dimension.   

Setting up environments 

Managing technical environments always consumes a lot of time and money, during both the setting-up and long-term maintenance phases. We therefore decided to first set up a fully operational integration and development environment, available from the first sprint, which gave us visibility for the deployment of subsequent sprints.   

Creation of an initial user story

The importance of the first US (user story), to be completed during Sprint 0, was demonstrated by this project. Based on a very simple US, we became aware of certain deployment issues related to our environments (including access rights to servers and product packaging). Without this first US, we would have been unable to deliver a single US in Sprint 1, so don't hesitate to do one!   

Scrum-inspired team organisation

The team came up with an organisation based on the Scrum spirit. It was formed of the following (with time allocated to the project for each role, as this was crucial for the project's success): 

• A Product Owner (PO) on the client side, with 25% of their time allocated to the project; 
• A Proxy Product Owner (PPO), with 100% of their time allocated to the project; 
• A UX designer, with a set number of days allocated to the project; 
• Three developers, including two full-time and one at 80%; 
• A Scrum Master/Agile Coach working part-time. 

Contribution of the Information Systems Department to the project

We were lucky enough to work with an Information Systems Department that understood the importance of working without an intermediary in agile projects, which enabled us to work directly with the business teams. Often, our "business representative" (the PO) is somebody from IT who acts as an interface between the project team and business teams. In this case, the Information Systems Department provided us with support in technical areas when required, while the project PO was a person directly involved in business operations.   

The PO's role: fully engaged and full-time! 

In my view, the PO's role is often underestimated in Agile. And yet this is the person who owns the product and defines what it will look like. We were fortunate to have what I call a "real" PO: a person on the business side who will be using the application developed and knows the business teams, as well as where to find business-related information. Our PO carried out valuable work in the early stages to define user needs with users, scope the project in light of the vision (sometimes saying "no") and have 90% of the user story information ready for when we looked at it in more detail. We saved a lot of time by avoiding unnecessary back-and-forths and unproductive discussions.    

Integrating the UX designer

You have most likely considered the following question: 'how to integrate "specific" profiles in an agile project, such as architects, experts and the UX designer?” The crucial factor for the UX designer's role is to be involved as early on as possible and throughout the project. In our case, the UX designer was involved right from the project scoping phase (before Sprint 0), which enabled: 

• Our client to see the project's future more clearly thanks to wireframes. The client was also able to express its needs more easily through this process. 
• It was then up to our UX designer to understand the client's needs and requirements, in order to offer the best possible design and customer journey.   

During Sprint 0, the UX designer worked with us to refine the initial user stories, in order to be able to provide models as early as Sprint 1. The UX designer also defined the visual identity and main navigation elements. The UX designer's involvement varies throughout the project: at the beginning, they must provide the full UX basis, which developers can dip into for the design of new functionalities, unless a new behaviour is expected. If so, their involvement will once again be required. That said, in my view, it is important that they are present until the end of the project, in order to ensure consistency right up to delivery of the final product and avoid any drift.    

Accepting change 

The team's three developers were experienced in the technologies used. One point that had to be managed was acceptance of the changes, following user feedback or analysis of the user stories. The use of iteration for a screen and/or functionality, as well as creating a simple solution before the end solution, were not well understood. It was crucial to explain that the aim was for users to be able to look ahead to the future functionality. This part of my job required a lot of active listening and understanding of the fears underlying these reactions, in order to help them find the best solution. I tried to avoid giving them a solution, instead enabling them to find the solution that best suits their project. They rapidly saw the benefit of demonstrating functionalities and then having feedback.     

The project phase: the heart of the topic 

Scope / Cost / Time frame 

The first thing to highlight is that we managed to stay on budget and on time! As for the scope, it was adjusted as the project moved forward. Initially, the client chose only 'Must' needs, which we then refined during our story mapping. By the time the project was completed, based on the initial story mapping, we achieved 99% of the 'Musts', 79% of the 'Shoulds', 65% of the 'Coulds' and 50% of the 'Woulds' (MoSCoW method) with the same budget. "How is this possible?" I hear you ask.    Here are the success factors: 

• A stable team working full-time throughout the project; 
• The experience of the developers to always put forward the solution most suited to the need (and often the simplest); 
• Reuse of the technical foundation of another website belonging to the client, which provided us with resources to meet business needs; 
• A full-time PO, who was fully committed, had decision-making power and knew how to say "no"; 
• The groundwork carried out by the PO with users; 
• A clear vision shared by all, including sponsors; 
• Use of Drupal, which facilitated management of access rights for the various profiles. 

If we look at the initially described scope and the implemented scope, we can see that certain functionalities were not provided, as it transpired they were unnecessary following user feedback. Conversely, as an example, a demonstration revealed to us that the employee working at the centre's reception needed the appointment schedule every day to manage incoming volunteers, a need that had not been brought up. We added this feedback to our backlog and carried it out in the following sprint, as it was essential for the application to function correctly.   

The most important things first 

With an agile project, priorities should be focussed on the most important things first and not the most complicated or riskiest. We had an experience of this: an essential need expressed by users was for the application to be able to connect to their Outlook calendar, in order to read their appointments and enter new appointments made by volunteers to participate in clinical trials. We therefore focussed user stories on this area in the second sprint. Unfortunately, due to a problem related to secure access to Outlook, we were unable to implement these needs, which were pushed back to Sprint 6 (of eight). This had two consequences: 

1. We had to move forward while imagining the solution for four sprints, which was a huge change of priorities for the PO. We also had to develop alternative solutions while we waited to have the Outlook solution, in order to be able to carry out tests and have operational software. These solutions were of course later undone. 
2. Once the Outlook solution was implemented, we discovered lots of subtle points and problems regarding related functionalities, which required us to carry out a lot of tests and add user stories, in order to adjust needs to the new requirements, even though they had previously been approved by users.  

Pay attention to testing 

Another lesson that I have taken away from this project is the importance of tests. Often in agile, we neglect testing somewhat as we are developing functionalities on the fly. This is where automated tests can be very useful indeed. In our case, the acceptance criteria were taken into account in the user stories, but there was a lack of more global testing (or 'regression testing') in order to check that adding a need to the global functionality had not altered it.   We also planned tests by the business team, but these were performed at least one sprint later, due to a lack of time for some of the people involved. The result of this is that we saw some anomalies and new needs too late and had to manage them as an emergency during the last sprints. All relevant feedback was, however, taken into account. In short, particular attention should be paid to testing in general when working with the agile (or even V-model) method, while bearing in mind the phrase 'just in time and just enough'.   If I had to do it again, I would recommend the following: 

• Add automated testing for key functionalities; 
• Systematically carry out regression testing; 
• Free up time for business teams to involve them in "just-in-time" tests. 

Involving business teams  

End users were identified very early on and we insisted on their presence at the various ceremonies and tests. We added specific workshops with them in the middle of the project in order to: 

• Remind them of the importance of their role; 
• Ask them whether the way we communicate with them is satisfactory and how to improve; 
• Ask them what new needs they have identified in light of previous demonstrations. 

A high level of involvement on the part of business team members is essential for the success of a product, because, without them, we could only make "a product" and not "the right product".   

Producing specifications

I can almost hear you thinking "wait, you had specifications, so you weren't exactly working agile!" Well, actually, we were, as we did not produce the specifications prior to the user stories, to tell the development team what to do, but rather after the discussion we had when we refined the user stories. These specifications are used only for maintenance and future product upgrades.  There were two types of specifications produced during this project: 

• Technical specifications that the dev team produced throughout the project, either in the user story itself or during the N+1 sprint for user stories completed in the previous sprint. 
• Functional specifications, which I produced myself, during the last two sprints and the first two weeks of the guarantee period.  

For both types, the level of detail caused a few problems later on (late discovery of bugs and technical constraints) and I think that we should have done them more on the fly, with intermediate approvals.    

Handing over to the third-party application maintenance team 

We knew that maintenance would be required for the application from the project's outset. Unfortunately, we dealt with this topic too late, which prevented a smooth transition. The post-project stage should be managed as early on as possible, as well as knowledge transfer. The ideal solution, in my view, is to have maintenance managed directly by the initial team, which continues to carry out upgrades.    

The contract

To end on a positive note, we managed this project with a fixed-sum contract, which was not at all restrictive, for several reasons: 

• The contract was not followed to the letter in terms of scope-related commitments. As explained above, we followed user needs while bearing in mind our commitment.  
• Simplified financial monitoring on the part of SQLI, as we had the right number of days per person and per sprint for the entire project. 

• Indicators monitored were related to agility (number of user stories in the backlog/carried out, number of points in the backlog/carried out, velocity chart, burn down chart) and no commitments were made in this respect. 

To conclude, this project was a success (satisfied users, happy client, project delivered on time and on budget, and a Scrum team happy with its experience), despite a few pitfalls that helped us all grow during this project and taught us lessons for future projects.