Firstly I should define what I mean by ‘worse’. Well, essentially:

• Quality of code decreases
• Ability to estimate tasks decreases
• Attention to detail decreases
• Time distracted increases
• Work done fails testing more frequently
• Contribution during discussions decreases

I suppose the first step in handling this is to sit down with the developer, a senior developer, and a director and have a good old-fashioned discussion on these points. But this is not going to do much to solve the problems, it’s just going to result in the developer either bawling their eyes out, or agreeing firmly to try and improve matters.

So, more drastic action has to be taken.

Addressing a lack of code quality

A sit-down review with a high quality coder can help. Mistakes and vicious habits can be pointed out, as well as correct principals and other methods. This should be a personal tutoring session and take place every week for a couple of hours. Yes, this kicks eight hours out of our two-week sprint, but I consider that that’s peanuts compared to the damage being done. It’s only the start, though!

Helping with task estimation

Estimating tasks is supposed to be a personal thing – the developers should visualize the process of developing the solution, of testing, of documenting and preparation. They should total the hours they’re likely to spend on these aspects and that should be their estimation. But if the developer has trouble visualizing, or breaking a task into ‘actual things to do’, their estimate will be rubbish.

To help the developer turn the task into actual things to do, it is a matter of simply extending the discussion of the task (prior to estimation) to include or share opinions from others on how they would approach it.

If the developer still doesn’t understand enough about the process to be able to give an estimate in hours, then it’s a problem. It’s a bogus developer who should be asked to re-evaluate his employment in the company. They may require extensive training, but in the case I’m talking about, where the developer has steadily declined, it may be time to put his experience elsewhere, rather on the frontline.

What to do when attention to detail decreases

Details are important, especially in software development – the world in which many finicky users stalk around with magnifying glasses. And, I personally find that when a developer makes the effort and pays attention to small things, that he is giving himself a little golden place in my heart. Obversely, when the developer ‘doesn’t give a hoot’, no matter how good they are, I get a little bit clenchy in the fist region when I see him.

Attention to detail can be increased by embarrassing the developer. Aye, it’s true. Point out his mistakes (even though they may not be technically mistakes) during stand up meetings. Laugh about them, make jokes. Be light-hearted about it, not stern. He will laugh too but watch his cheeks go red. If this continues to happen he will knuckle-down, out of the basic human need to ‘fit in’.

Another good way to make a mockery of a developer is to not single him out. Make a joke to the team that some silly person -did-whatever- and how funny and troublesome it is. If he immediately owns up to being the cause, it is something very respectable.

Removing distractions

I am always of the school of people who don’t want to restrict workers at all in the office. Introducing ‘no browsing’ or ‘no music’ policies is insane, in my opinion. The real way to remove distractions is to make the developer understand that while he’s not working, he is overloading himself in the future, and, since scrum is all about the team, he is increasing pressure on the team.

An interesting way to do this is to speak with another developer, someone who you trust and who you’re friendly with. Tell him or her that you are going to make an example out of them after the stand-up meeting, but only as an example to the other developer. Then, after the stand-up meeting, question your friend about his forum chatting or flickr browsing during working hours. Then directly ask the team how much pressure they’re feeling right now, and if they really have time to waste on non-productive activities. If they all agree that they do have spare time, that’s your fault. It might be a chance to introduce a brainstorming or knowledge-sharing session for them. That would be better than seeing them mucking about on youtube all day.

I also hate checking up on people. Procedures can’t be measured, only results can. But checking up sometimes help. It helps sometimes to just go and look at the developer’s screen. Don’t say anything, just look. They will feel uncomfortable, but since you’re not really putting any pressure on them to ‘get back to work’, they will get a splash of guilt, rather than anger. Pat them on the shoulder when you walk away, too. This is a friendly gesture which means ‘you’re part of the team, I like you’. It is a little condescending, but I feel it’s the right approach.

Reducing test failure

Again, this is where humility comes into play. It’s usually like this: the developer works on his task, tests it on his local machine, commits his changes, and then doesn’t test on the development environment, or does a very limited check to see if the thing didn’t break after his commit. Then he goes to make coffee or unwind his brain from the task he’s finished.

Then someone tests his task and boom. Test failed.

The developer often takes an hour or more to be informed of his failure, then some time to begin working on it again, then time to find and fix the problem, and so on and so on, damaging the team’s performance. Test failed tickets are like a stab wound to the team. They can be fatal.

So – how to make sure the developer fully tests his own work before and after committing? Humility, yes. Embarrass him again. Count up the number of test failed tickets during the sprint and make the developer with most wear some silly t-shirt during the next sprint planning session. Be creative, but not cruel. Make him feel like the other developers are laughing at him. There’s only one direction he can take to resolving it – and that is to ensure he doesn’t have any test-failed tickets in future.

Increasing the developer’s contribution during discussions

There’s not a lot that can be done about this one, except directly asking during discussions for the developer’s opinion. Try to get him involved in the same way you’d try to get anyone involved in a conversation. Ask questions, talk about the things they worked on, and so on.

If someone starts falling asleep during the planning session for example, depending on how horribly mean you are, a sudden clap is quite entertaining for everyone else, and will wake them up.

