Upstart

One of the most read articles on this blog is my 2010 post Introduction to Minimum Marketable Features (MMF). Today an interesting question from Kevin Patrick of www.knowledgehut.com was added asking if any of the readers had a simple method for applying t-shirt sizes (xs,s,m,l,xl etc) to stories in order to infer the size/complexity of a story. I added the method that I’ve found to work as a comment and thought I would expand that comment out into a new post.

The big problem with any kind of size estimation is that one mans hill is a another mans mountain, therefore using a fixed value like time often produces mixed results. For example an experienced developer who’s been working on the product for years and your new intern are likely to give wildly different estimations on the same feature if asked to make a time based estimation. To get around this problem it’s popular to use relative rather than fixed values, with the most popular system being t-shirt sizes as it’s an easily understood metaphor that doesn’t require much explanation, even here in Cambodia.

Being involved in several software startups has it’s advantages, one of the big ones is that I oversee around half a dozen teams to am able to quickly test new ideas. I’ve played around with t-shirt sizes a fair bit for these teams and have found a solution that seems to work well. I always begin by asking the team to take a story from that backlog that is of average size and clearly understood in terms of scope and complexity by **ALL** of the team. This “yard stick” story is very important as in the beginning it will be used as a reference point when estimating other stories in the backlog.

Once we have our yard stick story we then explain to the team that this is considered medium and then go on to explain what the other t-shirt sizes mean in relation to this one. We say that a “large” is double the size of a “medium”, a “small” is half the size of a “medium”, an “extra small” is half the size of a small and an “extra large” is double the size of a large. We also have a rule that if in doubt we always round up, so for example if the team is unsure whether the story is a medium or a large, then it’s rounded up to a large.

I tell all of the team to use their initial gut feeling and not to over think it. If there are some wildly different estimations coming from different team members, for example one says “small” the other says “large” I ask each member to explain the reasons for their estimation until the team reaches a consensus.

This system makes the process of estimation extremely quick as it can be achieved with a series of yes/no questions. We hold up story A and ask “Is story A double the size of story Z” (with story Z being our yardstick), if the answer is yes, we then ask the question “Is it more than double the size of story Z”, if the answer is also yes, we then ask “Is it four times the size of story Z”, if the answer is no, we then mark the story as a “large” and move on.

This may seem like the kind of exercise that you would give to kindergarten children, but anyone who’s experienced the pain of sitting through estimation sessions that often descend into petty arguments and that can drag out for hours will appreciate the simplicity of this system.

Some teams have trouble moving away from long drawn out debates about feature size and instead trusting their gut feeling, for these types of teams you should either time box the estimations sessions or as I prefer, do the estimation sessions as a stand-up meeting.

So to cut a long story short, I made the trip over to Vietnam for a few days to present on lean startup at Agile Tour Ho Chi Minh City on Sunday and then on Monday & Tuesday check out Bas Vodde’s Scrum Master Certification course.

After an entertaining Agile Tour Zichuan Xiong (Thoughtworks), Stanly Lau, Steven Mak ( both www.odd-e.com) & myself headed out into the backpacker district for some beers, it was there that after a few drinks my bag containing my laptop was stolen while I answered a call of nature. I was careless, so really I have no one to blame but myself.

The guys tried to cheer my up, but obviously I was pretty bummed about the loss and was of course turning over in my head the ramifications of the theft by trying to think if it contained any data like passwords that could cause further damage. Luckily we now live in a world of cloud computing so loosing a computer isn’t the disaster it once was, all of my files are in Dropbox, all of my work in version control. So fingers crossed, I change a few passwords and this is nothing more than a physical loss.

The next thing to enter my mind was what to replace it with, we’re not even halfway through the next beer and Zichuan is trying unsuccessfully to convince me to ditch Thinkpad+Ubuntu and get a Mac. I go to bed that evening with my thoughts split between cursing myself for being so careless and thinking about whether to go for another Thinkpad T520 or go for the smaller T420 and the merits of solid state drives.

