Silence is Golden

Was on a call with a group of directors reviewing a presentation for some set of functionality to be delivered and the discussion was heated and lively. At one point I IM'ed the technical lead and asked what she thought - she'd been pretty quiet. She sent back: with so many geniuses on the phone, I don't think I'd have anything of value to add ;-)

You know, the temptation is very high to jump in and share your mind. but sometimes it's just better to be quiet.

Watch the Scope: Who Can See What

When using or deploying a social networking application, it's very important to ask the question: who can see what. We deployed an items of interest reporting tool where each report was made up of individual activities. That was cool because the tool allowed users to search and tag individual activities. But most people come from a back ground where these IOI reports are private to the group that reads them or the person the reports are submitted to. So, they just assumed that the activities in this new tool did the same thing. Not so. Everyone could see the activities.

So when deploying a tool, ask the question: given each object the tool manages: wiki's, blogs, documents, activities, bookmarks, etc - who can see what by default. In today's social networking tools the bias is to make everything as accessible as possible. However, most users in the enterprise have been using tools that are closed by default. That's a very big change and can create some serious problems.

Don't Ignore the Auditor

Every large organization has auditors who monitor the software development process - what work products will you create, how will you capture approvals, how are changes documented, etc. In the midst of the battle, these guys will seem like a waste of time - picking at this and that when you've got WAY bigger issues to solve. The temptation is to ignore them.

The problem is that they've usually got the ear of someone higher up - and usually it's the whole reporting chain between you and that higher up. They have the ear and aren't afraid to use it, even for trivial issues. You may think it's a waste of the higher up's time and yours, but there it is. You'll just have to suck it up and do it. Don't hesitate to delegate these kinds of tasks. Their usually not hard (exactly the reason you hang on to them).

Pain in the neck? You bet. Waste of time? Probably. But you need to stay off the radar

Is It Really COTS?

In large corporations there are typically many IT development efforts going on all over the place. At some point an executive will see a solution for a department or local business and want it deployed to the wider organization. The logic runs something like this: they got it to work in their organization, I should just be able to install it for the enterprise. This sets the expectation that the solution can be deployed in a couple weeks if not by the end of the month. They think of it as Commercial Off the Shelf (COTS) - kind of like installing MS Office.

And they couldn't be more wrong.

If the solution is a small tool or simple web/db application, then it will probably go smoothly, but even here, enterprise wide deployments magnify problems. Some key questions to ask:

What are the key components that make up the system? Is there documentation that shows how these components talk to each other? When there's a problem, knowing these flows is critical.

Testing is everything - having a good test plan and test environment is important. Just because it worked there, doesn't mean it will work here.

Help support - when someone has a problem, who do they call? Do they call a company help line? If so are the tier 1 and 2 support people trained in the product?

Know what you deliver. This seems strange: management says 'take that thing over there and make it available over here' but does management and those stake holders 'over here' know what the product is? They'll say they want it, but do they know what it is? Document the functionality and get sign off from stake holders.

Testers

Having good testers on your team is critical. Here's what makes a good tester:

Writes everything down: error messages, steps, etc. I mean EVERYTHING.

Good at informal testing: able to run with the system and find issues.

Attempts to isolate the problem. They go beyond just saying the test fails.

Good at defect tracking - systematically documents defects. Doesn't announce every time there's a defect.

The test lead pulls in people to review defects. Doesn't just declare a defect and hopes that someone will deal with it.

A tester needs to be humble and not gloat over problems.

If tester finds something majorly wrong, they don't make a big deal about it - no drama, no blame. Other people are paid to do that.

Good testers are hard to find!

Team Content Gardener

I had someone suggest the other day that our team should have a content gardner - someone to organize team content, develop play books, educate on the use of blogs, setup standards, etc. Here's why I don't think this is a good idea:

This is counter web 2.0. One of the driving forces behind web 2.0 is user initiated content organization and sharing. Tagging, blogging and wikipedia applications are a perfect example of this. Tagging came about because we all got sick of that other guy who thought he knew how to organize everyone else's taxonomies.

If there are issues concerning how the team is using it's social networking tools, it's up to the team to communicate and this needs to start with the leadership of the team, but also needs a team that initiates dialog.

The team needs to know that reminders are okay. We're all super busy and can drift into old patterns of doing things. Reminders given in the right spirit build trust and help the performance of the team.

Consultants are good. If the team can bring in someone with an outside perspective on how to leverage social networking tools, that's a huge plus. It's up to the team to internalize these suggestions and practices. The consultant needs to realize this and go away when the consulting is over.

Those doing the work will have greater insight into how content should be organized.

There are exceptions to this rule. For very large programs, a content gardner may be just the thing. Pick you gardner carefully. Some people get hooked on the power they get by taking control over other people's content - you don't want that person. Also, mistakes are okay. There are not a lot of people that really know how to do content gardening - give them a chance to try new ideas out.



The bottom line is that teams need to internalize best practices. The team that realizes that it needs to take time to dialog about how their using the tools, will be the more productive team. Team leads need to make time to talk about how to organize content and make sure that their folks will be assessed on how proactive they are in this area.

Stupid Requests

I got a stupid request today - someone wanted an architectural diagram so that they could figure out something concerning disaster recovery. For this person, it was kind of like saying, "I need to find a coffee shop in NY City, can you give me a detailed map of the water system, I mean, you need water for coffee right?" I said something witty and scornful and moved on.

Here's the problem with the word stupid, it's a loose-loose word. The person it's direct towards now feels pissed off, shamed, etc And I've just feed my big fat ego. It can get even worse - the person doing the asking may be stuck in the middle and now has to satisfy someone who doesn't know what their talking about with someone who's being to knuckle head. Both accomplish nothing.

But here's the crazy thing: these are great opportunities - their easy! All I have to do is send a diagram and tell them if they need help, let me know. That's it! Sure you and I can see the problem a mile off, but who cares? We've engaged in a dialog (good thing), offered to help (good thing), and they get something to start thinking about (good thing).

So, loose the attitude and use the opportunity to foster a dialog.