Managing Regulatory Publishing Projects Using Agile

Email this to someonePrint this pageShare on LinkedIn0Tweet about this on TwitterShare on Google+0

The following post is the fourth of six in GlobalSubmit’s Agile for Regulatory Submissions series. GlobalSubmit’s regulatory services team employs the Agile Methodology for submission projects. By instituting Agile principles, our team has been very successful in delivering high-quality submissions ahead of schedule while maintaining constant, clear lines of communication with sponsors. To date, 75% of the regulatory submission projects executed by GlobalSubmit have been completed ahead of schedule.

The content used in our Agile for Regulatory Submissions series is adapted from the original work of Ken Schwaber and Jeff Sutherland called the Scrum Guide under the Attribution Share-Alike license of Creative Commons. Our series, which differs from the original work in the industry it describes, end product of the Agile process and professionals involved in producing the end product, is available for license under the identical terms.

When following the Agile Methodology for Regulatory Submissions, events are used to create regularity and to minimize the need for meetings outside of the methodology. All events are time-boxed, meaning every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events, such as Daily Stand Up Meetings, may end early if they have achieved their purpose, but cannot run over the allotted time. Such an approach ensures that an appropriate time is spent without introducing wasted effort into the process.

Other than the Sprint itself, which is a container for all other events, each event in Agile is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events sacrifices transparency and is a lost opportunity to inspect and adapt.

The Sprint

At the heart of the Agile Methodology for Regulatory Submissions is a Sprint, a time box of one month or less during which one or more “done” submission deliverables are approved and ready to be submitted. A new Sprint starts immediately after the conclusion of the previous Sprint, and as a rule sprints have consistent durations throughout a publishing project.

A Sprint is made up of Sprint Planning, Daily Stand Ups, the publishing work, the Sprint Review and the Sprint Retrospective.

During the Sprint:

  • No changes that endanger the Sprint goal are made
  • Quality standards are not lowered
  • Scope may be clarified and renegotiated between the Submission Owner and Publishing Team as more is learned

Consider each Sprint as a project with no more than a one-month horizon. Like projects, Sprints are designed to accomplish something. Each Sprint defines what is to be published, a flexible plan guide publishing the deliverable, the work itself, and the resulting submission.

Sprints are no more than one calendar month and can be shorter. When a Sprint’s horizon extends beyond one month, the definition of what is being published may change, complexity may rise, and risk may increase. A Sprint promotes predictability by making room for inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limited financial risk to one calendar month.

Cancelling a Sprint

A Sprint can be cancelled before the set time period of one month or less runs out. The authority to cancel the Sprint rests exclusively with the Submission Owner, although he or she may do so at the behest of stakeholders, the Publishing Team, or the Submission Coordinator.

If the Sprint Goal becomes obsolete, for example, the sponsor company withdraws its application, a Sprint would be cancelled. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. However, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any published documents with a status of “done” are reviewed. If work is partially complete, the Submission Owner typically accepts it. All incomplete published documents are re-estimated and the status is altered in the Submission Tracker.

Sprint cancellations consume resources. Everyone on the team must regroup and engage in Sprint Planning to start another Sprint. Sprint cancellations can be very detrimental to the Agile Team and are very uncommon.

Sprint Planning

A Sprint Planning session is used to determine the work that will be performed and a collaborative effort involving the entire Agile Team.

A maximum allotment of one hour for every one week of Sprint, e.g., a 4-week Sprint would have a 4-hour planning session. The Submission Coordinator is responsible for the planning session and that those in attendance understand the purpose of the meeting. The Submission Coordinator directs the Agile Team to staying within the prescribed time limit.

Sprint planning answers the following questions:

  • What can be delivered in the submission increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the Submission Increment be achieved?

What Can Be Done in this Sprint?

The Publishing Team forecasts the documents (section, studies, etc.) that will be published and delivered during the Sprint. The Submission Owner discusses the Sprint objectives the team intends to achieve. The objectives include publishing documents and updating the status of those documents in the Submission Tracker, which if completed during the Sprint, would achieve the Sprint Goal. The entire Agile Team collaborates on understanding the work of the Sprint.

The input to this meeting is the Submission Backlog, Submission Tracker, Issue Log, the latest submission, projected capacity of the Publishing Team during the Sprint, and past performance of the Publishing Team. The number of deliverables selected from the submission backlog for the Sprint is solely up to the Publishing Team. Only the Publishing Team can assess what it can accomplish over the upcoming Sprint.

After the Publishing Team forecasts the documents it will publish in the Sprint, the Agile Team determines a Sprint Goal. The Sprint Goal is the documents that will be published in the Sprint and updated in the Submission Tracker.

How Will the Chosen Work Get Done?

Having set the Sprint Goal and selected the documents to publish from the submission tracker for the Sprint, the Publishing Team then decides how it will publish these documents so that they are considered “done” by the end of the Sprint. The documents to be published from the submission tracker selected for this Sprint, the issues to be resolved from the Issue Log, plus the plan for delivering them is called the Sprint Backlog.

The Publishing Team typically starts by filling out the sprint backlog with documents the need to be published. Work may vary by size or estimated effort. However, enough work is planned so that the Publishing Team is able to forecast what can be done in the upcoming Sprint. Work planned for the first days of the Sprint by the Publishing Team is often broken down into units of one day or less by the end of the Sprint Planning meeting. The Publishing Team then self organizes to undertake the work in the Sprint Backlog, both during the planning meeting and as needed throughout the Sprint.

