This is a guest post from Bill Krebs, owner of Agile Dimensions LLC

The agile methodology of "scrum" is known for its 15-minute daily meetings. Its format contains three questions. Participants state what they did yesterday, what they will to today and what road blocker stands in their way.

The meetings can be deceptively powerful--if used correctly. But oftentimes they drag on for half an hour or more.

So what goes wrong? And how can you get back the benefits? Here are some ideas.

Focus

There are two kinds of work covered in a scrum meeting: Specific tasks from your project plans (or iteration backlog), and general interrupts and overhead (such as e-mail and meetings). Do team members ramble on about work that has nothing to do with their iteration backlog? Do they say a lot just to impress other teammates? 



Focus the talk on things that relate only to the tasks identified for that particular two-week block of work (an iteration). And then encourage people to focus on and finish two tasks per day. This will discourage the inefficiencies of multitasking. Team members are not limited to calling out roadblocks. They should mention any that appear. 



Have you ever heard someone who is "80 percent done" with a task every day? Each new day shows only partial progress, but never completion. Focusing on what was actually finished yesterday, and what will be finished today, helps cure this problem.

The scrum meeting is not about status. It's about completion.

Control the Number of Participants
Let the core testers and developers on the team do the talking. Other people may have an interest in the meeting, but they should just listen.

If your meeting gets bigger than nine people, hold two separate meetings and then have a "scrum of scrums" every few days where representatives from each group get together.

Go Offline
Our inner geek often wants to deep dive into architecture on the fly. (Who can resist?)

In those moments, however, the scrum master (who facilitates the meeting) should say, "That's a great topic, let's set up a time for the two of you to discuss after the meeting."

Don't leave everyone hanging while two people talk. And if you go a week without hearing your scrum master say, "take it offline," there may be room for improvement.

Remember My Three A's:
Awareness: The meeting is about knowing what your teammates are up to.



Ad: The meeting is an advertisement for collaboration. Micro teams of two to three people form, which makes for great collaboration later in the day.

Attack: Attack the blockers. The team can rally to address a problem--either within one minute in the scrum meeting, or more often, after the meeting. Problems that require detailed work by a subset of the team can be arranged for after the meeting. That way, people who are not involved don't have to sit through the discussion.



Those tips will cut the fluff--and speed up your work!

In the book Peopleware by Tom DeMarco and Timothy Lister, there's a humorous story about a project manager who--seeing the progress her team was making--knew she would deliver her project on time. With confidence, this project manager told management that she could guarantee the project would come in, as scheduled, by 1 March.

Management chewed over this unexpected good news and summoned her the next day. They told her that since she was on target for 1 March, they were moving up the deadline to 15 January.
 
I had a similar experience when I presented an initial update for a recent software project. I confidently explained to our stakeholders that the software enhancements for the common process tool would be delivered on time.

Sheepishly believing the stakeholders would be impressed, I waited for a compliment. 

Instead, the stakeholders proceeded to hand down a "schedule challenge" for the team to deliver three weeks early. Their rationale was that they wanted to capitalize on the team's productivity and wow the senior leadership team.
 
So, care to share your productivity war stories? 

Almost everyone knows the saying, "You are what you eat." But Michael E. Case, president and CEO of The Westervelt Co., a land resource organization, put a new twist on it by saying, "You are what you acknowledge."

In order to see something great in another, you have to have some experience with that quality or talent yourself. To admire and praise a team member's dedication and value as a human being to your team, you have to know on some level what it is to feel valued and to make a contribution to a team.

When project team members show they respect and appreciate fellow team members' commitment, integrity, openness, positive attitude, expertise, knowledge sharing and listening, that's what becomes the team's--and even the organization's--core values.

When these core values are brought to light, team members listen, they don't tolerate serving their customers poorly and they have a high sense of integrity. They become what they acknowledge.

Leaders must set the example in order to have others emulate it and make it positively "rampant" in an organization. And by the definition of former Chairman and Chief Executive Officer of JP Morgan Chase, William Harrison, Jr., everyone can do this. He dramatically stated, "Be a leader. We want everybody to be a leader...to be a leader you have to have a view, be willing to constructively express it, and use it to make something better. Under that definition, everybody can be a leader."

Everyone, then, not only can be, but IS a leader. Everyone, then, can demonstrate that ability to make something better. Team leaders who focus on and make it their honor and their duty to exemplify the power of acknowledgment achieve great results. Those of us who are acknowledged find it much easier to acknowledge others.

Acknowledgments truly transform both the giver and the receiver on a project team. They engender employee loyalty and engagement, improve relationships and enhance self-worth. These positive results are contagious, and the actions of each team member are amplified as the recipient picks up on this idea and spreads the circle wider. Like pebbles in a pond, the ripples radiate farther and farther out.

