In this section, we offer suggestions for the product team as it approaches forthcoming work on the CAMD suite. We've broken down future work for the CAMD team into three phases that relate to future work with a vendor:
Note that all of the methods and materials in this guide will likely be relevant throughout all of these phases so please continue to use them whenever you see fit.
What should the CAMD product team work on after 18F rolls off this project and before a vendor is in place? There are a number of things that we suggest:
You'll need approval from offices outside of the CAMD. Start understanding who these folks are and begin building your relationships.
- Map out your paths to production and record the stakeholders that will be involved in that process.
- Use this template to map out who your stakeholders are and what level of communication you need to maintain with them
- socialize non-functional requirements to relevant stakeholders
We have mapped out user processes in a number of ways - through use cases, user flows, and journey maps. Journey maps help us go deeper into the user's experience. We touched upon this practice but there's still more to do.
- continue to develop journey maps for the existing CAMD suite personas that you've created.
- use those journey maps to sketch out value proposition canvases; this process will help you think about what stories you want to put in your backlog.
Continue to work on the end to end story map capturing the end to end functions that a user can take while navigating through CAMD Suite. Use the high level themes to help gather the user actions at each step to get to high level epics that you can work with the vendor when they are onboard. Story maps will allow the vendor to understand how these user needs are to be met by the CAMD suite.
- After developing the story map and value proposition canvases, come together as a team (with your vendor) for a story writing workshop
- When you have vendors in place, this story map will help you onboard them. It will also serve as the basis for the backlog that you build together.
- The EPA offers many public facing data resources that have overlap. Understand where there is overlaps with AMPD and where there are distinctions. Take inventory and use this when you begin identifying user stories for public data consumers.
- Continue working together as a cross-functional and cross-branch product team. You've begun developing your team - keep growing together. See how you might apply scrum practices to other areas of your work.
- If any of you can take trainings, such as the scrum master certification training, now is a great time to do so.
- Continue using RevAMPD as a sandbox to learn and master user centered, agile, product driven tech principles. Use the RevAMPD site to prototype in small increments (aka 'cupcake' model) to validate your hypothesis and desired outcomes.
- During the pre-award phase, observe your users as they interact with your product(s) currently to refine and identify their pains and needs. This will allow for you to revise your value proposition canvas, personas and other user research frameworks and also cultivate interaction with your users and looping them into your product development process.
The CAMD product team has discussed holding a weekly study/discussion group. Here are a few materials that we recommend you read and discuss together:
- The Phoenix Project
- The Scrum Guide
- Journey mapping, 18F Method Cards
- Managing stakeholder expectations template
- Dollars to Donuts, a podcast presenting interviews on user research, hosted by Steve Portigal.
We've talked about the benefits of working closely an collaboratively with your vendor rather than sending them of to work independently to execute on tasks. To develop a close an collaborative relationship, you need to set up how you want to work together.
Hold a kick off workshop to set up your relationship. Some topics that you should definitely include are:
- What communication tools do you want to use together?
- Where will you store work and artifacts? This should be a place where vendors and the CAMD can access
- What rituals/events will you hold together (sprint planning, sprint review, daily stand ups, etc)?
- Identify the systems/technologies will the vendors need access to
- Go through documentation best practices deck
- Set your definition of done, which will offer a common understanding of what needs to happen for a story to be complete. You can include criteria such as "code has been pair programmed or reviewed," "automated tests exist at all appropriae levels," "user documentation is updated," etc.). Review your nonfunctional requirements (the "ilities") with your vendor to help set your definition of done.
- In the pre-award phase, you gathered information about your users (their pains and needs), your systems, internal stakeholders, limitations, etc via Mission Model canvases, Value Proposition Canvases, User Flows, Journey Maps, hypothesis and outcomes statements, etc that lay the foundation and help you design a consolidated CAMD Suite. Use these frameworks and the incorporated information to have conversations with your new vendor teams to set the stage into development.
- During this session, you can discuss the story map you developed along with some high level user stories you might have captured by now with your vendors. Collectively with the vendor, you can prioritize and identify a 'thin slice' that you can begin development to allow for continuous iteration.
- This may sound basic, but it's not uncommon for vendors to wait a while before being able to get started because they can't get access to the necessary systems and tools. Be prepared to get them ready as soon as possible.
As you work with your vendor, you'll continue to be the experts in user and business needs - the elements that drive the vision of the product. Let your vendors be the experts on implementation, ie, how to achieve that vision. A few tips:
- instead of thinking of your vendors as staff augmentation that you have to manage, think of them as collaborators on your cross-functional team
- set a cadence of review for each sprint and give them heads down time to work in between sprint planning and sprint review.
- communicate often and early
- advocate for machine parsable code and plain language documentation
Since you'll be working in smaller increments than are typical in waterfall projects, you won't have a detailed, multi-year plan to start. This means that you'll have to do more planning along the way.
- Let your sprint candence help drive further planning and iterating