When delivering with agile - how does assurance play its part?
The new government ICT strategy details ‘Agile’ methodology as the way forward.
The Major Projects Association (MPA) ensures the integrated assurance of big central government projects. The MPA mandate all major projects to have an Integrated Assurance and Approval Plan (IAAP) and departments are required to submit an IAAP for each major project for validation by both the MPA and Treasury.
In an agile environment: individuals, communication, collaboration, flexibility are king. Whereas: plans, processes, tools, documentation, contract negotiation are more conventional terms used in delivery methodologies.
In terms of providing assurance to stakeholders in an agile environment how does our approach have to change? The traditional style seems at odds with the agile principles.
Certain types of assurance expect to see documentation, plans, review points and, in fact, so do some of our clients. What happens when supply-chain implement agile when the client’s expectations’ or commitments’ don’t ‘fit’ the agile model?
The agile methodology is changing our views on delivery - shifting our attention to smaller teams incrementally delivering quality products instead of the conventional lifecycle methodology.
We need to think about the role of assurance in agile environments as it is definitely NOT business-as-usual.
What about legalities and/or safety-critical issues when delivering with agile – how does assurance play its part?
Will assurance in an agile world mean: face-to-face conversations, better collaborations between acceptance (testers) and developers, developers and designers, suppliers and end-users?
Does integrated assurance in an agile world mean that we have to re-think the definition of ‘integration’ to one that stems back to basics where clients and delivery teams communicate and collaborate?
Where we have to redefine roles and responsibilities for delivery and end-users alike?
The APM Assurance SIG is looking to supplement its own understanding of best practice in the assurance of agile projects with case study examples and methodologies.
We plan to begin a forum debate on the subject in the near future that will lead to a joint event with the National Audit Office on the subject in the summer 2012.
If you wish to get involved or have any suggestions/queries, please feel free to contact the Assurance SIG>
3 comments
Log in to post a comment, or create an account if you don't have one already.
Firstly, thank you both for your responses to this blog entry.David - thanks for the suggestion, I will use the information where appropriate and also refer to the data as part of the SIG KnowledgeBase?Adrian - The Assurance SIG wants to hold this forum debate and joint event with the NAO to ensure that points such as the ones you raised are debated. There is a lot of demand for 'Agile' and a lot of companies seem to be adopting this practise but I wonder if some of these organisations truly understand how, and what has to change within the organisation to make Agile work.We do not want to debate the need for, nor the means in which Agile can be adopted but focus our attention to how to provide Assurance in such an environment. I, for one, cannot wait to debate whether it is an 'adapted' form of Assurance or a 'new' form of Assurance that is needed I hope that both of you (and lots of others reading this) can attend the forum and event as I know that your thoughts/experience will be invaluable in this debate.Thanks againNaveed
I suggest you explore the DSDM Consortium documentation as I believe that to prescribe a reasonably robust assurance framework.
I welcome this examination into the world of agile projects by the Assurance SIG. Some will know that I have been scathing about so-called agile project management. To date I have seen no evidence of such a thing. Two points;1] an agile PM method needs to be able to demonstrate real difference - clear blue water - between it and say, APM BoK, Prince/2, PMI Bok...whatever2] the whole point about being professional project, programme, portfolio managers is our ability to adapt generic methods to the needs of the project etc.So, same question as ProgM is seeking to answer in relation to different kinds of programme management; is there an evolution of project management into a new species which we can call agile project management? Or do we simply adapt at need?In truth the answer may be moot as in any case we could do with some guidance on the project management of agile projects, be they IT, engineering or whatever.What I can do without is yet another book claiming to define agile PM but which in truth is just an adaptation of generic PM. These are of little use as they start from a premise of "new" as opposed to; "so how do make this work in my organisation?"Good luck to the Assurance SIG.