Discussion Forum > Spinning Plates
Ryan:
What I advise with all my systems is that you should be aiming to have all your projects in the state where there is no more work you can do on them. Only then can you really claim to be up-to-date.
To take a simple example, if you have a goal to run one mile every day then you have achieved the goal when you have run one mile. There is no more work left that day which you can do. Running a second mile would not be part of the goal.
Similarly if you are writing a book and have a goal of writing 1,000 words a day, then you have done all you can that day when you've written 1,000 words. To write more than 1,000 words is not part of the goal.
With email, voicemail, etc, you have done all you can when there are no unactioned items left in your inbox.
With more complicated projects the question is whether you have done all you can according to the stage that the project has reached.
What I advise with all my systems is that you should be aiming to have all your projects in the state where there is no more work you can do on them. Only then can you really claim to be up-to-date.
To take a simple example, if you have a goal to run one mile every day then you have achieved the goal when you have run one mile. There is no more work left that day which you can do. Running a second mile would not be part of the goal.
Similarly if you are writing a book and have a goal of writing 1,000 words a day, then you have done all you can that day when you've written 1,000 words. To write more than 1,000 words is not part of the goal.
With email, voicemail, etc, you have done all you can when there are no unactioned items left in your inbox.
With more complicated projects the question is whether you have done all you can according to the stage that the project has reached.
December 14, 2014 at 11:41 |
Mark Forster
Mark Forster
And if the answer to that last question is always No?
December 14, 2014 at 13:25 |
Alan Baljeu
Alan Baljeu
Thanks Mark, that helps a lot. The simple examples are especially clarifying.
The desired end state (write an article) turns into a process goal (e.g. write 1000 words on it per day) until the first draft is finished, then I would add additional tasks to get that end state (copy-edit, have it reviewed, add illustrations, etc.) This ties in nicely to your principle of "Keeping Your Markers Aligned".
At work, the projects have a lot more moving parts and a lot less defined urgency. So Project X for example includes stuff like:
- Setup equipment for delivery of software from Vendor
- Contact S and G about procedure for setting up office for the demonstration and follow up until they're done with it
- Analyze data on Vendor's product and get it to M
Project Y includes stuff like:
- Sketch up designs for Customer
- Add additional details to document
- Think about solution to problem caused by current design
- Create diagrams showing what needs to be changed
In addition, I also get various additional requests from both these customers for one-off tasks or additional large projects! I realize now when I was using FV I ended up just basically approaching these commitments haphazardly. Really, I need to clarify these project goals, what I'm committing to and what the degree of urgency are for the individual tasks.
@Alan: This is where having clear constraints and limits on your work come into play. Let's say your project is something like: "Develop the world's greatest operating system", if this was your only life goal, everything else would start falling to pieces. So really, you need to rephrase your commitment to something like "Develop the world's greatest operating system, while working only 8 hours a day 5 days a week." Once you've worked on it 8 hours, then it's 'done' for the day and you can fulfill your other duties.
Thinking about it.... I think something similar to how Mark used AF/FV for projects could also potentially work. Have a plate for the task "review progress on Ultimate OS project" and think up the next tasks to do, do those until they're completed and rinse/repeat. The "review progress" task would be considered "up to date" when you have created the next task to do for that project, or if a current task is outstanding on it.
I'll try this technique at work too to see if it helps.
The desired end state (write an article) turns into a process goal (e.g. write 1000 words on it per day) until the first draft is finished, then I would add additional tasks to get that end state (copy-edit, have it reviewed, add illustrations, etc.) This ties in nicely to your principle of "Keeping Your Markers Aligned".
At work, the projects have a lot more moving parts and a lot less defined urgency. So Project X for example includes stuff like:
- Setup equipment for delivery of software from Vendor
- Contact S and G about procedure for setting up office for the demonstration and follow up until they're done with it
- Analyze data on Vendor's product and get it to M
Project Y includes stuff like:
- Sketch up designs for Customer
- Add additional details to document
- Think about solution to problem caused by current design
- Create diagrams showing what needs to be changed
In addition, I also get various additional requests from both these customers for one-off tasks or additional large projects! I realize now when I was using FV I ended up just basically approaching these commitments haphazardly. Really, I need to clarify these project goals, what I'm committing to and what the degree of urgency are for the individual tasks.
@Alan: This is where having clear constraints and limits on your work come into play. Let's say your project is something like: "Develop the world's greatest operating system", if this was your only life goal, everything else would start falling to pieces. So really, you need to rephrase your commitment to something like "Develop the world's greatest operating system, while working only 8 hours a day 5 days a week." Once you've worked on it 8 hours, then it's 'done' for the day and you can fulfill your other duties.
Thinking about it.... I think something similar to how Mark used AF/FV for projects could also potentially work. Have a plate for the task "review progress on Ultimate OS project" and think up the next tasks to do, do those until they're completed and rinse/repeat. The "review progress" task would be considered "up to date" when you have created the next task to do for that project, or if a current task is outstanding on it.
I'll try this technique at work too to see if it helps.
December 14, 2014 at 19:06 |
Ryan Freckleton
Ryan Freckleton
Alan Baljeu:
<< And if the answer to that last question is always No? >>
Then you're not up-to-date. But I am having difficulty envisaging what sort of project would always have an unlimited amount of work to be done.
Ryan's example of the world's greatest operating system would actually consist of a lot of separate tasks. You would need to establish what would be needed. You would need to assemble a team to program it. You would need to test it out, publicize it, etc. etc. Each of these tasks would involve many other people. You would need to give them deadlines, copy dates, interviews, etc. etc. all of which would provide stages which would limit the amount of work you could actually do at any one time.
<< And if the answer to that last question is always No? >>
Then you're not up-to-date. But I am having difficulty envisaging what sort of project would always have an unlimited amount of work to be done.
Ryan's example of the world's greatest operating system would actually consist of a lot of separate tasks. You would need to establish what would be needed. You would need to assemble a team to program it. You would need to test it out, publicize it, etc. etc. Each of these tasks would involve many other people. You would need to give them deadlines, copy dates, interviews, etc. etc. all of which would provide stages which would limit the amount of work you could actually do at any one time.
December 14, 2014 at 21:35 |
Mark Forster
Mark Forster
The very large complex software creation project I'm involved in will never run out of things I can pour my effort into. In my case there is no delegating out - I'm the recipient of delegation, and I have enough to go by that I can keep working on it indefinitely. Yes I go for feedback and such but this doesn't hinder continuing to work on things.
December 15, 2014 at 3:47 |
Alan Baljeu
Alan Baljeu
Mark wrote:
<< But I am having difficulty envisaging what sort of project would always have an unlimited amount of work to be done. >>
I generally have the opposite problem.
I think my work is similar to Alan's. There is always more work that could be done, than can ever actually be done.
But that's OK. In fact, I think it's normal for many people.
In Agile Scrum, it's common to identify the whole backlog of work as a series of prioritized "user stories" which describe the stuff that users want a system to do. The highest priority items need to be pretty clearly defined, because they will be worked on very soon. The lower the priority, the more acceptable it is for the item to be more vaguely defined.
Users are constantly giving feedback (assuming anyone is actually using your product!). That feedback generates new "user stories", and it also informs the prioritization of the whole stack.
Everything on the stack has a cost: it will take time and work to figure out what the users want, and how much work (time and effort) it will take the developers to build it, test it, and integrate it into the product.
Everything on the stack also has a value: what real value do the users get from it.
Eventually there comes a time when the value of the items remaining in the stack is less than the cost of those items. Or maybe, the value is higher than the cost, but there is another project you could have your team work on, where the value/cost ratio is much higher. In either case, it's time to stop (or at least ramp down) the current project. This typically means there's a lot of stuff in the queue that just gets dropped.
And that's totally normal. People are making these kinds of cost/benefit decisions all the time, in all areas of life.
This has informed my own workload management quite a lot over the last year. I have never been able to see the possibility of "getting everything done", and working with this Agile Scrum method has made it very clear to me that this is quite normal and acceptable! My own work is very similar: I have lots of commitments and opportunities, which all involve creating some kind of value, at some kind of cost. The best I can do, at any given moment, is to assess which items RIGHT NOW will bring the highest value for the time and attention I give to them. The rest falls below the line and gets no attention right now. Maybe tomorrow. Maybe next week. Maybe never. It depends on the dynamics of the changing values, priorities, and opportunities -- and sometimes these change very quickly.
There is always something below that line -- not worth attention right now -- thus, there is always stuff that doesn't get done.
I suppose one's main work consists of "the stuff above the line", and "being on top of one's work" would mean "consistently getting THAT stuff done". Regardless of how often or how quickly it changes.
Maybe some of us can make that distinction more intuitively, more automatically -- and so, the only stuff that goes on The List, is the stuff that we are pretty sure is "above the line". This results in a "compact" list, or a standard "will do" list.
Others (like me) feel less confident in making that assessment, and so a lot more gets captured and written down -- resulting in long lists of things, most of which eventually gets dropped. It could be captured as a "will do" list, but many of the items would need to be written with question marks, meaning "do this? explore this? is this important?"
I would argue that both of these approaches are perfectly valid, with their own sets of trade-offs and applicability to different personalities and work environments.
<< But I am having difficulty envisaging what sort of project would always have an unlimited amount of work to be done. >>
I generally have the opposite problem.
I think my work is similar to Alan's. There is always more work that could be done, than can ever actually be done.
But that's OK. In fact, I think it's normal for many people.
In Agile Scrum, it's common to identify the whole backlog of work as a series of prioritized "user stories" which describe the stuff that users want a system to do. The highest priority items need to be pretty clearly defined, because they will be worked on very soon. The lower the priority, the more acceptable it is for the item to be more vaguely defined.
Users are constantly giving feedback (assuming anyone is actually using your product!). That feedback generates new "user stories", and it also informs the prioritization of the whole stack.
Everything on the stack has a cost: it will take time and work to figure out what the users want, and how much work (time and effort) it will take the developers to build it, test it, and integrate it into the product.
Everything on the stack also has a value: what real value do the users get from it.
Eventually there comes a time when the value of the items remaining in the stack is less than the cost of those items. Or maybe, the value is higher than the cost, but there is another project you could have your team work on, where the value/cost ratio is much higher. In either case, it's time to stop (or at least ramp down) the current project. This typically means there's a lot of stuff in the queue that just gets dropped.
And that's totally normal. People are making these kinds of cost/benefit decisions all the time, in all areas of life.
This has informed my own workload management quite a lot over the last year. I have never been able to see the possibility of "getting everything done", and working with this Agile Scrum method has made it very clear to me that this is quite normal and acceptable! My own work is very similar: I have lots of commitments and opportunities, which all involve creating some kind of value, at some kind of cost. The best I can do, at any given moment, is to assess which items RIGHT NOW will bring the highest value for the time and attention I give to them. The rest falls below the line and gets no attention right now. Maybe tomorrow. Maybe next week. Maybe never. It depends on the dynamics of the changing values, priorities, and opportunities -- and sometimes these change very quickly.
There is always something below that line -- not worth attention right now -- thus, there is always stuff that doesn't get done.
I suppose one's main work consists of "the stuff above the line", and "being on top of one's work" would mean "consistently getting THAT stuff done". Regardless of how often or how quickly it changes.
Maybe some of us can make that distinction more intuitively, more automatically -- and so, the only stuff that goes on The List, is the stuff that we are pretty sure is "above the line". This results in a "compact" list, or a standard "will do" list.
Others (like me) feel less confident in making that assessment, and so a lot more gets captured and written down -- resulting in long lists of things, most of which eventually gets dropped. It could be captured as a "will do" list, but many of the items would need to be written with question marks, meaning "do this? explore this? is this important?"
I would argue that both of these approaches are perfectly valid, with their own sets of trade-offs and applicability to different personalities and work environments.
December 15, 2014 at 7:24 |
Seraphim
Seraphim
Alan Baljeu:
<< The very large complex software creation project I'm involved in will never run out of things I can pour my effort into. In my case there is no delegating out - I'm the recipient of delegation, and I have enough to go by that I can keep working on it indefinitely. >>
I've having even more trouble envisaging this. This is a creation project? So presumably the aim is one day to market it, sell it, or at the very least put it to use. And yet it's infinite, never-ending, without any limits or constraints?
Even God in Genesis is depicted as having clearly defined targets for each day, plus a completion date!
<< The very large complex software creation project I'm involved in will never run out of things I can pour my effort into. In my case there is no delegating out - I'm the recipient of delegation, and I have enough to go by that I can keep working on it indefinitely. >>
I've having even more trouble envisaging this. This is a creation project? So presumably the aim is one day to market it, sell it, or at the very least put it to use. And yet it's infinite, never-ending, without any limits or constraints?
Even God in Genesis is depicted as having clearly defined targets for each day, plus a completion date!
December 15, 2014 at 8:36 |
Mark Forster
Mark Forster
Seraphim:
Nice to hear from you again. You've been very quiet recently!
<< I think my work is similar to Alan's. There is always more work that could be done, than can ever actually be done. >>
Frankly I find Alan's description of his work incomprehensible. If this is a commercial product which one day will see the light of day then how can there be more work that could be done than could ever actually be done? It would be like a car manufacturer saying, "We would like to issue some new models this year but we are delaying them infinitely because we keep thinking up more changes we could do".
<< In Agile Scrum, it's common to identify the whole backlog of work as a series of prioritized "user stories" which describe the stuff that users want a system to do. >>
I love the way you use a method which is intended to enable teams to react quickly to customer demands as a justification for the sort of "infinite" programming which it's designed to get away from!
<< Others (like me) feel less confident in making that assessment, and so a lot more gets captured and written down -- resulting in long lists of things, most of which eventually gets dropped. >>
I think we're approaching things from the wrong end. What matters at the end of the day is what we actually did. No one cares whether we had a list of 400 tasks or no list at all as long as we got the right stuff done.
If you keep track of what you've done each day and then look back over, say, the last month's work you can ask yourself questions like these. Was what you achieved what you wanted to achieve? What should you have done that you didn't? How much was wasted effort? How many initiatives did you start but fail to carry through? How many are now brought to fruition or progressing satisfactorily? Did you get full value out of the time and effort you expended? Are you satisfied with what you did?
Nice to hear from you again. You've been very quiet recently!
<< I think my work is similar to Alan's. There is always more work that could be done, than can ever actually be done. >>
Frankly I find Alan's description of his work incomprehensible. If this is a commercial product which one day will see the light of day then how can there be more work that could be done than could ever actually be done? It would be like a car manufacturer saying, "We would like to issue some new models this year but we are delaying them infinitely because we keep thinking up more changes we could do".
<< In Agile Scrum, it's common to identify the whole backlog of work as a series of prioritized "user stories" which describe the stuff that users want a system to do. >>
I love the way you use a method which is intended to enable teams to react quickly to customer demands as a justification for the sort of "infinite" programming which it's designed to get away from!
<< Others (like me) feel less confident in making that assessment, and so a lot more gets captured and written down -- resulting in long lists of things, most of which eventually gets dropped. >>
I think we're approaching things from the wrong end. What matters at the end of the day is what we actually did. No one cares whether we had a list of 400 tasks or no list at all as long as we got the right stuff done.
If you keep track of what you've done each day and then look back over, say, the last month's work you can ask yourself questions like these. Was what you achieved what you wanted to achieve? What should you have done that you didn't? How much was wasted effort? How many initiatives did you start but fail to carry through? How many are now brought to fruition or progressing satisfactorily? Did you get full value out of the time and effort you expended? Are you satisfied with what you did?
December 15, 2014 at 9:51 |
Mark Forster
Mark Forster
...and if you aren't satisfied with what you did maybe talk to your shadow self: "the Shadow appears as the sum total of the weakest, most flawed, inferior or even disgusting parts of yourself." - http://www.psychologytoday.com/blog/the-tools/201205/the-shadow
December 15, 2014 at 14:04 |
michael
michael
Mark: Suffice it to say that version 1 requires hundreds of hours to complete, so if I chose to work at it 14 hours a day I could, and after some weeks it would be done. There are two reasons not to work 14 hours a day: flagging energy, and the rest of life.
December 15, 2014 at 21:35 |
Alan Baljeu
Alan Baljeu
An update on my experience with spinning plates today and yesterday:
I "reset" my list at work and decided to start it from scratch, primarily because I had gotten stuck in a mode where I couldn't get minor/urgent tasks done (since I had a few things that I was never on top of yet). So far I've completed Presentation Z quite quickly and I'm quite proud of it. Everything else on my list, which mostly consists of maintenance tasks, is kept on top of very effectively. A lot of them are actually things I only need to do once a day to completion.
One experience yesterday clarified part of what I was missing beforehand. One of my projects is to further incorporate Stoic philosophy into my life. As such, it's an ongoing project that can have lots of directions of what to do next. E.g. read more Stoic philosophy, learn Syriac Greek and Latin, write a Stoic journal, contemplate adversity, etc. After exploring these different directions a bit, I decided on a specific contemplative exercise to do everyday until I feel sufficiently bored with it.
To use an analogy, imagine you're an explorer that's been dropped off on a new continent. Now in some sense what you could do to 'explore' is unlimited, but in another it's very obvious that you need to pick a direction and stick with it until you reach your stopping criteria. If you decide your goal is to reach that hill over there by the end of the week before you explore anything else, that means you have to hike a certain number of miles each day to reach it.
I guess an alternative would be to say that your goal is to spend 6 hours per day just wandering towards whatever seems interesting in the jungle, then spend the rest of the time analyzing what you saw until you get bored with that. This is similar to the approach that software/system testers use, since you can never truly run out of things to test in a product. But even they generally have some sort of "risk list" of what directions they need to focus on :)
I "reset" my list at work and decided to start it from scratch, primarily because I had gotten stuck in a mode where I couldn't get minor/urgent tasks done (since I had a few things that I was never on top of yet). So far I've completed Presentation Z quite quickly and I'm quite proud of it. Everything else on my list, which mostly consists of maintenance tasks, is kept on top of very effectively. A lot of them are actually things I only need to do once a day to completion.
One experience yesterday clarified part of what I was missing beforehand. One of my projects is to further incorporate Stoic philosophy into my life. As such, it's an ongoing project that can have lots of directions of what to do next. E.g. read more Stoic philosophy, learn Syriac Greek and Latin, write a Stoic journal, contemplate adversity, etc. After exploring these different directions a bit, I decided on a specific contemplative exercise to do everyday until I feel sufficiently bored with it.
To use an analogy, imagine you're an explorer that's been dropped off on a new continent. Now in some sense what you could do to 'explore' is unlimited, but in another it's very obvious that you need to pick a direction and stick with it until you reach your stopping criteria. If you decide your goal is to reach that hill over there by the end of the week before you explore anything else, that means you have to hike a certain number of miles each day to reach it.
I guess an alternative would be to say that your goal is to spend 6 hours per day just wandering towards whatever seems interesting in the jungle, then spend the rest of the time analyzing what you saw until you get bored with that. This is similar to the approach that software/system testers use, since you can never truly run out of things to test in a product. But even they generally have some sort of "risk list" of what directions they need to focus on :)
December 15, 2014 at 22:33 |
Ryan Freckleton
Ryan Freckleton
Mark wrote:
<< What matters at the end of the day is what we actually did. No one cares whether we had a list of 400 tasks or no list at all as long as we got the right stuff done. >>
Since that's essentially what I was trying to say (and NOT making <<justification for the sort of "infinite" programming which it's designed to get away from!>>), and it's what I think Agile Scrum actually accomplishes, I think maybe you misunderstood my post. I will try again.
Agile Scrum implements many of the list-processing concepts that Mark advocates on this site. It's basically a series of "closed lists" (the Sprint Backlog) which are fed by a constantly-changing "open list" (the Product Backlog).
The "backlog" I described in my earlier post should more precisely be called the Product Backlog -- the list of all **potential** development work that has been identified to go into the product. At the beginning of each Sprint, the team commits to COMPLETING a specific short list of high-priority items that they pull from the Product Backlog. This short, closed list is called the Sprint Backlog.
Thus, the team is always focused on completing a closed list of the highest-value and highest-priority items.
While they are doing that, the Product Owner is working with the customer to figure out what comes next:
- looking through the Product Backlog
- adding new customer requests
- removing things that no longer have value (because of changing needs/priorities/etc.)
- adding new items that the customer doesn't see directly, but have an important impact (like performance or stability)
- making sure the highest-priority items are defined clearly enough to really understand the value the customer is looking for, and how it might be developed
- re-prioritizing to make sure the highest-value items are near the top of the list, and are ready to be worked on
Thus, there's a process for "universal capture" on an open list, together with percolation, filtering, assessing, sizing, clarifying, prioritizing, etc.
My point in the earlier post is that this Open List usually has things on it that will never get done -- but it's not clear at any given point of time, which items those will be. They still need to be clarified, filtered, processed, and then dropped. Maybe the Product Owner will do regular pruning of the list to get rid of the clutter. All of this is perfectly normal. In fact, I've never been on a project where the initial project plan was completely defined from the beginning -- unless it's a very simple project with just a handful of tasks.
<< What matters at the end of the day is what we actually did. No one cares whether we had a list of 400 tasks or no list at all as long as we got the right stuff done. >>
Since that's essentially what I was trying to say (and NOT making <<justification for the sort of "infinite" programming which it's designed to get away from!>>), and it's what I think Agile Scrum actually accomplishes, I think maybe you misunderstood my post. I will try again.
Agile Scrum implements many of the list-processing concepts that Mark advocates on this site. It's basically a series of "closed lists" (the Sprint Backlog) which are fed by a constantly-changing "open list" (the Product Backlog).
The "backlog" I described in my earlier post should more precisely be called the Product Backlog -- the list of all **potential** development work that has been identified to go into the product. At the beginning of each Sprint, the team commits to COMPLETING a specific short list of high-priority items that they pull from the Product Backlog. This short, closed list is called the Sprint Backlog.
Thus, the team is always focused on completing a closed list of the highest-value and highest-priority items.
While they are doing that, the Product Owner is working with the customer to figure out what comes next:
- looking through the Product Backlog
- adding new customer requests
- removing things that no longer have value (because of changing needs/priorities/etc.)
- adding new items that the customer doesn't see directly, but have an important impact (like performance or stability)
- making sure the highest-priority items are defined clearly enough to really understand the value the customer is looking for, and how it might be developed
- re-prioritizing to make sure the highest-value items are near the top of the list, and are ready to be worked on
Thus, there's a process for "universal capture" on an open list, together with percolation, filtering, assessing, sizing, clarifying, prioritizing, etc.
My point in the earlier post is that this Open List usually has things on it that will never get done -- but it's not clear at any given point of time, which items those will be. They still need to be clarified, filtered, processed, and then dropped. Maybe the Product Owner will do regular pruning of the list to get rid of the clutter. All of this is perfectly normal. In fact, I've never been on a project where the initial project plan was completely defined from the beginning -- unless it's a very simple project with just a handful of tasks.
December 16, 2014 at 0:59 |
Seraphim
Seraphim
<Mark: Suffice it to say that version 1 requires hundreds of hours to complete, so if I chose to work at it 14 hours a day I could, and after some weeks it would be done. There are two reasons not to work 14 hours a day: flagging energy, and the rest of life.>>
It seems like the way to handle that in Spinning Plates would be to make a conscious decision how much work per day on the project you consider appropriate to keep it moving without crowding out your other work or interfering with the rest of life, and then you are "up to date" when you're on track with that plan.
It seems like the way to handle that in Spinning Plates would be to make a conscious decision how much work per day on the project you consider appropriate to keep it moving without crowding out your other work or interfering with the rest of life, and then you are "up to date" when you're on track with that plan.
December 16, 2014 at 3:14 |
Austin
Austin
Alan Baljeu:
<< Suffice it to say that version 1 requires hundreds of hours to complete, so if I chose to work at it 14 hours a day I could, and after some weeks it would be done. There are two reasons not to work 14 hours a day: flagging energy, and the rest of life. >>
This is very similar to writing a book. You have a target date for completion and you work out how much work you need to do daily in order to meet the target.
<< Suffice it to say that version 1 requires hundreds of hours to complete, so if I chose to work at it 14 hours a day I could, and after some weeks it would be done. There are two reasons not to work 14 hours a day: flagging energy, and the rest of life. >>
This is very similar to writing a book. You have a target date for completion and you work out how much work you need to do daily in order to meet the target.
December 16, 2014 at 10:43 |
Mark Forster
Mark Forster
Austin:
<< It seems like the way to handle that in Spinning Plates would be to make a conscious decision how much work per day on the project you consider appropriate to keep it moving without crowding out your other work or interfering with the rest of life, and then you are "up to date" when you're on track with that plan. >>
That's basically it. Though I would allocate the time per day according to the target date for completion rather than the factors you give. There is less scope for fooling yourself about the progress you are making.
<< It seems like the way to handle that in Spinning Plates would be to make a conscious decision how much work per day on the project you consider appropriate to keep it moving without crowding out your other work or interfering with the rest of life, and then you are "up to date" when you're on track with that plan. >>
That's basically it. Though I would allocate the time per day according to the target date for completion rather than the factors you give. There is less scope for fooling yourself about the progress you are making.
December 16, 2014 at 10:45 |
Mark Forster
Mark Forster
Seraphim:
<< Since that's essentially what I was trying to say (and NOT making <<justification for the sort of "infinite" programming which it's designed to get away from!>>), and it's what I think Agile Scrum actually accomplishes, I think maybe you misunderstood my post. I will try again. >>
No, I didn't misunderstand your post. I was amusing myself at the way in which you were using a project planning method for teams to justify your own personal list of 400 items (or whatever size it is these days). However what Agile Scrum does at the team/client level does not apply at the level of the individual members of the team.
<< At the beginning of each Sprint, the team commits to COMPLETING a specific short list of high-priority items that they pull from the Product Backlog. >>
Exactly. And the individual members of the team will each commit to completing their part of the specific short list. They won't each have a 400 item list they can choose from. They will each have a personal list of tasks which it's their responsibility to COMPLETE.
In the end what counts is whether they succeed in doing them all.
<< Since that's essentially what I was trying to say (and NOT making <<justification for the sort of "infinite" programming which it's designed to get away from!>>), and it's what I think Agile Scrum actually accomplishes, I think maybe you misunderstood my post. I will try again. >>
No, I didn't misunderstand your post. I was amusing myself at the way in which you were using a project planning method for teams to justify your own personal list of 400 items (or whatever size it is these days). However what Agile Scrum does at the team/client level does not apply at the level of the individual members of the team.
<< At the beginning of each Sprint, the team commits to COMPLETING a specific short list of high-priority items that they pull from the Product Backlog. >>
Exactly. And the individual members of the team will each commit to completing their part of the specific short list. They won't each have a 400 item list they can choose from. They will each have a personal list of tasks which it's their responsibility to COMPLETE.
In the end what counts is whether they succeed in doing them all.
December 16, 2014 at 10:56 |
Mark Forster
Mark Forster
Mark wrote:
<< I was amusing myself at the way in which you were using a project planning method for teams to justify your own personal list of 400 items >>
I'm glad I was able to give you some amusement. :-) But I think that's a mis-characterization of my post (or at least a misunderstanding). The point of my post is that it's easy to come up with examples of projects that initially include plenty of plans/ideas that never get implemented, but are nonetheless successful projects that deliver high value.
The reference at the end of my first post on Agile Scrum (above) to different personal styles of managing the "open list" of potential work was really intended as a sidebar, not the main point.
<< (or whatever size it is these days) >>
Actually, I haven't been maintaining any particular list for at least six months. I've been finding that I get more value optimizing my habits, calendar, and team processes rather than trying to find the best way of cataloging/maintaining a list of outstanding work.
<< In the end what counts is whether they succeed in doing them all. >>
Of course this is important. But it's also rather important that they are completing the right things (and ignoring, at least temporarily, everything else).
<< I was amusing myself at the way in which you were using a project planning method for teams to justify your own personal list of 400 items >>
I'm glad I was able to give you some amusement. :-) But I think that's a mis-characterization of my post (or at least a misunderstanding). The point of my post is that it's easy to come up with examples of projects that initially include plenty of plans/ideas that never get implemented, but are nonetheless successful projects that deliver high value.
The reference at the end of my first post on Agile Scrum (above) to different personal styles of managing the "open list" of potential work was really intended as a sidebar, not the main point.
<< (or whatever size it is these days) >>
Actually, I haven't been maintaining any particular list for at least six months. I've been finding that I get more value optimizing my habits, calendar, and team processes rather than trying to find the best way of cataloging/maintaining a list of outstanding work.
<< In the end what counts is whether they succeed in doing them all. >>
Of course this is important. But it's also rather important that they are completing the right things (and ignoring, at least temporarily, everything else).
December 17, 2014 at 2:27 |
Seraphim
Seraphim
Seraphim:
<< Actually, I haven't been maintaining any particular list for at least six months.>>
So why did you mislead me by saying "Others (like me) feel less confident in making that assessment, and so a lot more gets captured and written down -- resulting in long lists of things, most of which eventually gets dropped."
I can only go by what you write!
<< I've been finding that I get more value optimizing my habits, calendar, and team processes rather than trying to find the best way of cataloging/maintaining a list of outstanding work. >>
You say on one hand that it's a normal process to write down loads of stuff and reject most of it, and on the other hand you say that you have found a better method - which turns out to be the exact opposite. So I'm more than a bit mystified now as to what point you were trying to make.
<< Of course this is important. But it's also rather important that they are completing the right things (and ignoring, at least temporarily, everything else). >>
The individual team members will be doing the right things because they are the actions agreed by the team for the "sprint".
<< Actually, I haven't been maintaining any particular list for at least six months.>>
So why did you mislead me by saying "Others (like me) feel less confident in making that assessment, and so a lot more gets captured and written down -- resulting in long lists of things, most of which eventually gets dropped."
I can only go by what you write!
<< I've been finding that I get more value optimizing my habits, calendar, and team processes rather than trying to find the best way of cataloging/maintaining a list of outstanding work. >>
You say on one hand that it's a normal process to write down loads of stuff and reject most of it, and on the other hand you say that you have found a better method - which turns out to be the exact opposite. So I'm more than a bit mystified now as to what point you were trying to make.
<< Of course this is important. But it's also rather important that they are completing the right things (and ignoring, at least temporarily, everything else). >>
The individual team members will be doing the right things because they are the actions agreed by the team for the "sprint".
December 17, 2014 at 10:05 |
Mark Forster
Mark Forster
Mark wrote:
<< So why did you mislead me by saying "Others (like me) feel less confident in making that assessment, and so a lot more gets captured and written down -- resulting in long lists of things, most of which eventually gets dropped." ... You say on one hand that it's a normal process to write down loads of stuff and reject most of it, and on the other hand you say that you have found a better method - which turns out to be the exact opposite. So I'm more than a bit mystified now as to what point you were trying to make. >>
I wasn't intentionally trying to mislead you.
As an aside to my main point that many project plans include tasks/work that never actually gets done (and that this is OK), I was trying to express a new idea (new for me, at least) that some people naturally have a better sense of the "short list" of stuff they need to focus on right now, and more confidence that the right stuff will come to them again later when they are ready for it, rather than having to capture everything lest they lose it. Perhaps these folks operate more naturally in a "closed list" mode.
While on the other hand, some people naturally see connections and expansions and new ideas all the time -- a lot more open-ended material -- and have regretted losing those things when they DON'T capture them, because they get a lot of value from exploring these more open-ended opportunities. I've heard this type of person called a "scanner". Perhaps these folks operate more naturally in an "open list" mode.
Both sides have positives and negatives.
If you are always in "closed list" mode, you may have very strong focus, and very strong drive to completion and results. But maybe you don't really catch onto new and potentially valuable opportunities, and have a hard time changing direction when faced with changing priorities. (This reminds me of some project managers -- "Just work the project plan, thank you! When is your next task going to be done??!")
If you are always in "open list" mode, you may be very well attuned to new possibilities and new opportunities and ideas. You probably like exploring all the new connections and relationships you discover -- and you SEE these connections more than most people. You probably START lots of things. But maybe you have a really hard time FINISHING things, and don't have a strong enough focus on RESULTS.
Ultimately I think it's very helpful to understand one's tendencies in these areas, and to strive for the right balance between them. Your systems have been very good at exploring these dynamics and finding intuitive and effective ways of striking the right balance.
I admit I tend more toward the latter. But I don't think this is all bad, not at all! This has been a strength for me, my whole career. I am good at driving alignment in very chaotic environments with disparate goals and agendas, because I can see the connections between all these things, and like to explore them till I get clarity. It's a very open-ended way of working, and hard to nail down exactly what's going to come next. But I've had to struggle very hard to learn the skills needed to get things COMPLETED. I've always managed to find a way to deliver results, but driving to completion has never come naturally.
Anyway, I hope that helps clear up the misunderstanding.
[ Sorry Ryan, for hijacking your thread! I hope you didn't mind this diversion -- I really enjoyed it, myself. :-) ]
<< So why did you mislead me by saying "Others (like me) feel less confident in making that assessment, and so a lot more gets captured and written down -- resulting in long lists of things, most of which eventually gets dropped." ... You say on one hand that it's a normal process to write down loads of stuff and reject most of it, and on the other hand you say that you have found a better method - which turns out to be the exact opposite. So I'm more than a bit mystified now as to what point you were trying to make. >>
I wasn't intentionally trying to mislead you.
As an aside to my main point that many project plans include tasks/work that never actually gets done (and that this is OK), I was trying to express a new idea (new for me, at least) that some people naturally have a better sense of the "short list" of stuff they need to focus on right now, and more confidence that the right stuff will come to them again later when they are ready for it, rather than having to capture everything lest they lose it. Perhaps these folks operate more naturally in a "closed list" mode.
While on the other hand, some people naturally see connections and expansions and new ideas all the time -- a lot more open-ended material -- and have regretted losing those things when they DON'T capture them, because they get a lot of value from exploring these more open-ended opportunities. I've heard this type of person called a "scanner". Perhaps these folks operate more naturally in an "open list" mode.
Both sides have positives and negatives.
If you are always in "closed list" mode, you may have very strong focus, and very strong drive to completion and results. But maybe you don't really catch onto new and potentially valuable opportunities, and have a hard time changing direction when faced with changing priorities. (This reminds me of some project managers -- "Just work the project plan, thank you! When is your next task going to be done??!")
If you are always in "open list" mode, you may be very well attuned to new possibilities and new opportunities and ideas. You probably like exploring all the new connections and relationships you discover -- and you SEE these connections more than most people. You probably START lots of things. But maybe you have a really hard time FINISHING things, and don't have a strong enough focus on RESULTS.
Ultimately I think it's very helpful to understand one's tendencies in these areas, and to strive for the right balance between them. Your systems have been very good at exploring these dynamics and finding intuitive and effective ways of striking the right balance.
I admit I tend more toward the latter. But I don't think this is all bad, not at all! This has been a strength for me, my whole career. I am good at driving alignment in very chaotic environments with disparate goals and agendas, because I can see the connections between all these things, and like to explore them till I get clarity. It's a very open-ended way of working, and hard to nail down exactly what's going to come next. But I've had to struggle very hard to learn the skills needed to get things COMPLETED. I've always managed to find a way to deliver results, but driving to completion has never come naturally.
Anyway, I hope that helps clear up the misunderstanding.
[ Sorry Ryan, for hijacking your thread! I hope you didn't mind this diversion -- I really enjoyed it, myself. :-) ]
December 18, 2014 at 3:13 |
Seraphim
Seraphim
Hi Seraphim
From what you write, I think our brains are quite similar (minus my actual brain damage). It's that combination of unrelenting, natural curiosity and a propensity to want to learn, create and/or problem solve that makes us hum. LOL! My dad once told that the ideal job for me would be a professional student. LOL! Even when I was working hard hours and hard deadlines, I usually was taking a course or two to satisfy my brain. I also kept up and rotated billiards tournaments, dance and art competitions, marathons, band practice and enjoying my sports. I did all of this to keep feeding my brain and to prevent the torture of boredom. In short, I totally sympathize with you because I live in the same sort of brain.
I was very lucky in that I had to learn about planning, scheduling and prioritizing to keep up with learning and mastering my talents and interests. Unfortunately that required hours upon hours of practice. I knew that I mastered the particular skill or routine when I finally felt bored stiff with it. Then I knew that I was ready for the recital or competition. Also to enjoy your talents, you want to be able to enjoy the sport, art of music without thinking about it. People usually flub up when they have to think about the finger pattern, the next step, or what you body must do for the dismount. Judges also see hesitation in your movements. IOW, to enjoy what you're doing, you must resign yourself to lots of tedious practice. Also, when you have a lot of plates spinning with close deadlines, you have to prioritize learning, practice and mastery. Example: Do I devote more practice to the billiards tournament with a large purse or refine my dance routine for a contest that wins me $100 and makes me highly likely to be chosen as a dance partner? They both mean a lot to me but I'd prioritize my job deadlines first, my studies second, the pool tournament practice third, and finally carefully commit to only so many dance rehearsals around the rest. I'd let my dance partner know in advance the amount of rehearsal I had time for.
Bottom line: Even though it doesn't come naturally to me, I need to be willing to prioritize, plan and slog through a lot of tedium and boredom to get me in a position to enjoy my passions. As they say, "everything is a trade." LOL!
p.s. I also delete much of my ideas that seemed so brilliant and viable at the time (especially the thoughts that were doused in my pain meds. LOL!) But even though I delete much my ideas, I truly believe that allowing myself to generate the ideas or capture when they just appear, feeds my brain and my mood. LOL! Many supposedly wasted ideas have a seed of value.
Because my brain is naturally kaleidoscopic, I need to compensate by having an overview and some sort of guiding plan for my efforts .... especially if it's stuff that doesn't interest me at all. I want to get it over with as painlessly as possible. If I ignore something of importance, my conscientiousness becomes an unrelenting nag monster that spoils whatever I'm doing. The best way to quiet the nagging is to have a general or specific plan that covers it. I also need the confidence that my plan is doable. LOL! I also need some sort of plan to guide my natural tendency to go off on a tangent. Mark has taught me how to redirect myself when that happens (which is annoyingly often. LOL)......." Ooh, shiny!"
p.s. Another bloated post brought to you by the makers of Percocet.
From what you write, I think our brains are quite similar (minus my actual brain damage). It's that combination of unrelenting, natural curiosity and a propensity to want to learn, create and/or problem solve that makes us hum. LOL! My dad once told that the ideal job for me would be a professional student. LOL! Even when I was working hard hours and hard deadlines, I usually was taking a course or two to satisfy my brain. I also kept up and rotated billiards tournaments, dance and art competitions, marathons, band practice and enjoying my sports. I did all of this to keep feeding my brain and to prevent the torture of boredom. In short, I totally sympathize with you because I live in the same sort of brain.
I was very lucky in that I had to learn about planning, scheduling and prioritizing to keep up with learning and mastering my talents and interests. Unfortunately that required hours upon hours of practice. I knew that I mastered the particular skill or routine when I finally felt bored stiff with it. Then I knew that I was ready for the recital or competition. Also to enjoy your talents, you want to be able to enjoy the sport, art of music without thinking about it. People usually flub up when they have to think about the finger pattern, the next step, or what you body must do for the dismount. Judges also see hesitation in your movements. IOW, to enjoy what you're doing, you must resign yourself to lots of tedious practice. Also, when you have a lot of plates spinning with close deadlines, you have to prioritize learning, practice and mastery. Example: Do I devote more practice to the billiards tournament with a large purse or refine my dance routine for a contest that wins me $100 and makes me highly likely to be chosen as a dance partner? They both mean a lot to me but I'd prioritize my job deadlines first, my studies second, the pool tournament practice third, and finally carefully commit to only so many dance rehearsals around the rest. I'd let my dance partner know in advance the amount of rehearsal I had time for.
Bottom line: Even though it doesn't come naturally to me, I need to be willing to prioritize, plan and slog through a lot of tedium and boredom to get me in a position to enjoy my passions. As they say, "everything is a trade." LOL!
p.s. I also delete much of my ideas that seemed so brilliant and viable at the time (especially the thoughts that were doused in my pain meds. LOL!) But even though I delete much my ideas, I truly believe that allowing myself to generate the ideas or capture when they just appear, feeds my brain and my mood. LOL! Many supposedly wasted ideas have a seed of value.
Because my brain is naturally kaleidoscopic, I need to compensate by having an overview and some sort of guiding plan for my efforts .... especially if it's stuff that doesn't interest me at all. I want to get it over with as painlessly as possible. If I ignore something of importance, my conscientiousness becomes an unrelenting nag monster that spoils whatever I'm doing. The best way to quiet the nagging is to have a general or specific plan that covers it. I also need the confidence that my plan is doable. LOL! I also need some sort of plan to guide my natural tendency to go off on a tangent. Mark has taught me how to redirect myself when that happens (which is annoyingly often. LOL)......." Ooh, shiny!"
p.s. Another bloated post brought to you by the makers of Percocet.
December 18, 2014 at 14:15 |
learning as I go
learning as I go
Thank you for your post, Learning! There are a lot of nuggets there, and a lot of resonance with the issues I am thinking about these last few days. I give credit to YOU, however, not to Percocet, for the inspiration. :-)
December 19, 2014 at 0:23 |
Seraphim
Seraphim
The thing that I hope that it will give me is a clear criteria for whether or not I can take on a new task/project, based on whether or not I'm on top of all my other work.
I've been experimenting with it at both home and work. At home, it seems to be working really well, partially because I have really clear criteria for what I consider "currently on top of" E.g.
Anki cards: Have I cleared the due cards today?
Project X: Have I worked on it so that the time I've dedicated in beeminder is blue?
Project Y: Have I done enough pomodoros so that my beeminder goal is blue?
However, at work, I've been running ito a struggle with my projects. The current thing I've done is as follows:
Presentation Z: This is only done when it's totally done and finished, thereby stopping additional work to be added.
Project A: I'm 'on-top' of this if I've completed the next dotted task on my task list. I can break those tasks down as much as I want, but if I don't finish it in one sitting, I need to continue.
Project B: Same as Project A
My mail, memos, etc. are associated with a daily checklist so don't go into this time management system. (In other words, my calendar handles them).
So, any ideas for heuristics/strategies/techniques to determine what "being on top" of work should be? So far I've discovered the following in comments/discussions:
- Do a little work when the task comes up (even if' it's thinking and reflecting on it). This is the liberal 'little and often' rule that I believe Mark recommends with most of his AF/FV style time management systems.
- Do enough work so I'm on the blue line for beeminder. If I want to do more, that's great (and I usually do so) but 'nothing new' is due until the next day when beeminder goes from blue to red.
- Complete a chunk of work on it that I've articulated beforehand (my work project strategy).
I don't generally like to make detailed schedules if I don't need to, so some other flexible ideas would be nice.