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 |
|
