ESME Blog

Last week, we received the amazing news that ESME will be participating in the Demo Jam at SAP’s TechEd in Bangalore. This will be the first time that any team has presented at all three Demo Jams.  Abesh Bhattacharjee and Mrinal Wadhwa will be on stage presenting ESME to the crowd. Athavan Raja Durairaj will backstage supporting the two.

Each time ESME has been presented at one of this year’s Demo Jam, “local” team members have presented / supported. This is definitely one of the advantages of having a global team.  

Good luck next week to the ESME team at the Demo Jam.

P.S. We will posting the link to the live Internet video stream once it is available.

Thanks to Twan van den Broek for providing the picture

Introduction

“We are all part of teams. Java teams, ABAP teams. Communication in these teams can be a challenge”

This is how we opened our Demo Jam entry last week at the SAP TechEd in Berlin – the complete script is here. Based on my experience in Berlin, lately I have been thinking a lot about communication and its relationship to a team’s success.   

The story behind the Demo Jam in Berlin

How do you define “success”? This one word has a multitude of meanings – many of which are subjective in character. For me, “success” means overcoming adversity and the ESME demo in Berlin is an excellent example of a team dealing with enormous pressure and not crumbling under it.

Not many people know the “real” story behind our participation in Demo Jam and what happened during the Demo Jam itself. Craig said that we had a problem with one of our servers. What really happened was that there were network problems with our main ESME server. The reason for this problem has been discovered but is largely irrelevant to the point I want to make in this blog. We discovered the problem at the final technical check 5 minutes before the Demo Jam started. Darren Hague, Anne Petteroe and I took Darren’s laptop back stage and tried –along with the technical staff associated with the Demo Jam – to localize the problem.  After realizing that there was a problem with our initial server, we first tried to correct the problem. When we realized that this wouldn’t work, we decided to use a secondary server.

You have to remember that all this time the clock is ticking and Craig Cmehil, Jeff Word and other DemoJam staff are getting increasingly worried.  Are we going to make it on time?

Since the Java logger code was created by Darren, he could make the changes himself. The ABAP code, however, was contributed by Thomas Jung and Athavan Raja Durairaj  Thomas Jung was somewhere in the audience of over 2,500 screaming fans. We had to find him and fast. Anne went out and found him and brought him behind stage to fix the ABAP code. At this point, we had about 15 minutes before we were supposed to go on. 

At some point, Dennis Howlett  came back stage to see if he could help us. During this time, he sent off a tweet on Twitter with one word “backstage”. For all those who follow Dennis on twitter and know his wit, such one word tweets are exceedingly rare. This one word was proof of the strain that he (as well as the entire team) was experiencing.

Originally, we were the fifth from six teams. Realizing that we needed more time, we asked if we could go last.  We were granted this request. We had gained 6 minutes. Finally, after changing the code to communicate with the new server, we had to test our demos.  At this point, Craig came back stage and asked how long we needed. We said “10 minutes”. Craig then said “You have 10 minutes”.  We struggled and tested everything as much as we could. At two minutes before we were to go on stage, Jeff came and asked “Are you ready? Yes or no?” We said “Yes” and went on stage. As Anne was setting up the laptop on stage, we realized that we didn’t have a password to logon to the remote desktop. I had to race back stage, grab Darren and race back on stage to unlock the Remote Desktop. After doing this, we were ready but were still very worried. Moving from back stage to center stage meant disconnecting from the network and then reconnecting. We had no idea if everything would work.  When the lights focused on us and Craig started talking about sacrifices to the Demo Jam God, I thought to myself “We’ve sacrificed enough in the last hour: 3 kilos and 40 new grey hairs.“

For the Demo Jam,  I just had to give the introduction to ESME and provide the transitions between demos, Anne was doing the actual demos. We were both under unbelievable pressure. Speaking in front of a crowd of 2500 is tough. Combine this with uncertainty whether the technology is even going to work is even worse.

Although we would have liked to won the Demo Jam in Berlin, it was really of secondary importance. If you look at how Anne and I responded after our six minutes is over, we don’t ask the audience to clap. The first thing we do is to give each other a high five. At this moment, we were overwhelmed that everything had worked. If other team members were on stage, we would have included them as well. 

Lessons from the Demo Jam and ESME

Some might say that this is a personal story and too emotional and really doesn’t belong as a blog on a technical site. That is just my point; it is this emotion – this passion – that enabled us – the ESME team – to deal with a crisis.

Remember, the ESME project is composed of about 20 members spread across the globe.

This dispersion means that really have / had no possibility for face-to-face personal interaction. Although many of us had never met each other in person we had contact on a daily basis. We communicated with each other via twitter, ESME, emails, telephone calls etc. Our network was active. We were connected.

I consider these my individuals more than just “project” members -I consider them my friends.  We all have the same passion not only for ESME but also for collaboration in general. It is something we thrive on as evidenced by our exceedingly active communication with others – our networks.  When we communicate, we just don’t communicate about ESME or technology or our jobs. We communicate about our lives. It is the resulting bonds that give us our strength and our ability to master thorny situations such as the technical difficulty associated with our participation in the Demo Jam.

A note: Many of those in ESME (but not all) are SAP Mentors. If you look at the characteristics needed to be an SAP Mentor:

• Hands-On Expert in an SAP Product or Service
• Collaborative attitude
• Good Communicator
• Preferably working at a Partner or Customer of SAP
• Interested in Improving product and services of SAP and the relationship of SAP with customers, partners and prospects

