Agile governance stories

Agile governance stories
[ ] Regulated and flexible
[ ] Outsourced gov teams
[ ] Too much? Too little?
[ ] Change management. Esp. when there are law or rule changes.
[ ] David worked at co doing pacemakers. Class3 med device.
[ ] New product every 18months with delay.
[ ] Fundamental customer was gov regulator.
[ ] Pair with the regulator.
[ ] Find out the challenges regulators were facing.
[ ] New tech... Is it safe?
[ ] It's a lot to learn.
[ ] Systematize. Find what works. (No throwing it over the wall)
[ ] Need traceability, change mgt and assurance.
[ ] They won't test your software. They want to be assured that you are testing. Acceptance criteria. Stories, small changes. TDD. GIT.
[ ] Regulation perspective. Regulator can add a test.
[ ] Traceability... Give tests great names. Follow the regulator's environment. Use their words.
[ ] Perl scripts forced better sys design.
[ ] Rollout a sw patch for an existing medical device.
[ ] Pair with regulator.
[ ] Regulator needs to assure quality. Key is onsight regulator.
[ ] Ease of approval because regulator is involved.
[ ] Metrics... Why? Assurance. Concrete.
[ ] Example: Self driving car.
[ ] Instrumentation. Of outputs.
[ ] Automate data gathering.
[ ] Philosophy and values. If something is worth doing we need to share that.
[ ] Practicality.
[ ] Governance based. Developers, operations. 6 mos budget for developers goes up and for operations goes down.
[ ] Test in production. Lean startup.
[ ] Gather lots of data.
[ ] Measure outcomes not outputs.
[ ] Alistair Kroll book.
[ ] Stress testing.
[ ] Immediate outcome leading measures do exist.
[ ] Relative metric still meaningful.
[ ] Patterns for success... Err on the side of measuring lots of things.
[ ] Why are we measuring?
[ ] Documentation as part of the process.
[ ] Perl script to transform spec from test form to docs form.
[ ] Duplication is a problem.
[ ] Put tests in the language of domain.
[ ] Tests are things customers care about.
[ ] Hard to name? Hard to write a unit test for?
[ ] The tests are your spec.
[ ] Traceability from spec to software.
[ ] Docs... User manual, training, customer support recipes, new engineer support. Ramp up.
[ ] Approaches/patterns, high level design, domain concepts, tech stack, process, conclusions, reasons, insights.
[ ] Good names, glossary of top 20 names. Video of engineer diagramming. Pairing (good for all).
[ ] For other docs...why? What specific valueis there? What do we do already to deliver that value?
[ ] How do we change policy to better meet intent?
[ ] How do we map the process to the policy automatically?
[ ] Governance!