

Doing the Board: A simple daily planning exercise is our most important process - maxcameron
http://bigbangtechnology.com/post/doing_the_board1

======
smackay
To me this seems less like planning and more like task tracking. Everybody
alread knows / has decided what the task they had to perform on each day so it
was a simple matter of executing and recording the results. The hard part of
planning - breaking the problems into small tasks and deciding the order of
execution based on dependencies, deciding whether something is even worth
doing, etc. was only summarily covered.

~~~
maxcameron
Well, it's planning, just on a daily scale. This process does not compete with
pivotal tracker or basecamp, which is for planning and tracking our progress
on a larger scale.

If we're bottlenecked or dependent on another person or deliverable, it
doesn't make it on to the board.

But I agree, this process does not aim to decide what is worth doing.

------
amckinnell
Part of the "secret sauce" of Agile software development is that Agile teams
micro-manage themselves. I love Agile. I hate micro-management. Hey Alistair,
isn't that a logical absurdity?

Not really. Let me explain.

I love to work with Agile teams that are responsible and accountable for what
they do. The best way I know to do this is to check-in with the team everyday
and talk about we're going to get done today. Of course, this has to be done
in the context of some vision or plan that has a horizon greater than a single
day.

I hate it when someone who doesn't really understand the tasks tells me what
I'm going to do today and wonders why I didn't do something yesterday. I hate
that kind of micro-management.

So, everyday I take responsibility for my tasks and hold myself accountable to
my team. I don't let someone else be responsible and then hold me accountable.

------
dotBen
It's an interesting workflow, but I think the granularity they are suggesting
feels a little too micro-management like.

If you need to track whether your (presumably non-tech) employees have written
3 emails, your team have a motivation/time-management problem.

~~~
maxcameron
Hey there, yeah that's why I wrote that we try very hard to avoid micro-
management in this activity, and I specifically included emails in the "bad
tasks" example. It's definitely not a top-down initiative, or anything to do
with tracking our employees.

~~~
mikeryan
Max - I think you'd avoid this a bit if you changed your initial anecdote
(your interaction with Jason) to be more engineering and product focused, I
think thats where the micro-management concerns are stemming from.

~~~
maxcameron
Totally. Is it ok to go in and edit my blog post? Are there any rules to
follow when changing something you've released? Or can I just treat it like a
bug in the software we deployed?

Any chance you'd try this system out for a few days? I'd love your feedback.

------
GBKS
Isn't this basically how Scrum works in agile development?

We're doing this at work and include our direct client contacts as well (daily
15 minute conference call). It helps immensely in avoiding communication
issues arising from different time zones, locations and people never having
worked with each other.

~~~
mikeryan
Agile covers product tasks and is generally tasked at the iteration level
(week/2 weeks/ month whatever your iteration length). Though there is the
standard "what are you working on today?" "What will you work on tomorrow?"
and "What's blocking you" that comes up in Scrums.

That being said this stuff seems to cover all the daily tasks (meetings,
emails, etc) that is not covered in Agile. This is my main issue with this
process. If you're already an agile shop then now every thing you do is being
tracked. I'm not sure all teams would respond well to this. Personally I
wouldn't like it much - I, personally, would feel micromanaged at this point.

~~~
maxcameron
This approach certainly does borrow from the scrum daily standup meeting.
Again, our goal is not to track anything that takes less than an hour to do.

And I would like to stress that this isn't a "management technique," that we
force our employees to do. This process is for teams and people who see value
in looking ahead at their day and providing themselves some context before
diving straight in.

If I'm taking a car ride, even a short one across town, I still like to pick
my route.

~~~
mikeryan
_Again, our goal is not to track anything that takes less than an hour to do._

This point is not clear in your anecdote which has "I have some emails to do
and a form to send to the accountant" turning into line items on a board.

Also to be clear - I'm not anti-planning. I also would never tell you to
change a process that is working for you. But these are some reasons why I
wouldn't implement this planning technique for a team that I run. I'd prefer
to keep my planning product focused and I'm okay with resetting on tasks with
my team on a bi-weekly basis and a quick standup daily.

