Additional Blogs by SAP
Showing results for 
Search instead for 
Did you mean: 
Active Participant

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