The next morning I awoke in the hotel with a slight hangover and the realisation that I’m completely disconnected, my phone battery is dead, the charger was in the bag and obviously I don’t have my laptop. I can’t even send off a tweet to inform the world of my loss. Feeling down and somehow naked without internet access, I decide to hop on the next bus back to Phnom Penh.

Despite the negative events of the evening before, the bus trip was great. Without internet, ebooks, music or a phone I spend most of the time just staring out of the window looking at Vietnamese & Cambodian countryside which is so green, wet and stunningly beautiful this time of year. At the rest stops instead of having my head buried in my Nexus S checking my Twitter time-line I struck up conversations with other passengers on the bus and got to hear about their travels, these conversations took me back to the days when I was backpacking around this region and the freedom I felt during that period of my life. The six hour journey which I usually loath turned out to be quite pleasant and at the end of it I felt refreshed and positive.

Upon arrival at my house, after saying hello to everyone and giving them the story, my next port of call was my desktop. Almost as soon as I turned it on and looked at my near bursting inbox there was a power cut, it was if the gods were trying to tell me something. With the power out, I spent the next hour with my two year old daughter watching her unsuccessfully trying to teach the cat the same tricks the dog knows.

A disconnected day that occurred under the worst circumstances has now got me questioning the value of being over-connected. I can’t remember where I read it, but I recently heard the argument being made that knowledge acquisition in the information age is like trying to drink from a fire hydrant. Information is the modern day calorie, we’ve gone from a deficit to an unprecedented surplice and without self-control we risk turning this positive development into the mental equivalent of the obesity epidemic.

Laptop computers and smartphones are the facilitators; how many of us sit on the bed in the evening tapping away at a laptop instead of talking with out other halves about the days events? How many of us during family dinners have our smart-phone out under the table making sure we’re up to date with events on the other side of the globe that have no impact on our lives what so ever whilst pretending to listen to what the kids are saying about school that day? I’ve done both on more occasions than I care to admit.

