Examining the ongoing challenges of delivering high-quality, value-added ERP services in Higher Education.


Sunday, December 15, 2013

Scrum for ERP

As we attempt to implement our Student Information System (a quasi-ERP in most every way) using Agile/Scrum techniques, many interesting questions have arisen from the team. This article is the first of several in a series this week that analyze the special challenges of Agile/Scrum in the Student Information System context.

"Is Agile appropriate for a project of this nature?" 

It is true (at least to my knowledge) that we will be the first to apply Agile practices to PeopleSoft Enterprise Campus Solutions. This makes the team justifiably nervous, as there are no paradigms to follow or templates to steal. Moreover, search results for "Scrum for ERP" turn up articles such as this one that say things such as: "As far as I am concerned Agile methods have proven to be a disaster for ERP projects and I believe the Academic literature and case studies would prove that out." Now, I am not convinced there is a lot of "academic literature" devoted to this topic. Moreover, given that the road is littered with failed ERP projects and most ERP implementations follow traditional/waterfall approaches, it would be fair to say there are at least 10 failed waterfall projects for every Agile one. Find an infallible implementation methodology for ERP and you'll be a very rich man. (While I doubt that success pulling off my current project will lead to vast riches, a boy can dream.)

Fundamentally, the perceived conflict between Agile/Scrum and ERP extends from this mathematical logic: if Agile is designed for software development and packaged ERP is not about software development then ERP and Agile are incompatible, or to put it in mock mathematics: A = SD and COTS ERP != SD therefore A != COTS ERP. There are many reasons to dispute this logic, not the least of which is how much software we write to implement these systems. But I'll dive more into this topic in a separate post.

Plenty of us believe there is promise in Agile principles applied to the ERP context. This page on Jeff Sutherland's blog and the referenced white paper from SAP provide relevant context, suggesting how the principles can be applied. Also, a series at Guerilla Project Management also provides a lot of good advice (and I wish I had read it months ago!) for those in our situation. While there are several practical objections to the Agile "fit" that we can analyze and resolve one-by-one in reducing risk for our projects. Among the largest "issue" is the Scrum dictate of a single backlog and product owner. So let's start there.

Defining the Product Owner for ERP

I have been thinking about a lot about backlogs and products in the context of a multi-"module" software package. While it can be attractive to think about these packages as monolithic entities and they are often (but not always) purchased as such, my conclusion is that my software, PeopleSoft Campus Solutions, contains several products, to be extended and evolved in-house, that share common infrastructure elements; the infrastructure is, in itself, a discrete product delivered to the internal customer. Each of these products has a product owner responsible for prioritizing features, interfaces, extensions, and more. This model has imperfections:
  • Cross-product dependencies
  • Possible duplication of effort across teams
  • Possible investment in top priorities within a backlog that are not highest value across the program
  • Violates Scrum rules
For my organization what matters is that we are significantly more agile than we'd otherwise be, that we manage complexity and ambiguity better than we otherwise might, that we are more transparent and collaborative than if left to waterfall, and that we deliver working software and business value more frequently. Therefore, I will accept these risks graciously and do what I can to mitigate them. Here's how:
  • Weekly Product Owner meetings
  • Transparency of the backlogs -- including fully searchable database, cards on the walls
  • Ask PO and SM to periodically review the other backlogs
  • Establish über product owner (me) to assist each PO with themes, priorities, etc. 
  • Pull true cross-product or foundation elements into a separate backlog
Last week, we formed our teams and although there is some alignment with the logical "modules" defined by the vendor, we are trying to avoid anchoring ourselves to their definition. I am eager to see how Teams Red, Green, Blue, Purple, Orange, Silver, Yellow, and Tartan Plaid (subject to change) build, refine, and rank their backlogs (and as über owner I'll be paying close attention, yet letting the POs assert their sovereignty). For now, one of my answers to the concerns about "shared" product backlog items is that they're taking disproportionate share of our attention -- given the massive task ahead of us, we should govern ourselves according to the 80% cases! 

Some other issues that I'll cover on this blog in the next few days:
  • ERP Isn't Software Development; Agile is for Software
  • To Story or Not to Story
  • System Integration Testing: Where does it fit?
  • The Role of the PMO in Agile ERP 
And I'm guessing there will be more emerging topics to discuss.

posted by JasonShaffner @ 12:43 PM Add a comment!

3 Comments:

At June 24, 2014 at 4:12 AM, Anonymous Elizabeth said...

I enjoyed reading your blog ~ thanks for posting such useful content on "scrum for erp"

 
At June 9, 2017 at 1:58 AM, Anonymous University ERP said...

ERP software delivers high-quality value-added services in every university. It is based on a systemized arrangement of management.

 
At August 28, 2017 at 11:00 AM, Anonymous Anonymous said...

Oh, I love my ax dynamics erp software! The resource planning has never been so easy. I can't imagine my everyday work without this system, honestly.

 

<< Home