For me, who has been practicing the Agile in the IT industry for much of my career, earlier project management methodologies appeared as a big evil monster which try to control everything. After recently being certified as a PRINCE2 Practitioner, I felt like sharing current understanding and experience in a light read with the engineering community which may benefit large enterprise level Agile IT projects.
When looking into PRINCE2, the very first challenge was that it all appeared like geared towards Waterfall and a lot focused on control, for example its principle about Manage by Exception. The other challenge was, some really confusing terms like Configuration Item which can easily be termed as an artefact, basically anything (document, software etc which requires a version and status). Another example of confusing term was Product. In PRINCE2, Product can be of two types i.e. Management or Specialist. In essence Management Products are really documents created to support project like Project Plan and Specialist Products are parts of the final Product and would be handed over to the customer like software etc, though it can be documents as well.
Initially, there was a time when the dominant thought was that PRINCE2 may not be suitable for an Agile IT project. However, after much experience and analysing its potential application to some previous experiences, a light bulb was lit up that a tailored version (Tailor to the Environment) of PRINCE2 may be a necessary evil for the large enterprise Agile IT projects.
Let’s start with some of my experiences about what a typical large Agile IT projects lacks, for example lacking a coherent structure for the whole of the project. It is not to say that projects have no structure at all but more to say that it misses the coherent element and an end to end view of the project. Following are some specific areas:
i. When talking about enterprise level IT projects, Agile does not really discuss all the roles and responsibilities needed for a project. While Scrum is a good approach to structure a delivery team, it discusses less about large enterprise project team. For example, if the Scrum Master is not really responsible for the delivery then who is really responsible for the delivery of the artefact? Who to go to when there is an issue?
ii. On some projects, teams appear a bit distracted and appear disjointed towards the main product and end up spending time on less valuable artefacts or trying to fix a non-existent problem. Sometimes it leads to duplication of efforts or other times creating some unnecessary artefacts which are considered reusable, but no one really reuses them. In some cases, it leads to release nightmare as dependencies are less understood at an earlier stage. A number of companies and projects try to use the mechanism of Scrum of Scrums or something similar, but does it really work?
iii. While inherently Agile is supposed to deliver software as needed by the business but occasionally on long-running Agile projects, the technical delivery may be very good, but business may appear less interested in using it. One of the examples is of a large public sector project which was delivered on time and budget but never went live.
iv. Agile also seems to miss some other cool bits related to project management. For example, there is a principle about reflecting at regular intervals to become more effective which is typically done as retrospective ceremony but there is little or no attention to the lessons from previous projects and how learning can be applied to the future projects.
v. Documentation and reporting progress are also challenging on an Agile project. Agile is heavily influenced with the XP-Extreme Programming. I am an advocate of XP but probably not at the cost of the project or post project life cycle of the application. No documentation may appear very compelling to some during the project but may not look so compelling when looking at the end to end life cycle of the product. There can be situations where you have just code with a sea of fragmented wiki pages. For example, on one project we just had compiled Java code with even no source. Did it really help the next project or was it used more as a kind of mechanism to lock the client so no one else knows how it works and let the client suffer should they decide to go with a different provider?
PRINCE2 seems to appear as a good methodology to manage above mentioned gaps in on a large Agile IT project. For example, it provides a solid structure for the end to end life cycle of a project which helps not only the management team, but it can also help the development and delivery teams to see the relationship with other components and see the non-technical bigger picture. I think PRINCE2 can nicely fill above mentioned gaps:
i. Define Roles and Responsibilities and Manage by Exception principles and related concepts offers well-defined roles and responsibilities which can help to structure project teams relatively better. For example, for a large Agile IT project, a Scrum Master can facilitate a delivery team and a Project Manager can act as a Team Manager. It would allow, the team to focus on the development, a Scrum Master to facilitate them, a Project Manager to take the responsibility of delivery and an Executive to take the responsibility of the overall Business Case. It would put less strain on the Project Manager to facilitate technical aspects as one may not be technical at all. On the other hand, less strain on the Scrum Master as one does not have to be responsible for the delivery but purely facilitation (A true Scrum Master which I have rarely seen in the practical life). This also nicely address the challenge of whom to go to when there is a problem. Please note these are roles and not the person. One person may fill different roles, though some roles cannot be combined.
ii. The Focus on the Product principle and related concepts like Project Product Description, Product Breakdown Structure, Product Description and Product Flow allows keeping team focused on what is needed. It also allows seeing how these teams contribute to the overall Business Case for the project. Even an Executive can see the need of any team and how long it is needed for from a very high level. There is absolutely no harm in using Jira or similar tools to create the same structure but in this instance links are clearer, priorities are more organized, and team has more structured view of the end Product and its link to the Business Case. By all means, it does not suggest that you should describe all details up front before beginning of the project as it would just kill Agile, however you have an earlier structure in place and a Product Description can be matured at even the Work Package level. This also helps to map Product for the release cycle and see what is needed for what stage.
iii. Continued Business Justification and Manage by Stages principles can really help with the projects like large public sector project mentioned above which never went live. While teams Focus on Product and delivery, at a higher level management keep evaluating the business justification at each stage. Should a Product fail to justify its value to the business at any stage, it is relatively easier to identify associated risk and allocated people and resources. It helps management to justify its continuity or premature termination. In other words, Products are only continued when it makes sense to continue not only at the micro (team level) but also at the macro (corporate management level).
iv. Learn from Experience is a core principle of PRINCE2. It mandates and encourages to not only actively capture lesson in the Lesson Log and reflect or refer them in the End of Project Report but also apply lessons from previous projects at early stages of the project during the Starting Up a Project process.
v. PRINCE2 allows mature structure around mandatory documentations like Risk Register, Quality Register, Check Point Reports and in some cases provides a template to start with. It would also help to sort out pain of management reporting. The structure of Project Product Description, Product Breakdown Structure, Product Description and Product Flow, their related Work Package structure and stages allows management to assess the project progress more rigorously. As mentioned earlier, there is absolutely no harm to use tools like Jira for such structure. It is more about structure and reporting rather than what tool you use. Jira can be configured in a way which produces the statistics and reports needed by the management like Check Point Reports. It would allow Project Manager and teams to focus on the delivery rather than wasting much precious time on reporting.
In summary, I see project structure is a necessary evil for the large enterprise Agile IT projects. PRINCE2 appears as a good methodology to provide such structure, though it should be tailored (Tailor to the Environment) to suit the project as needed while maintaining the integrity using its 7 core principles.