So now I’m going to look at the theft of my laptop as a positive. I’m not going to replace it, I’m going to use a desktop at work and I’m going to use a desktop at home. I’m going to turn off the 3G on my phone and if I can’t find the discipline to do that I’m going to get rid of it and buy one of these Nokia bad boys for $18 (http://www.iknow.com.kh/phone/product_sale.php?productid=2222&status=New).

We’re all agile here, we all know multi-tasking when working is bad. If I understand this why do I think that it’s okay to try and multi-task between human interactions in the physical world and human interactions in the digital world? From now on I’m going to try my hardest to exercise self-control when it comes to my connectivity and consumption of information.

There is one school of thought that any activity that is not taking you closer to your goals is a waste of time. To a certain extent I agree, but I also understand that their are many activities that may appear to be a waste of time on the surface that are in fact helping you achieve your goals indirectly.

One such activity for me is reading fiction. You may be asking how as a software developer and entrepreneur my outputs can be increased by reading stories that are completely unrelated to my work? The answer is simple, reading is my disconnect, reading is my off switch.

We’ve all been there, it’s late at night, and after hours of work you’ve gone into that goggle eyed state of monitor hypoxia, you’ve been going around in circles for an hour before convincing yourself it’s time for bed (a decision a properly functioning mind would have made hours earlier). It’s 2am and your know you’ll be awaken an 7.30. A wealth of experience in burning the candle at both ends tells you that any less than five hours sleep means tomorrow is going to be a struggle. Yet despite exhaustion, you lay in bed struggling to keep your eyes closed, whilst your mind is still frantically turning over the days work in preparation for tomorrows assault.

Enter the disconnect. A disconnect is anything that can quickly snap your mind out of work mode and allow it to wind down in a controlled fashion, reading fiction is the perfect disconnect.
Reading a book is one of the few things in this world that requires your full attention and can’t be multi-tasked with other activities. Reading fiction with it’s imagery, emotion and make believe immediately starts utilising the areas of your mind that have been idling during your over extended hackathon while the parts that were red lining are given a timeout. Disconnects are vitally important in maintaining sustainable productivity and avoiding burnout.

I don’t just read fiction before bed, anytime I feel myself reaching the point of mental exhaustion, I walk away from the computer, find a quiet space and begin reading until it’s passed. There are many other forms of disconnects from brisk walks to meditation, but reading is the one that I personally find most effective.

Since the realisation that reading stories is not a luxury that eats into my productive time, but is a disconnect that indirectly increases it, I have started reading A LOT, I now get through two or three books a week! My Kindle is now my number one productivity toy and it goes with me everywhere, always preloaded with two yet to be read books. I must now be one of Amazon’s top customers!

If you want to get the most out each and every day it’s vitally important that you discover your own disconnect and begin using it as an important tool in your personal productivity arsenal.

I’ve now come to the conclusion that generally speaking Kanban isn’t a good fit for software SME’s. The reason I say this is that most SME’s can’t afford to have a dedicated product owner. I don’t include startup’s in this statement as here the lead developer, product owner and CEO are one and the same.

Most Kanban teams I know haven’t come form Waterfall or chaos, they’ve arrived form Scrum or XP, both of which use time based iterations or ‘sprints’. Sprints mean that most product owners will be very busy on Monday morning during sprint planning and Friday afternoon for demo, of course they still need to be around to answer questions as and when they arise, but this is usually far from a full time job and usually isn’t hugely disruptive. This leaves the multi-faceted product owner to focus on other tasks that are vital to a software SME, such as marketing, customer support or whatever today’s pressing issue is in a never ending sea of pressing issues.

The bottom line is that in most SME’s the product owners responsibilities are much broader than simply gathering requirements, feeding user stories to the team and then later signing them off.

The core of Kanban is simple, visualise the work flow, limit WIP and reduce cycle time. Ultimately if you follow these rules it always leads to the same place; very small stories or minimum marketable features that are often completed in hours rather than days and column limits that allow very little wiggle room. These things are great, don’t get me wrong, this is exactly the desired result, stories flying across the board and into production, no bottlenecks where stories are left to fester, teams who are very clear about the task in hand, great. Kanban is the last word in team agility, no question!

The only drawback is that now the product owner has to be constantly on top of the board to maintain flow. The product owner is involved in crafting new stories and signing off existing ones several times per day, although this is not a huge drain in terms time, it’s definitely disruptive and negatively impacts their ability to focus on other none team related tasks which are part of their daily workload.

If someone was to ask me the biggest difference between Kanban and iterative agile methodologies I would say that they both involve exactly the same actions, with exactly the same desired outcomes, except Kanban is dynamic and any action can occur at anytime where as iterative agile techniques group those actions by type and complete each group at a fixed prearranged time.

The question for you as an SME is whether or not you can afford to have a product owner responding full time to Kanban’s demands or you are willing to sacrifice some agility in order to free up your product owner to work on other responsibilities uninterrupted, because they can’t do both.

Today I’m going unveil my own personal agile technique which I use to increase my overall productivity, the technique is still a work in progress so this article will cover it in its current form.

The technique can be used in isolation or can be used in conjunction with macro team level agile methodologies such as XP, Scrum or Kanban and micro level personal productivity techniques like The Pomodoro Technique.

The aim of the technique is to suppress what I believe to the be the four enemies of personal productivity:

• Multitasking
• Working without a clear objective
• Burnout through not knowing when to stop
• Inventing things to do to avoid the important

To fully embrace the Daily Mission Technique you need to fundamentally change the way you think about work. You need to stop focusing on time and start focusing on outputs. Instead of approaching a work day by deciding try and do as many tasks as possible in a fixed period of time you need to start trying to do a fixed number of tasks in as little time as possible. The change sounds slight, but the effects can be dramatic.

When using the Daily Mission Technique time becomes the carrot on the stick, it’s the reward you are given upon completion of your objectives. Using the traditional method of working against a fixed period of time removes the incentive, when we complete a task more quickly and efficiently our only reward is another task, whilst with the Daily Mission Technique we are credited with free time which we can spend as we see fit, guilt free.

I developed the technique during the six months which has been an extremely hectic period of my life, I’m involved in three separate startups, one social enterprise and am supervising the construction of my new house. This period has personified a pattern that has plagued me for years, massive bursts of productivity followed by equally massive lulls of inactivity.
The pattern always played out in the same way, some event would capture my imagination and I would work every hour available until I burned out, then I would hit a lull that I struggle to climb out of until some new event captures my imagination and the cycle repeats itself.

I also noticed another pattern, it seemed that increased workload actually decreased my outputs and increased the height and depth of these peaks and troughs. I’m sure this is due to increased procrastination, added temptation to multitask and continually working to the point of fatigue.

The Daily Mission Technique has helped me to break the cycle and transform the peaks and troughs into a much flatter line with continued consistency.

The technique is broken into five simple parts outlined below.

1) Mission Planning

