In Manage It! Your Guide to Modern, Pragmatic Project Management, I explained a schedule game called "We'll go faster now." That's the game where the project team thinks they can improve their speed, even though there is no data that says they can.

There's a similar management game, called "Double Your Velocity." Say a team is new to agile. They estimate they can complete 72 points in a two-week iteration. In the first iteration, they complete 30. Ok, they figure out what's wrong during the retrospective, and they complete 55 points in the second iteration. They learn more about their estimation, so they estimate the stories better, and they refine what done means, so they plan for 63 points in the third iteration. They make it! They keep proceeding, and eventually, they settle in at around 67-68 points per iteration.

Now, a senior manager wants to "help" the team. I see this often masquerading as "motivation." A senior manager comes to the team, gives them a pep talk, and says, "I want to see you double your points for the next iteration." Depending on the team, they may ignore the manager, flip the manager the bird, or placate the manager by doubling their points for each estimate.

This is a management velocity game. It's a game, because management can't motivate people to do more work. Teams can see what's slowing them down, remove those obstacles and maybe they can finish more work. But this business of "motivation"? What a bunch of nonsense. (Tell us how you really feel, Johanna :-))

The real problem is when the manager thinks that the placating team has increased velocity based on his or her actions or pep talk. That's when the team might think they can go faster now, or they keep playing with their estimation points.

Velocity is personal to a team. Period. Mucking with the points does not make the work get done faster.

I meet managers all the time who they they are responsible for other people's work. "It's my job to make sure the work gets done."

Oh, boy. Those managers are wrong. Managers are responsible for:

• Creating an environment in which people can do their best work. This includes deciding which work to do now and which work to postpone or never do.
  
• Providing a system in which people can get and give feedback.
• Building capacity in the organization.

That's it. That's why I say managers manage the system.

Knowledge workers manage themselves. They learn how to break their work down into smaller tasks, so they can make progress. If people don't know how to do that, the manager or colleagues provide feedback, and someone might teach or provide coaching. But it's not the manager's job to manage the people. It's the manager's job to manage the system.

If you're a manager, think hard about the system in which your technical staff work. Are you creating an environment in which people can deliver good work? Can people give and receive feedback? Are you thinking strategically so you can build capacity in the organization?

If you're not a manager, and your manager doesn't know how to do these things, consider coaching the manager. It's likely your manager doesn't realize what his or her job is. Provide a little feedback and a little coaching.

When you think about management, remember that managers manage the system, not the people. The people manage themselves and their work. Just wanted to make that clear.

At last week's Agile conference, I spoke with a number of managers who weren't sure what their jobs were, now that their teams had moved to agile. They knew they weren't supposed to reassign people in the middle of a sprint, or even break up a team that's working together well, but they weren't sure what they were supposed to do.

Giving effective feedback, and coaching other people in how to give effective feedback is a great thing to do. Chances are quite good that few people in your organization know how to do so. In Behind Closed Doors: Secrets of Great Management, Esther and I suggest this model of feedback:

• Create an opening to deliver feedback.
• Describe the behavior or result in a way the person can hear.
• State the impact using "I" language.
• Make a request for changed behavior.

You need to create an opening so you know that the other person has time and is in the right frame of mind to hear you. A one-on-one is a great opportunity to give and receive feedback.

When you describe the behavior, avoid using labels. "You always break the build" just begs for one exception. "I noticed that you broke the build  Monday, and twice on Tuesday." People can argue with data, but it's much harder to argue with data you can measure.

When you state the impact using "I" language, you can explain the result personally. "When the build is broken, I hear about it from everyone. I suspect you do too. It's an obstacle I can't remove without you. I feel helpless, which is not a feeling I like."

When you make a request for changed behavior, you can ask to problem solve. "What would it take for you to avoid breaking the build?" Sometimes, the person you are giving feedback to doesn't realize they have an impediment that you need to resolve. One developer said, "I don't have virtual machine with the environment and I have no other machines." He went on to explain what he did have and what he needed. I hadn't realized that his build problem was really my problem to solve. Oops.

