Why am I leaving JTeam you might wonder? Well to be honest JTeam deserves a new leader.

I’ve successfully brought JTeam to where it is standing right now; a well respected company full of ambitious & talented employees and satisfied clients. We continuously enjoy what we’re doing and like to share it with the world, especially with you. But each company grows, and along the way I’ve noticed that JTeam is about to enter a new phase.

A phase of professional growth, both organic and aggressive, a phase of expansion and of more exciting (inter)national challenges is beginning.

A new phase sometimes requires a new leader, and in this case, I feel it does. JTeam deserves someone who is capable of getting the maximum out of it.  Someone that has proven experience in pushing a company to the next level. And we found him.

I fully enjoyed my years in the role of Managing Director of JTeam. I’ve learned quite a lot, met a large number of awefully interesting people, succeeded in delivering some really cool projects-  but most of all, really enjoyed working with passionate people. People that always want to learn, get the most out of what they’re doing and even more important, do it with a smile and in a well respected way.

This also holds for all our clients. Along the years I’ve met many entrepreneurs and business owners all of whom had wonderful dreams, compelling ideas and exciting projects.

But the thing I like the most is meeting the people behind these ideas, dreams & projects. I sincerely hope that we helped you achieving your goal and guided you well on your never ending journey.

Some people ask me “what’s next?” and luckily I can quickly answer this question.

I simply do not know what’s next, except enjoying a well deserved holiday of – let’s say – a couple of months. I will take my time to enjoy my personal life, get some rest, read all the books I got recommended and bought and -hopefully-  will soon be conquering the skies in a helicopter!

One thing is for sure: once I’m ready, you’ll hear from me. That might take a couple of weeks, months or years. Or maybe it’ll be a matter of days. Stay tuned!

In the previous part (part 1) of this series, I’ve discussed our first setup for a support structure in our company. As I said, this setup is not used anymore due to several reasons. In this blog post, I’ll clarify these reasons and take you in on our second setup of the support structure.

Keep in mind the original problems we had to tackle to improve our support initiative:

1. Knowledge stays within a select group of people. These people are not always available (e.g. when working on other projects). When these people are on holiday, sick or leave JTeam, work cannot continue. So, the ability to solve problems, or adding new features, depends on the availability of those people. JTeam becomes dependent on them.
2. People keep working on the same project over and over again which can become kind of tedious in the long run.

Problem description

Since the launch of version 1, we experienced some difficulty in realizing this plan. This was mostly due to the fact that people are outsourced, being unavailable at the office, or inability to get people away from the customer to take on the job of support member at JTeam. Depending on the customer, it is rather difficult to tell/ask a customer that our ‘empowering’ colleagues working on their project should return to the JTeam office to handle support issues.

Secondly, it is a big risk for JTeam to have three people working on support, situated at JTeam HQ, with the risk of not having any support call to handle. They can fill up their time with researching innovative technologies or writing blogs, all also *very* valuable for JTeam, but they don’t do any billable work. Eventually this will simply cost too much money.

Third, mainly because of the first point, a lot of the same people were assigned support duty, which made the knowledge transferring requirement obsolete.

Solution II

(code name : only the lonely)
To solve the availability problem, we changed the process in a way that availability is not an issue anymore. In this version, one person, each week, a whole week, will function as the first contact for support calls. This person will gather all support calls and might directly know how to solve the problem or checks if a solution is already documented on our company Wiki (Confluence). If so, this person can help the customer immediately. If not, the call will be forwarded to the team of people knowing the most of this project. It is the responsibility of the support person to check up on/manage the person handling the bug. The Project Manager of this project can do this as well, but it remains an important task of the support person.

In practice this means that the first contact will listen to our support email address and picks up issues from there. If this person fixed it, and thinks the solution to this problem is handy for reference, he has to document it on Confluence, so the next person scheduled to be first contact can benefit from that information in the future.

But…how do we let the customer contact support?

Project managers will still receive emails and calls from customers, since they are used to calling a specific person. And they should. The development team can change, but the customer needs one contact person which knows about their functionality and can help them with requirements and decisions. In this case, the project manager takes note of the call/email, maybe already answering, and forwards the support call to the support member for further handling.

Since, as a support person, you only have to listen to the support email address, people who work at the location of a customer, can also function as the first contact. To the customer will be communicated that it can happen that you have to answer some emails, or put other people to work. For the customer, this is more acceptable, then having a member of their development team, leave the team to be at JTeam for three days to handle support. As was the purpose in version 1 of our support process.

Next to the above process, we also have some technical infastructure to facilitate our support process. Problems that are issued by email, are directly and automatically logged into our issue tracking system Jira, so the customer and the development team have a reference of the problem at hand (see a future blog post about the Jira setup).

This way of work allows us to make a planning upfront for the person who is going to be the 1st line helpdesk person for what week. Depending on the internal vacation schedule we planned a week for everyone. The schedule is publicly available, and rescheduling is always possible if it is mentioned upfront!

