TWiki Success Story of Ensequence
I brought TWiki to Ensequence
when I started in Sept 04 as Engineering Manager of the Authoring Tools Team. I had implemented TWiki once before at a previous company - with mixed results. Several people in the new organziation had worked for me before, so they knew what twiki was all about.
This time I decided to start of using it for my own day to day work to publish status reports, project plans, documentation links, etc. At first glance, people (well, non-technical types) are a little put off by TWiki. The name sounds goofy (of course so did Java, Google, Yahoo, etc.), and out of the box its a little vanilla / geeky.
The development organization was/is in transition from 'startup mode' to 'grown up mode' and had started to make positive changes in development processes and infrastructure. They were transitioning from VSS to CVS, started using codeline branching, integration night builds, formal product processes such as requirements, specificication, reviews, etc. So the timing was right for TWiki.
I started it out running on my windows laptop - mostly because I knew the 'secret sauce' to running on Win32 with Apache 1.3 and cygwin. This worked ok, but things need a bit of tweaking.
At first i used it primarily for status reports, product planning, and documentation pointers, and knowledge base items. We were in the early stages of the product development lifecycle so were were 'documentation' heavy. I started of using a handful of plugins: EditTablePlugin
. B y having all my own product work on twiki, folks started getting used to the tool. I tried to make it easy by being fairly loose on the authentication front by using TWiki names for change tracking only - no passwords or domain loging integration.
Over time more and more developers started using TWiki for there own personal 'todo lists', some knowledge base items, etc. So far so good.
When we went into primary development / coding phase on the next major product release, a primary goal was to go to an incremental / continous integration model. Previous product cycles were of the 'big bang / waterfall' variety which cause quit a bit of pain. At this point I added (and slighly modified) the ActionTrackerPlugin
to schedule integration builds and smoke test scheduling. Everyone on the team would take a turn installing and testing the product - rather than having this 'grunt work' fall on the junior folks. Each person in the chain would perform their part (build, install, test, results) - edit the work item, and notify each other and project management as to the status / results of the test. This enables me to know what the state of the source / build / system is without having to herd cats all the time. An interesting side effect is that we now have a record of how well (or not) we are doing in having a stable build / product.
As of this writing in May 04 TWiki has been accepted by the Engineering, and I transitioned from my laptop to an IT owned Linux (RH 9.0) box. This has really been a relief, since most thinks from TWiki 'just work' on linux.
I still get a few jokes from Sales / Marketing / Executive staff about Twiki "Is your TWiki up? Are you Buck Rogers" - but they are starting to learn the 'way of our people'.
The best thing about TWiki is that is a centralized information clearing house, both within TWiki and to other place in the organization. It is easy to link to our bugzilla system, CVS web, etc. You don't have to chase down an email, etc. just go to TWiki and fill your 'clue bag'. And it gets information out of the hands of a 'few' people on an email exchange, and out into the open.
It has also made it easier for me to project manage. The plan is transparent - everyone knows what we are doing, the expectations, timelines, etc. There are still a few surprised, but on the whole it helps everyone get on the same page. It also helps me counter the 'I did not know I was supposed to...' type of thing.
The best thing I could do know is 'Brand' our twiki with Ensequence graphics, or even a skin.
- 15 May 2004