Standup Meetings

Coordination on a project team is really important - seems obvious right? One tool to getting there is to have a daily stand up meeting where each person gets 2 minutes or less to share the following:

• What have they accomplished


• What are the working on today


• What road blocks are they running into

First just knowing what each other are doing today is very helpful. I had frequent situations where someone will say, "you're working that? You may want to talk with Tom - he knows about that." Team members will raise questions that others can answer or there are situations that one team member doesn't even know what question to ask, but will get input. Team members also appreciate short meetings!

The key to the meeting is to keep it short and very crisp. How long depends on the size of the team meeting. I shoot for five to ten minutes. Everyone should have a minute or less. I've found that folks are usually around 15 seconds. There's always someone who goes over, but as the team has more of these, people settle into a rhythm.

Recommendations:

• Send out a recurring meeting notice. If the team all sit near each other, schedule a conference room. Meeting should run through the life of the project.


• Meeting is best held first thing in the morning. I have people in different time zones, so I schedule as early as possible for everyone. I give people a 1/2 hr to get into the office, get their coffee, check email, etc. Don't let time be the hang up. If people can't make it until 11:30am ET, then do that.


• Meeting notice example: "The purpose of this meeting is to keep other members of the team informed as to what you're doing and if you need help. Each person gets 1 minutes or less to cover the following: (1) what have you accomplished since the last meeting, (2) What are you working on today, (3) Are there any impediments preventing you from meeting your commitments, and (4) is there any time today or the rest of the week when you won't be available."


• If people are meeting in a conference room - everyone stands up


• I go first so I can model how the meeting should run. I find myself sometimes just asking for today's tasks and not contributing myself. Not good. I'm a part of the team as much as anyone else and have my share to carry.


• I take notes - not of everything everyone says, but key issues.


• Don't be afraid to use the phrase, "let's take that off line". I find that being specific helps, "Tom, can you and Al take that off line and let me know before next stand up?"


• It's easy to forget the meeting once it happens, but my work isn't done. I review the list of notes and follow up with people.

A great resource is the book, Death By Meeting by Patrick Lencioni. Very easy to read - it's a parable. It describes this approach along with some other meeting styles.

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.