Wednesday, May 5, 2010

Scrumming for Skills: The SAP BPX and Agile Development Skills Connection

One of the most compelling debates in the SAP skills marketplace is the emergence of the so-called "SAP Business Process Expert". Those of you who visit JonERP.com know that I can't go more than a month without a podcast or video that hits on BPX skills. You'll find frequent discussions on SAP's BPX community on this topic also. Why is this contentious? Because no one, be it IT Services firm or individual consultant, - wants to be left behind as the next SAP skills train leaves the station.

At the same time, no one wants to over-invest in hypothetical skills that don’t have market traction. Recently, courtesy of the Enterprise Geeks, I noticed a connection between these skills and Agile development. This connection helps to clarify some of the new SAP roles we should be anticipating.

Caveat - the business case for Agile SAP development is itself a heavily debated topic. But while helping out on research for the ERP Executive Magazine, I saw enough: Agile is going to be a factor on the SAP projects of the future. Look no further than the ASUG/SAPPHIRE Orlando schedule, where a number of Agile events are offered, including a customer panel entitled "Delivering Results with Agile SAP: A Panel Discussion."

So how do Agile and "BPX" skills connect? Fresh insights on that topic were shared by Thomas Jung of the Enterprise Geeks on a podcast replay he posted from SAP Inside Track Sydney. During the podcast, Thomas facilitated a discussion that included stories from the internal Web Dynpro for ABAP (WDA) team he is a member of. As it turns out, all the WDA functionality in the upcoming NetWeaver Enhancement Pack 2 (NetWeaver 7.02) release (late second quarter 2010 release target) was developed using an Agile/Scrum process.

SAP's internal teams are increasingly turning to Agile/Scrum, though it should be pointed out that up to this point, this shift to Agile has not altered the frequency of Enhancement Pack releases. What it has done, according to Jung, is to make it possible for his teams to incorporate customer and community feedback at more rapid intervals during development, rather than having to wait six months or longer for another Enhancement Pack release for that input to be included.

During the roundtable, Jung talked about the importance of a new kind of techno-functional role - someone who could work in shorter, Scrum-like iterations, someone who is able to speak the language of business requirements but who can also handle seeing a half-finished UI without getting turned off or intimidated by the technical loose ends.

I thought Thomas' quote on this new role was significant, so I got his go-ahead to share it in its entirety:

“SAP is not coming down from on high and saying This is the way to do it. When I say you delivered to customers in six weeks, that’s not necessarily the end person who will be on the live system - it’s certainly not the data entry person entering the data, and it may not be the business person giving you the requirements. I think that's why we see this role evolving. It goes by different names Business Process Expert, Solution Architect, - we need somebody who is in the middle who can understand a smaller chunk deliverable, a half written program, an API. We need someone who can understand why you ran a unit test against that code, and who can review the results of that unit test.

“That’s where having a Solution Architect with a middle layer of expertise who understands some of the technology and some of the business and who can do that middle translation becomes important. You need someone who can validate, and say, ‘Yes, you got these test results, and that is what we expected, but that is also going to roll into the larger application we're building here over 6, 8 or 10 Scrums, and that also looks good.’

“Maybe that person is the Scrum Master, guiding the project as well, or maybe it's someone outside the Scrum team altogether. In our case, at SAP, that person is also the Scrum Master and the Project Owner. In our case, they have to understand how each piece fits into the overall project, so the Project Owner role makes the most sense. But in the case of customers, it's more often somebody with a title of Solution Architect or Enterprise Architect or Business Process Expert.”

We can’t resolve these emerging roles in one blog post. I have always maintained that the BPX skills transition is less about specific roles anyway, and more about the gradual shift of most (if not all) SAP jobs into a process-oriented context. But with Agile gaining traction in SAP shops, there’s more fuel to the BPX skills fire coming.


No comments:

Post a Comment