you will see that are interesting parallels to the topics that I’ve just discussed.

The current state of software development

Now, you might be thinking to yourself – “Give me a break. Where is my handkerchief? I’m starting to get teary-eyed. What relevance does this have to software?”

If you look at the how software development or projects in the current enterprise environment are typically structured, there are usually short-lived projects based on a global team that come together for the first time in the project and then disengage when the project is over. 

How often do we hear about failure in such global teams? When the distance is so great, you usually can’t really get to know one another. There might also be cultural differences which lead to misunderstandings at a personal level. Unfortunately, to achieve optimal performance, it is often critical to bond the team members as rapidly and efficiently as possible. If a problem occurs in a software project and it is necessary that team members go the extra mile to meet a deadline or solve a difficult problem, it is usually the more cohesive team that will be successful.  I’m much more willing to help some one whom I know than a complete stranger.

There are currently a number of new community projects that are being formed in the SAP communities.  Community projects are project that take place in the community – that means usually outside of work hours and usually individual participation is voluntary. What I have discovered is that what keeps those individuals involved is their passion and the relationships to others in the team. 

Conclusion

I think it was these personal bonds that allowed us to deal with the stress / pressure involved with the Demo Jam in Berlin. We didn’t want to let each other down.  We supported one another.  This experience has taught me a lot about what makes teams successful – not only those in community projects – but in other contexts as well.  It is the personal relationships – the web that connects us with others – that is critical. As I have mentioned, these bonds were largely created by communication at various levels – twitter being the probably most important, because we were a distributed team.

Thus, my experience in this community project demonstrates the importance that such microsharing tools (such as Twitter or ESME) can play in teams. Although our script in the Demo Jam focused more on interactions of a technical nature (Java logger, ABAP watch, etc.), ESME is one example of a tool that creates bonds of a more personal nature.  Such platforms are instrumental in building strong teams that act well in times of adversary or stress which are unfortunately commonplace in the current corporate environment.

Note: I also posted this blog on SDN.

Although the script below doesn’t contain the exact words that we said at the Demo Jam in Berlin, it was our basis. 

Dick

We are all part of teams. Java teams, ABAP teams. Communication in these teams can be a challenge, and is most often not as rapid as we would like it to be.

Every day we are flooded with emails and hand on your heart, do you read every line in all your emails? When you need to communicate with teams, how do you usually do it? You send an email to a distribution list. Spray and pray.

With ESME, introduces a new concept in communication, which lets you filter out the noise! You decide which information you would like to receive and respond to.

Let’s look at three common problems:

1. How do I get answers to technical questions? Today, I use that old email distribution list and hope I find the right person. 

2. How do I deal with problems that occur in the development lifecycle? Today, I have to dig through various systems to find out what happened.

3. How do I deal with developers that change code without the telling the team? Today, I have to wait for my code to break before responding.

Let’s look at a simple problem: getting answers to technical questions

Anne

I have a CE installation problem. I have ESME open in my browser. I am going to type in my message here which goes to my followers and add these extra words, which are called tags. What are tags? Tags are special keys that other users in my team or company can listen or subscribe to. Because I add these words I make sure that my message goes to those people who are interested in this subject.

Darren is from another part of my company and has subscribed to tags that interest him. Remember I don’t know Darren. He gets a message about my problem and sends me a message in return referring to the SAP Note that helped him and solves the problem.

I don’t find an answer. I find the right answer.

Dick

With ESME, I can communicate with people whom I don’t immediately know. I can tap into tribal knowledge. Now what if we extend this so that the system talks to the same group of people?

Let’s look at a more complicated problem: how do I deal with issues that occur in the development lifecycle?

Imagine this, I am developing a WebDynpro application. Usually, when an exception occurs, I have to log onto the NetWeaver Administrator and open up the log viewer and find my exception amongst the 1000s of other exceptions. †Wouldn’t it be cool if this exception was sent to me?. When they have problems, maybe I will be informed but maybe not. Wouldn’t it be nice if I was sent this information.? Better yet, wouldn’t it be useful if my entire network was informed about this problem?

Let’s see how this works.

Anne

I am going to create an exception with my WebDynpro application.

See, a message just appeared in ESME. This message is created with tags. Those individuals subscribing to these tags will get the message.

You might think that people would be flooded with information but because, they choose to receive messages on certain topics or individuals, they decide what they receive.

Dick

Let’s look at a real complex problem: how do I deal with developers that change code without the telling the team?

Picture this: someone goes in and changes your code or one of your development objects. What happens – your code breaks. I bet this never happens to you. Now you have to find who broke the code and why.  Wouldn’t it be cool, if the system informed you when others changed their code?

Let’s see how this works.

Anne

I will now pretend I am that developer down the hall, and I will change one of my function modules in his name. Because this function module is one of my development objects, I subscribe to any changes which happen to it.

I just activated the function module and as you can see the system immediately sent a message to me, which arrived in my inbox in ESME.

The message tells me which object was changed, who changed it and when the change happened.

I can now respond before code breaks.

Dick

We have just shown you three ways to solve problems you experience on a daily basis.

1. How do I get answers to technical questions?

2. How do I deal with problems that occur in the development lifecycle?

3. How do I deal with developers that change code without the telling the team?

All with one tool – ESME.