I’ve written about it before, but in late 2008, we started a major transformation of our SAP NetWeaver development approach, processes and organization: We made a bold move with my world-wide distributed, 2000 people organization to adopt Lean and Agile Software development methodologies in a large-scale, systematic and consistent manner. The transformation was a major project and I have blogged about it on the SAP Community Network before (see my blog posts Square OneGood Riddance and Different people). The transformation was a major effort over several years and is still ongoing today — Lean and Agile are a journey, a mindset, not a one time act of implementation. In the meantime, we have added additional methodologies, e.g. Design Thinking, into our set of tools and they actually fit very well with Lean and Agile.

When we started the whole transformation, we often got critical remarks from people in our own organization who were concerned that Lean was a methodology originating in production environments — Lean was invented by Toyota in the 1940s already — and was not a fit for Software Development. That’s when I started to think about how to convince people that Lean (and Agile) was more than something for the automotive industry. Even in retrospective and after having had hundreds of individual talks and discussions around Lean, I like my original storyline around Lean Software Development back then. And I thought it might be worth sharing… So here’s my “dog and pony show” presentation why Lean is relevant for any larger Software Development organization:

Lean Software Development -- We're not building cars -- luckily Lean Production goes back to Toyota.
Taiichi Ohno introduced it first in 1940.
It was originally targeted at manufactoring.
A lot of criticism we hear about Lean in Software Development seems to come from the wrong perception that we would believe we can apply this 1:1 to our business.
But we know we are not building cars – luckily!
Lean Software Development -- Software Development is a creative process We are in Software Development which is non-deterministic by its nature.
It’s much more like animation movie making or modern architecture – you need to get the craftsmanship right, but more important to success is the creative and innovative character of what you are doing.
It is a creative process, it’s an information creation process, learning is part of the journey and hence change is inherent to Software development.
So rather than ignoring change, one better sets himself up to cope with it right from the start.
Lean Software Development -- Eliminate Waste & Maximize Customer Value Nevertheless, what is common between car manufacturers like Toyota and us in Software Development is the strong desire to sustainably and profitably stay in business.
In essence, it means eliminating all the waste that keeps you from maximizing customer value.
Lean Software Development -- The core concepts of Lean Software Development Luckily, we can look outside and see that a lof of people and companies in the same business as we have thought about and made practical experience how Lean Software Development can work.
Just to name some examples: IBM has e.g. transformed their DB2 business, Salesforce.com has changed an 500 employee organization to an “agile development model” in recent years as well… And Microsoft has radically changed their way of developing e.g. their OS platform and development tools following lean concepts and agile principles.
Mary and Tom Poppendieck have condensed their findings into writing and the following slides will explain in a bit more detail what the 7 core principles of Lean Software Development are.
Lean Software Development -- Think Different The first thing to keep in mind is the fact that “Lean” is not a one-time activity, some procedure to implement and then you are done.
It is about mindset and about sometimes surprising or seemingly counterintuitive thinking.
It is for sure about continuous reflection on how you are approaching things.
The foundation of lean is about continuous improvement and respect for people.
Lean Software Development -- Think Less is More -- Eliminate Waste Principle #1 is to eliminate waste – and without going into details, all Lean Production “waste types” translate naturally into software development process “waste types” as well…
Lean Software Development -- Think Three Sixty Kickflip -- Amplify Learning The second core principle is about learning as much and as early as possible and about correcting what you are doing.
Like training to ride a skateboard in a half- or full-pipe: repeat often, learn quickly, adapt in the next cycle.
Obviously, this principle gets manifested in fixed takt cycles, shipping working software early and often, involving stakeholders and customers from the start in each takt evaluating and giving feedback about the software, doing Scrum reviews and retrospectives to thrive for perfection in execution, looking at software development from an end-to-end perspective, etc.
Lean Software Development -- Think Marriage -- Decide as late as possible Fooling yourself to believe you can predict the future or making decision based on premature information at hand, can be very costly to revert if you have to change plans afterwards.
So core principle #3 is about making decisions as late as possible – but not later!
One example is to tackle problems with a set-based approach, trying out more than a single solution in parallel, only later deciding on the best option. Or doing early prototyping and first getting customer/stakeholder feedback…
Lean Software Development -- Think Pizza -- Deliver as fast as possible Core Principle #4: Deliver as fast as possible – both internal and external.
It’s the-fastest-to-market who wins, not the biggest!
It helps to avoid “inventory” on the shelf, gives you feedback early and allows you to put the right things into the next (short) development cycle – maximizing customer value!
Lean Software Development -- Think Rugby -- Empower The Team Most challenging is “think different” probably for management – which is why we need “lean freaks” in management.
It is about the insight that you get the best results, if you empower the teams, the colleagues who know best how to get things done, how to approach a certain goal. It is about respect for people.
It is about getting rid of “process police”: you manage things, and you release people.
Lean Software Development -- Think Brain Surgery -- Build Quality In If you want to deliver fast and are dependent on fast feedback, if you want to maximize customer value, then quality cannot be an afterthought.
You have to build quality into the product and the process simultaneously.
And quality is more than defect-free software! It is about change-friendly code and architecture, about usability, about flexibility – it is about the integrity of the whole product.
Lean Software Development -- Think House of Cards -- See the Whole Finally, think from a customer perspective – think from the delivery side.
Don’t just optimize one area, but strive for making the whole a success.
Lean Software Development -- The 7 Principles To become “lean”, all of the 7 core principles have to be considered jointly, not “pick some, ignore the others”…
That’s why Lean and Agile make perfect sense in software development as well. Dear Automotive Industry — no offense meant! 😉

