Technology and innovation – Economic production is no longer just about capital and labor, now knowledge and innovation are just as important. It has been proven that technology gaps can explain the disparity in productivity between different countries. Technological adoption, knowledge dissemination and information communication technology (ICT) are imperative for national competitiveness.
Your team needs to assemble a clear roadmap for their code. Architects and manufacturers use blueprints. You should too.
Tom Adams
What to build – Your roadmap should include a set of schematics which each fulfill a different purpose. These schematics differ for individual applications. A user-interface mock-up, application architecture diagram, and business process model are common. More detailed component diagrams such as Unified Modeling Language (UML) diagrams and flow models are often useful as well.
There is no “right” amount of pre-development documentation, but there is one wrong amount: none. Work out with your team what constitutes an acceptable roadmap before they start coding. The first checkpoint in your development process will be to review this documentation and ensure they’ve met this agreement.
Implementation and Testing – Refer to the roadmap you defined in the first step. Before starting new component(s), ensure that what you’ve already started is at least dev-complete. This provides you with an accurate view of the speed of development and reduces risk.
You can drive a non-technical conversation with your team about their “test coverage” (the portion of the code that is tested). It’s pretty simple: ask them to list their assumptions. Then ask where and how they test these assumptions.
Post-release -Succeed or fail, it’s important to circle back and review how the process went. Did your team accurately estimate the effort required to release a product? Did the testing adequately model the production scenario? Revisit the implementation and testing checkpoints, and review how well the team performed. How is the product running in production? It’s a good idea to visit the operations staff and obtain their feedback. This further creates trust between the development and operations teams, and will lead to more DevOps benefits down the road. Where are the remaining gaps in your product? If they’re in third-party code, now’s the time to consider whether to customize your packages or re-implement from scratch. Otherwise, you now have input on what to build for the next release.
Above all, hold yourself and your team accountable for the results of your effort.