Planning for the Daily Mission is as simple as defining the primary and secondary objective. Planning should not be completed on the same day as the mission and not before the previous mission has concluded. This leaves a window between the completion of the current mission and the end of the day prior to the next mission to set your next primary and secondary objectives.

The reason for this is clarity and discipline, it’s often at the end of the current workday that you can be most sure of what the next most important objectives are, also a significant time gap between planning and beginning the mission reduces the temptation to choose objectives which you want to complete rather than the ones you need to complete.

2) Primary Objective

It’s name is self explanatory, this is the all important objective of the day, the objective that you must do everything in your power to complete; no excuses. To finish the day without having completed your primary objective is a failure and a wasted day. Whilst to complete your primary objective is a success and whatever else happens, whatever distractions may arise to prevent you getting anything else done, you can go to bed on this day guilt free, comforted by the fact that today you took another step in the right direction.

3) Secondary Objective

The secondary objective which cannot begin until the primary objective is complete and is the difference between good enough and exceptional, the difference between guilt free and true satisfaction. Think of the secondary objective as a bonus prize, the extra push that when delivered consistently can turbo charge your progress. A day where you complete your secondary objective is not merely guilt free day, it’s an achievement. Something to be celebrated, something to strive towards each and every working day. These are the days that make the difference between success and failure in the realisation of your dreams.

4) Analytics

Progress tracking is a vital part of the Daily Mission Technique, it’s important to be aware of your track record so you can easily spot negative trends and periods of inactivity. The Daily Mission Technique uses a daily percentage score with 100% being a perfect day and 0% being a complete failure. The numbers are also aggregated into weekly, monthly and all time scores so that you can observe trends on a larger scale.

The 100% score is made up of five requirements each worth an equal 20%, as follows:

• Prior Mission Planning (20%)
• Starting Primary Objective (20%)
• Completing Primary Objective (20%)
• Starting Secondary Objective (20%)
• Completing Secondary Objective (20%)

You may question why starting and completing an objective hold equal weight? The answer is simple, in my experience the most challenging part of a task is often mustering the motivation to begin, especially when the task isn’t particularly interesting. This is the point where lulls of inactivity usually begin and the scoring system reflects that.

5) Retrospective

The retrospective is your chance to evaluate the days mission. If you didn’t reach 100% this is your chance to establish the reason why. Was it due to underestimation, fatigue or other distractions? Once you have identified the problem you should then think about how you can prevent this from reoccurring tomorrow. For example in the case of fatigue we could try decreasing the size of the objectives, going to bed earlier, not going to the pub tonight, completing only the primary objective for a few days or taking a day off. The purpose of the Daily Mission Technique is to creating and maintaining a manageable momentum, rather than trying to cram the most we possibly can into every waking minute followed by the inevitable burnout. A rolling stone gathers no moss.

Summary

Once you start using the Daily Mission Technique you will soon realise that the number of hours you work decrease while your outputs and the value of those outputs increase as you trim the fat by replacing general activity with focused productivity.

