Problems without Context

Are like pilots without a license.

Sure you’ll probably get there, but…

Will you get there on time?

Will you get there in one piece?

Will it cost you less than an arm but more than a leg?

Will you really know why you are going  there to begin with?

Without context to a problem, we are hoping to solve an issues with an infinite number of variables.  But when we add context to the discussion, when we frame the scope and reach of the problem, the players involved (and the ones that need to be involved) the solutions we come up with shift from being science fiction to now being within the possible.


One Size Does Not Fit All

Have you ever bought a shirt that fit you and given it to someone else who was either smaller or larger than you?

Didn’t fit, did it?

What about following a development pattern that lays out how to build user interfaces on the web while you are building a desktop application?

Probably didn’t fit either, all good ideas, all software, but the fit isn’t there.

What about using a new software methodology?

Agile, Scrum, Waterfall, Lake, River (the last 2 are made-up)…

Did they fit the first time?

Do they apply to your business?

Do they fit within your culture?

There are many ways to solve problems, that is what makes software development such an engaging, enriching and life-committing endeavour where you can learn something new every day and be exposed to a firehose of new ideas on a daily, maybe even hourly basis.

The best part about it – there is not one way or one size that fits all – instead, there are many ways, many sizes that each have their great pieces that we can bring together to make something incredible.

The challenge is knowing and learning which pieces to take.

Knowing is Half the Battle

Three things I learned last week that you can apply to anything, anything in life.

I don’t take credit for any of these, but I find myself repeating them to myself through every interaction I have had since then.  Take a problem you are working on and apply the below.

What you know

Simply put, what do you know about the problem, what facts do you have in front of you that jump out at you as important and frame the view of what is forming the framework of the problem.  The facts, not the emotions and definitely not the assumptions.

What you don’t know

On this problem, what do you not know- what hard facts still remain that you do not know about.  It’s the missing puzzle pieces in the problem that are holding you back and perhaps that is the best way to think about it – “what do I not have, that is preventing me from moving forward.”  Not knowing how to code the solution?  Definitely something you don’t know.  Don’t know how this process works?  Something you don’t know.

What you need to know

What is ambiguous, what is eating at you, what is making your gut say – “no that’s not it, we’re not there yet”.  These are the questions you need to ask next to be able to move forward in the problem and solve for what you do not know.  Do you need to expand on what you know (expanding your worldview and framework) or is where you are enough that you simply need some additional blanks filled in.

And to coin NBC, now you know, three simple questions anyone can remember from sports, to work, to fixing the garage door opener.

You can Chase Waterfalls

I’ve always admired Blizzard’s approach to shipping software – “We’ll ship when it’s ready” – policy to shipping software.

And I love it – I love that the quality and featureset come first to the user – the experience of logging in for the first time to an incredible experience is first and foremost.

But can it apply everywhere?  Can it work in your industry?

Maybe?  At some point in development, Blizzard (and DISCLAIMER – I have never worked at Blizzard, nor do I know anyone from Blizzard) someone is going to start asking – “Guys really, when are we going to be ready, if we’re not going to be done for this XMAS we’re going to miss our window” – they are a business they run in cycles just like everyone else.

So what is it about their fanbase that gives them those two years (with beta cycles both internally and externally) to apply that kind of… dare I say it… waterfall approach to Software Development?  They do patches and tweaks here and there, but there is a plan that they are delivering through, dropping pieces here, there and everywhere but it all culminates with a massive 12GB download onto your PC to play the latest expansion pact.  I’m sure there are any many iterations in between (how could their not be) but what comes out as the final game is usually released in one fell swoop.

And perhaps you’re getting hung up on the use of Blizzard and Starcraft, so take that slogan and apply it to your favourite game that goes into hiding for 4 years and comes out with some in a shrink-wrapped package for you to purchase.  Isn’t that waterfall?

The point – who cares what it is or what flavour of the month it is called, if it followed this or that – every company is different, every company has a twist they put on their development practices.  Figure out what your end goals are, develop a process that hits the mark, try it out, tweak and try again.

Don’t get hung up on what it’s called, call it your own and go out there and build some great software.

Timeboxes are not One Size Fits All

Timeboxes are by definition the goal of trying to complete x amount of work in y amount of time.  When time is up so are you.  They have been applied to all sorts of industries and activities;

  • Software Development
  • Manufacturing
  • Getting Ready for Bed

The goal is to create small enough tasks that the user is comfortably able to estimate and complete in that box of time.  Can you code this in one day or in 1 week.  If you take a look at this definition from Wikipedia you can see how some project styles keep timeboxes quite small – 1 to 2 weeks while others go on for 3 – 4 months.

Lesson #1: The total value of what you accomplish in a Timebox is variable and differs by size and scope of project.

So in essence, what I did on one project for a Timebox I cannot apply to another project (necessarily) and I need to apply some “insight” to ensure that I’m not painting myself into a corner… or a box.

How do Timeboxes handle Scope Creep?  They don’t, Scope Creep goes onto the backlog and it stays there until the next box.  Nothing new here, if you were building a feature in Beta 1 and received some feedback from your trials, it automatically gets punted to Beta 2 (to be built in) and/or if your team judged if valuable enough, you could do it now and push some of other Priority One feature out.

Lesson #2: Timeboxes should not prevent creativity in Software Development.

Although a strict timebox can ensure you ship on time (conceivably) what about the gal who is coding this feature now and it makes sense to fix it now, rather than create an item for the next release?  Why write code that is going to be overwritten in a release?

Alright, so I can be creative (still coming up with ideas whilst I code like a machine) and my timeboxes can be variable, but what about all that ongoing QA work of automation and performance?  How does that fit into the box?

Lesson #3: Timeboxing should not include QA

There I said it.  QA should not include Timeboxing (said it again).  Why?  Because QA should iterating over and over again, finding issues, running test cases in parallel, building up Edge Cases as Happy ones pass – in essence QA is a worm that should constantly be evolving, trying to stay ahead of the game.  Not all Timeboxing includes QA, some do, some don’t – I don’t believe it should.

Any QA team will have a list of test cases they are going to run, the more you touch, the more they test, the more they run and the longer they take.  You can run run as many tests in parallel as you want.  At the end of the day, you’ll realize this to be true when you sit down with QA and you start running through the litany of tests that you want them to run – “oh yeah can you run this suite too, I might have touched something there, and you can write some tests for these paths, I’d be interested in knowing how it performs, etc, etc, etc”.

Time well spent, that cannot always be boxed, but should be correctly estimated.

You probably have very different views on Timeboxing and that’s great and that is the point – there is no one size fits all methodology that works for everyone on every project, take aspects of the best methodologies that you have worked on, merge them together and make something that fits your organization – “WaterFallingDownAnAgilePathToNimbleness” – if it works, go with it.

Welcome to the gray zone.