Comments on: Guideline : How to Audit an Agile Project ? http://www.rgopinath.com/2011/12/06/guideline-how-to-audit-an-agile-project/?utm_source=rss&utm_medium=rss&utm_campaign=guideline-how-to-audit-an-agile-project Pragmatic, Hands-on, Result-oriented Process Consulting and Training Thu, 23 Mar 2017 12:03:51 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Satya http://www.rgopinath.com/2011/12/06/guideline-how-to-audit-an-agile-project/#comment-77794 Satya Thu, 23 Mar 2017 12:03:51 +0000 http://www.rgopinath.com/?p=631#comment-77794 This is very interesting. How do we see this guideline in the view of CMMI Maturiy Level 5 compliance? This is very interesting. How do we see this guideline in the view of CMMI Maturiy Level 5 compliance?

]]> By: Gopinath http://www.rgopinath.com/2011/12/06/guideline-how-to-audit-an-agile-project/#comment-3802 Gopinath Fri, 02 Aug 2013 15:35:45 +0000 http://www.rgopinath.com/?p=631#comment-3802 Mikael, I agree that the statement of user-stories alone may not satisfy ISO. You may be aware that the purpose of the user story is to trigger, Conversation & Condition of Acceptance. Where necessary it also needs to be supported by artifacts like wireframes, screenshots , architectural diagrams. Besides an ideal user-story needs to satisfy INVEST (Independent, Negotiable, Valuable, Estimable, Sized appropriately and Testable). This combined with several good engineering practices (mainly from XP) like TDD, Continuous Integration, Refactoring, Unit Testing, Code reviews etc. will meet most of the ISO requirements. Acceptance Test Driven Development is another new trend which is catching up where the requirements are written in form of acceptance tests. Thanks for the reference to the Stålhane & Hansen's paper. I have downloaded it from the net and will go through it. Mikael, I agree that the statement of user-stories alone may not satisfy ISO. You may be aware that the purpose of the user story is to trigger, Conversation & Condition of Acceptance. Where necessary it also needs to be supported by artifacts like wireframes, screenshots , architectural diagrams. Besides an ideal user-story needs to satisfy INVEST (Independent, Negotiable, Valuable, Estimable, Sized appropriately and Testable). This combined with several good engineering practices (mainly from XP) like TDD, Continuous Integration, Refactoring, Unit Testing, Code reviews etc. will meet most of the ISO requirements. Acceptance Test Driven Development is another new trend which is catching up where the requirements are written in form of acceptance tests.
Thanks for the reference to the Stålhane & Hansen’s paper. I have downloaded it from the net and will go through it.

]]> By: Mikael http://www.rgopinath.com/2011/12/06/guideline-how-to-audit-an-agile-project/#comment-3800 Mikael Fri, 02 Aug 2013 12:17:22 +0000 http://www.rgopinath.com/?p=631#comment-3800 Well I was not so much thinking of signed documents as documented evidence. I.e. ISO actually demands evidence. This can be done by photos of the white board. In additions user-stories alone may not satisfy ISO but you may need to consider adding acceptance criteria or some other less ambiguous means to satisfy the ISO requirements. There are a few papers discussing this in particular Stålhane & Hansen's excellent paper - The application of ISO9001 to agile software development. Product-Focused Software Process Improvement 9th International Conference, PROFES 2008, LNCS, Vol 5089, pp. 371-385. Springer, Heidelberg (2009) Well I was not so much thinking of signed documents as documented evidence. I.e. ISO actually demands evidence. This can be done by photos of the white board.

In additions user-stories alone may not satisfy ISO but you may need to consider adding acceptance criteria or some other less ambiguous means to satisfy the ISO requirements.

