Some of the toughest problems on projects are caused by pulling together a group of individuals. Often one or more don’t work out.

On an Agile project you commit to your work every day and explain what you accomplished the day before. There’s nowhere to hide hours of surfing the web or spending a whole day writing a few lines of code. Productivity and effectiveness are evaluated every day. If you’re struggling but really trying the team will pull together and try to help out. Just putting in time by sitting in your cubicle for 8 hours a day and attending the standup isn’t enough.

At this point it becomes a management issue. Scrum puts pressure on management to act. Jump in, give the difficult feedback and get the employee on track. Management isn’t just about having an office, filling out budgets, and running team meetings. Management is defining expectations and helping people live up to them.

If line management can’t arrive at resolution it becomes an organizational issue. As Scrum or other Agile approaches expand and become the norm the organization must adapt. Letting a team flail with a weak link is unacceptable. Large scale organizational change is hard. Ken Schwaber’s estimate is only 20% of organizations will successfully complete a Scrum implementation.

I’m not sure why, but as an organization we often have wordy Sprint goals that take up half a page and include all sorts of obvious qualifiers like “will be deployed and tested to QA with no serious defects.” The backlog items are squeezed into tortured sentences and stuck up somewhere in the team room. These sort of goals are ineffective. No one can remember them. Have a goal like “Have the CEO order a new widget” are a lot easier to get behind.

A developer reminded me of a good rule of thumb from Scrum and XP from the Trenches by Henrik Kniberg:

The sprint goal should answer the fundamental question “Why are we doing this sprint? Why don’t we all just go on vacation instead?”. In fact, one way to wheedle a sprint goal out of the product owner is to literally ask that question.

Are you kidding? Perfect reason to get a training request turned down. Don’t help me out with an elaborate giveaway.

Yes, right there on line 2548 is where I think I need to add a hook in. Does that seem right to you?

— Developer asking a remote team about one of their many giant classes over WebEx.

I just really feel like I should do some cleaning up while I’m in there changing the code.

— A Developer Working on a Legacy Code Base

The rewards of management can take a long time to recognize, but I heard this gem a while back. The developer was bothered by the state of the legacy code he was working with and really wanted to do some cleanup. Usual issue–almost no tests in place, plenty of nasty EJB dependencies and hard to test. For now he’s doing simple refactorings like renaming variables, extracting methods, and just deleting old commented out code.

It can take a while to convince a developer that it’s worth the effort to do some cleanup when working with legacy code. Many times it seems overwhelming to bother with changes. It’s a mess and not worth fixing. Then they reach the point where they’re not willing to just deal with patching up the problem. Every time they touch the code they make small improvements. This is how you wrangle in a nasty legacy codebase and make it workable and maintainable for the long haul.