Wednesday, May 30, 2012

Squeeze or Slice?

When it comes to planning the scope for an iteration, I generally think of two different approaches: squeezing and slicing. So which one are you? Are you a squeezer or a slicer?

The Squeezer

  • Tries to get as much out as possible in each squeeze
  • Some squeezes go "Splllppppppt!" and hardly anything comes out
  • More oozes out after you stop squeezing
  • You don't know how much the bottle holds
  • Even if you may know the bottle is 8oz, you never know for sure how much is left
  • You have to pound the end and squeeze repetitively to get the last little bit out

The Slicer

  • Each slice is more or less the same size
  • You can see exactly how big the loaf is and how many slices are left
  • Only the supernatural keeps the loaf from running out
  • There are just a few crumbs to brush up after the last slice

As you may have guessed, I'm an advocate of the slicing system. The characteristics mentioned above are maybe a little bit euphemistic because in reality, software projects are not factory baked and sliced bread. They're homemade and each slice is cut individually. When you first pull the bread out of the oven, you might ideally want the bread to be sliced into 10 pieces. However, after the first slice or two, you might find that the bread is heavier or lighter than you thought prompting you to make thinner or thicker slices going forward. If you slice off more than you can chew, it's easy to cut that piece in half and save the rest for later. You don't always know how many loaves there will be before you're done baking and slicing but you always have an easily manageable unit.

I like slicing because planning is "baked in". Each iteration isn't like a spin of the roulette wheel. You can respond to experience and adjust accordingly. And you always have a clear vision of what the end is and when it will come.

Friday, May 25, 2012

Dear Web Designers

If you don't care about responsive web design whatsoever, you may stop reading here.

One of the designers where I work recently shared a link to an article called Responsive Web Design: What It Is and What It Isn’t. It's a worthwhile read where the main idea is responsive design isn't just a method for making your website work on desktop and mobile. It's about making your website scalable so it fits whatever size screen the user has. Rather than "either/or" it's "everything/and."

Reading between the lines and honing in on my own pet peeves, why do so many web designs scale to small screens but not big screens? I find myself growing increasingly frustrated by seeing beautiful web designs with gobs of potential that only fill 1024 of my available 1920 horizontal pixels! That leaves nearly 47% of my screen unused.

This sparked a very insightful (for me) conversation with the designer. The process of scaling a website is generally conceptualized as a one-way process: start big and get smaller. There's no "start big and get bigger." It actually makes a lot of sense to me as a much more manageable process to only go in one direction.

Herein lies my plea: Web designers, please throw out your 960 pixel starting mold. It's outdated. It's time to get a bigger mold.

StatCounter Global Stats has plenty of data to show us why:
Source: StatCounter Global Stats - Screen Resolution Market Share

Source: StatCounter Global Stats - Screen Resolution Market Share

1024-wide resolutions had a huge market share three years ago and it's economically-savvy to design for the market. That market share has dropped consistently and significantly. Meanwhile 1366-wide resolutions have gone from non-existence to being the new standard.

I've done some analysis of the numbers. If you've shopped for a computer lately, you've probably noticed that all monitors are widescreen. Most Macbooks use an 8:5 aspect ratio whereas PC manufacturers have overwhelmingly adopted the 16:9 aspect ratio. Because PCs account for 90% of the market, I've chosen to focus exclusively on the 16:9 ratio. For the three years May 2009 through April 2012, 1024x768 has dropped by an average of 0.64 points per month. Meanwhile 1366x768 has increased by 0.53, 1600x900 by 0.1 and 1920x1080 by 0.14. The numbers are very consistent, aside from a completely bizarre November 2011.

So what size mold should be used now? It depends upon the context, like everything. If responsive design isn't in scope, then leave the mold where it is. If it is, here are some more numbers for you: For the three months February to April 2012, screen resolutions of 1280+ totaled 66.35% of the market, 1360+ were 42.07%, and 1600+ were 14.05%. Judging by the data mentioned in the last paragraph, I say, set the mold at 1600 because that market share has shown steady growth and I think 14% is a pretty big share. After that set the steps at 1280 and 1024.

Update: See how the trends continue for the months May through July 2012.

Thursday, May 10, 2012

One For and Two Against Test Scripts

The following is a follow-up to my own Technical Documentation as Reference Material as well as David Greenlees' "Idiot Scripts".

Several thoughts come to my mind when I think about test scripts written for others to use.

I have at times, even recently, asked other people to write test scripts. Not because I want to use them or have them ready to distribute to someone else but because I wanted to use it as a tool to give me insight their approach to testing. It probably isn't the most efficient method but it was what seemed to be the best solution for the circumstances.

To me the intent of scripts for use by business users or during UAT is basically the same: happy path/positive testing that shows that the system works as expected.

The problem I have with writing scripts for business users is that I expect them to know how the system works and test scripts are a horribly inefficient form of user documentation. Besides it leaves the intent of each step in obscurity. It makes more sense to me to teach the business user how to use the system and then let them use it, whether it's taught through a full blown manual, a help file, a training seminar, or a phone call. If the system is complicated enough that it isn't readily apparent to the average user how to use it they you're going to need some sort of training program regardless so why duplicate effort by writing test scripts?

The problem I have with writing scripts for UAT is the same as I mentioned above but it goes deeper. Some, perhaps most people, might not agree with me. When I think about writing UAT scripts, it gives my heart ethical palpitations! UAT isn't just verifying functionality, it's verifying that it's acceptable. Determining whether the software/website is acceptable is a judgement call that only the client can make. Granted acceptance criteria can be written out and those criteria can be negotiated between the client and the agency but it's still a subjective evaluation when it comes down to it. The specific problem then that I have with UAT scripts is that I, as the script writer, am determining whether the deliverable is or is not acceptable. If the client wants to write an objective set of steps that define acceptability they can do that but that's on them. And if they want to go through some sort of approval process then it just becomes a dog and pony show.

