Introducing a tool
successfully
A couple of concrete steps to take
A customer recently asked me
this: “We still lack a bit of acceptance among our users for the DSL. Can we
chat a little bit about ways of teaching them how to use MPS and the DSL?”
I suggested to ask their
colleagues in their sister department, because they seem to be quite successful
with it. For all of you who don’t have the luxury of just asking colleagues,
here are some pointers of what to do.
Three Preliminaries
First, I don’t think any of
what I am going to say is a) a huge surprise and b) specific to DSLs. It is
tried and trusted techniques of introducing something new into an organization.
The more disruptive the change is, the more critical is a structured approach
of introducing the change. And DSLs certainly are disruptive.
The second preliminary is
that all of what I am going to suggest won’t work if the new tool or approach
isn’t any good. Make sure that your “new thing” actually fits with the work
your users have to do. It’s ok to be disruptive, but you have to disrupt with
something really good. Otherwise you have no chance.
Third there’s politics, some
folks’ general lack of motivation to change and all kinds of other
psychological things to consider. I won’t cover these things here; we assume
the set of users you want to “convince” is not unreasonably opposed.
So let’s now look at how the
successful department did it:
Introductory Workshop
We had developed the first
version/release/prototype of the language with the help of two domain experts.
They were part of the language development team, and helped us make sure the
language was reasonably close to the domain. After we build a few prototype
models using the language with these two, we decided we were ready for a wide
audience. IIRC twelve additional users were scheduled to learn the tool next.
We started with a multi-day workshop where we explained the idea, gave an
overview over the language and then developed a few example models from their
specific sub-domain. Didn’t all go completely smoothly, but at the end of the
week I think there was general agreement that this new thing isn’t completely
crap and might actually simplify their work.
Champion
The next ingredient is a
champion; her role is to act as a bridge between the language development team
and the (growing) user community. She acts as the first level support for
questions from the users and works with them during the initial use of the
tool. She is also part of the development team’s Dailys and requirements
discussions, and she validates a new release before it leaves the barn. Every two
weeks when we release a new version of the tool, she writes a release notes
document that explains the new features, required manual changes to existing
models, or automatically executing model migrations. Every week she also
moderates a Q&A session where the users can ask questions; a representative
of the developers is also part of this meeting, so devs and users can discuss
technical issues directly.
Pairing
Nobody uses the tool alone
during the first phases of use. At least two, sometimes even larger gaggles
work together. As we all know, it is easier to avoid getting stuck when you’re
not sitting in front of the box alone.
Quick turnaround
No tool is perfect.
Especially not one which tries to “inhale” the semantics of a non-trivial
domain. An important ingredient to successful adoption is that the turnaround
time based on user feedback is reasonably quick. Nothing is more frustrating if
users find a problem or something that doesn’t fit their tasking, and then
nothing happens for weeks and weeks. Larger changes of course take longer (and
often need quite a bit of discussion to identify the right abstractions), but
you can win a lot of hearts and minds if small (and annoying) problems are
fixed quickly.
Wrap-Up
So basically that’s it. Quite
obvious, isn’t it? It one of these things where the problem isn’t that these
things are hard to come up with; it’s more a matter of just doing it,
systematically.