Sarbanes Oxley and Scrum

[Rohan D'Sa]

I keep running into a brick wall in my teams with documentation. There are folks who claim that we need to document in a lot of detail for SoX compliance.

What is your experience with that? How does this work with the 'Communication over extensive documentation' principle of Agile?

Would love to hear how I could counter the claims, if possible.

Regards,

Rohan

[Kamlesh]

Rohan,

I've worked on many initiatives in SOX regulated environment. It's not as big of a beast as it's always portrayed. If you have not already - I would highly recommend you connect with the SOX audit expert in your organization and understand the SOX requirements and guidelines.

This is what we've been doing for many years to meet SOX audit needs. I'm sharing, high level info from one of the initiative that passed SOX audit:

Business Impact: Medium

Documents furnished:

1- Approved Project Charter++ - 1 page

2- Approved Release Plan - 1 page

3- Approved User Acceptance Testing - 3 pages (Basically all our testing was automated and these pages were few screen shots and summary report of how many tests conducted, pass %, Fail%, etc)

Auditors "may" ask for proof of written requirements** - Grab photos of Team's Scrum board (Sprint Plan) each sprint / screenshot from an Electronic Tool and keep these photos handy.

** The requirements doesn't have to be written in lengthy BRDs and FRDs. Photos / Screen shots are valid from audit perspective.

++ Ask what's the right level of approver (Director/VP/SVP/...) for your initiative and get their approval at appropriate time.

Please connect with your organization's respective auditors and clarify what's acceptable and what's not.

Hope it helps. 

Kamlesh Ravlani
linkedin.com/in/ravlani | twitter.com/kravlani

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

[Pierre Neis]

Hi,

I did auditing/coaching in a global bank regarding SOX. We used ISAE 3402 protocols: http://isae3402.com.

PierreNEIS , Lean Agile Coach | Associate

Steaming still water!

M: +352 / 661 727 867 | pie...@wecompany.me

Luxembourg | Paris | Brussels | Geneva | Beirut

 

Next Conferences:

• Sept 11-13th, London, #play14London, http://london.play14.org/
  
• Oct 17 , Beirut, Agile Tour Beirut, http://www.agiletourbeirut.org/
• Nov 3-4th, Paris, Lean Kanban France, http://leankanban.fr/

[Rohan D'Sa]

Thanks a lot Kamlesh. Very useful insight.

We use Jira Greenhopper, so that should cover the sprint I think. Also, we mention everything in the story in terms of specifications.

I also hear of a number of random documents related to risk management which should be written. Have you ever come across those?

Regards,

Rohan

[Rohan D'Sa]

Pierre,

My question was more regarding affecting the normal way of working in Scrum and the effect SoX has on it in terms of extensive documentation.

[Pierre Neis]

@Rohan

If you follow basic Scrum, you don't have any issues here i.e. SoX doesn't impact it.

Now, basic Scrum means also:

- have a DoD

- have a DoR

- 1 piece of paper with the meetings

- 1 template for US

- having Minutes

You can take this http://www.infoq.com/minibooks/scrum-checklists to cover the most SoX points in a day to day work.

BTL, SoX wants to know if you have a process and so far Scrum can be described as one, an empirical one.

SoX isn't a deliverable (outcome) it's just part of the DoD.

ᐧ

PierreNEIS , Lean Agile Coach | Associate

Steaming still water!

M: +352 / 661 727 867 | pie...@wecompany.me

Luxembourg | Paris | Brussels | Geneva | Beirut

 

Next Conferences:

• Sept 11-13th, London, #play14London, http://london.play14.org/
  
• Oct 17 , Beirut, Agile Tour Beirut, http://www.agiletourbeirut.org/
• Nov 3-4th, Paris, Lean Kanban France, http://leankanban.fr/

[Rohan D'Sa]

On Thu, Aug 13, 2015 at 1:39 PM, Pierre Neis <pie...@wecompany.me> wrote:

SoX isn't a deliverable (outcome) it's just part of the DoD.

​Thanks for your reply, Pierre. That is what I also understood. However, I wanted to look at SoX practices to see that the DoD doesn't get bloated with unnecessary documentation.​

I will look at the link you sent and get back to you.

[Ron Jeffries]

Hi Rohan,

On Aug 13, 2015, at 7:18 AM, Rohan D'Sa <roha...@gmail.com> wrote:

My question was more regarding affecting the normal way of working in Scrum and the effect SoX has on it in terms of extensive documentation.

I’ve found in general that companies demand more SoX-related docs of themselves than compliance actually requires. As was suggested, you really ought to work with a real SoX auditor to find out what’s needed.

There is no rule against extensive documentation in Agile or Scrum: you build what you have to build. I believe that all documentation should be built as you go, so that it is ready to ship with the features. That is, if you build a feature in a Sprint, just as it should be analyzed, tested, coded, refactored in that Sprint, it should be documented to the desired level as well.

Regards,

Ron Jeffries

ronjeffries.com

An Agile method is a lens. The work is done under the lens, not by the lens.

[Ron Jeffries]

Pierre,

On Aug 13, 2015, at 7:39 AM, Pierre Neis <pie...@wecompany.me> wrote:

Now, basic Scrum means also:

- have a DoD

- have a DoR

- 1 piece of paper with the meetings

- 1 template for US

- having Minutes

I believe that one of these is actually part of Scrum. All of them might be useful.

Ron Jeffries

ronjeffries.com

I don't necessarily agree with everything I say. -- Marshall McLuhan

[Yves Hanoulle]

2015-08-13 14:27 GMT+02:00 Ron Jeffries <ronje...@acm.org>:

Hi Rohan,

On Aug 13, 2015, at 7:18 AM, Rohan D'Sa <roha...@gmail.com> wrote:

My question was more regarding affecting the normal way of working in Scrum and the effect SoX has on it in terms of extensive documentation.

I’ve found in general that companies demand more SoX-related docs of themselves than compliance actually requires.

+ 1 on that.

 

As was suggested, you really ought to work with a real SoX auditor to find out what’s needed.

There is no rule against extensive documentation in Agile or Scrum: you build what you have to build. I believe that all documentation should be built as you go, so that it is ready to ship with the features. That is, if you build a feature in a Sprint, just as it should be analyzed, tested, coded, refactored in that Sprint, it should be documented to the desired level as well.

Regards,

Ron Jeffries

ronjeffries.com

An Agile method is a lens. The work is done under the lens, not by the lens.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--

-- 

Yves Hanoulle 

Current community projects that need YOUR help:

• Community Tips for hiring a great team: http://www.hanoulle.be/hiring 
  
• Community Tips for Coaches: http://www.hanoulle.be/2015/06/community-tips-for-coaching/  
  
• Scrummaster and agile coaches survey: http://www.hanoulle.be/2015/05/salarysurvey/ 
  
• Who is agile "your country version"  >> mail me
  
• CoachRetreat in your country >> mail me
• CoderDojo's all around the world looking for coaches. This is the Belgium subscription page http://www.coderdojobelgium.be/inschrijvingsformulier-mentor

[Pierre Neis]

@Ron.... exactly... this is what I tried to figure out... we have all the stuff in scrum

ᐧ

PierreNEIS , Lean Agile Coach | Associate

Steaming still water!

M: +352 / 661 727 867 | pie...@wecompany.me

Luxembourg | Paris | Brussels | Geneva | Beirut

 

Next Conferences:

• Sept 11-13th, London, #play14London, http://london.play14.org/
  
• Oct 17 , Beirut, Agile Tour Beirut, http://www.agiletourbeirut.org/
• Nov 3-4th, Paris, Lean Kanban France, http://leankanban.fr/

[Rohan D'Sa]

On Thu, Aug 13, 2015 at 2:27 PM, Ron Jeffries <ronje...@acm.org> wrote:

There is no rule against extensive documentation in Agile or Scrum: you build what you have to build. I believe that all documentation should be built as you go, so that it is ready to ship with the features. That is, if you build a feature in a Sprint, just as it should be analyzed, tested, coded, refactored in that Sprint, it should be documented to the desired level as well.

​Absolutely agree, Ron. But most 'larger companies' have millions of sheets / checklists etc. that you need to fill well before you start building software or well after you're done. I'm not saying all of it is useless, but I just wanted to pointedly counter the SoX argument so that it does not interfere with the spirit of healthy, frequent communication among the team members.​

[Ashish Pathak]

Hi Rohan,

I too have worked in a 'large company' where SOX compliance was imperative. But we never let it come in our way! All we did was establish a technical feasibility date of the release and support it with a high level design document. It need not have a completely frozen/baselined design. We chose the 1st few sprints to establish this technical feasibility. The teams would have worked on the most important functionality by then and knew if the release was technically feasible. All effort after that would go as an expense. We ensured we leveraged some of our enterprise tools like JIRA, Confluence to structure and capture data at source. 

We never felt overwhelmed by the SOX requirements since we blended them in our development process. These were part of our DoD. We also engaged with our finance and explained how iterative and incremental development works and how they can tweak there process a little and become. We helped them map their regulatory requirements to Agile practices.

Ashish

Scrambled by my iPhone 6