This is a GTD style technique that I think works great for certain individuals
and not so great for others (I've always sucked at handling to-do lists),
which is why I'm not sold on it as a team technique. I think _you_ respond
well to it, but _I_ would not. So if it works for you by all means - keep it
going.

~~~
maxcameron
Mike,

You're totally right. I should have been more explicit in my example. Once in
a while, if I have enough admin work to do, I might write a task that says,
"administrative tasks," so when I do hit inbox zero and complete all of those
little tasks (that do add up to more than an hour), I can keep track of
accomplishing it.

I don't think there's any conflict between our two approaches at all. I
believe our system is:

\- Product based: all tasks that go on the board directly relate to our
product \- We're ok with resetting on tasks as well. It's just that if it
takes more than two days, we obviously got the task wrong, and it is either
too big or there's a bottleneck. There's no punishment for not completing a
task.

I used to dislike the idea of to-do lists because I wasn't good at following
up with them. This idea adds a social element, which has helped me a lot in
getting better at organizing my day.

Would you be open to trying this with your team for one day? It's a very low-
overhead technique, and you never know - you might just end up enjoying it.
And even if you don't get much out of it, maybe someone on your team will.

Can you see some value in that?

~~~
mikeryan
So unfortunately I left my engineering team on their own about a year ago to
start my own tech services company. My team these days are mostly virtual so
the system would break down a bit.

I'd be willing to experiment though I've always been pretty open to trying new
techniques.

~~~
maxcameron
Our goal is to help teams exactly like yours participate in this technique.
We'll be keeping you posted, we should stay in touch. What's your twitter?

------
Gio50000
A web app like <http://teuxdeux.com> with a color coded feature and team
accounts would compliment this approach.

~~~
maxcameron
Teuxdeux is definitely inspirational, and does a great job at what it sets out
to accomplish. I still see it as a personal task management app (like things,
omnifocus, rememberthemilk, even basecamp's to-dos, etc).

These apps are great for tracking big, permanent projects in your life, but
they're not suited for planning what you'd like to do in a day and then
accomplishing it.

I just see this approach as falling into a different category altogether,
something that I haven't found the right words for yet.

------
maxcameron
I'll post some pictures tomorrow for sure.

------
ruang
An actual picture of this would be nice.

~~~
maxcameron
It's up now.

------
davidedicillo
I wonder how good this would be as web application... maybe I should give it a
try.

~~~
dotBen
I have used Pivotal Tracker in the past for this, blending non-technical tasks
in with tech tasks so that all team members have tasks assigned and velocity
can be tracked.

Not sure whether a whole new piece of software is necessarily needed.

~~~
maxcameron
We hesitate to put non-technical tasks into pivotal and assign them point
values. We've found that changes our development velocity, which is not
desirable.

The other big issue is that our process is about setting out two or three
things we want to do in a day, and seeing if we can meet our goals.

It would not make sense to click the "start" button on three
features/chores/bugs at the beginning of the day, because again it would skew
the pivotal data.

~~~
dotBen
Arhh yes. For the sake of brevity I didn't get into more detail on how I've
done this in the past.

I've experimented with both using a separate project for non-engineering (to
avoid the skew) but also simply including non-dev work into the velocity with
the same rigor that items that offer true value get points and 'cost of doing
business' (pay server bill, write documentation) are non-point-accruing
chores.

Both work for me.

~~~
maxcameron
I see where you're coming from. If you're tracking tasks at all, you're doing
something right. However, if you use pivotal for task management, you can't
estimate how much you'll get done in a day. It's not like a developer can
press the start button on three features, even if they want to complete three
features in a day.

Our technique is about setting out a good amount of work for the day, and
trying to meet those goals. We pull few chores/bugs/features from pivotal and
throw them on the board all the time.

------
maxcameron
A photo has been posted on the article to show you our tasks for today.

