Think “Brain Surgery”. Think “Marriage”. Think “Three Sixty Kickflip”.

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 One, Good 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 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!

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.

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.

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.

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.

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…

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.

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…

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!

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.

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.

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.

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

To co-locate or not to?

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.

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

Tom Gilb (Agilist) about large scale

“If you don’t know what you are doing, don’t do it on a large scale.”