The Submission Owner can help to clarify the like documents, studies and sections in the Submission Tracker and make trade-offs. The Submission Owner should try to complete sections or studies, if possible. If the Publishing Team determines it has too much or too little work, it may renegotiate the deliverables to be published with the Submission Owner. The Publishing Team may also invite other people to attend in order to provide domain advice.

By the end of the Sprint Planning session, the Publishing Team should be able to explain to the Submission Owner and Submission Coordinator how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Submission Increment.

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met. A goal might be a complete study or a focus on certain types of documents. The Sprint Goal is created during the Sprint Planning meeting. The Sprint Goal gives the Publishing Team some flexibility regarding the documents to be published during the Sprint.

As the Publishing Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, the team publishes the selected documents. If the work turns out to be different than expected, they collaborate with the Submission Owner to negotiate the scope of Sprint Backlog while the Sprint is in progress.

Daily Stand Up Meeting

A Daily Stand Up Meeting involving members of the Agile Team is limited to 15 minutes. The purpose of the meeting is to synchronize activities and create a plan for the next 24 hours by inspecting what is forecast for that time period and what was accomplished in the previous 24 hours. The meeting is held at the same time and place each day to reduce complexity. Publishing Team members explain the following during the meeting:

  • What did I do yesterday that helped the Publishing Team meet the Sprint Goal?
  • What will I do today to help the Publishing Team meet the Sprint Goal?
  • Are there impediments preventing me or the Publishing Team from meeting the Sprint Goal?

The Publishing Team uses the Daily Stand Up Meeting to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint. The 15-minute, daily meeting optimizes the probability that the Publishing Team will meet the Sprint Goal. Every day, the Publishing Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Submission Increment by the end of the Sprint. The Publishing Team or team members often hold more specialized meetings immediately after the scheduled daily meeting for more detailed discussions, or to adapt, or re-plan, the rest of the Sprint’s work.

The Submission Coordinator facilitates the meeting, but the Publishing Team is ultimately responsible for conducting the daily stand up. The Submission Coordinator coaches the Publishing Team members on useful techniques for staying within the 15-minute time limit.

The Submission Coordinator also enforces the rule that only Publishing Team members participate in the Daily Stand Up Meeting.

Daily Stand Up Meetings improve communications, eliminate other meetings, identify impediments to publishing that must be addressed, highlight and promote quick decision making, and improve the Publishing Team’s level of knowledge. This Daily Stand Up Meeting is vital for inspecting and adapting, two of the core principles of Agile for Regulatory Submissions.

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Submission Increment and review the Submission Backlog, Submission Tracker and Issue Log to determine the status of the submission. During the Sprint Review, the Agile Team and stakeholders discuss what was done in the Sprint.

Based on that discussion and any changes made to the submission tracker during the Sprint, attendees determine on the next steps that could be taken to deliver the submission with high quality with the least amount of effort. This is an informal meeting, not a status meeting, and the presentation of the Submission Increment is intended to elicit feedback and foster collaboration.

A half hour is allotted per one week of Sprint. For example, a two-week Sprint calls for a one-hour Sprint Review. The Submission Coordinator facilitates the event and briefs the attendees on its purpose, as well as advises team members on staying within the time limit.

Here are a number of guidelines for the Sprint Review:

  • Attendees include the entire Agile Team and key stakeholders as invited by the Submission Owner
  • The Submission Owner explains what deliverables have achieved a status of “done” as well as the deliverables that are “not” done
  • The Publishing Team discusses what went well during the Sprint, what problems surfaced, and how those problems were solved
  • The Publishing Team demonstrates the work that has achieved a status of “done” and answers questions about the Submission Increment
  • The Submission Owner discuss the Submission Tracker as it stands and projects likely completion dates based on progress to date (if needed) and document production
  • The entire group collaborates on next steps so that the Sprint Review provides valuable input to subsequent Sprint Planning sessions

The Submission Tracker may be adjusted based on new studies that were ordered and other documents that will be delivered.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Agile Team to take stock of itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning session. As was the case for the Sprint Review, a half hour is allotted per one week of Sprint. The Submission Coordinator facilitates the event and briefs the attendees on its purpose, as well as advises team members on staying within the time limit. The Submission Coordinator participates as a peer team member in the meeting as her or she oversees and guides the Agile process.

The purpose of the Sprint Retrospective is to:

  • Inspect how the latest Sprint went with regard to people, relationships, process, and tools
  • Identify and order the major items that went well and potential improvements
  • Create a plan for implementing improvements to how the Agile Team does its work

The Submission Coordinator encourages the Agile Team to improve, within the Agile for Regulatory Submissions framework, its publishing process and practices that will make the next Sprint more effective and enjoyable. During each Sprint Retrospective, the Agile team plans ways to increase quality by adapting the definition of “done” as appropriate.

By the end of the Sprint Retrospective, the Agile Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Agile team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

©2015 GlobalSubmit. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Agile for Regulatory Submissions content, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Author: Jason Rock

Jason Rock is a pioneer in the field of electronic submissions. Mr. Rock has an extensive background working with global life sciences companies and regulatory agencies to promote eCTD adoption through the development of advanced applications. The commercial software Mr. Rock originally developed, and continues to improve, in his role as Chief Technical Officer for GlobalSubmit, is used exclusively by the U.S. Food & Drug Administration to review and validate all eCTD submissions the FDA receives.

Share This Post On

Submit a Comment