In late 2008, we started a major transformation of our SAP NetWeaver development approach, processes and organization: We made a bold move with my 2000 people organization spread out into development labs world-wide to adopt Lean and Agile Software development methodologies in a systematic and consistent manner. The transformation was a major change effort and I have blogged about it on our SAP Community Network before (see my blog posts Square One, Good Riddance and Different people). Looking at where we stand today as an organization, our ability to deliver customer value, to deliver reliably, to adapt in an agile manner, to interact with customers and to innovate our product portfolio in a high quality manner, I consider this multi-year transformation a big success!

With the move to systematic, standard Scrum methodology within the organization, cross-functional teams moved into the focus of our interest. “Cross-functional team” meaning people across the necessary disciplines working closely together as “one team”, namely software developers, software architects, information developers, UX designers, Scrum Masters and Product Owners to name the usual suspects. The great thing about these “cross-functional” teams is the ability to optimize the interaction between everybody that you need at the table to get the product done: efficiently and effectively. The more closely we can get this team to cooperate and interact, the better. They will share a better understanding of the overall goal of what they are trying to achieve, communication paths have been shortened as much as possible, diverse skills will increase the ability of the team to develop better ideas and approaches to the problem at hand, delivering more customer-centric results. All of this is also supported by the principles behind the Design Thinking methodology. And last but not least, once being “standardized” on Scrum approach, you can start training and developing complete teams in certain further skills, e.g. agile test practices, increasing likelihood to establish new software engineering practices in a sustainable manner.

ScrumWell functioning teams are a huge asset! While we sometimes like to see software developers as creative artists that can barely be forced into any constraint — at least that’s the romantic point of view that I myself tended to fall into when I was still developing software myself –, a fact is that almost all bigger software development projects are not done by a single individual but quickly by a number of people that somehow need to collaborate to get something relevant done. So the infamous “lonely guy behind a door” is something one does not necessarily see as the ideal working setup if you want to keep your customers happy and your business secured. Well functioning Scrum teams with predictable and transparent progress on the tasks at hand can be a big relief here.

Most of the time where I have seen teams to be dysfunctional or failing, have less been a general issue with working in cross-functional (Scrum) teams but rather could be attributed to the following:

1. Bad cut: The team did not work on a common problem, but was just a collection of people working on unrelated individual topics; sometimes “cutting” teams in a different way made this issue disappear

2. Bad chemistry: There were individuals in the team that did just not buy into the team as such; sometimes just assembling teams a bit different made this issue disappear

Very often I have been hearing discussions about the question whether teams have to be co-located, i.e. all team members being in the same physical location, or could — or even should — rather be distributed, e.g. across different locations or timezones.

I think either position — when taken rigorously — is somewhat shortsighted. Here’s why I think so:

We form cross-functional Scrum teams to make the group internal communication and interaction as efficient and “personal” as possible and get diverse skills to the table. Of course there are modern means of communication like phone, instant messaging/chat, Skype, telepresence etc. that have made the physical distance less of a problem. Still, if you imagine that a team sits in the same office physically and makes use of these communication means mentioned, you would ask yourself whether it wouldn’t be more efficient to just ask the question across the table or listen in on some side-discussion going on spontaneously on the whiteboard behind at the wall? Would be strange, wouldn’t it? So while it is not impossible to work together even when distributed, it is probably more efficient to be co-located. At least in most cases.

At the same time, there are good reasons to accept or even actively establish a “distributed” team: e.g. if your product manager needs to be local to your customers in a certain region or a certain market. Or if there is specific or outstanding talent that you did not find “locally” but had to look for abroad. And this was considered more valuable than the potential loss in optimal communication efficiency associated with it.

So I think the important thing here is: there may be very good and valid reasons to accept that a team is distributed, but those reasons should be well considered and consciously decided. Not arbitrary “accidents”. And they must for good reason outweigh the benefits of co-location.

Rules should cover the common sense 80% case. Exceptions always apply.