Wednesday, May 9, 2012

What Makes a Leader?

Being a leader is not defined by:
  • Having the highest salary
  • Having a big title
  • Having the most tenure
  • Having an expensive degree or certification
  • Having the most skill and knowledge in a discipline
  • Having the most opinions
A leader is someone who:
  • Motivates others without threats or coercion
  • Can enforce the rules without pissing people off
  • Realizes that you can't always make everyone happy
  • Can discern between best practices and the best for the situation
  • Can see and analyze conflicts from all sides
  • Places the interests of the team above her own
  • Draws out the quiet voices and speaks up for those who won't/can't
  • Is willing to be unpopular but doesn't wear it as a badge of honor
  • Owns his mistakes
In short, a leader is not defined by what you HAVE but who you ARE.

Funny thing is, I can't think of one single word that appropriately describes a good leader other than "leader." On the other hand, if you're a bad leader, you could be described as a jerk or a jackass, and the list goes on. Even if you're the boss that doesn't mean you're a leader. Being bossy is just an adult synonym for being a bully. A good leader shines with Honesty, Integrity, and Respect. Those only expose themselves through how a person approaches and reacts to a situation and the way they treat others.

The Test Pilot

Just because you...
    ...designed the airplane...
    ...built the airplane...
    ...managed the design, construction, and testing of the airplane...
    ...flew on an airplane once...
    ...played an airplane video game...
    ...have a cousin that flies airplanes... a book about flying airplanes...
...doesn’t mean you know how to fly the airplane!

I cannot emphasize this enough: testing is a skilled trade - whether it's testing an airplane or testing a website. The project manager for the the design and construction of a new airplane would not think twice about trying to fly the plane himself. Instead he delegates that responsibility to someone that knows how to fly the plane.

But just because you...
    ...know how to fly the plane...
...doesn't mean you know how to test the airplane!

Testing goes well beyond normal use. Test pilots need to be able to conceptualize the abnormal, the extreme, the emergency, even the absurd situations and have the skill to execute on them. Yes, every pilot should be trained to handle emergency situations but being forced into an emergency is far different from intentionally stepping into one.

Testing websites and software shouldn't be any different. There are certainly valid scenarios for the project manager or the client to do some testing but having them do the heavy lifting will lead to poor results.

Now this isn't to say that testing is an exclusive club by any means. You learn testing by doing. You really can't go to school to get a degree in testing. Attending a three-day seminar won't make you a good tester. Getting an expensive certification from ISTQB won't make you a good tester. You become a good tester with practice, by having an open mind, by challenging the status quo, by thinking, by being independent.

Tuesday, May 8, 2012

Fast, Good, Cheap, and _______

The Triple Constraint or Project Management Triangle is a device that describes opposing variables in project management. The variation that I'm most familiar with has the three sides of the triangle representing: Fast, Good, and Cheap. The principle is that, when applied to a project, one variable must suffer at the expense of the other two, whichever one that is, or vice versa. For example, you can have a project run fast and deliver a good product but it won't be cheap.

Who says you have to sacrifice though? It's really not a "who" but a "what", which I recognize thanks to a recent post by Catherine Powell. (Our models differ but it's because of her that my brain got to thinking about this.) There's a fourth project component missing from the model and that's Scope. The fourth variable necessitates compromise but before talking about how Scope comes into play, let's review how the Project Management Triangle works. There is a variable for each side of the triangle A, B, and C and a fourth variable for the perimeter of the triangle D. The perimeter is fixed so that no matter what, A + B + C = D. If A increases, B and/or C must decrease. If A and B increase, C must decrease.

Why does the perimeter have to be fixed? Let's face it, most projects, if not all, have one thing that is 100% non-negotiable. In the Fast, Good, Cheap model, this is Scope. Without answering "what is this project about" you really don't have a project. Even if a project has more than one "non-negotiable," one will still trump the other.

As you may have recognized, the three sides of the triangle are not permanently designated Fast (Timeline), Good (Quality), and Cheap (Cost). Rather, the three sides are that which is not the paramount non-negotiable perimeter.

For Example
Timeline: The client needs a website to go live at the same time as a huge marketing campaign
Quality: The website must adhere to government regulations
Scope: The functionality of the website has to include everything specified
Cost: The expense of the project cannot go one penny over

Let's now apply these variables to the sides of the triangle. When a side of the triangle is benefited, it gets longer but it gets shorter when penalized.

Variable Benefited Penalized
Timeline Decreases Increases
Quality Increases Decreases
Scope Increases Decreases
Cost Decreases Increases

Using the Fast, Good, Cheap model for the three sides, let's say Scope is our fixed perimeter with a non-negotiable set of requirements. Let's say the company wants a bigger profit margin, which is in essence cutting the cost. If we want it to stay on time, the quality will suffer because of reduced testing. If we want it to maintain quality, the timeline will suffer because of less-skilled (i.e. cheaper) labor.

Under ideal circumstances, we'll have an equilateral triangle. This requires doing your homework up front. Figure out what your non-negotiable variable is and then set the remaining variables based on that. Doing this should minimize the need to make compromises enabling you to not have to change anything. If change is necessary and compromises are undesirable, the only way to change the perimeter is to change the contract either through a change order or a completely new contract.