Skip to Content

In my Square One I gave a glimpse into how the development approach in NetWeaver R&D  — and now also at SAP R&D at large — has been changed over the  past 3 years towards “by the books” Lean and Agile Software Development  methodologies.

One has to acknowledge the fact that this  transformation is rather a journey than a well-defined end state, a  vision to strive for on a continuous basis rather than something that  you “climb up once” and then sit back and enjoy.

Even 3 years into  the journey, we’re still facing a number of concerns and areas we need  to improve. The good thing today is that we’ve reached a level of buy-in  into the concepts and ideas within the organization at large that  addressing and solving those issues is rather a question of when to  tackle them rather than whether to tackle them at all. Also, we’ve  meanwhile gained enough experience with Lean and Agile that we’re not  completely flying blind any more and can rather quickly come up with  incremental improvements.

“Lean” and “Agile” is to a large extent about mindset, it’s a way of thinking.

While  it seems pretty obvious today that in retrospective the transformation  of our R&D organization towards Lean/Agile has been the right thing to push for, things  had not been that obvious and easy when we started thinking about it.  That we would be successful in the long run, was by no means a given.  There had been many skeptics and critics in 2009: Why should the grass  be greener on the other side of the street? Why not just keep things as  they are? Why another hype initiative that is pushed through the  organization to keep some people busy and give management something to  worry about?

 

“More than any time in history mankind faces a crossroads. One path leads to despair and utter hopelessness, the other to total extinction. Let us pray that we have the wisdom to choose correctly.” [Woody Allen]

 

What I wanted to share with you in this post is how  we got things started, explaining how we pulled off the initial changes.  So here’s my personal top recommendations to those of you who might  consider making a similar change towards Lean and Agile in your own  organization:

 

1. Be explicit and bold about your goals

When we set off, we stated the following goals for our “Lean@Core” endeavor:

  • Increase productivity by reducing waste in products and processes,

  • improve flexibility to react faster to changing demands,

  • improve stakeholder satisfaction through reliable deliveries, transparency and predictability, and as a consequence

  • increase customer value.

Bold enough so that everyone can buy into the vision.


2. Be realistic and transparent about what you’re doing

Having bold goals is one thing, turning this into tangible and doable steps that get you there is a different animal.

So we always structured the transformation into 6-9 month project phases with clear objectives: this is what we will focus on and change (scope) and this is how we will do it (approach). After each project phase we did a self-assessment within the units on how far we’d gotten and shared the results broadly with the organization. This is the time to acknowledge shortcomings and missed goals — and it is the time to communicate and celebrate progress and achievements.

“I can count to 4. And repeat. I’m a drummer.” [Tré Cool]

 

3. Get top management actively involved

While  Lean implies respect for people and is built on the insight that those  who have to do the concrete task probably know best how to improve it,  you do need top management involvement and buy-in into the concepts and  ideas. You can’t change the development methodology if your top  management is not fully behind it, understands Lean and Agile, actively  promotes the concepts, drives the change in the organization and serves  as role models for the desired changed behaviors.

Finally, some of the  decisions you will have to implement, will not happen by sheer insight  of every individual involved, but need to be pushed through by  management across the whole organization. Of course this is a thin line  you’re walking as management.

In order to not only get buy-in of  top management but actually make top management part of the transition  efforts, my management team and myself came together in the so-called  “Lean Transition Team”, where we applied Scrum “by the books” ourselves  to work in 4-week Sprints on our own “Transformation Backlog”. Thus we  were having daily 15-minute stand-up meetings every morning in front of  our Scrum Task Board, were doing joint sprint planning (including effort  estimate “poker”), review and retrospective meetings, thus structuring  the 6-9 month project phases into smaller increments and — as a side  effect — were gaining own first-hand experience in how Scrum works.  Very helpful if you want to convince all your development teams to apply  the same approach. At least you can claim that you know what you talk  about…

 

4. Seek advice and support from external experts

While I am a strong believer that sustainable change has to be driven from within an organization itself — and is much more effective that way anyhow — it has been very helpful for us to have someone external with an extremely strong background in Lean methodologies on board for the change. We engaged with Porsche Consulting to help us shape and drive the change efforts. The consultants we had on the team were worth every single Euro spent.

While their specific experience with Lean Software Development was somewhat limited — with 10.000 R&D people we’re probably one of the largest software companies in the world that ever did a massive change towards Lean Software Development principles — their broad expertise with the application of Lean principles in various industries from Automotive to Health Care, from Production to Product Development was enriching our discussions and providing new perspectives and insights every day.