Transferring knowledge

So, if a lot of support calls are still assigned to the person with already the most knowledge of the project, how do we address the knowledge sharing and transfer issue? Not one person should have all the knowledge of the project! You’re right.
Well, to solve this, when new features are to be created for these support projects, someone who is available will be pointed out to pair program / learn from the master himself. This way knowledge is transferred and more and more people will understand the code of the project, so every time even more people can pick up issues for this project.

Knowledge transfer is important. If, in the team planning meeting, we know that some work on new functionality is planned for a support project, we will check to see if someone with less knowledge of that project is available to learn from the person who is implementing the new features. This can for example mean, that people that work at the customer 4 days a week, will work on some new features of a support project, the day of the week they are at JTeam. This way everyone will be familiar in a way with the projects at JTeam.

So…

this is the plan for now and is currently used at JTeam. As a true agile and pragmatic company, we’ll evaluate in a couple of weeks and review how this worked out in practice. If our structure is being modified I’ll let you know of course !

Any remarks and suggestions about our current support process, or other ways of implementing a decent support structure, are more then welcome.

As you might know, if you are a regular reader of this blog, JTeam is a software development company. We develop enterprise applications for our customers. See for example our blog post about the Paazl project for a description of one of our projects. After implementation, these applications often will be maintained and developed further by the customer’s own development team or is being outsourced. There are however some projects which stay at JTeam. We keep on maintaining the project and implement new features.

These kind of projects require a different type of development and management process than the other projects. Especially the support work for these projects (i.e. bugfixing) is something that involves a whole different approach.

Here at JTeam we’re constantly looking for ways to improve our development and management processes. This is why we wanted to create a better way to handle these support issues.

This blog entry discusses this process. It will feature multiple parts, so you can follow our strategies and conclusions. Maybe it will help you to find the perfect process for your own business.

Problem description

As said, support and maintenance work is work for projects which are ‘done’ but are troubled by bugs or other problems. At JTeam most of the time the person who knew the most of the project was assigned to fix the problem. However, this solution is not without problems:

1. Knowledge stays within a select group of people

   These people are not always available (e.g. when working on other projects). When these people are on holiday, sick or leave JTeam, work cannot continue. So, the ability to solve problems, or adding new features, depends on the availability of those people. JTeam becomes dependent on them.

2. People keep working on the same project over and over again which can become kind of tedious in the long run.

We thought of a possible solution for these challenges and came up with the following initial solution.

Solution I

(code name : you spin me round)

Our first official support initiative was a combination of support and maintenance work with rotating teams.

We assigned 3 people each week that had ‘support duty’. These 3 people were expected to pick up support and maintenance calls, for 16 hours a week, and handle them together to make knowledge transfer possible. Every week, one person left the group, to make room for a new person. This way, the two people who were already in the support team, and stayed in the support team, could transfer knowledge to the new person. Resulting in rotating teams with a lot of knowledge transferring. Additionally we made sure that every week there was a domain expert or a software architect assigned to participate in the support group, to teach the other members of the support group enough of that project.

With the big amount of knowledge transfer, a lot more people got acquainted with the running support projects at JTeam. The added value of this is that we, and in the end our customers, were no longer dependent on one or two people who knew how to fix the problem. More people knew enough of the project, so our availability factor increased drastically. Thus allowing JTeam to plan people more efficiently. They could be billable on a lot more projects then they were before. A Win-Win situation for both the customer and JTeam!

To make the support process more enjoyable for people, they were after all expected to be in the group for 3 weeks, we decided to invest in these people. At JTeam we believe in the personal development and improvement of our knowledge. We do this by training our colleagues and letting them investigate and work with new technologies. This is why we decided to let the people who work on support duty, investigate cool new innovative technologies when no support calls where due.

Business wise, we offered our customers an Service Level Agreement (SLA). We needed 3 people to be available every week that could handle support calls. That meant those people had to discuss with their teamlead that they will be less available for the coming week(s). This has influence on the project they currently were working on. Guaranteeing availability is an added service to the customer, which can be agreed upon in an SLA. Customers with this SLA will be part of this process and will benefit from the advantages of this system.

However….

this way of working was used for 3 months, but currently no longer used at JTeam due to several reasons. Next time I will describe these reasons along with our new support.
In the mean time,  I’d really appreciate your feedback on the above structure and solution. What do you think is wrong with this, and how could we improve? How does your company handle these challenges?

The things on the list do not come out of nowhere. We’ve always been a company partially driven by technology and innovation. We are always on the lookout for new technologies that can help us realize our projects in a more efficient yet exciting way. This way we became involved with for example the Spring Framework, which finally resulted in us co-founding SpringSource.

Recently, we decided we should visualize our view of the (technology) world a bit more and the format we’ve used is the BCG Matrix that puts a business’ activities into one of four categories. Paraphrasing and translating this to our business (the enterprise software deveopment industry), the four categories are