FAQ

Where does Daily Mission fit with other agile methodologies?

I use the technique primarily in conjunction with Kanban. Stories or minimum marketable features almost always require more than half a days worth of input. I break these stories into smaller parts and use those parts for my objectives. That same can be done for XP or Scrum.

Where does Daily Mission fit with other personal time management techniques?

I often use it in conjunction with the Pomodoro Technique, I simply estimate and break the objective into 25 minute pomodoros and continue as normal. The Daily Mission sits nicely between a macro level methodology like Kanban and micro level time management technique like Pomodoro.

So here it is, my first stab at podcasting. I’ve learned a lot in the last 24 hours, like that fact that I say ‘erm’ and ‘okay’ at every point where a comma would belong in a written sentence.

Today’s topic is the Pomodoro Technique and a bunch of hacks that I use to get the most out of it. The cast assumes that you’re already using the technique, if not go check it out – www.pomodorotechnique.com.

Podcast Feed: http://upstarthq.podomatic.com/rss2.xml

Is it just me or is the story about the waterfall being bad and agile being good starting to get a little old? Maybe I mix in the wrong circles, but I don’t know a single company still using the waterfall. I only see software companies that use a flavour of agile or follow method-c (chaos). The waterfall’s no longer relevant, so why do I still hear about it so much? It’s like a broken record.

Our industry is already past the waterfall and we’ve now entered the reign of the agile native. Developers that have never known anything but agile. I know because I’m one of them, and so are the dozen people currently in the lab with me. Not one of us is over the age of thirty.

We still like to sit around the camp-fire sometimes and have first generation agile immigrants tell us tales of hardship and woe from the old-country, but they are just that, tales. They hold little relevance to our current day to day problems and hold less relevance with each day that passes.

Admittedly every hero needs a despicable villain to accentuate their own greatness, but it’s time to accept that the waterfall, our arch nemesis bit the dust years ago and all of us standing around in a circle kicking a corpse is not doing our cause any favours.

If we really must have an arch rival to attack then let’s start attacking method-c. Thanks to it’s ability to do a pretty good impersonation of agile, it’s a far more challenging and deserving opponent. I mean, it’s very difficult to sell agile to a team if they already think they are agile.

I just read an interesting post titled Why We Don’t Write User Stories Anymore on Pawel Brodzinski’s blog. As the title suggests he’s stopped doing user stories in favour of MMF’s, this was interesting to me as I’m of the opinion that the two aren’t mutually exclusive and in fact should be used in unison.

User stories are simply a writing style, a style where a specification is written from the users perspective as opposed to that of the developer or product owner. The advantage of this approach is in keeping the team focussed on value generation.

MMF is also focused on value generation, that’s what the second M is for. If something isn’t marketable to your customer then it has no perceived value, raising the question of whether it’s worth doing at all. But unlike user stories MMF is a state, not a writing style.

You see a story is evolutionary, it has a life cycle and passes through numerous states on its journey towards completion or the scrap heap. They usually start as an epic, some huge story with so little mental investment that it has nothing more than a name. Names like ‘Android Version’ or ‘Maps’ sitting precariously as the foot of the backlog.

Given that no one has a change of heart, as the stories above them get picked off, these epics creep up the backlog until the day that they’re so high they can no longer be ignored. They now get treated to some additional brain cycles and are broken down into a series of smaller stories, at this point the stories tend to gain some extra meta data in the form of a description or if you are of the BDD persuasion something in the following format “As a X, I want X, so that X”.

The lucky ones will eventually make it to a sprint planning meeting or the planning column of a Kanban board. At this point the story is split and broken down into even smaller stories, we use MMF as a benchmark in this process, a thin red line that we shouldn’t cross.

The story has now reached the critical stage in it’s journey, it’s now an MMF, it’s now important, it’s now a first class citizen and it is now that it will be showered with attention by the team, product owner and stakeholders. Decorated with well crafted acceptance tests and sent on its way to begin it’s glorious journey towards deployment!

