If you have never heard of the buzzword “Agile” before, then you must have been living in Mars!
This is what every Manager wants to have, but not everyone can actually pull it off in its true sense.
Being a big supporter of agile technology, I have found the experience of implementing agile methodology in private and public sector remarkably different. Below is a summary of the differences between the two. For public sector, I have mainly focused on regulatory or policy driven projects. Please note that these are my personal opinions only and in no way contradicts others views.
| PRIVATE | PUBLIC (Regulatory/Policy Driven/Ministerial) |
| Much easier to adopt agile methodology as you have more autonomy to deliver projects | Where the project is regulatory or policy driven or Ministerial, it is not possible to use agile methodology. Since these regulations/policies come to effect on a particular date, the application(s) have to be released on or before those dates as a whole and fully tested. However smaller applications that enhance customer experience and are non-regulatory can be agile. |
| The key principles of agile methodology can be incorporated into the SDLC process: (1) fluid requirements (product backlog) but fixed time frame (2) capture product backlog at high level which is lightweight and visual (3) develop small incremental releases and iterate (4) complete one feature fully before moving to the next (5) testing throughout project life cycle – test early and often, and (6) collaboration with sponsor and business stakeholder at every level. | For regulatory/policy driven/Ministerial projects, SDLC follows a waterfall method. As part of this methodology, you need a Business Requirement Document (BRD) that captures all requirements, a Project Management Plan (PMP) that articulates the schedule, budget and risks/issues, Solution Design Document (SAD) that explains the technical details of the project and Test Strategy/Test Plan that explains how testing will be performed. In the waterfall method, the application/solution is only handed over to testing once development is completed. |
| If scrum based agile methodology is adopted, then each sprint spans approximately 2 weeks. You can have multiple sprints per phase of test driven development (TDD). You should be in a position to have incremental releases at the end of every sprint. Both development and testing should be completed at the end of the sprint. | The lead time between conception of the project and ultimate delivery could be 6-12 months. |
| There are only three roles in scrum: Scrum Master, Product Owner and Delivery/Development Team. Time boxed scrum meetings are held daily. Scrum Master enforces that only the delivery team participate in the daily scrum. | Project delivery is a collaboration among different siloed portfolios. A PM from portfolio delivery manages the project, Business Analyst (BA)/Solution Designer (SD) from the same portfolio delivery documents the key requirements. Development, Testing and Environment Support manage the build and implementation to production. Production integration manages the infrastructure and incidents. Weekly stand up meetings are held that involve representatives from all these groups. |
| Meeting with stakeholders (i.e. clients) is more informal. | Program/project status meeting is a formal event involving business sponsor and other stakeholders. This is in addition to status report from the PM. |
| Requirements gathering in the form of product backlog and User Manual documentation is an ongoing activity throughout the SDLC. There is no need for a formal BA and/or a SD. The Development Manager collects all the product backlog from the clients. | All requirements are completed in the form of a BRD (Business Requirements Document) and approved before build process begins. This requires early engagement of a BA and/or a SD to conduct workshops with business SME. |
| Adopts test driven development (TDD) which means that you test the application/solution as you develop, so that at the end of the sprint when development is completed, so is testing. | The application/solution is handed over to testing only after development has been fully completed. |
| Automation suite is created in a variety of technologies to support iterative regression of sprints. | Automation suite is created only in approved toolset. It is therefore critical to have a long term tool strategy, as changing preferred toolset in the middle of the project is not feasible due to the long approval process. |
| Client is embedded in the SDLC where they are invited to run sanity tests at the end of every sprint | Business is invited to participate in UAT (User Acceptance Testing) only when the code has stabilised and there is no critical (sev-1) or major (sev-2) severity defects outstanding. |
| Since client gets to review and test the incremental outcome of every sprint, the delivery is lightweight and matches client expectations. | Since business participates late into the SDLC when code stabilises, the interpretation between development/testing and business may be different. As such, change requests are raised to resolve those differences. |
| Application Development and Test Manager plan the entire agile delivery model and sprints. | Every team (BA/SD/Development/Testing/Environment Support) has its own estimate and schedule. PM is responsible to combine these into a proper schedule and acquire approval from business stakeholders. |
| Scrum Master is responsible for all reporting to the clients. | PM is responsible for all reporting to the business stakeholders. |
| Application Development, Test Manager and Accounts Manager are responsible for keeping track of expenditure to stay within the stipulated budget. | Resource managers assign the resources to the project, but the PM is responsible for keeping an eye on the expenditure. If the project exceeds the allocated budget, then a change request is lodged with business to ask for more funds. The process could be cumbersome and time consuming. |
Notwithstanding the above differences, it is still possible to adopt some of the principles of agile methodology in the public sector. For example, you can adopt the sprint concept of agile methodology. In this case, it is closer to iterative development than agile development as you do not have incremental releases at the end of each sprint. However, it benefits the SDLC process when you are light in requirements gathering. Smaller applications (desktop/web/mobile) that are non-regulatory/policy driven/Ministerial and increases customer experience are good examples for adopting the agile methodology.
Moving to agile based delivery mechanism in public sector requires a cultural shift as well as innovation to the work practice. The entire project delivery needs to be broken into features that can be released in incremental fashion. Business has to be fully embedded into the project to assist with testing each of the features after a sprint. The Managers from different teams, the PM and Business Sponsor/SME should have some degree of autonomy to make decisions quickly. Key artefacts such as law letters, notifications etc. which require approval from policy departments need to be completed well in advance of the build process. There should be appetite to release applications in piece meal fashion to a url that is not made public until the date of the release. Alternative option to this should be further explored where the application is opened to a closed group of customers as part of a pilot deployment. And finally, the CapEx budget process should be adjusted to incorporate the agile methodology. An agile development approach needs to be driven by the capital budget, not the operating budget (referenced from: http://www.cio.com/article/3061232/agile-development/3-misconceptions-cios-have-about-agile.html ).
I would recommend reading the article “3 Misconceptions CIOs have about Agile”: http://www.cio.com/article/3061232/agile-development/3-misconceptions-cios-have-about-agile.html
Learn the Art of Software Testing 