Agile software development is a set of approaches to software development where requirements and solutions evolve through collaboration between cross-functional teams and stakeholders.
Agile encourages flexibility and rapid response to change while advocating adaptive planning, iterative development, early delivery, and continual improvement. Agile principles can be applied to other disciplines, including proposal management, to support flexible, adaptive processes that reduce waste, time, and cost.
This article explores how Agile can be applied to proposal management to increase the effectiveness of your proposal development process.
Agile proposal management is essentially Agile project management. Agile project management is a term used to describe project management that uses Agile methodologies.
This may include daily standups, collaboration with stakeholders, and continuous integration and availability of the working product (i.e., drafts between color team reviews), which have long been standard proposal best practices.
Agile proposal management follows the Scrum framework. A Scrum is comprised of short iterations, called sprints, within which work is completed iteratively. A proposal response effort is a Scrum.
Sprints are a period—typically 1 – 4 weeks long—when the Agile development team produces the next increment of the product (in our case, the proposal). Sprints are the writing and development process that occurs between each color team review. The Scrum comprises three key roles, which together make up the Scrum Team (aka, the Proposal Team):
Product Owner = Capture Manager:
This is the leader responsible for maximizing the value of the products (proposal responses) created by a Scrum/Proposal Team. The Product Owner/Capture Manager typically takes on several roles, including business strategist, product designer, market analyst, customer liaison, and project manager.
The Product Owner/Capture Manager defines the vision, manages the backlog (action items), prioritizes needs, oversees development stages, anticipates client needs, acts as a liaison between the team and stakeholders, and evaluates the progress at each iteration.
Scrum Master = Proposal Manager:
This is the leader responsible for daily stand-up meetings and tracking the overall progress of the product development. The Scrum Master/Proposal Manager makes sure the team is not blocked at any time due to external or internal issues.
They help everyone understand Scrum/proposal development theory, practices, rules, and values. They also ensure that everyone on the Scrum/Proposal Team understands the goals, scope, and product (proposal) domain.
Development Team = Proposal Development Team:
The (Proposal) Development Team is a collection of individuals working together to deliver the requested and committed product (proposal) increments. The (Proposal) Development Team as a whole is responsible for delivering the committed product sprint on time and with the defined quality. Individuals within the (Proposal) Development Team typically have specialized skills and focus; however, to optimize performance, it is best to have a balanced set of skills to deal with ever-changing challenges.
Scrum Activities
As summarized in Figure 1, Scrum involves four key activities, conducted once every sprint, with the exception of the stand-up, which is held daily:
Daily Stand-up Meeting:
The daily stand-up meeting is one of the most important activities in a Scrum-based approach. In a stand-up meeting, the Scrum/Proposal Team discusses the daily progress for a 15- to 30-minute period. A key point of Agile is the importance of keeping these meetings short and precise.
Daily stand-ups—so called because they should be so brief that you don’t need to sit down for them—have long been a best practice in the proposal development process. Too frequently, Proposal Managers allow these meetings to extend far too long—sometimes taking up more than an hour each day. This tends to waste the team’s time, which negates the purpose of the review and results in reduced productivity. Instead, items requiring more time should be tabled and scheduled for a separate meeting.
Sprint Planning Meeting:
The Sprint Planning Meeting is a collaborative effort involving the Scrum Master/Proposal Manager, who facilitates the meeting; the Product Owner/Capture Manager, who clarifies the details of the product backlog items (action items) and their respective acceptance criteria; and the Proposal (Development) Team, who help define the work and effort necessary to meet their sprint commitment. With proposals, the Capture Manager and Proposal Manager typically work with the proposal team to establish expectations on the quality of product expected during the next review.
For example, some companies may target a roughly 60% complete document at Pink Team, 85% complete document at Red Team, and 100% complete document at Gold Team (Figure 2). It is imperative that everyone on the team understands the sprint expectations, which may vary from organization to organization, and even from team to team. These meetings are critical in ensuring the team is on the same page and working toward a common goal.
Sprint Review Meeting (Color Team Review):
During this meeting, the (Proposal) Development Team provides the work product accomplished during the sprint. The (Proposal) Development Team and stakeholders review the work accomplished in the sprint (See Figure 3: Sprints Aligned with Color Team Review Cycles).
Based on the work product and any changes to the product backlog (action items) during the Sprint, attendees collaborate on the next things that the (Proposal) Development Team should do to optimize value. The presentation of the increment (proposal draft) is intended to elicit feedback and foster collaboration.
Agile stresses the collaborative nature of the sprint review meeting. However, color team reviews frequently come across as an attack on the proposal team. To better embrace Agile and improve the effectiveness of these meetings, we can increase the collaboration during these reviews, which will improve productivity and change the tone for the better.
Retrospective Meeting (Lessons Learned Meeting):
Retrospective/Lessons Learned Meetings are held at the end of each sprint. During the meeting, the team reflects on how everything went during the sprint and decides what changes they want to make in the next iteration. Often in the proposal development process, we skip this stage at the end of each sprint and save this meeting until after the final sprint.
To better embrace Agile and its commitment to continuous improvement, proposal teams should add a brief lessons learned meeting to the end of each sprint.
With Agile, success stems from iterative development, collaboration, and regular stakeholder feedback—and it’s no different with proposals. As our tried-and-true best practices have shown, iterative development, collaboration, and regular stakeholder feedback support a successful proposal development process. But there are always areas where we can improve and better embrace Agile methodologies:
This article presents just one way the Agile Scrum Framework can be aligned to our existing proposal best practices to drive adaptive planning, iterative development, early delivery, continual improvement, and reductions in waste, time, and cost.
I define an increment, definition of done, and sprint review to align with proposal best practice color draft milestones. You can define an increment, definition of done, and sprint review to align with whatever milestones make sense to you. The key is to follow the five elements of the Scrum Framework: 1) Sprint Planning, 2) Daily Stand-up, 3) Development, 4) Sprint Review, 5) Retrospective (Figure 4).
If you’re looking to integrate Agile into your existing processes, this may be an easy way to start. As you conduct your Retrospective Meetings, you may find that applying Agile in a different manner may be more effective.
That’s OK—the point of Agile is to drive flexible and adaptable processes for continuous improvement!