Agile Proposal Development: A Spotlight on Scrum

Two weeks ago, I posted an article that discussed how proposal management is in actuality project management. I pointed out how our long-standing proposal best practices are Agile, and have been Agile long before Agile was the latest industry craze. I have been so pleased with the discussion that this article has sparked.

I plan to build on some of these discussion points in a series of articles focused on how we can expand the application of Agile in our opportunity pursuit processes. Last week I discussed the role of stakeholders and explored how we can better integrate stakeholders into the business development lifecycle. This week I’ll take a look at Scrum, how our proposal best practices fit into the Scrum model, and how we can learn further from Agile ideologies to improve our proposal processes.

Scrum

A Scrum is comprised of short iterations, called sprints, within which work is completed iteratively. In my calculations, a proposal response effort in actuality 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). And following this logic, sprints are just the writing and development process that occurs between each color team review.

Scrum Roles

As we mentioned last week, the Scrum comprises three key roles, which together make up the Scrum Team (Proposal Team):

• Product Owner (Capture Manager)
• Scrum Master (Proposal Manager)
• Development Team (Proposal Development 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 point of time due to external or internal issues. He or she helps everyone understand Scrum/proposal development theory, practices, rules, and values. He or she also ensures 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

Scrum also involves four key activities, conducted once every sprint, with the exception of the daily stand-up, which is held daily:

• Daily Stand-up Meeting
• Sprint Planning Meeting
• Sprint Review Meeting (Color Team Review)
• Retrospective Meeting (Lessons Learned Meeting)

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 sit and discuss the daily progress for a 15 – 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 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.

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, proposal leadership typically works 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—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. 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 the 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.

Final Thoughts

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. Keeping stand-ups short and sweet will bring the meetings back to their original purpose and provide the proposal development team with more productive time. Encouraging more of a collaborative environment during our color team reviews can help foster a more positive morale and transform reviews into working sessions, rather than a series of monologues and attacks. And making time for regular retrospective/lessons learned meetings can help the team to increase effectiveness and efficiency by continuously learning and improving.

Written by Ashley Kayes, CP APMP

Senior Proposal Consultant, AOC Key Solutions, Inc. (KSI)

https://www.linkedin.com/in/ashley-kayes-cp-apmp-a3750413/