ESME Blog

Introduction

Describing the mechanics of any project is tough, especially if you’re an insider. Detailing what’s happened with ESME is particularly challenging because it is unlike any other project in which I have participated. At this stage (and remember we haven’t yet gotten to the first TechEd), anything I say is preliminary and tinged with the sort of caution that any ‘beta’ release’ brings.

Regardless of anything else, of one thing I am 100% certain. ESME is a case study in the power of community, the dynamics that can emerge, the value of active cooperation between ’suits’ and ‘geeks’ and the results that are possible. Put another way, how else might the germ of an idea emerge to become a functional application in less than three months without the benefit of community?

The backdrop

Roughly three months ago, I received a Tweet from Anne Petteroe (@yojibee.) Unfortunately, Twitter doesn’t provide enough history to quote exactly but it went something like this: “Do you know about ESME, we need your help.” I had no clue what was going on. Darren Hague and Richard Hirsch describe a casual conversaton that occurred on Plurk that was the genesis on what we now call ESME -or the Enterprise Social Media Experiment.

The idea was simple. Take the concepts behind Twitter and apply them to business process problems that occur inside the enterprise. But why me? Somehow or other, the people who were mulling this problem thought I might be able to add some business value. This is highly unusual because it is often the ‘make people,’ the geeks who declare they know what’s best for end users. ESME is proof positive that no longer applies as a design principle.

Within days, a team of people from within the SAP community had either been approached or expressed a willingness to get involved. A few more days, some frantic Twittering and the casual conversation had become a project with a clear goal: Get something ready for TechEd and attempt to get it into DemoJam.

By anyone’s standards that’s ambitious. How can you go from zero to product in less than 90 days with a ragbag of people and an idea? This is where I digress and explain the actors and the relationships that either existed or were formed.

The players

The initial team included Darren Hague, Richard Hirsch, Abesh Bhattacharjee, Oliver Kohl, Anne Petteroe, Mrinal Wadhwa and myself. I personally knew Richard and Oliver from meeting in the Blogger’s Corner at SAPPHIRE Berlin. The rest were only known to me by name. It was quickly suggested that we add more people into the mix in order to get a broad set of suggestions and input from different perspectives. Marilyn Pratt for instance came in as someone who could help us if we were successful in achieving a place at DemoJam. Eddie Herrmann, a past DemoJam alumni could help us shape our ‘pitch.’ I know both these people. Given the short time frame, we needed to use Scrum methodology and for that Adobe’s Matthias Zeller was our early Scrum Master and mentor. The full ‘cast’ of interested parties can be found here.

Since then, the team has changed. Oliver and Abesh withdrew for various reasons (though there is no reason why they cannot rejoin) and we were subsequently joined by Jen Robinson and Kirsten Gay. Jen and Kirsten are key to the design principles needed for the UI. The final key player is David Pollak, the driving force behind lift, the Scala web framework.

Why this group?

Each person who has joined the team has been connected to another, either directly or indirectly through the SAP Developer/BPX networks, many of whom have mentor status. There has therefore been in implicit level of trust from the get go. There has never been a question of: “Why is this person coming in?” It has always been assumed that each could contribute something – mostly by way of code – but with the common goal of developing for TechEd and possibly DemoJam.

In other words there has been an affinity from day one to the project and to each other. This is a dynamic that is well understood – affinity groups may have loose ties but they can act as one where there is a clear, common goal. If I look at the Wikipedia definition of Affinity Groups, ESME displays most of the attributes Wikipedia describes:

Affinity groups are organized in a non-hierarchical manner, usually using consensus decision making, and are often made up of trusted friends of a common ideology. They provide a method of organization that is flexible and decentralized.

Affinity groups can be based on a common ideology (eg. anarchism), a shared concern for a given issue (eg. anti-nuclear) or a common activity, role or skill (eg. Black Blocks). Affinity groups may have either open or closed membership, although the latter is far more common.

Group operations