And last but not least, you should never underestimate how much more convincing those external experts can be in discussions with your own management above than “just you” stepping into their office with some fancy ideas how to change key processes in the company that people have started to get used to (and some of them even have built their sole purpose in the company around)…

5. Pilot concepts first

Besides getting more confident that you’re actually changing things in the right way, having done pilot runs of certain concepts in a limited but representative part of the organization helps you being more credible with your own folks when rolling out things at larger scale. In particular, if things have been tested within your organization, got tweaked and improved based on credible colleagues’ feedback and then get applied, helps to convince skeptics that tend to argue that things may work in the “outside world”, but not in your company that is of course always very different from the rest.

“If you don’t know what you are doing, don’t do it on a large scale.” [Tom Gilb, Agilist]

6. Create tangible impact for a majority of the organization quickly

Even though piloting is important, if you don’t push for a larger and timely change across all of the organization, it can easily happen that you get stuck before you have made it across a sustainable threshold. Complacency and the tendency of larger organizations to fall back into old behaviors, is something you have to always be careful about.

So what we did immediately was to declare the application of Scrum as development methodology by (at the time) 1000 colleagues until the end of the first project phase (i.e. after 9 months) as objective #1. Such an objective makes you plan big time for rollout, training, tooling etc..

One positive side effect of this is that the whole organization can very transparently see that you are serious about the change. And nearly all people in your organization feel and experience that things are really changing for them. If you would start with some other area (like e.g. Portfolio planning), the number of people seeing an immediate change would probably be much smaller.

Last but not least, going for a specific change that affects basically everybody in the organization allows you to make everybody an active contributor of the transformation itself and influence how things are evolving. At the same time tons of issues will be surfaced by this and you’ll be able to fill your transformation backlog for months to come ๐Ÿ˜‰

“A good way to counter this cynicism is to avoid naming the transition effort. Teams that have lived through the “Quality 2000” initiative that was followed by “Better, Faster, Cheaper” and then “Customer First!” will not respond well to the “Scrum and Proud of It” campaign.”

[Mike Cohn, Succeeding with Agile]

7. Do Scrum “by the books”. Always.

There  is quite some tendency in large organizations to tweak each and every  thing “so that it works for us”. Probably not just at SAP. If there are  1000 developers you probably get 1000 opinions on how development should  be done best. The problem when listening to 1 developer though is that  the other 999 developers will debate with you “til the cows come home”.  That’s something you can easily avoid by doing “Scrum by the books”. No  need to debate as this has been applied all over the world successfully  already and therefore should be good enough for us as well. Furthermore,  once you stick to the books, you can actually use all the books,  tutorials and trainings available on the market to help you in your  rollout efforts within the organization. So did I mention this already?  Do Scrum by the books. Always.

 

8. Find your “8 ton” lighthouse showcase

Why  “8 ton”? One of the Porsche consultants on our team once told us a  story of another company they had been working with: there they had come  up with a moving assembly cart that was moved through the assembly line  rather than the individual parts being moved to the stationary spot  where the heavy machine was assembled in former times. 

Actually the assembly cart together with the machine assembled was weighing more than 8 tons but could finally be easily moved on rails by a single person by hand through the assembly line — proving that things previously considered impossible in the company could be changed if you were starting to think “outside the box”. What is your “8 ton” lighthouse showcase for you being serious about the Lean transformation? That of course is different in each company. For us, we have been going for the following two “8 tonners”:

In project phase one, we radically wiped out micro-reporting that had become the desperate means over former years to gain back control over what was going on in the growing complexities of product architecture, release planning and project management. Teams were basically asked to only report back along Scrum Planning and Scrum Review meetings and show working software every 4 weeks — our Takt cycle. Quite some change after years of excel and KPI craziness. Interestingly, things didn’t become worse, but improved with teams being empowered to define their Done Criteria. In the meantime, we’re running regular Quality Workshops with each team where the team itself works on improving and extending their Done Criteria, sharing best practices across the organization. And surprisingly, the criteria the teams apply to their own work are often more ambitious than what had before been centrally defined. Good riddance to micro-governance.

