will take much longer than Mark expects to build his reputation. Even
if Mark is an exceptionally good programmer, his team is already quite
competent, and the decision-makers within the organization are more
concerned with the performance of the team as a whole than they are
with any individual. Mark may not realize it yet, but it will be difficult
for him to differentiate himself technically from his teammates.
In the interim, Mark will struggle with the development processes
that he strongly feels are inefficient, and as a result, he’ll enjoy his work
less. This will in turn affect his own motivation to differentiate himself from his peers. There is a better way. In his article “At Your
Service: Creating a Service-Oriented Software Engineering Team
within your Organization” (STQE Magazine, May/June 2001), Robert
Sabourin describes how reframing a software engineering team as a
service provider to other teams in the organization can greatly
improve the ease with which that team is able to enact measurably
positive change on the organization as a whole. And there’s no reason
this idea should be limited to only teams of testers or developers.
Sabourin says that when a service provider is first seeking out ways to
earn trust from its customers, it’s much simpler to build trust by adding
services instead of trying to convince the customer to abandon a service
provided by some other organization in exchange for one you will provide.
Almost every student of computer science is taught in introductory
algorithms courses that a change can be viewed as some combination
of an addition and a deletion. We can view the changing of an existing
process in the same way. There are costs—time and money and
trust—associated with removing or “deleting” the old process, and
then similar costs for adding the new service. However, it typically
requires much less of an investment of trust to add a service, because
doesn’t disrupt an existing structure. If you can manage to add a service that’s useful to the organization and meet a need that was not currently being met before, you will build trust that can then be “spent” to
change existing processes. In fact, once you have successfully added a
few processes, you may even be asked to change things that you previously petitioned to improve in the first place.
A Matter of Mindset
Let’s say Mark decides to take this approach. How does it differ from
what he was already doing?
There are two steps to adapting a service-provisioning based outlook. The first is to reflect on the services that you are capable of providing, which may or may not already exist in the company.
For example, Mark is working in a Windows-centric environment,
but he’s also quite accomplished in Linux development. He has done
a great deal of web application development using open source technologies. He is willing to spend some extra hours outside work on side
projects related to his job, which is a luxury that many of his older co-workers cannot afford due to other responsibilities. Finally, he has a
fair amount of experience in operating and integrating bug-tracking
and revision-control systems. Mark decides that within his organization, he is capable of adding value by providing services related to
1) Linux development, 2) web application development, and 3) revision control and bug tracking.
The second step involves finding opportunities to “sell” these services in situations where people want to add to the existing process.
This step is fairly simple because most people who are in pain are not
shy about expressing their anguish.
There’s one sticking point in the second step for many people,
though. Most developers will hesitate to add components process that
they feel aren’t really needed, no matter how loudly others are clamoring for it. This desire to be efficient in the short term can actually
hamper one’s ability to improve the overall efficiency of the process in
the long term, since adding services can be a great way to build up the
trust needed to make broader changes.
As an example, Mark has often heard Andy, the director of test engineering, complaining that he has no good way of visualizing the statistics
maintained by their current bug-tracking system. Andy would really like
an application that could generate charts to show the trend of how the
number of bugs opened, re-opened, resolved, and so forth, has changed
over the course of a project, especially when each project approaches its
deadline, and different branches are required to be maintained.
Mark’s first thought when he hears this request is that some other
open-source bug-tracking tools already have this capability, and that
this functionality could be acquired “for free” by simply switching over.
It’s a procedure that he has implemented before, and he knows it can
be done relatively painlessly, save for the fact that the test team and
product owners would need to learn how to use the new system (a
time and money cost).
The other approach—writing a program to solve a problem that
has already been solved—is something Mark finds highly distasteful.
In many respects, writing new software is wasteful compared to simply switching to the other bug-tracking system.
However, Mark reasons that if he were a consultant offering his
services to this organization, this perceived need would provide the
perfect opportunity to build trust with the client, because it doesn’t
involve changing any existing processes at all, and it’s something the
client feels is desperately needed. By meeting the perceived need, Mark
can start to acquire the trust currency he needs to make things more
efficient in the long run, especially since the director of test engineering is such an influential person in the organization.
Perceive and Be Perceived
It may seem as if adopting a service-oriented “method” isn’t really
much of a change at all. Mark’s intent has not changed. He still wants
to make things better within the organization. However, his perspective of what he’s fundamentally doing has shifted subtly, and in a way
that will improve how others perceive Mark and his actions.
Mark’s new statement of action would be something like:
As a provider of Linux development, web application development,
and revision control and bug tracking services at Informila, I
would like to make things better by adding components or processes
to fulfill needs that have been expressed by the organization.
The outlook is totally different. Mark has gone from focusing on himself as an individual to identifying himself as a provider of services. While
the shift is strictly one of notation, it removes some of the ego from his
perceived role, and allows him to occasionally see the opportunity in
courses of action that he might other wise dismiss as silly or ineffectual.
In my experience, this seemingly superficial change has a very real
effect on the kinds of opportunities that one will pursue, and the ways in
which one will react when confronted with adversity in these pursuits.
Another shift Mark has made is that he’s focused on adding
processes to build trust before trying to introduce changes to existing
processes. Lastly, he’s focusing first on needs that have already been
recognized by the organization, before trying to address things he has
only noticed himself.