It also helps a developer feel like a sturdy cog in the wheel if you praise them. And, when he feels like a contributing member, he will act as one.

In the end, it’s essential to remove the ‘dead wood’ from the team’s little bridge, and replace it either by employing someone different, or solving the problems causing the wood to rot. If you don’t, the whole thing can collapse.

It is a very powerful tool, and that becomes obvious after a brief play around with it.

But the product backlog we have is growing, as more and more tasks, defects, and stories are being created (by me). It has reached the stage where it is so long it would take our team a year to develop it all. But, at the growth rate I’m seeing, it would be futile to even try.

What can be done?

Well, in Trac, there’s not much functionality to split the backlog, except by component but again, this is fiddly and not what I’m looking for. I would like a way to divide the backlog into blocks of work either by yearly quarter, or importance ranges.

The only solution I have considered so far is to create a series of reports, and keep my head mostly swimming around in the ‘current’ backlog block. But does this make sense? I suspect it is more a way of mentally handling the stories rather than actually dividing them up, which could result in other people viewing the backlog to become confused.

Well, this is a blog, and these were my thoughts. Thanks for reading.

I think we’ll be seeing more web-based applications, games, and Java developments, and less of the standalone desktop type software being created. This seems to be the trend, anyway.

What this trend (whether it exists or not) means is that the move will be towards much more agile development – but what kind?

More on this after I’ve given it some proper thought…

The first of these tasks was an ongoing piece of software custom-written for a single user. It has been completed long ago, but we had a task about possible changes needed to be made, and indeed, on the final day of sprint, the user provided the requirements. To me, this goes against Scrum principles, and as such not only makes me angry, but makes me wonder how well we’ve actually implemented scrum.

The second incomplete task was never started, it required a deployment to be made first. I had personally planned the deployment for the final day of sprint, and even informed users, but this was canceled by our director, who essentially was in a panicky mood, and I feel there was no real reason not to deploy.

That leads to the final unfinished task. Deployment. We set aside eight sprint hours for the deployment of the product onto the production environment, and today, the retrospective and demonstration day, is when we’ll have to do it.

Nevertheless, this sprint went well. A word of warning I could give as a result of my experiences is – if you have an easily startled director overseeing what you do, sit him/her down with a cup of hot chocolate and let them experience a comfy sofa while you go behind their back create mad product downtime. Or get approval beforehand.

Towards the end of almost every sprint, we were seeing that our burndown chart suddenly drops down as tasks are put through testing.

Due to this, we don’t really get an idea of where we are, in terms of development. An eight hour task could be coded but not tested, and that means eight hours still in the backlog. Spending twenty minutes testing it essentially ‘leaps’ the task from zero to completion. Not correct at all.

One solution is to report hours spent on all tasks, rather than just completed tasks. This might be even further from reality – essentially it would just show effort, which is generally not going to change from day-to-day and reporting it doesn’t show anybody anything.

This was causing me to have a minor meltdown, and thus this rather colourful chart evolved in my Excel spreadsheet:

The sprint meltdown chart.

Forgive me for the lack of labels here. Y-axis is number of hours (points) remaining in the sprint. X-axis is the nth day of the sprint.

The meltdown chart is always displayed as an ‘X’, with expected effort starting at zero and moving up to the planned hours limit, and expected burndown moving in the opposite direction.

Additionally, there is a central ‘window’ in the chart, and using this window I can spot mid-sprint what the outcome of the sprint will be if we maintain current progress.

There are four sections of the window, and briefly, if the real effort and burndown intersect in pane:

• 1. Effort needs to be reevaluated. Developers are sprinting and can probably cool off a bit, depending on whether burn is above or below average. If above, then tasks estimations are askew. In this case I would spend time to reevaluate with the team. If burn is below average, the sprint might have room for additional tasks. I would ask the developers if they would accept extra work added mid-sprint. Keep in mind that doing this might break the sprint later on.
• 2. Sprint is in serious trouble. If actual effort is below expected effort, it’s time to take the cane to the developers. In reality this can take the form of discussing the problems after a stand-up meeting, or scheduling a brief meeting. It’s likely the developers will state that they incorrectly estimated the tasks, and will complain that external factors are changing the scope. It could be time to alter the backlog, removing items if necessary.
• 3. Sprint estimated poorly, or horrible code quality. If the burn is in this window pane, then the second half of the sprint will be a walk in the park. You can decide if you want developers to stroll or pick up additional tasks. It might be worth paying closer attention to the quality of code – unless estimations were completely off, one or more developers could be writing rubbish code. I would spend time investigating the overall quality of the work done on the tasks.
• 4. Increase effort, depending on the burn, if it is above expected. If it’s below, effort can remain the same. Sprint is more or less on target.

These points depend mainly on how close the intersection is to the center of the chart. The closer to the center, the less attention you as a product owner need to pay.

In the image example, you can see our intersection landed in pane 2. From there, we turned up the effort of the developers, pumped them full of coffee, and managed to drag the sprint back on target.

I have no reservations when it comes to encouraging developers to work harder, but I see such effort boosts in terms of karma. More coffee mid sprint can more-or-less be translated into more beer at the end of it.