However, this is not enough to sustain any sort of group. There have to be some boundaries and while these have not been formalized, ESME people know that once we get past TechEd, then decisions of that kind need to be taken. Even so, early on it was decided to move the main group activities outside of SDN.

We were faced with one of those delicious dlimmas that are afforded to a very few. The moment we went public with the DemoJam entry video, we found people coming at us from all sides, clamoring to know more or wanting a piece of the action. This was in part due to the fact that I am connected to a number of high profile bloggers who, once they got a sniff of this, started writing interesting stories. What I didn’t realize was just how much interest there would be, albeit the blogosphere is raging with Twitteresque stories. It is also in part due to the fact the ESME YouTube video was watched some 200 times over a couple of days. The current view count is 369.

As a team, we knew that if we were to stand any chance of making it to TechEd, we needed to control group membership as far as possible and ensure the core team players could be left to get on with what they do best. Therefore, we moved the team to an Assembla environment and established a closed GoogleGroup.

That gave us a lot of advantages. We could for instance control who had access to whom for the purpose of any public statements. We could contain development reports and questions within an environment that allows people to remain focused.

In any project of this kind, early feedback is essential to keep disparate teams both in touch with the main goings on of the project while ensuring we’re all working towards something with which we can collectively agree. That has been especially important from a design perspective where we know that visual impact and usability are crucial.

In order to meet this need – and bear in mind we’re talking people in at least six countries and 15 time zones – we set up nightly Scrum calls. This has been challenging because everyone is working on this project in their own time and at weekends. Sometimes people can’t make the calls.

That’s OK because Assembla and GoogleGroups keep us up to speed anyway. However, the nightly calls serve a vital touchpoint for encouraging team members, ironing out operational problems and allocating tasks in what is unquestionably a dynamic and high speed environment.

For myself, I made an early decision to keep out of most calls because I’m not a code person and so would have little to add and might become a distracting influence. However, when business decisions have been necessary, that’s where I speak up.

What about leadership?

Leaders emerge, they don’t acquire their position by title or position. Each team member brings a specific skill to the table. There is no point in assuming that one person knows best. We had a design in place, a problem to solve and a time limit in which to get it done. Each person knows what they need to do and when people need to collaborate, it is on the basis of ‘who wants it?’ It is my experience that those most interested in collaboration are the right ones to form sub groups. That’s born out here. Should the project become commercial in nature, then that will change but for the purposes of community based projects operating over short time spans, this ad hoc set of arrangements has worked extremely well.

The community angle

All of this is designed to get readers to understand that community or affinity groups can produce remarkable results. This project would not have been possible without three things: SDN and the informal Twitter networks that have emerged among the various group members on the one hand and a hard floor deadline for a project in which we could collectively believe.

The challenge set by the group would not have been executable if it wasn’t for the fact this community can draw upon a broad range of technical and business skills. In his post, Mark Finnern alludes to some of them.

You can argue that this self selecting groupwould have emerged anyway. I disagree. The fact for example that Richard Hirsch is one of the best detailers of business processs scenarios I know is only one element. We needed someone who absolutely understands end user needs and Kirsten is that person. We need a framework that will be highly scalable. David and Darren are the go to guys. We also need Flex and SAP people who understand how it all comes together at the back end. Where else would you find that except in SDN?

So what is the secret sauce? I sense that if the community is large enough, you’ll always find groups who are willing to push the boundaries of innovation and invention. The fact SDN and Twitter have brought this group together in a discoverable context is more than serendipitous, more than coincidental. It is more than vaguely knowing, learning to trust and having a deeply felt mutual respect for one another. It is because the community exists for EVERYONE’s common good and provides the environment for EVERYONE to get something positive out of their involvement.

Final words

If you look at Mark Finnern’s post, you’ll see some of us will be presenting at various times during TechEd. We believe it is important to share experiences because ESME is a proxy for the good things that wil come out of communities that are tended, nurtured and contributed to. It’s your choice but I’d encourage anyone who has an interest in these things to come along to the sessions. There is much, much more to share.