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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Why would it matter if it wasn't private? It's not like you're putting mission critical info on the board - there's not enough space to write out anything detailed.
