Monday, May 22, 2017

Estimating

I was flying home from a client visit last week at the airport getting ready to board the plane when the gate agent announced that the flight was gonna be delayed by ten minutes due to some unspecified mechanical issue. Ten minutes later they announcement another ten minute delay. They did this two more times.

So what was going on? Did the airlines not want to admit upfront that they had a 40 minute delay so they fed the delays to us ten minutes at a time? Or did the person who is doing the work really not understand how long it was going to take? I started thinking about how common it is for people to not be able to provide good estimates. Sometimes they underestimate the complexity, or maybe student syndrome sets in, or they're just overly optimistic.

It was ironic, but part of the work with my client that week was explaining the technique of relative estimates using t-shirt sizes and story points. The team I was working with was  new to agile and used to the old way of doing absolute estimates, which as we all know are not as accurate because of things like student syndrome or Parkinson's Law.

So how do we get better at estimating? I think the real question should be how we recognize estimates for what they are. An uncertain prediction of a future event. Even when we use story points, we won't know our true velocity until after a couple iterations when the team has time to come together. At the beginning of the project, we need to recognize how much uncertainty we have. So instead of saying "that will take about 2 months" we should say "that may take 2 months, but it could take as long as 3 months." So we provide not only the estimate but some measure of the uncertainty that goes with it. Similarly, if we think a story might be 13 points, but there's a lot of uncertainty, we should state that and make the story 20 points (or 21 if you're being strict with your Fibonacci sequence). Now if only I could get the airlines to provide a more accurate estimate the next time there's a delay...or at least how certain they are!

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.