Thursday, January 22, 2015

What Matters Most?

During this RRSP season, I am left to think about how I plan to be successful as an investor with a vision to become financially independent while I am still young enough to make the most out of it.

To figure out this plan, I have to make a fundamental decision about what is most important to me: do I care more about growth? or do I care more about security?  This decision has to be made with some regularity because life goes on, and my circumstances may change the way I view these two opposing values.  

It is critical though to decide which is more important because this decision will guide the way in which I invest.  If I choose growth, then that means that I must take on more risk and I need to have an aggressive schedule of continuing investment.  I will likely choose investment methods that skew my portfolio more toward equity positions in emerging markets and less towards bonds, GICs and lower interest producing, but safe investments.  If I decide that security is more important to me, my investment methods will likely lean more towards bonds or expensive stock in well established large organizations that produce a lower yield, but won't go away anytime soon.

Different things get in my way too.  In a growth scenario, I will likely need more cash to invest, where new cash doesn't make much difference in an investment for security scenario.

I measure the success of each strategy differently as well.  Growth strategy is measured by a high return on investment, while a security strategy is more focused on consistent portfolio size...some growth doesn't hurt, but it isn't failure if it stays flat.

Disclaimer: I'm not a professional investment advisor, but I get the basics.  This post is more about how to plan strategically within an organization.

Monday, January 19, 2015

There is only one way to ensure you spend less money


Thinking about setting goals this time of year, we tend to do things like say "I'm going to bring my lunch to work every day" because we have a goal to spend less money and perhaps get out of debt or invest in retirement or whatever.  It is a common for people to set targets like this because it gives you the ability to completely control the input that you put into your goal.  If you don't meet your target, you have nobody to blame but yourself.

Individuals do this, managers do this, companies do this.  In my experience, a target like this is a recipe for failure.

The problem is this: I've only addressed my real goal 'incidentally' as I set my target.  My assumption is that if I bring my lunch, I can save about $10 per day which gives me $200 to put on that big credit card bill.  Without a goal to reduce my debt by $200 a month or $2400 a year, I may end up just hating peanut butter that much more with nothing to show for it.

When you set a target, go right at the meat of what you want to accomplish and set that target.  Don't commit to 'how' you're going to achieve it so much...that may change day to day.  Stay focused on what you want to accomplish.

Wednesday, January 14, 2015

Product Owners: You need to tell a story

As a product owner on an agile team, you have a few choices on how you want to manage your product:

  1. React to everything you hear and treat every item on your backlog as a crisis.  Schedule a meeting with your type-A CEO every month and transcribe every rant that he mentions into a notebook and then attempt to be everything to everyone.
  2. Randomly fire ideas into the backlog.  Your development team is just looking for ways to keep busy, so as long as it remotely resembles the last 5 features you built, it's likely going to be a good thing to work on.  Periodically, put things in there that you heard a customer mention during the last quarterly account review
  3. Come up with a vision for how you want your product to evolve.  Identify the two or three types of people that use your product and tell a story about how their lives become easier as we add features.

The last one is the one that development teams really need your help with.  Analytical people like developers tend to jump directly to solution mode and begin to see nothing but trees.  It is the job of the product owner to keep the forest in focus and find the areas that have all the mature trees that are ripe for cutting so that the 'cutters' don't just clear the whole lot.

If a cutter needs to set up a winch to deal with a particularly tricky tree, just leave it to the cutter to deal with while you walk through and mark the right trees to harvest.  If the cutter needs to replace an axe or saw or have them sharpened, you can expect that they will do that first before they go onto the next tree.  Your story is about the mature trees you've harvested...right?

Tuesday, January 13, 2015

Release Planning vs Sprint Planning

In software development, you can't really get much done unless you plan.  But it is important to understand that there are different types of planning.  And as there are different types of planning, there are also different methods and measures used for each.

