Hi everyone! I've been using GTD for about 3 years now. Initially, it helped me to take a huge step forward in my organisation and productivity. But over the last few months, I've noticed some gaps for me. I feel like I get loads of tasks done, but I don't necessarily get my big projects or tasks done as efficiently as I could.

About a week ago, I discovered something called Agile Results - developed by a software developer at Microsoft. This system helps you to get a big picture view and prioritise really nicely. It overlays GTD so you can use both together. I can see that it's going to be hugely effective for helping me with time management.

As soon as I started reading about it, I realise that helping to manage an Agile Results Implementation is something that Tinderbox was born to do - and not only that, but folks who love Tinderbox would love Agile. But I was amazed that when I searched on the TBX forum, there's nothing about it!

So I was just wondering if anyone is using TBX with Agile and if they'd like to share their implementation. I'm just setting mine up now. Also, if you use GTD and love TBX, but feel like you're getting lots done but not necessarily the most helpful things or that you never have enough time, then take a look at Agile.

Small world! I have known David Allen (of GTD fame) for a long time and am about to write a Foreword to the new edition of "Getting Things Done."

I have known generally about the Agile Results approach but not about this specific implementation. Of course I am interested. Is there any specific link or site you can suggest? I also agree that Tinderbox epitomizes the agile/evolving approach to everything, so it's a natural match.

Thanks Mel - this looks interesting, but will require study at length! Coming to how Agile Results might be implemented in TBX you're right that in principle (just about) anything can be built but I think it would be helpful to begin by clarifying which aspect(s) of the AR methodology you'd be looking to implement.

On my first glance through I've picked up on the 3+3+3 idea. It would certainly be easy to build an outline to house major projects, sub-sections etc, although this wouldn't be hugely different to a number of GTD-inspired project outlines that are described elsewhere in this forum (search "GTD").

However there would be no need to constrain (say) the level 2 items in the outline to be the "do in a week" level of granularity. You could use prototypes to designate "day", "week" and "month" level items and allocate them as appropriate within various sections of the outline. These could have boolean "SelectNext" and "Done" attributes and then the SelectedNext AND NOT Done items at each level could be collected by agents, but I'm sure there will be more creative ways to implement these and other aspects too

Really interesting - thanks for introducing me to it

Rob

Off topic but possibly interesting on the subject of dashboards: my NaNoWriMo dashboard. Note that this is pretty minimal -- with only a month to work in, I didn't want to spend time on infrastructure and miss my wordcount. Even then, the bar charts for chapter length turned out to be fairly useless.

So, I was wondering if the more experienced of you could offer some guidance on setting this up (I can tell there's probably more than one way to do this).

I'd like to have different views so a year view (e.g. 2015) where I can see a map or an overview of my year with the months, key outcomes, and sprints. And then a month view (e.g. January 2015) where I can see a map of the month, and the set up of the flow of my weeks, the key outcomes for the month, a week view and a day view.

If I make January 2015 a container inside 2015 then I think I lose some of the information of the 2015 view - the key outcomes and sprints would be inside the container rather than visible. So I'm guessing the best way to achieve this is with an agent? Does it make sense to experienced users to achieve this with dates or perhaps with a tag of 2015 and a tag of January (my head works in tags) since dates always have a day associated with them? Or do I lose some functionality like timeline or calculating dates with before and after searches that I won't get with tags?

And is it a simple matter to create what I think of as "templates" (in my head this is a map version of a prototype) for a year, a month and a day - so if I map out what a general year looks like and ask it to display certain information, I can just copy and paste this to use it for a specific year?

Sorry for the noob type questions, I'm hoping that working this out will benefit others who are interested in an agile implementation.

And for those who are working on this, how are you setting up "Hot spots"?

**Update: I just found $PrototypeBequeathsChildren - that'll be very useful!

Mel: I'm hoping to turn this into a tutorial document. Stay tuned: it's continuing to evolve. I'm hoping to talk a bit more about this on http://markBernstein.org this week.

Can you set a default view? No, but only because all containers 'have' all views and even have more than one at a time. Thus container X can be open in one tab as an outline, a second tab as a map, etc. It's all the same data. Switching view types is as simple as there are numerous methods - menu and shortcut - for doing so. The issue is more - especially with map view - getting it to open showing the exact part of the map you want. I'm not sure that there is, as yet, a method to say "always open this container based on these co-ordinates". I think that once initially set up the container remembers it's last location but I may be wrong - more regular users of maps may correct me on that.

I think you've 2 design tasks. The first is broadly visual deign and can be done with notes and containers: on your dashboard-type view how many/big items do you need. Sorting this first makes sense as there's no point in designing a really detailed layout only to realise it doesn't fit the screen space available. Do look at this section of aTbRef about maps, it still holds good for v6 other than the fact that maps are now the left pane. Mock up the sort of results you want to see. some might like numbers, some patterns or charts etc. This will will inform the next task.

Secondly, now you've some idea of what you want you can figure which attributes need setting and where to use prototypes, agents, rules etc.

You can just build incrementally, but this is one of the few cases where you're effectively executing a known design so it is reasonable to to some work in advance. However, once you know the 'design' for your document the joy of TB's flexibility is you should then be able to execute the design within a mature doc that has your work data but, as yet, no reporting framework. Add in the necessary attributes, prototypes, etc. and you're good to go.

Don't forget to use throw-away models. In other words build tests you don't intend to keep. this lets you test/refine the design without the danger of affecting other data in you main working files. You can then add in the design only when confident with its workings.

Of course, that's only a suggestion! Don' feel obliged to to everything as described - TB's a very flexible tool.  the advice above is simply the expereince of mistakes I've made along the way.

1. Funky? Not entirely sure of the meaning but my guess is you're referring to the contents of the calendar months as shown in Map view. Changes in v5 & v6 map UI mean the layout need a bit of tweaking. You want to look at the agent at /System/Agents/DayDate generator and Formatting/Day Formatting, specifically the reset values for $MapScrollX and $MapScrollY. If you were referring to some other facet of that doc, could you be a bit more descriptive as to where we should be looking?


2. Pie charts. Yes, in v6. I'e not used them extensively.  These are MB's notes:
Quote:

3. Tabs.  v6.1.0 release notes state: Tinderbox now saves the tab state of each window separately, and restores the tab state when loading the window.

4. Date designators, can't be stored as values - 'today' is parsed into a date value immediately it is applied. I assume you're thinking about building out grids of map objects with dates//times. The best approach for this I've found is to set the 'first' object (hour of day, day of month, whatever) and have the rest of the grid set themselves via a rule (or stamp) based on their previous sibling. For instance set your day prototype so $RuleDisabled is true (i.e. rule doesn't run in the prototype) then give it the $Rule:

if($StartDate=="never"&$SiblingOrder>1&$StartDate(prevSibling)!="never"){$StartD
ate = date($StartDate(prevSibling)+"1 day");}

Now, if a note is set to use the prototype it will always be 1 day (same time) later than its previous sibling. Sibling #1 is never set as it's assumed the user will set that to seed the correct date. You can add in more date maths if you need to skip weekends, but i hope the general idea is clear.  You don't have to use a rule - you could use similar code in a Stamp if you prefer that way of doing things.