Examining the ongoing challenges of delivering high-quality, value-added ERP services in Higher Education.
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...
0 Comments:
<< Home