Thursday, March 30, 2017

The Bullet Journal

I started something new in February, a bullet journal. I've played with different tools to help me keep organized and remember stuff, and this is my latest.

I went back to using paper over electronic tools for notes over a year ago based on research that showed you remembered things better when you took notes the old fashion way. Even then, I wasn't sure of the best approach. For a long time I was using standard legal pads, but I didn't want to take them with me when I traveled. I had a small organizer that allowed me to put paper in and out. I had tabs for different projects and clients but I found I was flipping pages to much.

I've adopted a way to combine the legal pads and my bullet journal. I still keep a legal pad at my desk and write down about everything. At the end of the day, I review my notes and copy everything over to my bullet journal. This serves as a review, makes sure I don't forget any action items, and gives me a chance to jot down some reflections at the end of the day.

I am using a Moleskin 5x8.5 dot grid soft cover notebook and a set of Sharpie fine point pens in 4 colors. I use different colors when I change subjects or otherwise want to highlight an idea. I have pages to capture books/movies/music I want to get, a page to capture things I'm grateful for, and a page where I have a year-long calendar.

We'll have to see how long I keep this up. I've got the book "The Doodle Revolution" sitting on my bookshelf, maybe I need to dust it off so I can add doodles to my journal.

Wednesday, February 08, 2017

The Canvas Strategy

I’m making my way through the Tim Ferris' book Tools of Titans. It’s well over 600 pages but it has a lot of useful, interesting advice, though I'll admit some of it is a bit out there. He breaks the book up into three areas; Healthy, Wealthy, and Wise. The book is really just a summary of podcasts done over the years with some other advice added in.

One piece of advice I appreciated is what he called the canvas strategy. The idea really came from Ryan Holiday. The name refers back to when apprenticeships were common; a budding  painter learns his craft by serving under a master and doing such things as preparing his canvas. 

In today’s terms it’s about serving the people you work for…sounds like servant-leadership! Some examples he gives includes ideas such as giving your boss an idea you came up with and not looking for credit or finding out the job no one else wants to do and taking it on yourself.


This strategy will accomplish a number of things. It will keep your ego from getting to big.  As you make those around you successful, you will also become more successful; the adage "a rising tide lifts all boats." Finally, if you're feeding ideas to your boss, or coworkers, then you will start steering the direction they are going.

Tuesday, October 11, 2016

How to Measure Value

Agile is about delivering value, so it is important to understand the value you are delivering within an iteration or release. However, I seen many teams that focus on how many story points they deliver but not really thinking about the value of those story points.

So are there ways to measure value? The answer is, of course there is. One way would be to use the Planning Poker approach, but instead of estimating the effort for each story you can estimate the value of the story. In this case, the team doing the work would include the product owner, any sponsored users, and other users or subject matter experts. Just as you would start with estimating effort, you would pick one feature or user story and assign it an arbitrary value, such as eight points. Then you would go through and assign values to each of the remaining features or user stories relative to that one.

From here, there are a couple more things you can do to refine your value measurement. One approach would be to divide the value of a story by the story estimate. For example if you had a three story point story with a value of three, you would have a feature of 1 value point/story point. Likewise if you had a one story point story with a value of three you would get a answer of three value points/story point, which would indicate that this would be a more valuable story based on the value per points.

Another approach would be to calculate the cost of each user story. If you have a team that is pretty stable you can estimate how much it cost to perform an iteration. You should also know your velocity, so it's a simple math equation to come up with your cost per points. So for example if you had a five person team and average cost per person of $200/hour, you work that out for a two-week iteration you're looking at $80,000. if your velocity is 50 points then your cost per store is $1600 so an eight point story would cost $12,800.

So these are just a couple ways in which you can measure the value of what you're delivering. You could do something as simple as the T-shirt sizing approach, where a story may be small, medium, large, or extra-large in value. In any case you should look at someway to ensure that you are measuring the value you are delivering and not just the effort being completed.

Friday, July 29, 2016

Empathy Mapping

I ran an exercise at the beginning of a new project last week; Empathy Mapping. This is part of an overall approach of using Design Thinking along with agile development.

The idea to empathy mapping is to get to understand your users. Per the diagram below, you want to get an understanding of what your user thinks, says, feels, and does (though I have seen other examples that are slightly different than this). You would do this mapping for your main users for your product or the problem you're trying to solve.



To do this, you first want to identify the roles you are going to map. For each role, give them a name to personify it more. So don't call it Budget Approver, call her Laura. Draw out your map on a flipchart and draw a little sketch on Laura in the middle. Have the team talk a little about what Laura does, then have them start capturing these ideas on post-it notes and putting them on your flip chart. What you get is something like this:



