[valarauca1]

I'm a big fan of old fashion modules are flow charting.

Start by flow charting your program, divide the task into a group of single statements tasks that can be described without the words, "and", "or", "but", etc. If you need to use those words, you need to chain tasks or make decisions.

After several revisions (3-4) you should have a nice overview of what the program should do, and how it will do this.

Selected tightly interacting objects, and combine them into modules. This will be very apparently visually if you followed the first step correctly.

Now you have your scrum/agile modules which can be outlined and given to subordinates, and tracked.

:.:.:

If the whole thing is a just a big ball of spaghetti, make a another revision. If its very very small you might be glossing over the technical details.

[digikata]

Do people mostly use sticky notes / white boards for this? In theory UML tools should be great at this, but in practice I've found that they mostly get in the way. Even if the tool itself works well - then disseminating the info locked in the tool becomes awkward.

More recently, I've fallen back to frequent meetings and a wiki as the best way to work through this kind of activity - but it feels like there should be a better way.

[michaelochurch]

Now you have your scrum/agile modules which can be outlined and given to subordinates, and tracked.

"Agile" micromanagement is great if you're looking to bleed talent. Highly recommended if you're looking to reduce costs and don't care who leaves.

[nitrogen]

Indeed, a collaborative team is much better than top-down micromanagement. It's a pleasure to work with "agile" teams where everyone can define their own tasks.