Release Planning
For agile shops, the product owner is responsible for the release plan and priority order of the overall backlog.  The backlog is a list of features that are very high level and represent actual value to the customer.  Each item on the backlog represents something that they would like to tell customers about that would make them want to buy the software.  Each item that gets delivered on that backlog represents a conversation with one or more customers and the idea is that those conversations result in sales.  If you talk to the sales people in your organization, they'll tell you that conversations that don't result in sales are the wrong conversations.

So, when we look at release plans, we need to have some idea of how long it will take to get to various points in the priority list.  If a feature is 10th most important, but we know that it will take 2 years before we finish with #9, then it tends to change how we think about our product strategy and we may decide that 10 is really more important than 5 if we want to avoid becoming irrelevant.

To do this, teams will go through some sort of high level estimation.  Most teams these days use what we call 'story points' in estimation.  They are the 'relative' size of features from their peers on the backlog that have a loose ranking to distinguish their size.  Lots of teams use a fibonacci sequence for sizes (1,2,3,5,8,13,21) in an effort to avoid mathematical equivalents to time.  They are not meant to be exact, they are a best guess given the limited amount of information that a team has at the time.

So basically, the release plan will look at the rate in which teams are able to cross things off this list in short iterations and use an average for each short iteration to take an educated guess as to how many items can be crossed of in a given amount of time, or basically in a certain number of iterations.  This 'rate' of completion of the backlog is often referred to as a team's velocity.

Sprint Planning
A lot of people tend to look at a sprint backlog as a subset of a release backlog.  This notion is only partially true.  Most teams don't get to spend all of their time working on features on the backlog...in fact, once you make your initial release, you can expect that your team will likely need to split its focus in at least equal measures between the backlog and supporting existing customers (fixing bugs, investigations, usage reports, etc).  Even before you release, the team often has to spend time doing things like planning, code reviews, setting up equipment, explaining things to salespeople, helping with power point presentations, you name it.  All of which is important, but slows down progress on the backlog.

Since none of these other things are part of the story that the product manager is going to tell customers, then they don't have story points, only the features in the backlog have story points.  For this reason, story points don't make a very good primary input to sprint planning.  They make a decent secondary input as a 'gut check' to ask ourselves questions if we can do more or perhaps we have too much, but most teams that plan their sprint need to account for their time a little more closely in order to have a realistic plan.

I recommend that for sprint planning, teams break down all their work for the sprint into tasks and estimate each task in hours to help them figure out realistically what their capacity is for a sprint.  This doesn't have to be very exact, just rough math will do.  Break down tasks into 4 hour chunks..no less.  Determine how long your sprint actually is, times the number of team members and include vacations, holidays, doctor's appointments or whatever in your tally and try to not exceed 70% of the total number of hours available for all the tasks.

After you've filled up your tasks and added or removed stories or activities to flesh out the plan, total up the story points and ask the question "Does this reflect our average velocity?" and if not, figure out why.  Not matching on average velocity is totally ok so long as you are working on the most important things in your sprint.  If your velocity is lower than average, find out if there are things in your sprint that can be deferred.  If it's really high, make sure your sizing is right and that you've properly identified all the tasks....don't spend too much time on this...just make sure the team all agrees that time is not being wasted.

Relating Sprints to Releases
When you have completed your sprint, you will have burned down most (if not all) of the tasks and if all went well, many of those tasks were part of stories on the backlog.  If we make the assumption that the team made good decisions about what to put into the sprint, then the only thing that is important about the sprint is that progress on your tasks was not detrimentally impeded and that you were able to complete what was committed to.

As a secondary measure, we should look at the number of story points that were completed in the sprint.  Remember though that all of that important work that was done in the sprint may not have story points associated, but was important none the less.  You can't make a linear relationship between the number of points earned during the sprint and how much important work was done.  All you can do with story points is determine how far down the feature backlog you were able to go.

Some other assumptions have to be made here:

  1. You should assume that if in a sprint, you had other important stuff to do that kept you from working on features, that you will likely see more of the same in the next sprint or sprints.  
  2. You should assume that everyone was engaged and working as hard as they should be, and
  3. You should assume that we were working on the most important things
Assuming these things, you have the ability over time to average out your story point velocity and have a good idea of how many iterations it will take you to get to any point on your backlog.