Going through this exercise will help make some discoveries about what your users are going through. You can take this as a first step in identifying pain points; things you want to solve with your solution, but don't go into solutioning just yet. Take the observations and identify the themes that pop out. You can apply Affinity Diagraming for some structure if needed.

So now you are ready to get to insights. What does this really mean? Maybe it's time for the 5-Whys to help understand the situation. This is really the problem we're trying to solve. Now it's time to start discussing solutions.

As you get into development, don't throw out your maps. Keep them posted on the walls in your team room. As you are making decisions later in the project, they may help guide you.

Friday, July 08, 2016

Personal Design Thinking

I'm currently reading the book Design the Life You Love by Ayse Birsel. The book takes a look at Design Thinking and applying it to your own life. It is based on the success that the author has had as a product designer.

The book takes you through a four-step process; Deconstruction, Point of View, Reconstruction, and Expression. She uses examples from her own design career to help illustrate the steps of the process. 

In the Deconstruction phase, there are exercises to break your life down into some of its pieces. For example, in one exercise you start with the number of areas including family, work, friends, and hobbies and break those down into more meaning for you. It's really just a mind map that you're trying to create. 

The section on Point of View is meant to help you try to look at things differently. For example, she talks about how Steve Jobs looked at a rice cooker with a magnetic power cord and thought that would be a great idea for a laptop. The idea is taking something in one context and moving it to another context. 

Reconstruction is taking the pieces that have been identified and put them back together in a different way. 

Finally, Expression is about how you externalize this effort. There are some different ideas including vision letters and vision maps. 


This really is a workbook that you want to spend time on every day to go through the exercises. I would not recommend getting the book in an electronic format, it is much more practical to have the physical book that you can draw in as you go through the exercise. There are some exercises that involve drawing, mind mapping, etc and throughout the activities, you want to go back and review earlier work. 

I'm working through the last section, so I don't know how it will all turn out, but I have had some valuable insights. The book is laid out logically and it does get you to think. 

In closing, there is a quote from Ralph Caplan, author of By Design;

When it comes to life,
There is no such thing as design
There is only redesign

Monday, June 06, 2016

Ready Ready

I heard the term "Ready Ready" being used at work last week. I've heard of "Done Done" but this was a new one on me.

I remember the first time I heard the concept of done done. When a developer finishes coding, the story is done but not done done. There are a number of other steps that have to be completed before it is really done, that is done done. The team should come up with the definition of done at the start of a project. Typically it's things like coding is finished, unit testing was completed successfully, and the story was accepted by the author.

But how do you know when something is ready to start, when it's ready ready? Do you have a definition? I've seen where the work can get delayed when a story is brought into an iteration when it isn't ready to be started on for various reasons. In order to avoid problems with getting the work done in each iteration, the team should have a definition of when a story is ready to start.

So here are some ways to make sure your story is Ready-Ready:
  1. Ensure the story and acceptance criteria are clear. The story should be in the proper format of As a I want to so that .
  2. The size of the story is small enough to be completed within the iteration. If the story is to large, the team should look at breaking it up into smaller stories.
  3. There is obvious user value.
  4. The story is immediately actionable, meaning there aren't dependencies that aren’t ready. If your story requires some yet to be completed action from another team, you don't want to include it in your iteration until that action is complete.
Making sure your stories are ready to start before including them in an iteration plan helps ensure you don't run into problems during the iteration. One approach to this is to hold a backlog refinement meeting. This could be done near the end of the current iteration as a way to check the potential stories for the next couple iterations. This way, if a story isn't ready ready, it gives you a chance to get it ready before you get to the iteration planning meeting.

Taking this approach is a good way to ensure you are ready-ready.

Tuesday, May 31, 2016

Empathy and the Sponsored User

Empathy is an important attribute in Design Thinking. In order to solve our customer's problems, we really need to understand them. We need to walk in their shoes. But there's a limit to how far we can take this. We can spend hours talking to an astronaut, but we will never truly understand what it's like to walk in space.

Agile has this idea of the Product Owner, but you don't see much written in agile about empathy. One approach that can help you get past the empathy hurdle mentioned above is to find a key user (or users) to be part of your team. Some organizations call this a Sponsored User, the organization leading the project sponsors this person't participation in order to get their direct input into the product.

The sponsor user becomes one part of the multi-disciplinary team. Their input is important, but it isn't the only input. While they may understand the customer perspective, you need to balance all the project constraints, especially the time and cost it may take to implement some of the sponsored user's ideas. Don't lose sight of your minimal viable product (MVP) in trying to make the sponsored user happy.

You may also have more than one sponsored user, depending on the breadth of the solution you are trying to provide. If your current release has two or three major themes or epics, you could have a different sponsored user for each epic. Contrast this to the idea of having a single product owner responsible for the overall solution.

So when empathy isn't enough, make the user part of the team in order to keep the direction of your product moving the right way.