Giving effective feedback, not beating around the bush, being clear and firm, not labeling people, is the mark of a congruent team member and team manager. Learn how and you'll have a much happier team.

I was speaking and teaching last week at the PMI Regina's PDC (Professional Development Conference). I taught an estimation workshop and we had some illuminating discussions about what to do when people on your project can't estimate. We all agreed people tend to be either optimistic estimators, where they think the work will take less time, or they will be pessimistic, where they think the work will take longer. Rarely does someone change. Our discussion about what to do when someone consistently miss-estimates was the part where I saw servant leadership.

One project manager said, "I don't want to crush someone's hopes or ignore their hard work, but how do I explain that each and every assignment he's been late on and I just don't believe his estimate?" Good question.

People need feedback on their estimation, and a project manager might be able to help the person see where this estimation suffers from the same problem as the previous estimations.

That's where the servant leadership comes in. A PM who's not a servant leader will think, "Hmm, your last 5 estimates have been off by 50%. I'll add 50 %," and be done with it. But a PM who is a servant leader gives feedback and asks for a re-evaluation, "Joe, you might not know this, but your most recent 5 estimates have been under-estimated by 50%. I don't want to blindly pad your estimate. I'd like to help you learn to estimate better. Is that ok?"

If that's ok with Joe, now you have a way to help the other person learn to estimate better. I like breaking tasks into inch-pebbles (one- to two-day tasks that are either done or not done), starting with user stories, or using Delphi estimation as a way to help people learn to estimate smaller tasks and see when that work is actually complete. One guy I worked with said, "I always thought it just took a few minutes to set up a new branch. But when I tracked what I did, I realised it took me closer to an hour, by the time I was actually done and ready to start writing code and tests. Who knew?" Until he created inch-pebbles he had no idea how complex his work actually was.

Great project managers serve the project and the people on the project. They don't take estimates at face value, without understanding how the estimate came to be. But they don't autocratically change the estimate without providing feedback.

If you're a leader in the organisation, whether you're a team lead, a project manager, or a manager, think about how you can serve the project, the organisation, and the people. You'll get better results if you remember the people.

As public awareness and government agenda put pressure on companies to adopt more environmentally sound policies, opportunities for those who fancy “saving the world” are on the rise. Green technologies such as videoconferencing, virtualisation and power management are all hot topics at the moment and as adoption rates increase, demand for IT staff to maintain, run and manage these systems has risen accordingly.

Green IT has come to prominence over recent years as businesses look to cut energy costs and the need for business travel. Many organisations have already begun to implement green initiatives; with a number of larger companies even having dedicated CSR (Corporate Social Responsibility) teams to oversee the companies green goals. For the business the benefits are clear, allowing them to reduce overheads, cut carbon emissions and communicate their green status to their customers and stakeholders.

For IT professionals, the benefits are also there for the taking. As companies invest in a greener future, they need staff with the right skills and attributes to handle and oversee the smooth running of new technologies and new systems.What is also encouraging, is that the green IT market is constantly expanding, meaning a steady stream of jobs should be available in the years to come. If you are thinking of taking a fresh direction in your career, getting up-to-speed on green IT could set you on the right path to better, greener things.

You may have heard "there's no room for project managers--or any other kind of manager for that matter--in agile." Well, there is. Sort of. The role for managers and project managers is much closer to a form of servant leadership. It's certainly not command-and-control project management. Here are some ideas that may help you move closer to an agile approach for project management.

Ask the project team to explain what their deliverables are to get to the next milestone. Forget this business of assigning people tasks. The people on your team are grownups. You can treat them like grownups. You don't have to--and you shouldn't--assign them work every day. Not only should you not assign them tasks, you should ask them--as a team--to tell you what they have to do to get to the next milestone. Let them fight it out, ahem, discuss it. The more discussion, the more confidence you have in the schedule.

Use iterative or rolling wave scheduling, so you don't try to create an entire schedule before you know what's going on, or worse, once you realize the original schedule was someone's pipe dream. Once they've reached one milestone, it's time to estimate and plan to get to the next one.

