4.4 Project Management Processes
As explained in Section 3 - Low-Code Application Development, delivering apps with Low-Code is different from traditional hand-coding. Thus, a different process is needed to help Low-Code agile development teams focus on the right activities and work items at the right time. The Low-Code app development process flow is optimized for delivering business apps, broken down into four activity categories or phases: Setup, Define Needs, App Delivery, and Run App. These activities and work items are organized with the responsible resources who are consulted for business need requirements and refinement, the resources needed for completing the work item tasks, and who on the project team has final accountability for completion of each activity and work item tasks in the process flow.
As explained in Section 3 - Low-Code Application Development, delivering apps with Low-Code is different from traditional hand-coding. Thus, a different process is needed to help Low-Code agile development teams focus on the right activities and work items at the right time. The Low-Code app development process flow is optimized for delivering business apps, broken down into four activity categories or phases: Setup, Define Needs, App Delivery, and Run App. These activities and work items are organized with the responsible resources who are consulted for business need requirements and refinement, the resources needed for completing the work item tasks, and who on the project team has final accountability for completion of each activity and work item tasks in the process flow.
The contractor project team, consisting of the project leadership team and the development team Tech lead, will drive the implementation of innovative solutions that solve complex technical and business issues. The Tech Lead uses an iterative agile methodology (See Section 4.2.1 Agile Development Practices) to establish the connection between business and technical teams and harness the promise cross-functional agile teams can realize on Low-Code App product delivery.
Low-Code App development activities or phases and process flow have corresponding activities, work item tasks and roles that can be mapped to a typical agile development practices as described in the Figure 5 table below.
| Agile Activity Phase | Low-Code Activity Phase | Work Item | Description |
|---|---|---|---|
| App Estimation | After making the business case, determine the effort and budget required and available to create the Low-Code App. Consider the Epics, Features and high-level User Stories in the Product Backlog. Estimate total App Story Points using ‘t-shirt sizing’ methods. Responsible: Product Owner Consulted: Tech Lead and Business User Stakeholders |
||
| Sprint Planning | App Delivery | App Initiation | After the initial Epics, Features, high-level User Stories and Target Devices are recorded in the Product Backlog, select and prioritize items for the Sprint Backlog, refine the User Stories, break them down into tasks, estimate their size in Story Points using Planning Poker methodology, define ‘Definition of Done’, and define ‘Minimum Viable Product (MVP)’. The resulting Sprint Backlog is worked off in the development sprint iterations. Responsible: Product Owner Consulted: Tech Lead and Business User Stakeholders |
| Application Architecture design | To make sure the application is a success, it needs to have a good architecture runway that allows scalability, performance, and component reusability. Responsible: Tech Lead, acting as Architect |
||
| Iteration Planning | Every development sprint iteration starts with Release Planning and Sprint Planning so that everything is clear for the sprint iteration. Planning should include recent user feedback on the prior sprint iteration to promote user adoption. Responsible: Tech Lead Consulted: Product Owner |
||
| Development Sprints | Iteration Delivery | After iteration planning, development is executed according to the sprint backlog and according to agile best practices described in this section. Responsible: Tech Lead, Low-Code Developers Consulted: Product Owner |
|
| Mockups – Low and High Fidelity | During the MVP definition, ideas should be presented first with low-fidelity mockups. Some of the mockups should be taken to high-fidelity so that project stakeholders can be aligned with the vision for the application. Responsible: UX/UI Designer Consulted: Product Owner and Business User Stakeholders |
||
| Customer Journey | During the MVP definition, it is necessary to define the customer journey, the multi-touch point mapping, the experience map value, and the business value metrics. Responsible: UX/UI Designer Accountable: Product Owner Consulted: Business User Stakeholders |
||
| Implement Look and Feel | During the MVP definition, it is necessary to implement the look and feel based on the high-fidelity mockups. This will give a vision for how the application will look in the future and allow a faster development process. Responsible: Front-end Developer Accountable: Tech Lead Consulted: UX/UI Designer |
||
| Native Plugin Development | During the project implementation it might be necessary to implement features that require the use of mobile device capabilities. This requires native development of the plugins to be added to the application. Responsible: Front-end Developer Accountable: Tech Lead |
||
| Iteration Tests | The developed features for the sprint development iteration are continuously tested in a CI pipeline process to assure the quality of the application. Unit, Component Integration, Functional, Device, Load, and Security testing are required before conducting the iteration Demo with the Product Owner and stakeholders. Responsible: Developers, Tester Consulted: Tech Lead |
||
| Quality Assurance | Code quality scans are run to verify coding standards and static and dynamic App security tests are run to verify secure coding standards. Responsible: Developers, Tester Consulted: Tech Lead |
||
| Iteration Demo | After iteration development testing is complete, a demo is conducted with the Product Owner and stakeholders to validate ‘Definition of Done’ for the user stories and to validate MVP criteria for the completed features to assure that the features developed are correctly implemented and working in the way the users expect. Responsible: Tester Accountable: Product Owner and Business User Stakeholders |
||
| Release Integration | Production Rollout Plan | The developed application needs a release Production Rollout Plan that defines the way the application is going to be deployed and used. This includes the criteria for a Release Review, MVP criteria, release promotion to CD staging and production environments, Government UAT, security testing, successful production rollout and tasks required to identify when a Rollback Plan should be triggered in the event of release failure. Responsible: Product Owner Consulted: Tech Lead |
|
| Release Demo | After development, a release demo (UAT and Security Test) is performed to assure that the features developed are: (1) correctly implemented and ‘Definition of Done’ and MVP criteria are met, (2) RMF and security controls are demonstrated for ATO, and (3) the App is working in the field the way the users expect. Responsible: Tester, Government Test Team Accountable: Product Owner and Business User Stakeholders |
||
| Production Release | Run App | Production Release | The application is deployed to the Staging Environment for Government UAT and Security Testing. Following successful Government testing, the release is promoted to the CD Production environment. If it is not a standalone application, it is connected to other production systems or application configurations. This process is based on the Production Rollout Plan document for the release, and it ensures a successful and shorter deployment process. Responsible: DevOps Engineer Accountable: Product Owner |
| App Promotion | To assure application success and user adoption, it is very important to have the application internally promoted with users and stakeholders. Create an internal marketing campaign with a video, demo with the app journey, and all internal PR work needed to show that this was the right app and solution (BES Executive Sponsor, Business User Stakeholders, IT management, etc.). Responsible: BES PMO Adoption Champion Accountable: Product Owner |
||
| App Feedback | After an application is in production, find out from users what they think so you can improve the app in future releases or fix urgent issues. The feedback you gather can be related to functionality, user experience, or app issues. Responsible: Product Owner Accountable: Tech Lead |
||
| App Troubleshooting | If issues with the app are detected, DevOps must be able to execute symptom analysis, identify the root causes, and mitigate the problems. Otherwise, the application will not be adopted nor will it be successful. Responsible: Tech Lead, DevOps Engineer Accountable: Product Owner |
||
| Evaluate Business Case Metrics | Compare the application in production with the business case and metrics defined in the define needs phase to determine the success of the application. Determine adoption rate and develop a plan based on the findings. Responsible: Product Owner Consulted: Low-Code Adoption Expert |
||
| App Optimization | In the future, there might be a need to evolve the application, issue new releases, or deliver new features. Periodic product portfolio reviews can determine and prioritize the next steps. Responsible: Product Owner Consulted: BES PMO Adoption Champion, Low-Code Adoption Expert |
||
| Performance Monitoring | Continually monitor the application to identify possible future constraints and act on problems that may appear even before being reported. Responsible: DevOps Engineer, IT infrastructure management Consulted: Product Owner |
||
| Adoption Monitoring and Tuning | After a mobile app is live, measure user adoption and identify actions to increase user adoption. Responsible: Product Owner Consulted: Business User Stakeholders |
Figure 5. Low-Code Phases, Work Items and Roles Mapped to Agile Development Process.
Inevitably, in any discussion about digital transformation or Low-Code platforms, BES management or PMO business user stakeholders will ask, “what’s in it for us?" The best way to answer that question is to demonstrate business value as quickly as possible. That’s why in the Foundation Stage we recommended starting with a small project to demonstrate how little time it takes for a small agile team to get a working App. After seeing that, the BES PMO is ready to move on to bigger projects. In addition, key work items, including: App Business Case and Metrics Definition, App Estimation, Mockups – Low and High Fidelity, App Promotion, App Feedback, and Evaluation of Business Case Metrics after production roll out provide valuable insights into the success of the App roll out.