Image Description

Putting it Together

This lesson is a part of an audio course Productivity Systems for Developers by James Bowen

We’ve now covered how to gatekeep commitments, how to focus, how to set up your workflows and how to setup efficient reference data with mind maps. Now we want to put it all together. Before we can discuss our personal ways of improving, we want to have a consistent approach to our work. Let’s get this bit on auto-pilot first. Each step of the way, I’m trying to get you slightly more systematic and consistent.

I want to free your brain up for the creative and ingenious stuff, that’s what we’re good at, and the strength we want to focus on. Edmond Lau, author of “The Effective Engineer” wrote a great article in 2017 about the components that make a remarkable career. These components are:

  • Passions
  • Strengths
  • Market demand

We can’t control market demand, but we can hopefully improve our strengths and still follow our passions. I want my productivity system enabling the first two by ‘getting out of the way’.

We’ll go back to the start of our 2 week sprint at work, and how we can plan our 2 weeks. Since agile also dictates embracing change, we’ll also discuss how to work on a daily basis, rolling effortless with changes. We’ll also look at how to integrate with coding. Let’s start with sprint planning.

Using Your System for Sprint Planning

The morning of a new sprint, the first thing I do is to run my bash script that creates all my new templates. It creates me:

  • A new file system directory named as per the current sprint
  • Mind Map templates, copied into the correct folder.
  • An email folder following a similar naming convention.

I also have an overarching mindmap of ‘My Domain’ that I maintain fairly infrequently. This is just an overview of:

  • What the department is aiming for this quarter
  • Where I fit into this.
  • Who the important teams and their contacts are - for my collaboration
  • Links to important resources (everything from quarterly meeting minutes to expense forms)
  • And finally a link to the current sprint mindmap. I update where this link points to every 2 weeks.

I keep this lightweight enough that I’m not constantly maintaining it, but just detailed enough to give me a quarterly ‘landscape’ if you will. Now I have my ‘per sprint’ mindmap, and that’s linked to my overall landscape, I am ready for my planning meeting. Let’s discuss that next.

Your 2 Week Sprint Mindmap

You’ll have shared collaboration tools like JIRA, Trello, Wikis and the like. And this is where the majority of your info should reside. This is the teams collaborative understanding of the world and the onus is on you to keep yourself in sync with that and your personal system. Fortunately that’s not onerous.

During our planning meeting we discuss the JIRAS that we are planning to commit to. I replicate just the names of the stories in my mind map. I just want a high level view of what the team is committing to. If there’s anything about the story that’s important to me, but doesn’t warrant slowing the team meeting down, I just put it in there as my personal notes. Obviously if it is important to the team I just say something there and then!

As well as my lightweight notes I have a checklist in my mind map. Because I use a template, each map that I generate already has ‘warning notes’ ready for the meeting. I am ‘greeted with’:

  • Do we have any third party collaborations for our stories?
  • Have we identified blockers to any story?
  • Has the entire team been invited to discuss pitfalls?
  • Any planned absences (e.g. annual leave) in the team this week?
  • Any dependencies between stories?

Now whilst all of these points should form a ‘ready to accept’ checklist that the whole team uses, I keep this as a safety net for the whole team. If the points have already been discussed I just keep my mouth closed! If we’ve missed it, my mind map doesn’t.

Just remember the point with mind maps - they reflect your landscape back to you and give the brain the chance to get new ideas. What a way to supercharge your planning eh?

So after planning, at some point in the next 2 weeks I will pick up a piece of work from our backlog. Let’s look at that now.

Using Your System for Picking Up a New Piece of Work

When picking up a piece of work, I look both at my own notes in my mind map and the JIRA itself. JIRA may in turn contain external links such as to a wiki for detailed notes. At the very least it should contain the story Acceptance Criteria, otherwise what was the point of the planning meeting again?

At this point I turn my mindmap into something of a ‘cache’ of information for that story. That’s my personal workspace, so if there is any information I want to add or enrich I do it here.

For example, maybe I read the AC’s and there’s some peculiar situation which might require a little thinking through? I can add my notes/stream of consciousness supporting that into my mindmap.

Maybe the wiki documentation that supports that story throws out a few implementation options?

I can create a mindmap node of ‘supporting materials’ with the original wiki documentation and some stack overflow links so I have ‘one place to go for answers. When I come back to this work tomorrow, or the next day, I’m not scrambling round google a second time trying to find what I need. I do the same with bamboo plans and bitbucket repos - one place to go.

If the work is really complicated, I use my bash template to create a new sub-mindmap. Then I break it out from there. I try not to do this too often as that’s more places to keep current, but sometimes there’s just too much to think about. I have a Docker uplift project as I mentioned before and as there’s so many facets to it, it’s too big for one mindmap alone.

As I go, new things I have to do _as well as have to store might present themselves. _For now these go in my mind map. But wait... Isn’t that a slight contradiction? I mean GTD clearly separates actionable from non-actionable material, and I have a workflow tool in OmniFocus. Shouldn’t ‘things to do’ be going there?

Well yes, but I’m currently mapping everything out in my head, I don’t know what my actions even are and I don’t want to lose flow. Batching and flow trumps everything in my opinion.

Where my digital system saves me is by offloading this maintenance effort. I use Freemind to dump everything new, whether it’s a step to complete or just reference info. When I’m finished, I simply:

  • Create a project corresponding to the JIRA in OmniFocus.
  • Cut all actionable items from my mindmap.
  • Paste them into OmniFocus.
  • Sort the natural order of that list and fill in any gaps.

I get the best of both worlds this way. I don’t lose my flow defining what the project work is, I simply separate identifying items from organising them. Remember that Evernote stat on context switching every 3-5 minutes? We can avoid context switching this way.

Once the actions are in OmniFocus, the act of sorting and ordering might well identify new gaps, so they go straight into OmniFocus. I'm left with a mind map that correctly just contains reference information, and I maintain workflow steps in OmniFocus from them on. Finally, I link this project in OmniFocus back to where the mindmap lives on the file system. Let’s move one level lower next, when we’re actually coding.

Image Description
Written by

James Bowen