• (Cash) cows – technologies with a high marker share in a slow-growing or mainstream sector that can help us big-time realizing our projects. Technology in this areas are regarded as being mature and sometimes possibly a bit boring. They generate money and interest though from a large amount of users in a sector that we find interesting
• Stars – rapidly growing technologies with a high market share in the early-adopters area. We already use these technologies to realize projects in a more efficient way than we used to do. Technologies in this area are cool and regarded as being innovative. Potentially, technologies in this area can become cows if managed correctly
• Question marks – technologies that grow quickly, but still do not generate significant amounts of revenue. Should be invested in in order to make them stars. Potentially technologies in this area could add to our ability to better service our clients
• Dogs – technologies that (in our minds) do not add to our possibility to implement and maintain software enough, do not generate enough money to make a profit from given our current situation and/or are not interesting enough for us to invest time in

After having categorized the technologies that we use and might want to use, we ended up with a pretty solid matrix. The challenge with things like this usually is in my opinion how to make them part of the company’s mindset and to keep them alive. We long though about a way to make this happen and we settled on putting it up somewhere in a prominent area in the office. Not only did we want to put it up somewhere, it should be editable in a way.

To do this, I’ve ordered semi-permanent whiteboard markers. I didn’t know these things existed and found out about them after some Google’ing. They’re only erasable by using a wet cloth. This means if you scribble on the window or whiteboard using a normal whiteboard marker, you can still erase the scribbling, but not the semi-permanent stuff.

I’ve drawn up the matrix on the window near our lunch table. This way, we can look at it over lunch and discuss things. The window looks out over the city so people can also pretend to be looking at it, while in fact they’re enjoying the view.

It’s been up there for about an hour and people already began scribbling on the window to express their disagreement with the way some things are categorized. Also, some things have been added and some renamed. It seems like it’s working .

In the future, you can expect more blog entries about individual technologies on this list. Some opinions might be controversial or personal to one individual employee in the company, nevertheless they always add to the discussion about what should be in the matrix and where.

From say 2002 to about 2007, we’ve only had the occasional Linux user and hardly any Mac users, so the fact that Exchange is not a decent cross-platform solution really wasn’t too big of a deal. Lately however, we are starting to get more people that prefer an OS X or a Linux environment. Now I wasn’t aware of that, as I was working for SpringSource the past 4 years, so in fact, I couldn’t care less . But… as you may have heard, I’ve quit my contract at SpringSource and for the time being I’ll be at JTeam (more on that later by the way). In other words (since I am a Mac user), now all of a sudden I *do* care.

According to this excellent blog entry by there is no decent solution for synchronizing Exchange calendar information with Apple iCal.app and from what I’ve heard, the situation is exactly the same for Linux users. For the OS X user the wait shouldn’t be long anymore, since Snow Leopard is on its way and this version of OS X includes Exchange support. For Linux user there is no native solution that I know of.

In the meantime, several people have figured out workarounds that (literally) work more or less. I believe there’s somebody that maintains his schedule in a Google Calendar, is able to send out meeting invitations and also able to accept and reject meeting requests, but his Free/Busy time is not available in the Exchange calendar. There’s also somebody that just has everybody call the office manager to schedule an appointment (that somebody would be me). It all works… but more often less than more…

This lead me to think we should search for a more permanent solution. One that cross-platform, doesn’t require any more maintenance than a full-fledged Exchange server (mind you: we don’t have do a lot of maintenance on it at the moment).

Systems administration is not a task I like particularly well (and it’s also not what I’m going to do at JTeam on an ongoing basis), but I’m guessing it’s going to make a lot of people at JTeam very happy if we get this sorted out, so why not get it out of the way then. I’ve spent a little time looking for solutions and finally settled for Google Apps. For now for email and calendaring only. Maybe in the future also documents and more.

In the next few weeks, we are going to try Google Apps out with a test domain and hopefully by the end of March, we’ll have a final decision on whether or not Google Apps is going to be the new email and calendaring solution.

A little bit of background on the reasons for this change. The most important reason for it is that I think for a software development shop of about 25 people, I don’t think it makes sense anymore to manage all kinds of internal systems for things like email and calendaring. Yes, in the past, when no alternative (such as Google Apps) were available maybe, and maybe if you’re a very large organization… But these days, it makes sense IMO to focus as much as possible on what you’re doing best and at JTeam that’s software development, not systems administration (ah, so now I’ve revealed that we suck as managing systems?? ). A second big reason is spam. We’ve been fighting the spam problem with relative success, but Google seems to do a much better job at getting rid of spam. The last reason might maybe be cost-related, but that’s definitely not the main reason. Yes, I do believe it’s going to be cheaper in the end, but that doesn’t matter too much. The other reasons are way more important.

Concluding, it sounds like all is geared towards getting people to focus more on what they do best and get stuff that doesn’t matter (deleting spam, calling up office managers to schedule appointments, managing useless systems) out of the way.

I’ll report back with some findings later on.