The Everyday Agile Workbook
Contents
Introduction
2 Introduction
Long story short: Being agile is about being able to respond to disruption.
4
Agile at a Glance
5
Agile Trends
6
Agile Trend Highlight: Culture Challenges Continue
9
How Developers Can Become a Security Asset
In software development, capital-A Agile is a precise process to how products are made. But, there is something compelling and useful about the idea of Agile work that can help everyone – not just software developers – work iteratively, incrementally and interactively every day.
Why it Matters In the 2020 Federal Employee Viewpoint Survey (FEVS), an annual snapshot of sentiments across the federal workforce, nearly a quarter of respondents said the pandemic had been extremely or very disruptive to getting their work done. On top of that, almost half of respondents said their work demands greatly or somewhat increased.
10 Test Your Knowledge 12 Applying Agile to... Planning Your Workday 15 How to Co-Innovate for Agility 16 Applying Agile to… Communicating With Colleagues
This isn’t just a federal workforce issue. We all need a better way to handle varying workloads and increased disruption when the need arises. Being agile can help.
18 Case Study: How a Long Serving DOJ Employee Became a New Agile Practitioner 20 Case Study: How the Census Made a Hard Pivot When the Pandemic Hit
23% 48%
22 What’s Next?
of employees reported the pandemic was either extremely or very disruptive to their ability to do their work
A GovLoop Guide 2
of employees reported greatly or somewhat increased work demands because of the pandemic
In last year’s guide, we defined agile broadly as “an interactive, incremental and highly interactive way of working.” This is still true. In this guide, we’ll focus on being agile as a response to unwelcome change. The Agile Alliance defines agility as “the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.” Accordingly, one of the four tenets of Agile software development is placing more value on responding to change than following a plan. This tenet can apply to anyone, really. If you look at all four tenets of the Agile Manifesto, you’ll see that this way of working is about staying flexible for the goal of providing something valuable — and quickly — without breaking your back.
• Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan This guide offers practical and actionable ways to stay light on your feet despite disruption. We feature worksheets that cover common tasks for government employees, such as planning your workday and communicating with colleagues. And we go over trends, insights and case studies on how government is being agile. Software developers may have canonized the Agile philosophy, but it can work for you too. Find out how in the following pages. For the purposes of this guide, here is a quick overview of what we mean by Agile vs. agile.
Agile
agile
both
→ a specific work philosophy with origins in software development that promotes continuous learning and userfocused value delivery
→ an iterative, incremental and highly interactive way of working, where you are nimble in the face of change
→ a highly disciplined workflow that requires formal training; some team members may be wholly devoted to encouraging Agile adoption, such as Agile coaches and scrum masters
→ does not require formal training or certification, though it will require intention and certain skills such as responding to change, communication, teamwork, organization, etc.
“The ability to create and respond to change… A way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.”
→ requires conducive organizational culture and leadership buy-in
→ does not necessarily require conducive organizational culture or leadership buy-in; individuals can be agile
The Everyday Agile Workbook 3
- Agile Alliance
Agile at a Glance A quick overview of what you should know about “big-A” Agile Traditional vs. Agile Software Development
(Source: TechFAR Handbook Appendix A)
Topic
Traditional Thinking
Agile Thinking
Requirements
• Known requirements negotiated upfront
• Broad goal, “what” and “why,” known upfront, just not “how”
• Tasks preplanned to end of period
• Government states in solicitation process that Agile processes will be used
• Government usually applies “kitchen sink” philosophy, including everything it can think of in the requirements list because a working product won’t be available in a year or longer Methods
Conventional method goes through the following steps in a linear fashion: 1. Design the program 2. Document the design 3. Create a second version of critical design/operations 4. Plan, control, monitor, testing
Task Identification
• Contract requirements are defined pre-award • Technical or system requirements are refined post-award at beginning of each sprint • Relies on frequent inspection and adaptation Compresses five sequences of conventional method (see left) into shorter cycles, e.g., one to four weeks • Develops a system through repeated cycles and smaller portions • Allows developers to test and review during development
5. Involve customer
• Creates a repeatable model so product is pushed into production quickly
All tasks approved at beginning by customer
Team identifies or uncovers work as it goes, from sprint to sprint » Government sets priorities, approves work at beginning of each sprint, accepts work at end of each sprint
Software Delivery
Software delivered at end of linear development phase
Software delivered frequently with features that allow deployment » This outcome is called a minimum viable product
Changes to Technical/System Requirements
Significant changes in requirements impact cost baseline, which results in contract negotiation
Requirements are refined (there may be a tradeoff, which forces prioritization by government)
Timeline of Agile Development 1950s – 1980s Iterative software development used occasionally in defense and space programs
(Source: Government Accountability Office’s Agile Assessment Guide)
2001
1990s • Scrum • eXtreme Programming • Dynamic Systems Development Method
Agile Manifesto
A GovLoop Guide 4
2001 – Present • • • • • •
DevOps Disciplined Agile Lean Software Development Kanban Scaled Agile Framework Scrumban
The Starter Kit Need some more Agile 101? Here are excellent places to start. They offer guidance, best practices, FAQs, use cases and more. • The TechFAR Handbook for Procuring Digital Services Using Agile Processes
• GSA Tech Guides: 46 Agile guides (GSA)
• The Digital Services Playbook
• Agile for Everyone: How to Improve Everyday Work Processes (GovLoop)
• Agile Assessment Guide: Best Practices for Agile Adoption and Implementation (GAO)
• Agile Government Handbook (Agile Government Leadership)
• Quick and Dirty Guide to Agile Project Management (U.S. Digital Service)
• The Agile Manifesto • Agile Alliance
Agile Trends The 14th Annual State of Agile Report in 2020 surveyed more than 40,000 Agile practitioners across sectors, including government. Here are some of the findings: Reasons for adopting Agile
Benefits of adopting Agile
Accelerating software delivery and enhancing ability to manage changing priorities remain the top reasons stated for adopting Agile.
Organizations continue to realize many benefits through adopting Agile.
71% Accelerate software delivery
70% Ability to manage changing priorities
63% Enhance ability to manage changing priorities
65% Project visibility
51% Increase productivity
65% Business/IT alignment
47% Improve business/IT alignment
60% Delivery speed/time to market
42% Enhance software quality
59% Team morale
What the data means: The outcomes may not always match the expectations for adopting Agile. Though there are broad similarities, slight variations between the reasons and benefits of Agile may indicate that certain outcomes may be more likely than others. • The ability to manage changing priorities: 63% said this was a major reason for adopting Agile. But more respondents – 70% – said it was a major benefit, making it the No. 1 positive outcome participants saw. • Business/IT alignment: Only 47% cited this as a reason for adopting Agile, but 65% saw it as a benefit after adoption. The Everyday Agile Workbook 5
IN THE NEWS More Flexible Modernization Funding Ahead What happened: In May 2021, the Office of Management and Budget (OMB) and General Services Administration (GSA) announced a more flexible repayment process for agencies that tap into the $1 billion Technology Modernization Fund (TMF). • TMF has provided incremental funding for federal IT and cybersecurity modernization projects since 2017. Agencies were once expected to pay loans back in full. • Congress provided a boost to the fund as part of the March 2021 COVID-19 relief package. “We plan to use these resources to enable the federal government to better respond to SolarWinds, the COVID-19 crisis and support the economic recovery,” said Federal Chief Information Officer (CIO) Clare Martorana in a press release. Federal agencies will now be able to pay back TMF loans in the following ways: • Full repayment: for projects that yield direct financial savings that can be used to fully repay TMF. • Partial repayment: for projects with strong positive impact and that will yield some financial savings, but where the proposing agency doesn’t expect to reach full cost recovery. • Minimal repayment: for projects aimed at tackling the most urgent IT issues facing government, including critical cybersecurity improvements and initiatives that help agencies meet the demands of the COVID-19 pandemic but are unlikely to create direct cost savings. Why it matters: The flexibility has removed a major barrier for federal agencies that need to be agile and modernize critical systems that won’t necessarily meet high cost-savings requirements. “It is more aggressive — to meet the urgent technology needs of the federal government today, as well as more ambitious — to anticipate the demands of tomorrow,” said GSA Acting Administrator Katy Kale.
Culture Challenges Continue Organizational culture continues to be the most common challenge around Agile adoption, the 14th Annual State of Agile Report found. Challenges experienced when adopting and scaling Agile
48%
General organizational resistance to change
46%
Not enough leadership participation
45%
Inconsistent processes & practices across teams A GovLoop Guide 6
44%
Organizational culture at odds with Agile values
43%
Inadequate management support and sponsorship
Many of the challenges the federal government faces are linked to culture as well, such as teams having difficulty with close collaboration and customers not trusting iterative solutions, according to GAO. To create and encourage a culture that supports Agile, answer the questions below.
Does your organization’s culture support Agile methods? ☐ Sponsorship for Agile development cascades throughout the organization. • Have senior stakeholders openly and explicitly supported the use of Agile processes? • Have Agile champions been established? » Agile champions may or may not be senior stakeholders, but they should have the respect of Agile adopters and senior leaders alike. Their role is to help protect early Agile programs from derailment by those who do not understand the new methods or are skeptical of change.
☐ Sponsors understand Agile development. • Do senior stakeholders and Agile champions understand Agile? » Although the roles and responsibilities in a traditional process are well-documented, in an Agile environment they are more flexible and may not be understood as easily. This is why sponsors and champions need to differentiate between traditional and Agile roles, cadences and processes.
☐ A climate of trust is being built. • Are there opportunities for members to become familiar working across organizational boundaries? » Shared experiences build a climate of trust in which all parties feel respected and accepted. That helps the team achieve its fullest potential. • Are all team members easily accessible for collaboration? • Are there transparent communication practices? » For example, make all artifacts that contribute to the development of the system broadly accessible to everyone associated with a program, including oversight boards.
☐ Rewards are aligned to Agile development methods. • Are incentives and rewards focused on the team, not just individuals? » If organizational rewards are not structured to promote team performance, then competitiveness or a lack of respect among team members might increase. In an Agile environment, establish incentives to focus on team success, in addition to traditional individual incentives.
The Everyday Agile Workbook 7
A GovLoop Guide 8
How Developers Can Become a Security Asset An interview with Michael Ducy, Cloud-Native Transformation Specialist, Red Hat For agencies to realize the full benefits of DevSecOps, they need to apply the DevOps tenet of continuous delivery both to software and security. This is a big change from a traditional development environment in which security typically operates as a separate function that comes into play at key points in the development life cycle. In that model, security also is seen as a drag on the development process and an obstacle to innovation. Agencies can avoid those pitfalls by fully incorporating security into the DevOps process and, more importantly, into the daily workflow of their developers. To learn more about this, GovLoop spoke with Michael Ducy, Cloud-Native Transformation Specialist at Red Hat. He discussed three ways agencies can reduce risk and improve compliance while also driving innovation.
Let Developers Drive Innovation When it comes to security, IT experts often talk about the importance of “shifting left,” that is, addressing security earlier in the development life cycle. But it’s not just security that shifts left with DevOps. In traditional IT environments, developers were expected to adhere to a detailed IT architecture, which was updated periodically. To take advantage of today’s rapid rate of innovation in technologies and architectural approaches, agencies need to give developers more leeway to decide what languages, toolsets and capabilities they might need to build an application, said Ducy. “Keeping the state of innovation at the development level is very important, because it helps you further down the line, as you’re trying to reach your customer, or your user, in this new digital world,” he said.
Let Developers Drive Security Because the DevOps environment is so dynamic, security can keep up only if it is fully integrated into the day-to-day work of developers. It comes down to continuous delivery. As developers download libraries, JavaScript packages and other tools, they need to ensure that they are running the necessary checks on risk and compliance. Security needs to become just another gate in the continuous delivery process. In this environment, the security team plays more of a consulting role, helping developers understand security requirements “so that they can make better choices in the future as they go through this more modern way of working,” Ducy said.
Establish a Trusted Software Supply Chain Integrating security into the development process provides the foundation for building what Red Hat calls a trusted software supply chain (TSSC). With a TSSC, all stakeholders can be confident that security, compliance and privacy requirements are addressed throughout the software development life cycle. Such trust is essential to accelerating a program’s ability to achieve authority to operate. Many pieces must come together to build a TSSC, and it won’t be easy if agencies take a piecemeal approach, said Ducy. “With the Red Hat OpenShift Container Platform, we provide a complete holistic solution that enables you to build a trusted software supply chain rapidly and to onboard new teams quickly to start working in this way,” he said.
The Everyday Agile Workbook 9
Test Your Knowledge Choose the correct answers for the following questions. There may be more than one correct response. 1. Which of the following software development requirements are considered Agile?
4. Which of the following are best practices for creating a culture that supports Agile?
a. The broad goal and “what,” “why” and “how” are known upfront. b. Tasks are preplanned to the end of the development period. c. Contract requirements are defined before the contract is awarded. d. Technical or system requirements are refined post-award at the beginning of each sprint. 2. What is a minimum viable product? a. Software delivered at the end of a linear development phase. b. A prototype that developers test internally. c. A final software product that provides the most value to customers. d. Software delivered frequently with features that allow for deployment.
a. Encourage a culture of competitiveness. b. Stakeholders understand what Agile development entails. c. Senior leaders alone openly and explicitly support the use of Agile. d. Incentives focus on team success. 4. Who needs to “buy in” to Agile methodologies to support organizationwide use? a. Senior leaders b. Supervisors and managers c. Team members d. All of the above 6. In the 14th Annual State of Agile Report, the majority of respondents saw this benefit in adopting Agile: a. Business/IT alignment b. Project cost reduction
3. Which is not a tenet of the Agile Manifesto?
c. Software maintainability
a. Individuals and interactions over processes and tools. b. Working software over comprehensive documentation.
d. Managing distributed teams Answers are on the next page.
c. Customer collaboration over contract negotiation. d. Following a plan over responding to change.
A GovLoop Guide 10
Answers: 1. a, c, d; 2. d; 3. d; 4. b, d; 5. d; 6. a
Thoughts to Consider For the Agile skeptic … Q: Is Agile software development feasible given agencies’ limited resources? U.S. Digital Service: Agencies need to ensure adequate resources are applied to manage their contracts irrespective of the strategy used; Agile software development is no exception. While the process is highly interactive, the overall amount of work is not greater — just applied differently — to produce quicker results.
For the Agile fanatic ... Q: Should agencies use Agile software development to address all IT needs? USDS: No. Agile software development is intended for activities that require significant software design and development. Many IT needs can be met with commercially available off-the-shelf items and commoditized services, such as subscription services for software licenses, with little or no development work. In those cases when development is not needed, the government is best served by purchasing commercially available off-the-shelf items.
Better Retrospectives: The Plus/Delta Framework Whether you’re working in Agile sprints or just trying to improve your workflow, reflecting is a critical part of moving forward. But sometimes, fully unlocking the value of retrospectives can be tough when they only entail identifying a laundry list of problems and shortcomings.
Use this framework the next time you review a project or process, and you’ll find retrospectives to be something you look forward to.
Plus (+) • Identifies things that are working
To overcome this, approach retrospectives from a problem-solving standpoint at the outset.
• Items that the team or individual wants to continue building
“It’s a simple shift, changing ‘What did you like, and what did you hate?’ to ‘What should we do more of, and what should we change?’” wrote Jacob Anderson, Community Engagement Specialist of Colorado Springs, Colorado. “It’s a simple reinforcement of the concept that we’re all working to make something better. And that, to me, is the essence of government.”
Delta (Δ) • Identifies opportunities for change • Items are action-oriented, specific, within the realm of possibility and should be reviewed and acted on
The Plus/Delta framework is a reflection tool that encourages continuous improvement through action-focused reflection. The Everyday Agile Workbook 11
Applying Agile to... Planning Your Workday When I first started working, one of the trickiest things to pin down was planning my work schedule. Once I felt like I had a good routine going, something else changed in my environment that washed it down the drain, whether it was a new responsibility, different projects, COVID-19, a Wi-Fi outage or incessant construction noise. I thought to myself, “Once I achieve a consistent, noise-free routine, I’ll be able to work seamlessly.” To be honest, that kind of workflow still hasn’t happened. As the weeks went on and the pandemic seemed to extend our remote work stints into eternity, I learned that change was always going to happen despite my schedules and routines. Sure, some days, everything went according to plan. But other days, I knew disruption would be inevitable. Acknowledging this reality drastically changed how I viewed planning my workday – and helped me stay productive and valuable to my team, while being flexible and kind to myself. When we think about agilely planning our workdays, preparing ourselves for disruption will help us stay light on our feet and less stressed when change comes our way.
Tip #1: Set realistic expectations. Are your energy levels low? Do you have a lot of meetings on your calendar? Think about your whole environment – external and internal, mental and physical – and how it could affect your workflow. Knowing how you work will help you set realistic expectations that help you stay productive but don’t burn you out.
Try this: Be kind to yourself. What are some realistic limits to your productivity today? Examples: dependents, poor sleep, last-minute meetings
A GovLoop Guide 12
Tip #2: Do a midday check-in. Remember that part about setting realistic expectations? Sometimes we get it wrong at the beginning of the day, and that’s OK. It could be helpful to pause in the middle to make sure you’re on track, particularly with urgent tasks or large projects. Reassess and reprioritize based on how the earlier half of your day went.
Try this: After your midday break, write what you were able to accomplish in the morning:
And what you have left to do in the afternoon:
Tip #3: Plan large chunks of time, then incrementally smaller ones. Software developers who use Agile methodologies work in two-week sprints. This is key to how they create software products with user value in a short amount of time. Planning your next two weeks (or one month or three — whatever works best for you) can help you extract more value out of your time too. Remember: Planning takes time and energy, and well-planned projects will show value in the end. Having a broader map of your coming weeks is like having a first iteration of your schedule, after which you can change incrementally week by week and then day by day.
Try this: • Record all upcoming deadlines, events and meetings in a calendar you (actually) use. • For large projects, write down what you want to accomplish each day leading up to the deadline. • Review steps and schedules as necessary on a weekly and daily basis.
Tip #4: Get rid of what doesn’t work. There are a lot of productivity hacks out there that just don’t work – and it’s up to you to decide what they are. Can’t wake up at 5 a.m. to deep work? Don’t. Feeling burnt out after brainstorming past 4 p.m.? Stop. (Note: Of course, some of these tasks come at the discretion of your team too. Sometimes you may have to brainstorm after 4 p.m., but consider that you bring the best value for your team by bringing the best version of yourself.)
Try this: Consider this: Is there a habit or way of working that hasn’t helped you work agilely recently?
The Everyday Agile Workbook 13
At NS2 Labs, innovation comes first. We created a place where innovating to solve our nation’s most pressing problems comes first – no matter what industry you’re from.
NS2 Labs is your place to collaborate, ideate, and innovate.
Join the NS2 Labs Community Today Get ready. Roll up your sleeves. NS2 Labs is open for collaboration – virtually and in-person. © 2021 SAP National Security Services, Inc. All rights reserved.
sapns2.com/labs A GovLoop Guide 14
How to Co-Innovate for Agility An interview with Kyle Rice, Chief Technology Officer, SAP National Security Services (SAP NS2) For too many years, government, industry and academia worked in silos to solve overlapping problems. But let’s think about it: Why repeat work that is already done? It’s time to close the gaps. It can be as simple as plugging into an existing innovation ecosystem with industry and research partners. “The last thing you want is to have multiple organizations doing the same work in parallel,” said Kyle Rice, Chief Technology Officer at SAP National Security Services (SAP NS2). “If you get in the trenches in the beginning and work together, it’s much more efficient. You’re not recreating foundational work,” Rice added. Take space exploration, for example. Fifty years ago, every rocket launch was a bespoke, customized exercise. You spent precious resources trying to figure out the basics of takeoff. But over the years, industry streamlined launches, which allowed agencies that took advantage of commercial advances to focus on aspects that mattered more to their mission. In a nutshell, co-innovation offers more agility. Agencies can pivot faster because they can build on the shoulders of those who came before and those who are beside them. NS2 Labs offers the place, people and tools to coinnovate. So far, they have completed 56 projects and are working on 16 more with this co-innovation model. Here are some insights into how they made it work.
Bringing people together How can organizations that seem to function so differently from one another, collaborate to work together?
The key is in seeing and speaking to each sector’s unique perspectives of success, Rice said. The labs’ supply-chain hackathon is one example of a dual-use program that had value for government and industry. With the best minds participating across sectors, they were able to produce a new capability that builds and improves more-secure supply chains. Additionally, it’s helpful to communicate and emphasize a project’s objectives rather than the implementation. Technologists from government, industry and academia likely have different backgrounds with varying language around skill sets. Focusing on the objectives can help organizations figure out who would be best for working on a particular problem, rather than getting confused by the nitty-gritty of implementation.
Bringing ideas into reality Brainstorming ideas that bridge silos is the first step, but making those ideas actionable is the other half of co-innovation. To co-innovate better, the type of environment in which people work matters. According to Rice, a space that will help bring concepts into reality should be: • Integrated – to provide all the capabilities you need to execute an idea. So when ideas strike, you don’t lose time moving to another facility. • Stimulating – to spark creativity. • Secure – to protect sensitive or classified information. • Safe – to foster an environment that is free from any agenda other than innovation. For instance, NS2 Labs doesn’t charge for participation and doesn’t require SAP technology to be used. “Let’s go where the mission takes us,” Rice said.
The Everyday Agile Workbook 15
Applying Agile to... Communicating With Colleagues Good communication skills are important in any situation, but especially for “big-A” and “little-a” agile work. The following are a few scenarios you may find yourself in where clear, engaging communication is the chief task ahead of you. Choose Your Path: Follow the arrows below to see where you’d wind up on the agile spectrum in these situations. Are you taking the most agile approach?
Scenario 1 Your boss assigns you a last-minute project due in two days. You already have a lot on your plate, and finishing the project on time would likely mean you have to cancel personal obligations. What do you do? Ask your boss about possible extensions? Yes. See if there’s flexibility.
No. It was assigned.
Gauge availability, ability and oppenness of others to help? Yes.
Prioritize projects and communicate realistic expectations?
No. That’s not your role.
Yes. Set expectations.
No. Get as much done as possible.
Most agile
Least agile
Takeaway: Open communication and maximum flexibility lead to the most agile outcome.
Scenario 2 You’re charged with leading a survey to gauge opinions on a new agency policy. How do you design the questions? Does the survey have boxes for open responses? Yes, you want space for answers you may not have considered.
No, you want concrete, statistically significant responses, so it’s multiple choice.
Does your survey have comment space only at the end or after every multiple choice? After multiple choice. You want specificity and to maximize the value of each question
At the end. Why create more work for respondents after every question?
Do you allow respondents to rate responses? (ex. 1 = strongly disagree, 5 = strongly agree) Yes. You want more ways to sort info and identify areas of need.
Most agile
No. This data is of little use. You just need to know their answers.
Least agile
Takeaway: Maximize opportunities for audience feedback. Make sure you open the door to ideas you might have missed. A GovLoop Guide 16
Yes or No? Answer the questions below to grasp how agile you are. Also consider what other factors could make these situations more agile.
Scenario 3 You’re facilitating the daily standup meeting to track progress on a project or product. Assess the standup. Most agile Is it short? (15 minutes or less)
Yes
Is everyone addressed, not just one person?
Yes
Is it at the same time, same place every day?
Yes
Are team members late?
No
Is everyone prepared to share progress or impediments?
Yes
Are the details of problems or ideas discussed?
No
Are clarifying questions asked to understand common goals?
Yes
Is the team energized?
Yes
Least agile No
Somewhat
No No
Sometimes
Yes No
Somewhat
Yes No
Somewhat
No
Takeaway: Standup meetings should ultimately encourage teamwork, trust and transparency.
Scenario 4 You’re presenting on a work topic at an all-hands meeting. How do you lead the presentation? Most agile
Least agile
Do you have an agenda?
Yes
No
Do you articulate the main purpose of the presentation?
Yes
Do you have visual elements to accompany your presentation?
Yes
Do you speak about main points that are relevant to the audience?
Yes
Somewhat
No
Do you engage the audience throughout?
Yes
Somewhat
No
Do you take questions or comments?
Yes
No
Do you allow multiple ways for people to ask questions or add comments? (written, verbal, etc.)
Yes
No
Do you reiterate the main purpose or takeaway?
Yes
Somewhat
No No
Somewhat
Takeaway: Having a clear objective and engaging the audience can help produce the most value for the presenter and audience.
No
Case Study: How a LongServing DOJ Employee Became a New Agile Practitioner (Adapted from 18F’s blog post, “Building product management capacity in government part 3,” written by Lalitha Jonnalagadda and Bill Laughman) Background: The Justice Department (DOJ) needed to find a better way to intake the 100,000-plus civil rights reports it receives every year. Due to the dozens of reporting pathways for the public, the process was “confusing and inconsistent” for those who tried to file potential violations, 18F said. “Without clear guidance and expectation setting, many people submitted reports that required extensive follow-up to collect missing information, or submitted reports that fell outside the purview of the Division altogether,” 18F said in a blog post. Working closely with 18F, a tech and design consultancy within GSA, in June 2020 the division launched a new and improved portal with the help of Agile processes. Here’s the story of the experience for one DOJ employee, the portal’s product owner*, who evolved from an Agile skeptic to Agile champion over the process. Who? Bill Laughman, DOJ Civil Rights Division “I’ve been with the Civil Rights Division for about 20 years serving various roles, with my latest role in leading complaint intake and processing violation reports for the Administrative Management Section. I’m the primary correspondence liaison for Division-wide report triage. I also serve as the main point of contact for congressional inquiries to the Department.”
← Before
After →
* A product owner is the “voice of the customer,” the person who is accountable for ensuring business value is delivered in a product (GAO Agile Assessment Guide).
A GovLoop Guide 18
JANUARY 2019 18F submits recommendations for modernizing intake process using Agile
Laughman’s initial thoughts:
How his perception and comfort changed over time
• Wide-eyed! Initially, these concepts seemed great ideologically, but we didn’t know what practical implementation would look like.
Validation:
• So many acronyms! I was hesitant to ask what the terms meant because I didn’t want to seem unqualified. • Skeptical! We asked for some previous projects that 18F had successfully implemented so that we could collectively set expectations. • Not having a project plan or an anticipated output or timeline was confusing and daunting!
“Once you buy into the Agile methodology, you have to sell the rest of your team on it as well. Momentum increased as we continued to incorporate user feedback into our development. Our end users are empowered throughout the development process and now recognize the value of an Agile approach.”
- Laughman
Shorter feedback cycles with the general public, intake teams, and development and design teams helped us validate our progress, which was huge! Our notion of a team is redefined. Our team now included end users invested in making the portal useful and valuable.
Roadblock: After developing on an initial tech stack for about two months, we hit roadblocks preventing us from progressing further. We revisited the vision, conducted a risk/benefit analysis and decided that investing in a new stack would allow us to be scalable and resilient for years to come. Although it was a tough decision, our stakeholders weighed the consequences of developing further on a legacy stack and decided to pivot toward a modern tech stack even after spending significant development time and effort.
Validation: Overall uptick in morale! Our division worked as a collective team rather than individual sections. The 18F team established open communication and transparency while sharing information at all times, which helped build trust among internal DOJ teams, stakeholders and 18F teams.
JUNE 2020 New civilrights.justice.gov launched
Skills Laughman learned as a result:
Decision-making
Empathy
Empowerment
The Everyday Agile Workbook 19
Technical complexities
Case Study: How the Census Made a Hard Pivot When the Pandemic Hit An interview with Kaile Bower, Executive Director, Business Operations Staff, Communications Directorate, U.S. Census Bureau Background: Communication has always been key to the success of the decennial census. As part of every census, the U.S. Census Bureau embarks on a nationwide effort to encourage everyone to respond online, by phone or by mail. And that means everyone: It needs to reach into every community possible across the 50 states and five territories. As part of the 2020 campaign, the communications team focused on continuously monitoring and optimizing its efforts to drive the highest response possible. Years in the making, the campaign plan was ramping up for the final big push when the pandemic hit, forcing the communications directorate to rethink its plans. In an interview with GovLoop, Kaile Bower, who led the Campaign Optimization Review Team, discussed how the team adapted to the rapidly changing situation. The responses were lightly edited for brevity and clarity.
GovLoop: When did you realize that you needed a new strategy?
What steps did you take to formulate a new strategy?
Bower: It was about mid-March 2020 when
We were lucky in one sense. We had already established a cadence of daily meetings, seven days a week. We were briefing leadership every day as well, to let them know what we were seeing, and we had a great team of contractors we were working with who were experts in the media. We were able to stop and say, “How are we going to pivot? If you’re not leaving your house, how do we connect with you?”
the government basically shut down and sent everyone home. As that happened, we realized that the modes of communication that we had planned may not be the best for the new situation. We had billboards in high-transportation areas as people were commuting to and from work. And we had to realize that people weren’t going to be commuting for a while. So, how do we reach those people that we thought would be seeing those billboards, or listening to the radio on their drive to and from work? But our job didn’t change: We still had to make sure that we reached every person in the country to let them know how important this job was for them to fill out their census. We needed to stop and say, “How do we reach these people? What do we need to do to change the way we’re communicating?”
One thing we ended up doing was advertising on pizza boxes, because we knew people were getting home delivery of food. Also, we had had all these materials set up for partnership events – for our people who were on the ground who would be going to music festivals or community events and handing out census information, bags with the Census name and website on them. All of those were shut down. So we worked with the local communities that were
A GovLoop Guide 20
providing food assistance, and we repurposed those bags so they could take the food, put it in those bags and then send them home with the people who needed it.
How did you get people thinking creatively like that? We had permission to think outside the box. Leadership really stood behind us and said, “OK, figure it out – put all the ideas on the table, and let’s see what we can do.” By being given that permission, all of the ideas came out. Some were great, some were not so great. But it allowed us to look at each one and see which was going to be feasible. And then we turned to the experts that we had hired – Team Y&R, which led and managed all media-buying efforts in support of the 2020 Census campaign. They were looking at the landscape, analyzing people’s media consumption, and they fed us all that data that we needed to figure out where the best invitation of change would be.
At a personal level, how did you adapt to this challenging environment?
Takeaways: Having gone through this experience, what lessons or best practices would you share with other people? First, you need to prepare as much as you can ahead of time. You want to think through how you’re going to use the data you’re collecting, and then take that time to set up your systems that let you do the things that you want to do with that data. In the beginning, it’s a lot of requirements-gathering, and it can feel very… not exciting, right? But it’s worth it in the end. Next, it’s important to adopt a growth mindset culture. You need to make sure that it’s OK if your first effort doesn’t go as intended – that we’re going to use those results to further your thinking and open new possibilities. Give the people you work with the permission to fail. Finally, you really need to trust your experts, because you hired them for a reason. If they’re telling you something from their experience, you need to trust that.
I have three children, so you know my life is chaos every day! And this has been my third census, and I think you find out after working one, you either thrive in a chaotic experience, or you don’t. Those people that do thrive in chaos tend to come back every 10 years and want to work on the census again. It’s just that kind of rush: What we’re doing is so important and exciting, because we are really leading change at this point. Everything we do impacts the world around us, including our communities, our neighborhoods. It’s that commitment to really wanting to make a difference.
The Everyday Agile Workbook 21
What’s Next? Luckily, being agile doesn’t require you to rip and replace all old habits. With the amount of disruption we already face in our lives, it would be too overwhelming – and exactly counter to the idea of what working agilely means. So, use what is helpful to you and don’t worry about the rest. Dealing with change is something none of us will ever quite get comfortable with, but we can get familiar. We hope this guide is helpful to that end. Signed,
Pearl Kim Staff Writer
Thank You
About GovLoop
Thank you to Red Hat and SAP National Security Services for their support of this valuable resource for public sector professionals.
GovLoop’s mission is to inspire public sector professionals by serving as the knowledge network for government. GovLoop connects more than 300,000 members, fostering crossgovernment collaboration, solving common problems and advancing government careers. GovLoop is headquartered in Washington, D.C., with a team of dedicated professionals who share a commitment to the public sector. For more information about this report, please reach out to info@govloop.com.
Author Pearl Kim, Staff Writer
Designer Kaitlyn Baker, Creative Manager
1152 15th St. NW Suite 800 Washington, DC 20005 P: (202) 407-7421 www.govloop.com | @GovLoop
A GovLoop Guide 22