In project phase two, our 8-ton lighthouse example was the introduction of “TGiFriday” — our “Technology Group Innovation Friday”, the possibility for each person in the organization to spent 10% of their working time — Friday afternoons typically — on arbitrary innovation topics of their choice or use the time for self-learning in new technology fields like mobile or in-memory. In an organization where development in 4 week Takt cycles has become the norm, this concept re-introduced slack into personal schedules and created room for people development and innovation. Knowing that our organization had previously been challenged by spending every single breath of our developers on delivering thousands of requirements of our stakeholders, the introduction of this TGiFriday concept has indeed been an “8 ton” example of us being serious about respect for people in the purest sense of Lean. But TGiFriday is probably worth a blog post by itself …

“Another turning point,
A fork stuck in the road.
Time grabs you by the wrist
directs you where to go.
So make the best of this test
and don’t ask why?
It’s not a question,
But a lesson learned in time.”
[Green Day]

 

More than enough written for this second blog post. Congratulations to all those of you who made it down here ;-)…

If you feel like sharing your thoughts: I am again happy to get your feedback on Twitter (@_bgoerke) or as comments to this post directly here on SCN.

 

Björn Goerke | Technology & Innovation Platform Core

To report this post you need to login first.

18 Comments

You must be Logged on to comment or reply to a post.

  1. Sascha Wenninger
    Hi Bjoern,

    what an awesome follow-up to your great first blog. And like all good movie producers, you’ve set the scene for the next sequel on TGiFriday. Unlike with most movies though, I can’t wait for the sequel!

    Many thanks for sharing your real-life experience so clearly and convincingly. I’m sure your writing will go some way towards inspiring change in other organisations.

    Regards,

    Sascha

    (0) 
  2. Matt Harding
    I especially loved the line: “The problem when listening to 1 developer though is that the other 999 developers will debate with you “til the cows come home”. ” – While less “agile”, I believe this is a common problem in the IT industry (and not just within development) with a viable solution you put forward in this scenario.
    Plus the reduction of micro reporting to focussed done criteria must have free’d the projects so much too.
    Thanks for sharing,
    Matt
    (0) 
    1. Bjoern Goerke Post author
      Hi Matt,
      you are absolutely right with your observations. The “thin line” you have to walk in the transformation as a management team is figuring out where to listen to your organization (actually, you can only listen to individuals) and where to stop going for all-consense-driven decisions. You have to seek for best practice experiences made and at some point in time push them into the larger organization. The good thing about using Scrum is that it is one of the best “best practices” available and hence the risk of being completely wrong with it is rather low. But there are other topics that you need to better pilot internally before implementing them large scale. While one of the core principles in Lean is Respect for People, this does not mean that anarchy would be ok. You need clear common ground and clear boundary conditions for all — especially in larger organizations. Freedom to optimize and individually tweak approaches within those boundaries is what you can afterwards easily allow — and actually: this is desired.
      Thanks for your feedback,
      best regards, Björn
      (0) 
      1. Matt Harding
        I can imagine those clear boundary conditions would have been fun to settle on too ๐Ÿ™‚
        Your clarification makes me even more impressed with the transition (i.e. Visionary thinking from the onset) – now let’s hope that CDP start to adopt these processes more universally too so that all customers can benefit from these “best practices” when engaging CDP when somehow SAP standard doesn’t cut the mustard.
        (0) 
  3. Yariv Zur
    I really like this post in the sense that you can take the titles “as is” to almost any massive shift in thinking you want to do in an organization. Whether its implementing LEAN or changing mindset to other things (e.g. for non-development organizations) these are the right headers to consider. I find all of them extremely applicable to other changes which we (SAP) should implement.
    (0) 
    1. Bjoern Goerke Post author
      Hi Yarif,
      Yes, I fully agree with you! The principles apply to all major organizational change. Seems like we have done a few things right this time ๐Ÿ˜‰
      Best regards, Björn
      (0) 
  4. Mark Finnern
    Hi Bjoern,

    Love the insights that you shared and proud that SAP was able to change to this better development methodology.

    Question: “Thus we were having daily 15-minute stand-up meetings every morning in front of our Scrum Task Board”

    That implies that the transition team was local. No managers from other locations involved. There I see one of the biggest obstacles for the lean success. We live in a global world with distributed teams. How do you overcome the distance/time zone problems?

    Excellent humor too, Mark.

    (0) 
    1. Bjoern Goerke Post author
      Hi Mark,
      thanks for your feedback.

      Actually, the Lean Transition Team (LTT) I mentioned was a co-located team — we started the transformation locally in Germany first and only later extended to the other TIP Core locations. Nevertheless, the daily stand-up meetings were always partially “virtual” as some of colleagues in my management team were always on travel around the world and had to dial in. Not ideal, but something you can make work. Furthermore, “below” the LTT, we had Lean Implementation Teams (LITs) in each of the 100-150 employee sub-units which were consisting of local and remote colleagues out of the units. There we had to tackle the issue of remote work. It is possible.

      In general, I don’t think that globalization implies that Lean would not work as your comment may suggest. Lean only surfaces issues more clearly that otherwise get hidden away more easily: having a product owner being somewhere in the US and a development team sitting somewhere in India may be a bad setup no matter whether you do Scrum or anything else. It’s probably inefficient. Having a development team spread across 3 locations is inefficient and makes communication difficult if not impossible.
      Therefore, Lean and Scrum promote the idea of co-located teams. This should be the norm/standard. As usual, exceptions apply and there are sometimes good reasons to have people (for their specific skills) working closely together across remote locations. But again, whether this works out or not is independent of whether you do Lean/Agile or Waterfall/Random/Arbitrary as a development methodology.
      Best regards, Björn

      (0) 
    2. Bjoern Goerke Post author
      Hi Mark,
      thanks for your feedback.

      Actually, the Lean Transition Team (LTT) I mentioned was a co-located team — we started the transformation locally in Germany first and only later extended to the other TIP Core locations. Nevertheless, the daily stand-up meetings were always partially “virtual” as some of colleagues in my management team were always on travel around the world and had to dial in. Not ideal, but something you can make work. Furthermore, “below” the LTT, we had Lean Implementation Teams (LITs) in each of the 100-150 employee sub-units which were consisting of local and remote colleagues out of the units. There we had to tackle the issue of remote work. It is possible.

      In general, I don’t think that globalization implies that Lean would not work as your comment may suggest. Lean only surfaces issues more clearly that otherwise get hidden away more easily: having a product owner being somewhere in the US and a development team sitting somewhere in India may be a bad setup no matter whether you do Scrum or anything else. It’s probably inefficient. Having a development team spread across 3 locations is inefficient and makes communication difficult if not impossible.
      Therefore, Lean and Scrum promote the idea of co-located teams. This should be the norm/standard. As usual, exceptions apply and there are sometimes good reasons to have people (for their specific skills) working closely together across remote locations. But again, whether this works out or not is independent of whether you do Lean/Agile or Waterfall/Random/Arbitrary as a development methodology.

      Best regards, Björn

      (0) 
  5. Bala Prabahar
    Hi Bjoern,

    When you work with 1000 brilliant developers, as you said, you would theoretically get 1000 “outside the box” ideas. Since software development is not science, how do we decide which one is better? Would Scrum “by the books” help solve that issue objectively? Unlike other development projects – such as building construction – the outcome of software development is not easily testable/measurable.
    Even today at the 11th hour of going live, we determine we’re not ready for go-live and announce delays instead. The delays in the software development doesn’t concern me as much as the timing of such announcements.  With 20+ years of s/w development experience, frankly speaking, I become dumbfounded when delays are announced at the 11th hour. What are we missing? Why it is difficult to determine the status of software development project few weeks/months before going live? Do you think we need a fancy method to determine that? IMO, no we don’t need one; there is probably a critical hidden problem which keeps us from seeing the obvious.

    Would “Lean and Agile Software Development methodologies”  address that hidden problem I’m wondering.

    Best regards,
    Bala

    (0) 
    1. Bjoern Goerke Post author
      Hi Bala,
      thanks for your thoughts.
      Lean/Agile/Scrum doesn’t prevent that projects can go haywire. In the end, there’s a certain scope, certain time and certain developers available. You need to manage those three carefully. Lean/Agile/Scrum help you to a) see regularly where you are (Sprint/Takt principle) with ideally “working software each takt”. They help you to focus on the most important things first (backlog) so if time runs out, you might at least have covered the really important features. They help you debate with your stakeholder/customer regularly, what he/she really wants (making sure you don’t see late surprises at the end of the project phase) and thus allows you to tweak the feature scope in due time (or to mitigate if time/money runs out). Scrum provides you with great practices to do better effort estimates (planning poker) and to become systematically better with it.
      So overall, Lean/Agile/Scrum don’t keep you from blowing up a project, but they definitely help you to become systematically better at delivering in time, in scope and in quality.
      I am also not a believer in fancy project KPIs and software metrics. Usually works in academic environments, but real environments tend to be less controllable and hence don’t provide the environment to apply those approaches with reasonable effort (i.e. bad cost/benefit ratio).
      We go for everything that can be automatically derived out of code and tests. And tests — especially automatic ones — are absolutely key. So usually, you apply XP techniques (Pair Programming, Code Reviews, etc.) or Test Driven Development (TDD/A-TDD) in parallel, as example.
      Software development is not science, agreed. It has elements of arts, agreed. And it is for sure an engineering discipline. So don’t leave it to your good luck to finish software projects successfully.
      Try Lean and Agile. We have made excellent experience with it. Large scale and in software product development (not just project development).
      Best regards, Björn
      (0) 
  6. Dagfinn Parnas
    Thank you so much for sharing the insights made during the journey so far.

    From a customer perspective, it is natural to look to SAP for ways to reduce the overall TCO of the ERP solution. Customers use a significant share of their IT budget to operate and implement custom-specific modifications to SAP-based systems and very few have made the transformation to lean and agile methodologies for this work.

    Customers need to drive this change themselves, but I would like SAP to attack this problem as well and think about what role they can play in order to work as a catalysator for that change. I believe SAP can help in areas ranging from how to organise teams to deliver automated tests and tools.

    Perhaps we will be able to discuss this at a future SAP Mentor Monday?

    (0) 
    1. Bjoern Goerke Post author
      Hi Dagfinn,

      thanks for your feedback. I’ve received the feedback regarding customers wanting to apply similar transformations also from other people. Very interesting thought and definitely worth a follow-up.
      Yep, let’s go for a SAP Mentor Monday discussion…

      Best regards, Björn

      (0) 
      1. Mark Finnern
        Hi SCNers,

        As Lean/Scrum at SAP is a hot theme. We are going to have a public SAP Mentor Monday Webinar on the 27th of February with Bjoern, Dagfinn, Twan and other SAP Mentors with experiences in Lean/Agile. 30 minutes will be time for your questions, so come prepared. Details here: http://wiki.sdn.sap.com/wiki/display/SAPMentors/SAP+Mentor+Monday

        Conference with you then, Mark.

        P.S. Folks were wondering yes the SAP Mentor Mondays are webinars were SAP Mentors often in conjunction with SAP employees are sharing their expertise. They are free and open to the public.

        (0) 
        1. Mark Finnern
          Hi SCNers,

          Feb 21st is President’s day in the US, we have the webinar with Bjoern Goerke a week later.  The title of my last comment didn’t get the message ๐Ÿ˜‰

          Sorry, Mark.

          Repeat: SAP Mentor Monday: Lean at SAP with Bjoern Goerke + SAP Mentors
          Presenters: Bjoern Goerke, Dagfinn Parnas, Twan van den Broek Monday 27th of February 12:30-1:30pm PDT 

          (0) 
  7. Dagfinn Parnas
    Another question from me.

    It has come to my knowledge that there exist quite a few developers that honestly detest Scrum and what they call the “Church of Scrum” community.

    From debates with them, the main point they bring up is that they experience a large degree of micro-management from leaders, project managers, POs and scrum masters and feel that there is no longer a level of trust in their ability to deliver. I don’t agree at all that this is caused by Scrum, but they may have a point that scrum can become harmful for developers if implemented wrongly or for the wrong reasons.

    At the end of these debates I always wonder how many developers have this feeling, but as far as I can see there is no major research in the area.

    Therefore, I am interested in hearing if SAP has done any surveys on developer satisfaction before and after the transition to Scrum  (and Lean).

    (0) 
    1. Bjoern Goerke Post author
      Hi Dagfinn,
      again, another good question: Yes, we have been doing regular survey’s with our R&D colleagues asking for feedback regarding our Lean/Agile implementation. We have not asked specifically though whether they like or dislike Scrum (in retrospective, you wonder why we didn’t come up with this simple question ;-). We asked whether they are satisfied with the implementation of Lean and whether they believe that the change will in the long run be beneficial. The majority of colleagues in my area had agreed to this. I would assume that this includes Scrum as a methodology.
      In general: I don’t think it is overly wise to be “religious” about any development methodology. Stay pragmatic and do what makes sense. No need to become “religious” about it.
      Best regards, Björn 
      (0) 

Leave a Reply