You are indeed what you acknowledge! Why wait to start practicing this--as a leader, do it now and reap the rewards! 

Developing reports is an art form--and it's one that every project management office manager needs to master.

Well-designed reports contain large amounts of useful information in a time series, making them a valuable data repository. And if the report covers the right questions, the process of gathering the information can generate valuable insights for the project team to act upon.

That information also allows stakeholders to extract trends and status.

And if you deliver them in person or attach a note to highlight specific issues or messages, reports can form the basis of a targeted, purposeful communication.

Some people simply like getting reports--and dropping those people off your distribution list make them more upset than you realize. This also applies to cutting content. As a rule of thumb, by the third month it's probably too late to remove sections or drop recipients without encountering some issues.

Another benefit of reports is only starting to be recognized. Jon Whitty of the University of Southern Queensland here in Australia has been measuring the emotional effect of project artifacts. Based on Jon's work it seems a well-formatted report will in itself increase positive emotions.

The project manager feels comfortable because she or he has a "proper report'' that is part of the "clothing'' every project manager wears along with their Gantt charts and other expected artifacts. And senior managers experience positive emotions because the existence of a well-presented report suggests control, order and capability.

The challenge is to design reports that are relatively easy to produce, ask the right questions, are well-structured and well-formatted, and contain needed data.

What are your experiences with reports?

Last time in my post, PMBOK^® Guide for the Trenches, I discussed scope. Now, I'd like to cover some basic truths about schedules that project managers need to know, but won't find in A Guide to the Project Management Body of Knowledge (PMBOK^® Guide).

One vital truth that the PMBOK^© Guide is clear on is that scheduling is only one aspect of effective project management, along with scope, cost, risk, communication, procurement, human resources, quality and integration.

But you won't hear that from professional schedulers--no, no, no.

It's often believed that the central tenet of project management is the ability to resource-load a schedule baseline into one of the more robust software packages that perform critical path analysis.

This is part elitism and part what I refer to as "black box syndrome." Project team members are led to believe that if a certain software package is fed all the data it needs, then the push of a button will deliver all the management information needed to successfully complete a project.

This, of course, is hokum, but I've seen it in many a project management office.

On the other side of the coin, it's a fundamental truth that you cannot manage a schedule with a list of milestones or action items, no matter how elaborate that list may be.

What tends to happen with action item lists or databases is that they essentially turn into, , polls and polls are not legitimate management-information systems. With a poll, there's always someone who has more recent information or more complete information than what's in "the system," rendering the data there unactionable.

Note that I said the data in the system. There's a profound difference between data and information.

Legitimate management-information systems process data into information using some kind of methodology. For schedules, this method is critical path. And it's a safe conclusion that there is no legitimate schedule management without critical path.

For serious project work, a critical path network is absolutely essential. This no doubt contributes to the phenomenon of schedulers thinking critical path management is all that is essential in project management, with the other stuff kind of ancillary.

I'm looking forward to everyone's comments.

In my previous post, I talked about work commitments. Sometimes success in project delivery requires breaking those commitments if they are not in line with your goals. If you need to break a commitment, I recommend the following steps:

1.    Identify a commitment you have made that is not benefiting the project.

2.    Consult with the project manager and/or supervisor whether this activity can be removed from your list.

3.    Identify someone suitable to deal with this task. Seek advice from your manager when in doubt.

4.    Once you've secured management authorization, transfer the details of your commitment to that person.

5.    Advise the person to whom you originally made the commitment that the task has been reassigned to another person, and explain the reason for this action.

Depending on your role and authority, you may be able to deal directly with the person to whom you made the commitment, and you can resolve the conflict without involving other parties.

There's no magic formula for undoing what's done. But by breaking such commitments in this professional manner, you are renegotiating the terms of your commitments and earning trust and credibility. 

I recently watched a Hindi movie called 3 Idiots. The moral was to follow your passion--which got me thinking...

In the software industry I've seen examples of technical leads who were promoted to project manager based on the assumption that they'll perform just as well in that role.

But in several of these cases the technical lead has failed in the new position. That's because project management is not about resolving technical issues. It has other parts: resource management, cost management, expectation management, etc.

Companies shouldn't automatically follow the standard growth path for each role, whether it's for a software engineer, senior software engineer, technical lead or project manager. Rather, the path should be decided based upon an individual's capability and interests. A technical lead may be interested in business analyst work or quality-assurance activities instead of the project management role.

Also, as individuals we should have the opportunity to follow our passion and not feel tied to a typical career path.

What do you suggest?