Using “Agile Playbook” and “Shipley” in the same sentence sounds counter-intuitive. There is nothing agile about Shipley, and Shipley has nothing to do with software development lifecycles. But here is the intrigue – taking a framework (or parts of it) that works well in one context, and applying it in a completely new context creating a new amalgamation that works even better. Stay with me!
But first off – What is “Shipley?” some might ask. It is a niche reference that is not well known outside of the government contracting industry.
“Shipley”, or Shipley Business Development Lifecycle Guide, is a 96-step-process framework organizing the phases, processes, and roles involved in developing winning business proposals. The framework, with various degrees of customization, is widely used for writing Federal bid proposals. We will skip over most of the irrelevant details and focus on the Proposal Development Phase. It goes something like this (slightly simplified here):
Steps 1-5 and 10 are relatively self-explanatory. What throws off the unenlightened (that was me 2 yrs ago) is steps 6-9 – the so-called “color reviews”. Let’s elaborate on them:
STEP 6 Pink (Team) Review – the team reviews mockups, storyboards, detailed outlines, and rough content. The objective of the review is to validate the strategy and direction before too much is invested in writing the content of the proposal.
STEP 7 Pink Recovery – the writers incorporate feedback from the review in step 6 and further elaborate on their content to create an evaluation-ready draft of the proposal.
STEP 8 Red Review – non-authors are invited to review the proposed draft simulating a government evaluator review. This step provides the internal check whether the proposal addresses the evaluation criteria as specified in the RFP, from the viewpoint of an independent evaluator (Hence why non-authors are, generally, invited to provide the fresh-eye perspective).
STEP 9 Red Recovery, White-glove and Publish – the writers incorporate the feedback from the simulated evaluation and make necessary content corrections. Copy editors and graphic designers take a final look (white glove) at the document to ensure visual appeal and consistency, correct formatting and proper grammar. The document may be reviewed one last time by the executive team (Gold Review) before being finalized and sent to the printers (or PDFed or burnt on a CD).
But how’s that related to Agile Playbooks?!
I will assume here most people reading this already have a pretty solid understanding of what Agile is (and if not – we need to talk! Seriously!). It may be worth, however, sparing a few sentences to talk about “Agile Playbooks”. It is another term that I have seen mostly used by a) big consultancies / professional services organizations or b) you guessed it – government agencies.
The various Agile Playbooks may differ somewhat, but there are a few common threads. The Playbooks are:
a document – could be in Word, PDF, HTML, or Wiki, but regardless of the format, they are published somewhere, they are referenced, updated and maintained.
they are more descriptive than prescriptive – and that is by design. In its core, Agile is an adaptive and team-driven methodology. No one gets to tell a team how they should practice Agile (though, there are scores of coaches – yours truly included – to help teams get “more Agile”).
they consist of “Plays” (Agile practice patterns tied to the Agile Manifesto and Principles) as opposed to the traditional sequential processes with defined inputs, outputs and prescribed activities in between.
they introduce new concepts (rather revolutionary and disruptive for most organizations) and they tend to raise more questioning than answer such.
When used in the context of a government agency, it is worth noting three more aspects:
The Playbook comes to replace previous, usually well-documented and authoritative SDLC (Software Development Lifecycle) processes. As such, the Playbook becomes the replacement authoritative reference (with all implied scrutiny for its content and quality).
The Playbook impacts the entire enterprise and must contain “Plays” on Team, Program, and Enterprise level. It must remain descriptive but contain enough agency-specific colloquialisms to make it relatable and usable.
The Playbook is (typically) created by an external consultant, experienced in Agile coaching, but generally with very little understanding of the organization. Basically, an outsider who is about to tell how the Agency must pivot and realign years (and decades) worth of internal processes and practices.
An Agency Playbook needs to address the entire enterprise and help all players, especially the ones outside of the traditional “Solutions Delivery” organization, understand their role in a new Agile organization. The Playbook becomes an anchor and a round-table for bringing together all traditional enterprise roles in a new engagement model – Business, Solutions Delivery, Operations, Security, Compliance, Acquisitions, and Capital Planning.
How do we create a document, that is disruptively different from everything the Enterprise has experienced so far, yet obtain a wide-spread consensus and support for it?
This is where a modified version of the Federal Proposal Writing portion of the Shipley process comes to the rescue. In its core, a proposal is a document, that is:
authoritative (if awarded – it becomes a contract),
it is often more descriptive than prescriptive (talking about approach and methodology, rather than solution specs),
it is often written by a consultant (or a team of such) that may or may not be part of the team executing the contract,
must create consensus among a diverse group of people (the various teammates, the business development team, the operations team, the finance/pricing team, the executives, and ultimately – the evaluators), and
it must be of high quality and fidelity.
Pretty much – the same characteristics as in the Playbook description above!
Here is how we implemented a Shipley-inspired approach to writing the Agile Playbook for a major Federal Agency.
Remember the diagram from above? This is our modified version – quite similar but with a little twist at the end:
STEP 1 – Know the Customer and Their Agile Readiness: A small team of Agile Coaches conducted a series of interviews with project teams (there were a few trailblazers trying to be as agile as possible in a waterfall SDLC), business units (all major ones), and IT branches (all major branches impacting or impacted by the software delivery process) – their executives and mid-management). We had some structured questionnaires, but we leaned more on open-ended questions and unstructured conversation. Our objective was not only to assess the current level of maturity but also to capture the culture of the organizations and the sentiments toward agile – identify pain points, opportunities, risks, proponents and detractors.
STEP 2 – Study the Waterfall SDLC Process: As part of step 1, we discovered that the organization had a fairly well streamlined, well thought-through and documented SDLC framework. Why throw the baby with the soapy water? As much as the Agile practices introduce a major change in the way of thinking for what is a valuable process or a document, there are steps and artifacts that are unavoidable. For example, the Software Security Plan and Security Assessment Report are FISMA-required deliverables that must be produced by all teams – waterfall and Agile (Maybe we should keep those templates!). Conversely, enterprise processes such as Project Initiation or Release/Change Management are still applicable to an Agile organization (with potential modifications). Another reason to study the SDLC process is the inherent duration of the Agile transformation process – we expect that at least for 2-3 years (the usual contract duration) waterfall projects will coexist with Agile projects (hopefully, gradually decreasing the former and increasing the latter). During that transition period, the organization should be able to support both execution paths with minimal overhead and no identity crisis.
STEP 3 – Summarize Findings and Recommendations: The interviews and the SDLC research generated from the first two steps unveiled some patterns and themes of findings, root causes, and recommendations. We documented and shared the Findings and Recommendations with our stakeholders – IT executives, all interview teams and participants, and our working group of Agile champions.
STEP 4 – Exec Support?: Obtaining the executive support for our high-level recommendations and overall direction for Agile implementation was crucial! No Agile transformation can survive and outlive its executive support. Agile requires major shifts in the organizational structure and the organizational culture. The Playbook brings them to light, but it takes executive muscle and commitment to carry out the execution.
STEP 5 – Magic Happens: This is where the weeks of initial assessment and study of the organization, meets the decades of joint industry and Agile experience of the coaches. The first draft was a little crude, but “good enough” – it had a well-fleshed out outline the language was a little unpolished and with some gaps in places, some references were missing, the tables unaligned, the graphics – hand-sketched or scraped off the Internet.
STEP 6 – Socialize Internally, Pink Review: This was the first unveil and test of the coaches’ vision for the new Agile delivery model. We presented the rough (placeholder graphics, a few missing sections, unpolished language) “Pink” draft to our immediate government product owners – the two leads overseeing our contract and performance. The “Pink Review” spurred multiple conversations regarding governance, measures of success (for each Agile Pilot and for our Agile Transformation as a whole), minimal-required practices, and potential best candidates for the first pilots. The feedback and the conversations were more strategic and directional and they provided the initial internal alignment for us to proceed with fully elaborating the Playbook content.
STEP 7 – Pink Recovery: The feedback and conversations from step 6 helped us crystallize our content and graphics. We updated the document to a point when it was ready for the first review from an external stakeholder. Some formatting was still missing and a few graphics were a little inconsistent, but we had well-rounded content ready to be shared externally.
STEP 8 – Socialize Externally, Red Review: the next critical test was to find out how would and an external and unfamiliar reader would read, understand and receive the document. We enlisted the help of 12 volunteers. They came from different backgrounds and parts of the organization – business leads (and future Product Owners), Technical Project Managers, Security, and Governance stakeholders. They all shared certain passion and appreciation for Agile, but they were not part of our initial ideation and visioning. They represented the remainder of the organization that was about to embrace agility and play it by our Playbook. We held a formal kick-off for the reviewers, gave them a timeboxed deadline for the review – one full 2-week sprint. Note that at this stage, the document was structurally finalized but still unpolished – smart, but not pretty. We put more value on the early feedback than making good impressions.
STEP 9 – Red Review, White-glove, Publish: At the end of the Red Review sprint, we held a feedback sharing session following the Scrum Retrospective format. Each reviewer summarized their feedback and asked their most pressing questions. We rationalized their feedback and incorporated it in the first release candidate version. The copy editor and the graphic designer are currently putting their final white-glove touches before the last 508 test and formal release.
STEP 10 – Inspect and Adapt: In contrast with the Shipley process where at this step the proposal is out of the door and nothing can be changed about it, in the case of an Agile Playbook – this is only the beginning of a long-lasting and iterative journey. We fully anticipate that putting the Playbook to play with the first pilots will uncover blind spots and opportunities for improvement, which will be incorporated in subsequent editions.
And in the spirit of Agile, a quick just-in-time Retrospective:
What worked well: the incremental approach for developing the vision, obtaining support, elaborating the vision iteratively and testing it on expanding groups of stakeholders, worked well and helped greatly with the early adoption. The process itself may not be unprecedented, except for putting it in the vernacular of the Shipley methodology.
What didn’t work well: using the “color review” references worked well with my co-coaching partner who was familiar with Shipley, and made for short Jira task titles. However, the references didn’t work well right away for my government product owners who didn’t have the industry experience. I had to give them the abridged Shipley 101 overview before the Jira tasks made sense to them.
In conclusion: keep the process, but use the “color” references cautiously.
Bella Trenkova
Comments