“Step on that chair, dream about what could be and be curious how to make it real. But it’s YOU to take the first step.”
Check out the replay at https://events.sap.com/teched/en/embed.aspx?sid=41454 .
SAP TechEd 2017 Executive Keynote, Las Vegas, USA
“Course heading, Captain?” [Pavel Andreievich Chekov]
“Second star to the right – and straight ’til the morning.” [Captain James T. Kirk]
Check out the replay at https://events.sap.com/teched/en/embed.aspx?sid=33416
SAP TechEd 2016 Executive Keynote, Las Vegas, USA
Your future hasn’t been written yet. No one’s has. It’s you who creates your future. So make it a good one, all of you!
Check out the replay at https://events.sap.com/teched/en/embed.aspx?sid=28917
“As usual, I’m working with stuff that was deliberately designed not to burn. But no amount of careful design by NASA can get around a determined arsonist with a tank of pure oxygen.”
― Andy Weir, The Martian
Watch the keynote replay at https://events.sap.com/teched/en/embed.aspx?sid=26506
I think I was 14 or 15 years old, when I saw a documentary about Silicon Valley and its startup culture on German television back then. Being a young computer addict myself at the time already, hacking along on a Commodore VC64, I was completely fascinated by the innovation culture shown and the entrepreneurs and startup founders they interviewed. One of them was Andreas von Bechtolsheim, one of the founders of SUN Microsystems, an early investor into Google and now working on his new company, Arista Networks.
I can still remember how Andy was interviewed in the documentary: an enthusiastic guy with shining, smart eyes explaining that SUN was an acronym for Stanford University Network and that they had set out to build a powerful, networked workstation based on the UNIX operating system that would soon outpace the existing computers architectures both by computing power and by low price! For years this documentary has been the basis for my romantic dreams about once working in the Silicon Valley myself, which actually came true in 1996.
Well, what I hadn’t ever dreamed of was actually meeting Andy Bechtolsheim personally! How should I? But believe it or not, I met him yesterday for one and a half hours face to face. A Silicon Valley icon. Energetic as ever, his eyes alert and witty, and being so fast when talking about any topic we happened to get to, that I could barely follow… We discussed how cloud changes HW design, how the cloud is now becoming good enough for everyone/everything if even United States’ agencies use it, how the PaaS and IaaS market might grow to roughly 24B$ by 2020 getting 10 times it’s current size and how this will thus disrupt the markets of a number of big traditional IT companies, and how enterprise software is making its way into the Cloud as well. It was unbelievable to see how fast Andy could elaborate on all those topics, hard to keep pace with him as he went along the flow of ideas and facts… For sure Andy is one of the most impressive people I have met.
These are some of the surreal moments in life, I’d say… 😉
Inspired by a comment to one of my prior posts (You know that story of the Russian cosmonaut?), a comment about noise and getting into love with it, I thought it may be worth sharing some of our experience with building (office) space for building teams.
When we moved large-scale into Lean and Agile Software Development methodologies five years ago, the role and work of “the [cross-functional Scrum] team” got more and more important and we started to consider office space concepts that would better fit the new working model than our traditional 3-4 people offices that we had in some of our development locations (e.g. in the headquarter offices).
Colleagues were in search for collaboration space, needed spots for daily Scrum stand-up meetings and their Scrum boards, needed meetings rooms for the takt-start planning and takt-end review and retrospective meetings (all at the same time, of course). Also, we wanted to be able to move individuals easily and quickly around, if e.g. teams were changed or a UX designer was supposed to join a team, and we didn’t want to always wait for weeks to get an official move approved and implemented by facilities or contractors… “Grab your laptop and make yourself comfortable at your new spot” was the goal…
As a first try, we had experimented with 3 “team rooms” which had been set up by tearing 2 walls down and making 3 normal offices into a bigger team room. While the pilot teams that moved in liked the space after some adjustments for their team related work, it quickly became clear that a) they had only accepted the room because each one of them still had their original desk in their prior office room and b) the team room was “an island” that was missing support infrastructure around: ad-hoc meeting rooms the team could retreat into to not disturb the others, “phone cells” for phone conversations that were disturbing the others or private in nature. So we figured out that we need more than “team room” islands in the classical office environment, but a space for teams that has been designed for that purpose from the ground up.
That’s how we started the initiative called “Office Space for Teams” (OS4T), a collaboration of Facility Management, our central Lean unit and “the business”, i.e. parts of my R&D unit. The goal was to pilot concepts for office space particularly tailored at teams and their need for communication and collaboration, supporting innovation and creativity.
There’s meanwhile a short video about it on YouTube that you might want to check out (3 minutes) to get an impression yourself:
We quickly figured out that in a “Lean” environment, it would be stupid to not involve the main stakeholder into the whole design exercise: the Scrum teams themselves. So we ended with having a joint team from the three units above, plus external architects, plus representatives from the development teams themselves that gave input and guidance to the actual design the architects and interior designers came up with.
The declared goal was to emphasize “networking over nesting”, i.e. priority 1 was to provide teams with an environment that would foster communication and collaboration supporting innovation and and that would not make the individual’s wish for “nesting” the main goal. “Nesting” meaning: “let me alone, I want my private spot where noone disturbs me and I can ‘nest’ in”.
The area affected was two “H”-shaped wings of our building, seating around 280 colleagues before the remodeling. The restructuring of the old smaller office rooms, meetings rooms, coffee corner into a coherent overall concept, resulted in more than 30% additional workspaces, places where people could sit and work, simply due to the fact that a lot of space was “wasted” in the past with pathways to connect the offices. So the new design made better use of otherwise “dead” space.
I don’t want to bore you with the full story and all the nitty-gitty details — this goes beyond a blog post I fear and the video above may already give you a good sense of what Office Space for Teams is about — but share a few of the insights and learnings that we have made over the past months while “living” in the new space (I myself as well):
1. Open space for helping opening minds
If you want to foster creativity and innovation — and software development is a highly creative undertaking — provide the team with light, color, diversified and a haptic rich environment.
It helps getting into a creative and open state of mind. Sitting alone in a closed room, grey walls around you, a neon light buzzing at the ceiling and a steel door keeping everyone else out, is for sure not going to help make yourself more creative. Just to paint some extremes…
2. Flexibility is key
One of our goals was to make changing teams and “who sits where” easily changeable. One can think about moving tables — even though one has to acknowledge that there are health and safety regulations in place that forbid to place tables or workstations anywhere, have power lines crawling all over the floor etc.. But one can standardize on the workplace equipment, e.g. provide everyone with a (powerful) laptop and mobile rather than a workstation and a landline phone, have people use containers with rolls rather than fixed cupboards etc.. So that in practice they can move their own stuff within 5 minutes rather than waiting for 4 weeks for a contract mover to carry their boxes and IT to re-wire their workstation… So far, from what we’ve seen, things are flexible enough in our new office space and there wasn’t a strong demand to completely rearrange everything from ground up. We have changed team mixes a few times and people have been moving around quickly and easily. So it seems that one worked out.
3. Not all teams like such a collaboration environment
It seems that in particular teams, that rather are groups of people that work more or less independent from each other, consider a less “collaborative” environment more preferable as it is less distracting for them. If you’re in a team that is heavily interacting, e.g. because you are working in exploratory mode on a brand-new product idea, then the situation is very different. Feedback from such teams has been very positive. Which leads to the next finding:
4. Believe it or not, but people are different
No matter how well you design the workspace, people — and teams — are different. What works well for one, can be a pain in the neck for the other. So it seems advisable to provide people with enough “variation” of workplaces: some Design Thinking rooms for whole teams when in creative mode. Some more separated spots where individuals can work if they need concentration and don’t want to be disturbed. One developer wants to work rather isolated for a while, while others prefer to be more part of the group etc.. The only thing limiting what one could provide is normally space constraints. Or the fact that you won’t accomodate everyone’s perfect preference and still keep a team together locally somehow. Or finally the nasty constraint called “budget” — you cannot foresee everything and planning for the extreme case means usually “over-provisioning”. And this isn’t an option in most cases. So there’s always certain trade-offs to accept. And some learnings to be made.
5. People will need time to “settle down” in the new space
Whether you come from a completely open “cubicle space” environment or from a classical “two or three people in a room” one, you will need time to adjust yourself to the new setting. Also, people need to figure out how to use the space in the best way. We have one meeting room with bean-bag like seating, no table, just a projector at the ceiling and some whiteboard wall. Originally, the feedback from the team was: we can’t use that room. Later, when we wanted to actually change the room into a Design Thinking room, the same team came back and objected and wanted to keep the room as it was: because they had figured out what meetings were best done in that kind of setting (and liked it that way). And for other purposes they simply chose a different room.
6. Beware of the “library effect”
Being part of conversations is great. But only if it concerns your work. So while teams like the fact that you are easily informed about what’s going on in your team by “listening in” or being able to easily contribute, if the communication “flows over” from some neighboring team that is unrelated then it’s considered “noise”. So better make sure that teams are acoustically separated from each other. Otherwise you will quickly end up in what we call the “library atmosphere”: everybody is so concerned about disturbing someone else with their talk that no one dares to make any noise at all any more. The result is an artificially silent space: No one wants to speak because you feel everybody else in the room can understand every single word.
So the more open a space is, the better your sound design needs to be. Concrete floors and bare ceilings, as stylish this may be as an “industrial look”, are probably not a good idea while carpets, sound absorbing ceilings and “sound breakers” in the room can make a big difference. Some glass walls (or real walls) and sound-proof doors are a great idea as well from time to time. Not everything has to be completely “open”.
As a result, we have put glass walls around the “team living rooms” that were originally openly placed within the teams regular workplaces. The effect is that these spaces now get used for various purposes by the team — informal meetings, face-to-face discussion, reading, relaxing with a coffee after lunch… The glass walls shield sounds, but keep the open and light atmosphere overall.
7. Fun is a serious thing in Germany
So you have to plan for those things very thoroughly as well 😉 We turned some former server rooms into a pool billiard and a kicker room. Who works seriously needs to have some serious fun from time to time…
We have made several surveys with people after we moved in: If asked whether they want to rather stay in the new office space or move back into the old office layout, roughly 2/3 prefer the new one over the old one. This is after 15 months “living” here roughly. This result was showing up after we had done an intensive “care-taking” phase immediately after moving in, collected feedback from the teams and adjusted dozens of specific details here and there based on input we had received. We now consider the concept a success overall, with admittedly the potential for further improvements as mentioned above. There’s always things to improve…
So that’s my personal experiences with our Office Space for Teams project, without the claim of completeness or final truth. I love to work in the new office space. But that, of course, is personal preference and taste.
P.S.: Uh, I forgot, we heard some concerns about “private space” in an open office environment. Developers (sometimes even managers) are a creative species. Nature always finds it’s way… 😉
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! 😉 |
Another recurring question I have been running into and have heard heated debate about is whether our cross-functional teams have to be “long-living” (sometimes “forever-living”), i.e. they don’t change their setup and mix of people, or should rather be “living” in the sense of adapting them optimally to the changing tasks at hand. Do you bring teams to work or work to teams?
As I had written in my prior blog post before, a well-functioning team is a huge asset. So you don’t kill productivity achieved in such a team light-heartedly by ripping the team apart every now and then for arbitrary reasons. Rebuilding a team and getting it back into a high level of productivity is time-consuming and hence expensive.
At the same time, sticking to an existing team setup just because it’s a functioning team but seeing that the product priorities and goals have over time changed so much the current team setup is more of a misfit than a fit, doesn’t look reasonable either.
So somehow one needs to find a healthy balance between long-living and living team setups. As always, before triggering any change, why not empower those impacted and potentially best knowing what to do ideally, i.e. the teams themselves, and let them work it out on their own? 😉
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.
I believe it’s the best times ever for software developers.
Software developers never had more influence than today. Look at companies like Apple, Facebook, Google, Amazon, Microsoft, SAP and others, to name just a few, that have made it into the top ranks of fortune 500 companies within the past few years largely based on software assets directly or indirectly. Starting as startups and outgrowing many other industry players by sheer speed and total market capitalization. All based to a large extent on the work and intellect of software developers.
At the same time, it has never been easier and cheaper for a software developer to get her hands at an abundance of hardware power for a bargain price and software components for free:
Back then when I started developing software myself, things were quite different. You had to invest in hardware upfront, software libraries and frameworks were rather the exception than the rule, the Internet did not exist and what you needed to learn you were teaching yourself out of books that you got in University libraries and bookstores if you were lucky.
I can still remember that during my first “professional” software project — I was freelance student programmer at SAP in 1988 — I was coding a graphical windowing system on my own as part of some graphical org chart rendering and manipulation product that connected to an R/2 Human Resource backend system initially and later to an R/3.
These graphical windowing systems were state-of-the-art on the computers I knew from home, a Commodore Amiga or the famous Atari 512, but if it came to Personal Computers in the office environment, the DOS console was still predominant. As Microsoft Windows was still not something to be assumed commonly available at customer sites, I had to come up with my own solution. So I coded a windowing library, mouse drivers, clipping algorithms, UI control libraries, printer driver code etc. What a stupid idea from today’s perspective, but back then? OK, perhaps it was even stupid back then… But nobody kept me from doing it 😉 The more concerning thing though is the following: How often do we make the same decision today? Re-invent rather then reuse? That’s why I believe Open Source is the way to go in many many cases.
“Back then” as a developer, you were basically working in a single programming language that only changed every few years. I started as a student in seventh grade with Basic on a Commodore VC20 that a friend of mine had invested into. Only to figure out quickly that the really cool and fast stuff needs to be done in 6502 assembler/machine code. I can still remember one family vacation as a highschool student when I was writing a hundred pages of assembler program “freestyle” with paper and pen at the beach in the shade to later on type it in when I was back home — LOL.
Later I switched to Pascal, Modula II, Java and C/C++ if it came to “serious” programming languages. It was only when I ported the ABAP kernel on all the SAP supported Operating System platforms from C to C++ compilation — I wanted to embed an XML parser I had written in C++ into it — that I blew up the kernel’s binary to a size of more than 100MB due to the C++ debug information required oll of a sudden. That was when someone wise pressed the emergency button and decided to promote me away from development into management to make sure I don’t create further trouble ;-).
Today, you have to handle a much bigger number of computer languages if you want to stay up to date with the trendy programming environments. The number of special purpose Domain Specific Languages is constantly growing, each of them often coming with their own specific environment and libraries, and JavaScript is on the best way to establish itself as the universal glue language not only between all the other domain specific languages and frameworks but also as a bridge between the gazing crater between client-side and server-side software development skills.
While in a way the fundamental principles and truths about software engineering and computer science have basically not changed over time, I believe that formerly as a software developer you were much more busy doing the nitty-gitty detail, from the ground up, fixing one screw after the other individually kind of development work and today as a software developer you are much more busy with “orchestrating” how you put powerful libraries, components and frameworks together. It’s like getting from building a car in a handcrafted manner to industrial mass production of cars from pre-fabricated components. The impact you can create as a single software developer, as a team or a software company, is by factors bigger than a few years ago.
What hasn’t changed though, is the enormous fun and satisfaction that comes out of the creative work that software development meant back then and still means today. “Look, mom! Look what I have created!!!”
Hey, how come I feel so old all of a sudden???? 😉
Björn Goerke's Blog 