I was giving another demo and was asked to demonstrate collaboration. As I was discussing Contour and it's usage of discussions, on-line access and notifications to enable collaboration on a requirement it became clear that the customers idea of collaboration was more in terms of real time like a white board application. It caught me off guard because I realized that his definition of collaboration was valid. In my mind true collaboration is on going and not finite. Open source is a good example; someone starts and idea or concept, people join in, discussions happen, changes occur and over time the idea evolves. This is long term collaboration vs meetings (on-line or in person) which are relatively short term and hard to capture. Take the white board example. At my previous job we did a lot of white boarding and while it was useful to extract the ideas, we would cling to these diagrams by dragging the white board around or taking a photo of it.

While both definitions of collaboration are valid and important I feel that the idea of evolutionary collaboration is really what all the hype is about these days. This backstage as well as Contour operate in this vain.

Thoughts?

I just read this article from wired  about using games to engage people to work. The basic premise is that if you make something fun, as in a game, then people will be more likely to participate. Even better is that the time and effort from these "gamers" is actually usefull. It got me thinking about RM and project teams. We were talking today at Jama about teams feeling like they are part of something and that a key ingredient to the success of the project is the excitement of the team. An inspired team is, in my opinion, much more likely to succeed than a stressed, bored, or disgruntled team.

So what could our tool do to provide some fun while helping with the success of the project? I'll hope for some additional feedback but for now will supply one idea I came up with:

Daily task review (not to catchy)

On a previous project we had daily standup's to discuss what we were planning on doing that day. It was hard to get people engaged because there was a fine line between gabbing on and on giving too much detail or worse just saying "same as yesterday" or "bugs". One thing we tried, and it seemed to work...for a while...was to say in a couple of sentance's what we planned to do that day. The key is "That day". We would then write it on a card, put today's date and stick it on the wall. Then the next day we would look at the card and indicate whether or not it was finished, if not we'd evaluate what's left, rephrase and put today's date.

Wouldn't it be cool if each day a developer/analyst/QA/PM logs in to Contour to play "Daily Task Review". The trick is that rather than the developer having to pull information the system would push. From there it would show yesterdays task and ask "did this get done?". You'd answer "yes" or "no", if "no" then you'd be asked to amend the task, recalculate and move to the next. A "yes" scores you 10 points. A "no" scores you one less for each day the task is extended (9,8,7...). The data from this would be usefull for helping PM's estimate future projects but the scores would be used in comparison to other members on the team, like a competition. You could even add some handicaps for things like "new to the technology" or "new to the company" to allow for ramp up.   This isn't about who's better at completing tasks but rather who's better at estimating. In addition, you'd get better and that could also be tracked using nice fancy graphs. Teams could, and should, still do daily standup's but having reviewed

tasks team members would be more succinct and informative.

This may seem obvious but bear with me for a bit on this. As

we were discussing the benefits of using a tool to capture and manage

requirements the classic benefit, of course, was the idea that the earlier a

defect (in a requirement) is caught the less expensive the overall cost. I specify

"in a requirement" because there was this tendency, in our discussion, to just

say "defects" which could mean code defects or requirement defects. I mentioned

brought this up and everyone acknowledged this to be true.

But it got me to think about defects in requirements. A code

defect is fairly straight forward. Something in the code fails some test,

simple. The area becomes grayer when the developer logs it as "works per the Requirement"

or something to that effect. Question is, how did we get here? How can it work

per the Requirement but fail per QA. There could be several reasons. One being QA's test

case is not in line with the Requirement or that the requirement the developer

was working off changed and somehow QA caught wind of the change.

This problem is even worse and is more likely to be caught

not by QA but rather by the end user. This gets into the importance of showing

the end user the product in short iterations, but that's a different

discussion. Even with quick iterations the customer finding an issue is still

considered a defect in the requirement. Something we should accept as natural

and unavoidable. Regardless, analysis has been done, development has been done

and QA has tested all based on a defect in the requirement. Maybe defect is too

harsh a word. What we are truly capturing here are miscommunications or

misunderstandings.

Let's take a step further back for a moment from this moment

in time. Could we have caught this earlier?  The second scenario with the end user finding

the issue is more complicated. The issue with QA finding a bug is much easier

to fix. This is of course where a tool can help. (You saw it coming) Basically

this occurs when there is a breakdown in timely communications. If the

requirements changed the correct parties need to be made aware, simple as that.

I'd even argue that even if there is an inkling of a thought that it might

change all parties should be notified so they can brace themselves.

The more complex scenario of user found defects can be

reduced through constant communications, reviews, and discussions. Take for

example a requirement the customer has reviewed and "signed off". That should not

be the end of the story. It should be reviewed by QA and development, who can

then add comments and suggestions (openly without fear of retribution) such

that the customer can review and agree or disagree. Even as development is

developing they should feel free to add new revelations, screen shots demonstrating

ongoing progress etc. The term "signed off" should be stricken from our

vocabulary. Rather it should be "I'm happy with what I see today".

During a typical day an individual could be monitoring or

working with multiple meetings, requirements, task at any one point in time. So

for true collaboration between all these individuals you would either need a

single person with super human power to multitask, multi respond sitting in a

single room of computers, phones and postIt's, tracking and coordination every

discussion and every event for one project. Alternatively you could use a tool

that can handle thousands of notifications, discussions and events daily all

the while keeping a history of these events.

That's our vision.