We all experience it many times every single day. With italian cars that just won’t start in the morning. With Exchange Calendar appointments that simply disappear. With mobile apps that just won’t connect to the Internet when we need them. With auto-correct features in email clients that changed some words in your email in a career-bending or relationship-ending fashion without you noticing before you pressed the send button.

What I refer to is the bitchy randomness at which technology failures light up our days. Light up in flames. And like with all things people love from the “consumer space”, the expectations rise also towards the so-called “enterprise space” to follow accordingly. That’s commonly referred to as “consumerization of IT“.

Over the past months and years, we got painfully aware that even in ABAP the developer community has become comfortable with the status quo, complacent almost as to how easy and predictable it is to quickly code a new application to serve your employer’s or contractor’s needs. Far too easy, we believe. We all feel that it has to remain a certain science, wizardry, black magic to understand how a computer program actually works. And it has to feel arbitrary to some extent. Like bringing up your kids.

My team got notice of this burning issue already some months ago, but it took us a while to build up the necessary sense of urgency around it. And luckily, with Design Thinking, we got the tools at hand to really confront the problem heads-on. How could we bring the random malice of the consumer space experience to enterprise computing? What we came up with is simple but effective. As always.

After building and pushing around a fancy straw prototype of the solution in a Design Thinking session, we decided to introduce the COME FROM statement in ABAP. It contrasts with the GOTO statement, which for good reason has been considered as an approach too naive to effectively confuse programmers by acclaimed computer science legend Edsger W. Dijkstra already in 1968, as it does not impact the control flow of a program by telling where to jump to in execution, but rather tells where to come from whenever program execution happens to pass the given source code location. It started as a notion, but we quickly turned it into an ingenious idea and then into a brilliant concept. In particular if one looks at the additional attributes that one can add to the “come from” statement:

where <expression> can be any valid ABAP expression yielding a floating point value between 0 and 1, or whatever else at which the execution is not determined at all.

As common sense implies, the COME FROM statement will be executed with the given probability, resulting in the programm execution continuing in the first statement following the COME FROM statement or continuing at the statement at the <source code location>.

Without thinking for too long, even the most junior developer will realize what enormous excitement such statements can bring to otherwise trivially boring code.

In a relentless effort to bring unnecessary reduncancy into the set of ABAP language features, we have also decided to introduce a new statement for execution blocks:

SKIP. <statements> END SKIP [WITH PROBABILITY <expression>].

The careful observer will have recognized our villainous brilliance to move the probability expression to the end of the SKIP execution block in order to further reduce code readability.

We plan to introduce these new ABAP language features with SAP NetWeaver 7.4 after some more intensive validation with customers.

With SAP NetWeaver 7.5 we will then provide a set of new capabilities in the ABAP development tools to improve the effectiveness of the new statements above.
First, we will introduce what we call “progressive obscurity” in the “ABAP for Eclipse” editor: with this feature you can — based on personalization of your Eclipse settings — determine whether the editor shows or hides the SKIP and COME FROM statements from display. This adds enormously to the fun during professional code review sessions. We are also testing whether randomly hiding normal statements outside of SKIP blocks could further help to confuse code reviewers.
Second, we will add support for the above statements in the ABAP Debugger and the ABAP profiler, which will be enhanced with predictive code execution capabilities built right into the tools themselves interfering with the underlying runtime Virtual Machines.

We are also working on bringing the above concepts into other programming languages: River Definition Language (RDL) is a natural candidate of choice. But also for Java we are pushing a proposal into the Java Community Process (RCP) to embed these capabilities into Java 8. For C/C++ we have started discussions with the ANSI committee. The ECMA committee has been approached by us to embed the concepts into ECMAScript/JavaScript and the major browser vendors have been invited already to a workshop in Walldorf. If we do something, we do it right.

Obviously, all of this is only a stop gap solution to bridge the time until the probabilistic behavior has been pushed further down the stack into the hardware itself. We have started to try to convince major CPU/MPU builders like Intel and AMD to add the above features to their hardware designs yielding utmost performance in randomness.

We understand that such a hardware driven approach will take some time to be ubiquitously available in all IT landscapes. We have therefore triggered efforts with Operating System makers to provide software solutions to the market that already today bring the benefits of random behaviour to end users. Solutions include TCP/IP drivers, DNS and DHCP servers, network domain login modules, Exchange server modules and file system drivers that will show arbitrary failure and outage behavior.

A renowned IT analyst company, that wants to remain unnamed for unspecified reason, has estimated the 2017 market for such solutions to exceed 37 billion US$ in total. While we consider the market significant, we have certain concerns though how much of this market we can actually tap into with a standard software solution, as corporate IT departments already today seem to have deployed partial solutions for random infrastructure behavior. At least that’s what we deducted from end user reports we’ve evaluated.