Make people on the team estimate their own work, or, even better, estimate their work as a group. A group's estimates are bound to be better than an individual's, and much better than a manager's estimate. Group estimation is a form of Wideband Delphi, an estimation approach that's been around forever, and works like a champ. When people create their own estimates, they tend to track them, because their estimate is part of their deliverables.

Consider using timeboxes to help focus people on the work they have to finish now, not the work for later. Timeboxes are a time-honored approach to finishing pieces of work. Use them.

The more you move from command-and-control to guiding/steering the team, the more they will produce. And, the more you practice ideas like these, the more flexible you are as a project manager, which makes your value go way up. And, it's easier to find a job.

I refer, of course, to the metaphorical carrot held aloft by a stick - the carrot being an incentive for whatever beast of burden happens to be saddled by someone wielding said stick. More specifically, what are the best incentives for those working within IT?

Salary and benefits

Perhaps the most obvious incentive for employees is the most measurable - salary, bonuses and other benefits. It is quite true that paying under market rates is a good way to de-motivate staff and increase staff turnover as a result - but there is a point at which salary benefits do little.

Indeed, once the baseline market rate for a position is reached, there will be little productivity benefit received beyond this - it is at this point that working conditions become more important than monetary concerns.

Some benefits can help improve the environment, though - the option to have flexible working hours, for instance, can help boost morale - as can the option to telecommute. Perhaps the most important aspects of keeping a team productive is the way that team is managed - from the goals set, through communication and general understanding of processes and procedures.

Realistic goals and deadlines

Managers, take note: asking the impossible is not only futile, it's also a great drain on the morale of your team. Tackling the insurmountable may be some people's idea of a challenge, but to be asked to continually push harder and harder to meet targets - and then ultimately fail anyway - is a sure-fire way to diminish morale.

A little deadline pressure can work to spur on a developer - but if it's continuous the effect will quickly fade. It's best to keep a mix of attainable, moderate goals with the occasional push for a deadline - too little or too much workload will otherwise have a detrimental effect.

Open communication channels

Good communication is also the key to keeping your team in check - without regular updates and the occasional meeting, it's easy to lose synchronisation - this is especially true in environments where telecommuting is commonplace.

Ensuring that the whole team is aware of the current state of affairs and primary goals will eliminate any potentially morale-breaking instances in which effort expended by a member of the team could be wasted, misguided or otherwise for naught.

Having each team member understand what the principal goals are for any given collaboration or project will also help in terms of improving overall productivity, as any potential issues can be distributed and solved collectively before it becomes a critical point of action.

Stress-busting working practices

As I mentioned in my last post, there are an array of tools and methodologies that can help a development team. You can eliminate a lot of stress from a development-deployment cycle by undertaking more rigorous practices which might otherwise not be used.

A reliable deployment cycle will rely heavily on testing - particularly in scenarios where there is a lot of stake (such as a major reversioning of a critical application or launch of a primary web application). Allowing time before launch to test the capabilities of a new system (and to eke out the bugs) will shield the development team from the necessity to fix such bugs discovered after the launch.

Taking the time to document the development and testing procedures can also help in hedging against future catastrophe - while developers may not relish having to document their work, most will be aware of the headaches it may save should it ever be needed.

Technical understanding from management roles

One key irk many technically-minded people face is that of the technically inept manager - parodied in Dilbert on a regular basis, but sadly with a strong grounding in regular situation.

Managers of a technical team do tend to have a degree of technical ability themselves - indeed, those promoted to the position from a development role will likely have a very good understanding. There are exceptions, however, and the inept management style is seldom good for the team as a whole.

Without some semblance of understanding of the challenges developers face, the managerial aspect of such a team becomes more difficult - and estimates on deadlines, system requirements et cetera can become more lax. This, of course - can exacerbate the issues I've covered above.

Understanding your technical employees is critical in terms of getting them to work effectively - if you understand the work, the process and procedures that should be followed, you can better manage expectations outside the team and preserve an environment conducive to the best possible output.