Would recommend expanding this topic in two directions.
-
How to 'go where the work is', when we decide we can do that. The USDS checklist is good, but is it the only model or just a good model? At the scale of e.g. Navy HR, product delivery teams might spend all their time traveling and none of their time developing. Are there ways to pursue this with a hybrid model or should it be the one delivery team that owns the process soup to nuts from user to digital product? Would it make sense to have delivery teams at 'major concentration areas'? Leadership will almost certainly ask questions along these lines when there's a lot of users.
-
Really hone in on the idea of dropping out middle-men. Not just in between users and the development team, but between the development team and the product. The way the Navy works today, there's a valley of death between the dev team and getting the product into prod, and that significantly impacts the quality of user feedback that is received (and is possible to receive). I think you'll hit this more in '04 - Certify the Process' but this should also help us make the case for not using competency-based system engineering processes as we're required to do today (the 'SETR' process), avoid mandates for silly things like using a single enterprise testing tool for all products, etc.
This document should unambiguously state to its audience that you need to form teams you can trust and then trust them to own the whole thing, IMO.
Would recommend expanding this topic in two directions.
How to 'go where the work is', when we decide we can do that. The USDS checklist is good, but is it the only model or just a good model? At the scale of e.g. Navy HR, product delivery teams might spend all their time traveling and none of their time developing. Are there ways to pursue this with a hybrid model or should it be the one delivery team that owns the process soup to nuts from user to digital product? Would it make sense to have delivery teams at 'major concentration areas'? Leadership will almost certainly ask questions along these lines when there's a lot of users.
Really hone in on the idea of dropping out middle-men. Not just in between users and the development team, but between the development team and the product. The way the Navy works today, there's a valley of death between the dev team and getting the product into prod, and that significantly impacts the quality of user feedback that is received (and is possible to receive). I think you'll hit this more in '04 - Certify the Process' but this should also help us make the case for not using competency-based system engineering processes as we're required to do today (the 'SETR' process), avoid mandates for silly things like using a single enterprise testing tool for all products, etc.
This document should unambiguously state to its audience that you need to form teams you can trust and then trust them to own the whole thing, IMO.