Patents are of course pending.

Hope is at the horizon. The days of waiting are numbered. With probability 0.5.

All will be fine

You meet them everywhere: At “hackathlon” events, at conferences, in developer forums, at StarBucks, even in the supermarket in front of the cereals and before you can even address them with “Son, why don’t you come over to our side of the platform?” they pull out their light saber, wave the shining and humming blade fiercly in front of your nose and shoot the probing question at you: “Father, what’s your API???”.

This is them. The next generation of programmers. The “scripting kids”. The developers that rule the mobile apps space. The ones that are quick and nimble if it comes to combining the latest in mobile app development — whether it’s native Android or iOS, whether it is HTML5, CSS and JavaScript doesn’t matter — with services provided by the Facebooks, the Twitters, the Amazons of the world, exposed as Application Programming Interfaces, or “API”s. They know that stuff like the inside of their pocket and if not they know how to figure it out quickly on the Web. They have their favorite server-side platform, whether it’s php, Ruby or node.js — it doesn’t matter. Some might even remember Java. They are fluent on these platforms and there is little interest in switching. What for? You glue your mobile app together using your favorite technology, which is defined by you being super productive in it plus it being somewhat at the forefront of being hip in the community — hey, that’s part of the fun.

So, “what’s your API??”

If we — SAP — want to attract a larger developer community to our technology, then clearly we need to address the needs of this generation of mobile application developers. It’s many of them. And they are active in a highly attractive and massively growing space: mobile apps.

And I believe there are 3 aspects of this that we need to tackle:

  1. We need to enable our own platform, i.e. SAP NetWeaver Cloud (aka HANA Cloud Platform), at the relevant level with APIs itself. A simple example is management of the platform itself (e.g. deploy, start, stop), but also services like monitoring, configuration etc. are obvious examples.
  2. We need to make it easy for applications and services built by our partners and customers on top of our NetWeaver Cloud platform, to API-enable their offering. Our customers own highly relevant business content and services and can expose these offerings easily via our NetWeaver Cloud platform to e.g. mobile consumption. This is where the highly valuable business content for a developer community enters the scene.
  3. We should provide the means to manage those APIs on top of our platform, make it easy to document, find, consume, monitor or meter those APIs. This should come as a service of the platform itself.

This morning, I had my monthly takt-end “Product Review meeting, a day-long meeting where my management team and myself take a look at the aggregated sprint results of our various products in development. We do Scrum in a very systematic way in my organization with around 2000 developers spread around the world. The Product Review takes a full day and constitutes the only “status update” about products and programs that I ask my organization to come up with. And that’s enough, by the way.
Today, we took a look at the current status of Gateway-As-A-Service, which is the SAP NetWeaver Cloud-based incarnation of our SAP NetWeaver Gateway product, a gateway that exposes business functionality implemented in our SAP Business Suite and accessible via Remote Function Calls (RFC), Business APIs (BAPIs), Dynpro screens (via “screen scraping”) and various other programming frameworks, in a standard-compliant manner based on REST and OData protocols (serialized as JSON if needed). So you can easily consume any of the business functionality in e.g. your mobile app in a simple, coherent and standard-compliant way. I am totally excited about the fact that soon our customers and partners will be able to expose any business functionality in the SAP Business Suite to the Internet and mobile applications without even installing an SAP NetWeaver Gateway in their corporate infrastructure, but can do so by simply connecting securely via our Cloud platform where we handle all the infrastructure provisioning. That’s a major step towards getting to those APIs we talked about above. Not the full story about APIs yet, but I am confident we’re getting closer every day…

I am very confident — I am convinced — that we are able to handle all the technical challenges at hand. The bigger challenges we will have to address are the following:

  1. Bridge — or smooth out — the inherent friction between expectations of extremely straightforward and simple access to business functionality on the consumption side, i.e. for example in the mobile apps space, compared to the variability and complexity of underlying business processes supported in the backend business processes. This will be harder the more “generic” the APIs exposed will be — the intrinsic problem of customizable standard software that can potentially do every variant of a certain process –, and it may be simpler the more specific the use case will be — e.g. if one of our platform customers exposes a specific service to the Internet, it can be completely “hardened out”, resulting in much easier APIs. So perhaps we should rather focus on making it easy to “harden” out specific versions of APIs than trying to expose everything “generically”.
  2. Solve the business model underlying the API consumption model: It’s great to expose APIs technically, but for sure there need viability and monetization considerations to be taken into account — not just for SAP as a platform provider, but in particular for our customers and partners willing to expose APIs for their services on top of the platform.     

So all of this comes with considerable challenges, but the opportunities opened up by such an approach of API level access to the platform and SAP customers’ business use cases are enormous.

“Success is where preparation and opportunity meet.” [Bobby Unser]

Any thoughts out there on this?