There are a few papers discussing this in particular Stålhane & Hansen’s excellent paper – The application of ISO9001 to agile software development. Product-Focused Software Process Improvement 9th International Conference, PROFES 2008, LNCS, Vol 5089, pp. 371-385. Springer, Heidelberg (2009)

]]> By: Gopinath http://www.rgopinath.com/2011/12/06/guideline-how-to-audit-an-agile-project/#comment-3702 Gopinath Mon, 29 Jul 2013 12:25:06 +0000 http://www.rgopinath.com/?p=631#comment-3702 @Mikael: Thanks for your comments. I agree that the checklists cover only Scrum and the compliance with ISO 9001 is not very explicit in it. But they cover all the ISO requirements in spirit . To reconfirm I read through the ISO 9001 standard , all the clauses you have mentioned and I did not find anything which is a blocker to agile implementation. Any reasonable and pragmatic ISO auditor will not raise issues if you are following Agile in true spirit. Yes you may face some problems if the auditors start asking for formal signed-off documents. This usually happens when the auditors do not interpret ISO correctly and also do not understand the process of Agile development. But it will be good in the longer run if you could take up the challenge of convincing the auditor that the practices you are following meets the intent of ISO. Agile per se is not against documentation. It advocates writing documents that makes sense, to the details it makes sense (i.e. don't over document) and to the formality it makes sense to the business. Your questions are very relevant and have prompted me to think about writing a blogpost on how to map ISO & Agile practices. Hopefully I will do that very soon. @Mikael: Thanks for your comments.
I agree that the checklists cover only Scrum and the compliance with ISO 9001 is not very explicit in it.
But they cover all the ISO requirements in spirit . To reconfirm I read through the ISO 9001 standard , all the clauses you have mentioned and I did not find anything which is a blocker to agile implementation.
Any reasonable and pragmatic ISO auditor will not raise issues if you are following Agile in true spirit.
Yes you may face some problems if the auditors start asking for formal signed-off documents. This usually happens when the auditors do not interpret ISO correctly and also do not understand the process of Agile development. But it will be good in the longer run if you could take up the challenge of convincing the auditor that the practices you are following meets the intent of ISO.
Agile per se is not against documentation. It advocates writing documents that makes sense, to the details it makes sense (i.e. don’t over document) and to the formality it makes sense to the business.
Your questions are very relevant and have prompted me to think about writing a blogpost on how to map ISO & Agile practices. Hopefully I will do that very soon.

]]> By: Mikael http://www.rgopinath.com/2011/12/06/guideline-how-to-audit-an-agile-project/#comment-3676 Mikael Sat, 27 Jul 2013 14:09:23 +0000 http://www.rgopinath.com/?p=631#comment-3676 The checklists you mention only cover Scrum. How do you audit ISO compliance? ISO 9001 Clause 7.2.2 states that where the customer provides no documented statement of requirements, the customer requirements shall be confirmed by the organisation before acceptance. In Scrum this may be a challenge. assuming the product backlog is complete and approved by the client (which is not given) then if only user stories are given and no formal requirements exist the team may not comply. Further, clause 7.3.1 says that the organisation shall determine the design and development stages. This can probably be mitigated, but how do you audit it? Other clauses which are challenging includes 7.3.3, 7.3.4, 7.3.5, 7.3.7, 8.1, 8.2.3, 8.2.4, 8.5.2, 8.5,3. I don't think the checklists you have suggested cover any of these clauses. However I so think these clauses can be satisfied but it may demand some tailoring of the basic scrum process. How have you audited these aspects? The checklists you mention only cover Scrum. How do you audit ISO compliance? ISO 9001 Clause 7.2.2 states that where the customer provides no documented statement of requirements, the customer requirements shall be confirmed by the organisation before acceptance. In Scrum this may be a challenge. assuming the product backlog is complete and approved by the client (which is not given) then if only user stories are given and no formal requirements exist the team may not comply.
Further, clause 7.3.1 says that the organisation shall determine the design and development stages. This can probably be mitigated, but how do you audit it?
Other clauses which are challenging includes 7.3.3, 7.3.4, 7.3.5, 7.3.7, 8.1, 8.2.3, 8.2.4, 8.5.2, 8.5,3. I don’t think the checklists you have suggested cover any of these clauses. However I so think these clauses can be satisfied but it may demand some tailoring of the basic scrum process. How have you audited these aspects?

]]>