But this time we wanted to change our approach. I wanted our team members to concentrate on core business activities that could not be delegated.
It is for this reason that we wanted to delegate the web renovation as much as possible. In other words we wanted to become clients.
What I Didn't Want
What I didn’t want was quite clear.
- I didn't want anyone on my team to be struggling on <div>s with cumbersome browser bugs;
- I didn't want to have to worry if servers were up or down;
- I didn't want the unpleasant surprise of finding malware on our server's file system;
- I didn't want to keep myself or my team busy with designing, testing, writing, integrating, growing, or correcting codes for mailing list subscriptions, dynamic information production, back up procedures, or configuring frameworks for content management systems, or having to build one ad hoc.
What I Wanted
What I wanted was also quite clear:
- I wanted something on the Internet easy to maintain and update;
- I wanted something that could make use of all the power of the Internet and the wealth of online services from Flickr to Scribd, from Slideshare to Facebook. But not with those plug-ins and rigid panels full of colors and social network reference logos;
- I wanted those functionalities to be an integral part of our site in order to help our identity emerge in a silent and seamless way;
- I wanted everyone visiting our website to recognize us and enjoying recognizing us;
- And I also wanted to put future and incremental versions of our sites into production, and do it in a way that progressively implements improvements and features. Even small versions, but nonetheless valuable for me.
In short: what I wanted was "living software" capable of growing.
This time I wanted all of this as a client.
A Hardly Agile Reality
Many of the experts I know in IT Architecture, User Experience, Web Development etc. etc. recently placed a section on their LinkedIn CV with reference to Agile Methods aimed at showing the agile skills they achieved.
This is why, having seen the birth of agile, I was quite surprised to hear their reaction when, as a client, I told them what I wanted for my websites.
"It's the same thing we were thinking of doing".
"...but we can’t provide a small weekly order as you suggest. It's not worth it for you. You tell us what you want and we'll make you a prototype".
"...if you don't like the visual design we have in mind for you, we can change it even a hundred times. But first let's establish a period of time, let's say one week, in order for us to finalize the changes".
And how about the IT Architects - they too with "agile" in their CV...
When we hinted at updating one of our sites they told us 40 person-days were needed to elaborate their view of the site...
Being the Focal Point of the Process
The recurring sensation I got was: everyone, User Experts above all, said we were the focal point of the project's process but we often found ourselves involved only marginally.
If I'm to be considered as part of the focal point of something, I would expect to be able to say what I like and what I don't like, particularly in this situation because who better than us knows our identity and our users?
The smirky smiles on their faces led us to believe we were not being taken seriously.
In short, User Experience was supposedly not for us. There wasn't even the need to listen to our ideas :-)
And It Doesn't End There
My team was used to giving continuous feedback and exchanging ideas amongst each other but were advised against this way of working by the majority of those experts.
For them it was without a doubt preferable to organize our collaboration by accessing BaseCamp, by using a calendar, monthly milestones and weekly feedback on Skype.
Their replies sounded a bit like "tell me more or less what you want and don't worry, I'll do it for you". So much for us being a central part of the project.
Obviously none of this comes anywhere close to being Agile nor is it at all efficient.
My team is also used to replying to a legitimate and fundamental question:
"How much will I earn if I decide to hire you?"
The ROI should be clear to clients when taking on a supplier.
Obviously not to the last cent, but you should be able to understand the way in which a certain activity will produce possible income.
What was the User Experience's ROI for example?
And by User Experience I mean all the activities that are put in place in order to achieve this learning experience by the user.
The various User Experts' reply was similar:
"you can't calculate the ROI... you need considerable and continuous investments for User Experience to be productive... but the User Experience is necessary, you can't do without it."
Out of curiosity we asked IT Architects, Visual Designers, etc. We got the same reply for IT Architecture, Visual Design, etc.
The Showdown
The FCcom team considers our reorganization a happy event.
It celebrates ten years of growth and satisfaction with XPLabs and perhaps for a while we made believe we weren't listening.
Until the day we got together to discuss the estimates by the various experts.
It didn't take long to realize that the operating costs needed to do what we had in mind - excluding the costs of the time/effort needed to be dedicated to the project - were the same as buying a typical, expensive little house on the exclusive Amalfi coast.
Figure 1 - Amalfi Coast
And these were just the costs of the first release of our web sites.
Once each and every member of my team pictured that dream house and the beautiful blue water on that lovely beach, they asked for a "timeout".
"But can it really be so difficult and so expensive to develop a website today?"
I asked my team.
This is one of those typical situations where you ask yourself a question and the whole team answers with wide-open eyes and worried look on their face:
"Hey, you’re the methodologist."
A New Idea
I forced myself to find a solution.
I wanted to find a development process for producing something that was halfway between a website and a blog and who knows what else, something that could produce value quickly, easily, and incrementally.
No prototypes, no wireframes for locating layout and interaction.
As of day 0 a functioning, mininum version had to exist.
I wanted to be able to say "I like this or I don't like this" on a working system - whether it regarded layout, colours, styles or content structure...
It was a question of combining components of flickr, twitter and slideshare all together but in a transparent way without having to program heavily.
And our identity had to emerge from these components, not the identity belonging to other brands. Our own ideas had to emerge - with all due respect for the talented experts.
And despite the experts were telling me it was impossible to do I kept thinking of the little house on the beach and I kept believing it was possible to do :-)
A New Product: K Log
We needed a K Log.
A Kombined Log.
Indeed we wanted to reinforce the "combined" Log.
We realized what we needed when we saw it on the blackboard written amongst the various scribbles.
Seeing those letters on the blackboard gave the impression of a mathematical formula: The concepts of complexity, entropy and self-organization deriving from the Second Law of Thermodynamics.
A name and two valid inspiration sources?
No one on the team believes in combinations: KLog chose us to be developed. No doubt about it.
These inspirations together with the new method I was writing about brought on the new idea of Just Klog It!: the process the team would later use to develop our Klogs.
You Caaaan Dooo Ittt!
Using post-its stuck on the wall the team established a series of rules, starting with the things a Klog should and shouldn’t have:
- Graphics yes, but only if efficient (not minimal, but efficient);
- No fixed templates;
- No dynamic menus;
- Yes to a dynamic organization of contents
- And yes to malleable components.
- No to "Posted By", No to Plug-ins!;
- Yes to social maps
- and so forth
Yes. We didn’t want to make the most attractive and user expert site in the world. We wanted a site that would express who we are keeping in mind the navigators that we would eventually have the pleasure to host.
We wanted to make our site together, having fun doing it. Without having to manage contrast, resistance and heavy technlogical situations.
On day 0, without any knowledge of Typepad and with rudimetary memories of CSS :-) we had online the first version of our site, what we call Klog 1 (the first version of Klog).
Day after day we introduced, cancelled and modified elements. Our methodological objective was to find repeatable criteria in order to organize HTML and CSS codes in such a way as to be able to make changes as quickly as possible.
When we needed specific skills - such as visual design or social network experts - we would get them involved in our team, by literally being present. Our passion and fun was contageous.
Developing a Klog requires work and knowledge, but technical aspects are overcome by the ability to organize the components and give them a malleable structure.
This Klog
This Klog is on a trip.
It’s not perfect but it expresses the idea we initially had in mind.
Just Klog It! may not be valid for every situation but in our case it enabled us to save many thousands of Euros, reaching goals that would have been very difficult to reach otherwise.
We like the idea that anyone wishing to learn the basics of programming and visual design can try to show their own identity by making the user’s experience a lively one. We think that this is a fun and educational activity. A company can learn a great deal on how to communicate and do marketing.
How can you possibly invest thousands of dollars and euros without having a clear idea of the ROI those investments will produce and without knowing how much the site will cost in a month, a year or years?
Ah! We went back to some of the experts we initially contacted. Those who advised us against incremental steps, continuous deliveries, how to place the team, shared experiences. They forewarned us of how prototypes and wireframes were irreplaceable.
Some of them now agree with us and we may even collaborate eventually.
