Examining the ongoing challenges of delivering high-quality, value-added ERP services in Higher Education.
Sunday, December 15, 2013
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.
Tuesday, December 3, 2013
Today was intended to be our first real step into Scrum. Coach Frank arrived early and checked out our wall of user stories – considering how new most of the team is to the methodology, we had accomplished a lot. We were feeling great. We were ready to plan the first sprint.
Or not. It quickly became apparent that we don’t have a clear definition of our product, and that’s kind of a problem. Just a minor trifling matter.
How the hell could we possibly think we were ready if we don’t even know our product? What’s wrong with you, Shaffner? Jeez. But before you lose all semblance of respect for me, let’s break this down. I knew we would face this problem, and although I don’t have the answer at the ready, I have complete confidence we’ll figure it out. Together, as a team.
We are treading unsteady ground: to my knowledge, there has
never been a Scrum implementation of Oracle’s PeopleSoft Campus Solutions. The consulting team members on-site at my institution have somewhere on the order of 150 years’ experience implementing this software package and every project followed a waterfall methodology, although the team has experience with some iterative techniques. As a result, there is no blueprint for us to follow.
[And a word for those of you unfamiliar with this software suite – Campus Solutions is a suite of inter-connected modules, more or less aligned with student-related business processes: Student Financials, Financial Aid, Student Records, Admissions, Advisement, and a somewhat confusing module called Campus Community where shared data and frameworks are managed. The technology is Java-based but mostly rooted in an interactive development environment known as PeopleTools. We are also implementing OBIEE.]
The debate before us is not new – ERP teams often look askew at Scrum, noting that implementing a commercial off-the-shelf application is completely unlike building new software from the ground up; meanwhile, the hard-core agilists bring tales of using Scrum for Thanksgiving dinner.
One conceptual approach could be that we have
one product -- the student information system -- which would dictate one product backlog, forced into an ordered stack. We plan to go live with the student financials area first (November 2014) so presumably all the stories related to that module would land at the top of the backlog for quite a while… This is not an option, since the lion’s share of our end user base are not primarily concerned with this module – and we cannot afford to wait six months or more before showing completed components of the student records or advising modules to concerned citizens. Of course, the product owner could deem this sufficient value to cherry-pick stories to pull to the top, but this would be clunky at best.
On the other extreme, we could treat each “module” or functional area as a product in its own right; this would require us to have multiple product backlogs, multiple development teams, etc. Adding people into the equation, while our team is way too large for the single-product model, there also aren’t enough software engineers to support the modules-stand-alone product model. Moreover, this would perpetuate a stovepipe/silo model that has already proven problematic in the first few months of the program. So we need to find some happy medium.
Tomorrow we will spending the morning thinking through different models for defining the boundaries of the product(s) and how to (re)align our organization to support that vision. Will let you know how it goes...
Sunday, December 1, 2013
Friends know that I'm a big fan of Twitter -- it is the only way that I can stay current with trends across my industry and announcements from vendors, it is my primary news source during the week, and it has proven a powerful means of building a professional network. I don't use Twitter for entertainment (or at least not primarily) -- the only celebrity I follow is @StephenAtHome. It isn't that I doubt the utility of Twitter for more frivolous purpose, just that I don't have enough personal bandwidth for anything other than one Twitter persona and theme.
What I find interesting is how little traction Twitter seems to have gained within people at my office, friends around town, college classmates -- all those "real" people I interact with off-line. There may be 50M Twitter users in the United States (at least according to this article from Business Insider) but very few people in my real life are users. And what surprises me even more is these aren't technophobes, but IT professionals, business consultants, and other highly educated people with smart phones and tablets. They "just don't get it" and while they may listen to my protestations for how valuable Twitter has proven in my professional life, they aren't buying. Even in rooms where I might successfully evangelize any number of other things, the value of 140-letter posts into the ether is a lost cause.
I'm not sure what this means -- except it tells me to avoid investing in the newly minted stock... So I'll just keep on getting the value I get from the many-millions minority and stop trying to convince my friends to join me!