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 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 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.

Thursday, November 6, 2014

Velocity vs Capacity

Interesting to watch teams as they plan for a release and attempt to keep their 'velocity' constant as they move from release to release.

In my mind, teams need to strive to increase velocity.  This doesn't mean that I don't think they are working hard enough or that I think that people need to work longer hours.  In fact, I'm sure we have all heard the phrase "work smarter, not harder" as we've progressed through our careers.

I watched a bunch of people present a release plan this week and I saw something interesting.  Teams explained how the plan that they were presenting was right because the velocity was either the same as last release, or explainable as to how it was different.  This highlighted for me that there was a fundamental disconnect between a teams velocity and their capacity.

As a startup company, velocity and capacity are often the same since teams don't tend to have distractions other than getting V1 out the door.  After V1, teams are often distracted by customer issues, internal meetings, audits, reviews, you name it.

Capacity is how much work a team can get done.  It's an input.  Assuming I have the same number of people and the same amount of interruption, I should have a constant capacity.  My Velocity however is the portion of that time that I am actually executing against the backlog of stuff that actually holds value to my customer.  It is what I output.

If we are actually doing our jobs, we are reducing distraction and increasing our velocity from sprint to sprint and increasing the rate in which I provide value to my customer.

Wednesday, July 31, 2013

Don't Miss Retro

Scrum is a very lightweight development methodology.  The idea behind scrum is to be as lightweight as possible with maximum communication.  There are a few meetings to be had in scrum, but only a few...10 minute daily meeting of all team members, 30 minute demo per sprint to all stakeholders, 30 minute planning session at the beginning of each sprint and a 30 minute retrospective at the end of each sprint after everything is done.

I've heard comments from teams over the years where people tend to complain about some it is the biggest waste of 30 minutes in the whole process.  I think the reasoning behind this is that teams tend to re-hash the same topics over and over again and they never seem to get resolved.  I can see the frustration with this, but not discussing issues doesn't make them go away.

Here are three things to try for more effective retrospectives:

1.  Get Everyone Involved

Retrospective should never be the scrum master or the resident nit-pick rambling on about how bad everything is.  It has a format, and it should be followed...every time: Did Well/Do Better/Stop doing.

I see retro's deteriorate into 'What went well?...hmmm...well, we worked really lots done...that was good...'  This isn't helpful...atta-boys come on payday. 
  • Encourage everyone on the team identify the one thing that works that we need to keep doing, and discuss if it's possible expand into other areas to improve other areas.  
  • At the very least, get everyone on the team to suggest one thing that the team could improve on to be more productive...creativity is critical here.  
  • Be critical of process and get people to examine one aspect of the process that everyone just does without thinking that doesn't really provide value and discuss ditching it.
Agile teams are intended to be self managed.  A manager's job is to ask questions like these every day, so it's now the team's job to do do it.

2.  Time Box The Meeting

Get someone on the team to mark the start time and stop abruptly at a pre-determined stop time...even if you are in the middle of a heated debate.  The meeting should never exceed 30 minutes, so do some quick math before you start to determine each member's time slice and stick to it.  If more discussion is needed on any topic, add it to a 'parking lot' list and set a time for another team meeting at least 24 hours earlier.  Give people a chance to think about it and time box that meeting too.

I've seen retro's go on for hours as finer points are debated which just adds to team frustration when things don't improve.

3.  Set Goals

Make sure that when the team comes up with an action item, it should be tied to a desired outcome.  Don't just set rules for the team to follow that don't add any value.  Ask yourself, 'Why would we do this differently?'  If you can't come up with a measurable outcome, then perhaps it isn't something that the team should consider.  This is harder than it sounds at first, but it will come with practice.

For example, someone on the team suggests "I've noticed that we all work through lunch and don't take a break...I think we should start to take lunch break every day."  While there is no doubt that this is a good rule to follow, the team should look at the reason this is important in terms of value and try and measure it.  Perhaps the team feels that taking a lunch break will make for more productive afternoons.  Perhaps the team feels that taking a lunch will make the team happier and less 'touchy' in the afternoons.  Whatever the reason, identify it and make it a point to review the 'outcome' as opposed to the 'input' to measure the teams success at self management.

I would even go so far as to say that the retro item be re-worded to say 'Improve the mood in the afternoon by taking lunch break every day'  This may even give another team member an idea of something to try to 'improve the afternoon mood'.

Saturday, April 27, 2013

Too Much Focus - Why Leadership Needs a Broad Lens

People need goals to solve problems, not suggestions.

Consider an organization that builds cars and has problems with the cars that they make consuming too much gas. This overconsumption is making them inefficient, smelly and otherwise poor quality which is impacting their brand and losing sales.

The leadership needs this overconsumption problem solved, so they begin collecting information on how to solve this problem. After research and thorough investigation, they realized that when you drive too fast in one of their cars, you burn more gas. The leadership asks the team how to keep people from driving the cars too fast. They found the simplest solution is to attach a 2x2x4 inch block of wood to the bottom of the gas pedal...a governor of sorts. This 'governor' would prevent the gas pedal from being fully depressed and would effectively reduce the speed that the car would go. After running some tests, they found that indeed, the blocks made the cars go slower, burn less gas, run longer and cleaner and improve the overall quality of the experience...just at a slower pace.

Problem solving at its finest, the leaders begin communicating how the cars go too fast and burn too much gas to the team and that these new wooden blocks are going to save the company from certain disaster. It's hard to argue with the speed/overconsumption logic and of course the test data is right there, so work begins and cars start getting shipped to go slower. Perhaps this will prevent the gas consumption to some degree, nobody is arguing that...but then nobody is really looking at the problem anymore. Instead, innovation gets applied to the problem of how to put the new block/pedal assembly in place as efficiently as possible and save money on this new innovation.

I call the goal of applying the blocks to all the gas pedals an input goal.

OK, I may be guilty of oversimplifying here, but you get the point. We have been taught that as leaders we need to quickly identify problems and just as quickly drive down solutions and get some action. How much innovation did we leave on the table here? Perhaps the guys that build the engine have known for a while that the air intake is too small and needs re-design. Perhaps the guys that make the body know that the material they use is much heavier than it has to be. Perhaps the wheels are too small. Maybe our speed hungry customers climb under to remove the wood blocks from the gas pedal when they get home and wonder what the heck we were thinking.

A good leader will likely keep asking questions and uncover all of these innovative solutions, but a great leader will help the organization understand the problem, set a high output goal and encourage everyone to drive towards it. How about instead of telling the team to apply wooden blocks, we challenge them to reduce fuel consumption by 50% and see what we can come up with.