[SCRUMDEVELOPMENT] Agile SOX

[Michael Wollin [e-mail] [SCRUMDEVELOPMENT]]

In the conversations I’ve been having with my client’s internal SOX compliance people, we have reached agreement that SOX can be handled partly in the acceptance criteria of the stories and partly with the Definition of Done. But we have hit a snag.

In their world, the User Acceptance Testing requirement can be met by the Product Owner, coming from the business, accepts the story as done. Alas, there may be a need to have a proxy product owner in some cases who is from the Information Management department and not the business. Not our first choice, but If this should be necessary, the SOX people don’t feel the Proxy PO can do UAT and be compliant.

Looking for wisdom and for references to authoritative and/or insightful articles too.

Michael

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Michael,

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
In the conversations I’ve been having with my client’s internal SOX
compliance people, we have reached agreement that SOX can be handled
partly in the acceptance criteria of the stories and partly with the
Definition of Done. But we have hit a snag.
In their world, the User Acceptance Testing requirement can be met by
the Product Owner, coming from the business, accepts the story as
done. Alas, there may be a need to have a proxy product owner in some
cases who is from the Information Management department and not the
business. Not our first choice, but If this should be necessary, the
SOX people don’t feel the Proxy PO can do UAT and be compliant.
Looking for wisdom and for references to authoritative and/or
insightful articles too.

I would rejoice that they're going to insist you have a real PO, and are
going to make it happen.

Other than that, what do they suggest for getting PO approval of the
acceptance tests developed with the PO Proxy?

There's no magic to SOX or any other compliance auditing. It's all about
working with the auditors. Try to see the goals from their point of view
and work to let them know that you have the same goals. Work
side-by-side to develop a successful and acceptable solution.

- George

['Voris, John' [e-mail] [SCRUMDEVELOPMENT]]

There are probably a few articles out there.
I agree that you will have to adapt to the Auditors, but beware that it could be the case that their requirements change with each new group of young auditors that arrive each year.
But as long as your P.O. accepts a signoff from the "Proxy P.O. for I.T. Requirements that includes SOX", you should be good.

This dilemna is also faced by Pharmaceutical firms that have FDA and documentation tasks embedded into either Acceptance criteria or Defn of Done requirements.
I would think that the philosophy that "Agile and Quality are built in at the beginning and at every step in the process" would also apply to SOX requirements.
But convincing auditors that your light-weight process adheres to their requirements, too, could be your biggest challenge.

And I wonder if utilitizing a group Peer Code Review might be one avenue to instill the notion into lower team members of SOX requirements - - where you have 3 reviews per program, 2 for quality and 1 of the three done by someone putting on their SOX hat. That person on the team should rotate every so often.

John Voris, AgilePhilly

Post by Michael Wollin ***@mercurysw.com [SCRUMDEVELOPMENT]
Looking for wisdom and for references to authoritative and/or insightful articles too.
Michael

['Steve Ash' [e-mail] [SCRUMDEVELOPMENT]]

Hi all



Have read the other replies and concur but here is my 'take'.



Let me start by saying I have never been involved with SOX auditors (wrong
side of 'pond').

However, I have been involved with auditors in other fields both internal
and external and this is the way I have addressed the 'problem' with success
although sometimes more 'painful' than it really needed to be:



Auditors are stakeholders!

Ask them for their User Stories (May need some training here)

Sometimes their User Stories become Non-Functional requirements (however you
handle them in your organisation)

Order, estimate and prioritise just as you would all the other requirements
(US/PBI).

Get Acceptance Criteria

Talk to them about the details when needed.

Get them to UAT their US

Simples!!!



Sometimes I have had pushback from them initially but when 'The Agile Way'
is explained, they come round to the idea and having tried it they realise
that their 'life' has been made easier.



You need to 'dangle carrots' to get people to change!!



Steve Ash

[Pierre Neis [e-mail] [SCRUMDEVELOPMENT]]

Hmm, not that easy to respond according that SOX is more less an acceptance

criteria.
Now, the purpose of agile is only having "pigs" meaning that our

stakeholders should also be "engaged".


Regarding to the basics of Audit, you will have 2 actors:
- external audit: in charge with measures, issues, variability, status and
risk level -- attending time to time
- internal audit: preventing the organisation from severity issues and
attending more often.


For both, it's quite easy to make them run as an agile team. But, is their
behaviour with the audited-people "agile"?


This is really a niche!


Now, you have ISAE 3402 (I guess) protocols supporting SOX. These protocols
are measuring if the work done is relevant to SOX. Then it makes perhaps
sense to see how agile is responding to those protocols.


Pierre
*NEIS*Senior Lean Agile Coach | Associate
M: +352 / 661 727 867
wecompany.me | You can book me <https://pierreneis.youcanbook.me/>

Post by 'Steve Ash' ***@ootac.com [SCRUMDEVELOPMENT]
Hi all
Have read the other replies and concur but here is my ‘take’.
Let me start by saying I have never been involved with SOX auditors (wrong
side of ‘pond’).
However, I have been involved with auditors in other fields both internal
and external and this is the way I have addressed the ‘problem’ with
Auditors are stakeholders!
Ask them for their User Stories (May need some training here)
Sometimes their User Stories become Non-Functional requirements (however
you handle them in your organisation)
Order, estimate and prioritise just as you would all the other
requirements (US/PBI).
Get Acceptance Criteria
Talk to them about the details when needed.
Get them to UAT their US
Simples!!!
Sometimes I have had pushback from them initially but when ‘The Agile Way’
is explained, they come round to the idea and having tried it they realise
that their ‘life’ has been made easier.
You need to ‘dangle carrots’ to get people to change!!
*Steve Ash*