Today the subject of time sheets reared its ugly head. Someone was actually trying to make the argument that time sheets had a role to play in an agile organisation. In my opinion once you’ve reached the point at which you’ve so far distanced yourself from value generation that the metric used to gage performance is time, with no relation to throughput or quality, then it’s time to scuttle the ship.

I would rather have one employee who turned up for an hour each day and added real, quantifiable value than ten staff who put in eight hours of time wasting crap. You know who I’m talking about, they make up 80% of the work force!

Tracking time is only acceptable when it’s measured in context, for any business involved in production that context should be value generation. Scrum and Kanban already have this covered with velocity and lead time,  both use time but the key difference is that value generation makes up the other half of the equation.

If for billing purposes you need to figure out how many developer hours have gone into a project, then take the number of people on the team, the start date and the completion date and do the maths. Don’t subject the whole team to accounting for every minute of every day, it’ll do nothing but create mindless drones and mountains of hugely inaccurate data.

If that maths is too complex because you or your team are juggling multiple projects at the same time, then stop and repeat after me; multi tasking is bullshit. Take one project and see it through to completion then start the next, if you have three months to complete two projects, then spend six week on one and then six weeks on the next, do not run them in parallel. Switching between tasks generates waste, time sheets generate waste, waste + waste does not equal agility!

All agile development methodologies share one thing in common, they break big features into smaller features and sort them based on business value. Sounds easy enough right? Well yes and no. Behind this simplicity is the complexity of how and where those splits are made. In my experience, the key to successful splits or dissections lies in knowing along which lines to make incisions and knowing when it’s time to stop cutting. MMF (Minimum Marketable Feature) helps us in both departments. Let’s break it down into its component parts.

Minimum

If a split would result in a story so small that it couldn’t be marketed to your customers, then the split shouldn’t be made. To help with this decision I always ask whether this feature would justify its own bullet point in an imaginary customer email summarising the features of a new release, if the answer is no, then don’t split it.

MMF only prescribes the desired size of a feature at the time we start work on it. Usually each MMF is the descendant of a series of larger features. Features that we’ve broken apart in order to give more detail as they ascended the backlog, indicating their growing importance. For example a feature called “geotag photo” is a descendant of “photo sharing”, which in turn was a descendant of “iPhone client”, which again was a descendant of the original feature called “mobile support”. The feature “mobile support”, “iPhone Client” or “photo sharing” may no longer be in the backlog, but dozens of their decedents are. This is the evolution of a feature, where by the addition of greater detail is organic.

Marketable

Ask yourself whether the feature is marketable. If the answer is no, then you should probably give it the chop as it creates no additional value for your customers. Steve Jobs and other visionaries have the ability to know their customers needs before they know it themselves, but for the rest of us mere mortals, creating features that don’t create recognised customer value should at the very least trigger red flags, flashing lights and loud sirens.

Feature

A feature is demonstrable behaviour of the product. For example, a feature called ‘shopping cart’ or ’3.5mm headphone jack’ are acceptable whilst ‘design database schema’ or ‘injection molding research’ are not. Although ‘database schema design’ or ‘injection molding research’ might be valid and necessary activities, they are not features in their own right, they are things that may need to be done in order to implement a feature, there’s a difference.

MMF Smells

• The MMF is too small to inform your customers about
• The MMF has no demonstrable value for your customers
• The MMF appears outside of the top third of your backlog
• The MMF can be understood by domain experts but not your average customer
• The name of the MMF is an action rather than a thing
• The MMF you’ve started work on could be split into two MMF’s

MMF Triggers

• Edit Feature: When you find yourself wanting to edit an existing feature, ask whether it would be best split into other features or MMF’s
• Split Feature: When splitting a feature look at its position in your backlog and ask yourself whether it’s too early to be giving this feature extra thought and attention
• Begin Work: When beginning work on an MMF ask yourself if you could break it down further