Machiel Groeneveld tweeted about (automated) testing, he argued that tests fit Deming’s definition of inspection.

I replied that, when tests are being developed and executed at the same time as the software, you could see that as a form of “build quality in” instead of inspection. That leaves room for interpretation, as Machiel instantly noted. For instance, does that only include developer tests? Or do tests from a separate tester (in the same team) also qualify as built-in quality?

Lars Vonk chipped in that software tests should not be primarily aimed at quality, but as a tool to prevent bugs and as a process improvement tool.

Donald Reinertsen then introduced an economic perspective on the situation. His argument is that there is an economic tradeoff between prevention and inspection. If inspection (and the associated rework) is economically more feasible than prevention, than you may have a legitimate case for inspection, despite Deming’s principle.

Deming’s underlying assumption is that prevention is always cheaper, because to prevent an error from happening again is a one-time investment, while inspection and rework is a recurring cost. An interesting observation is that automated tests may violate this assumption. An automated test lowers test execution cost significantly, maybe even more than the cost of preventing bugs. Reinertsen uses the example of the spelling checker: experience tells us that inspection with a spell checker is cheaper than preventing spelling errors in the first place.

If you or your team are moving more towards prevention instead of inspection, that’s a good thing. But keep in mind that one day, the cost of more prevention might outweigh the cost of inspection and rework. As soon as you hit that point, look for more valuable alternatives to improve your process.

Possibly related posts (automatically generated):

1. My week on Twitter (2010-03-08)

What did the acceptance test say? RT @mvzoest: *lol* http://tinyurl.com/ylpoh7e How recognizable #

I'm looking for reviews/tests of the Magnat Interior 501A home cinema speaker system. Google is not very helpful Anyone? Thnx! #

@luus is that arrow pointing at the street light? #newHuusOfLuus in reply to luus #

@laurensbonnema that would give a completely different perspective on "collocation" in reply to laurensbonnema #

@biemond I'm just organizing it, there's no need for me to give up Good luck with the entire FMW stack! #developerderby in reply to biemond #

@whitehorsesnl "Unsupported" Next question please #wow #talkaboutproventechnology in reply to whitehorsesnl #

@luus what made you switch from iphone to nexus? I still can't choose in reply to luus #

Possibly related posts (automatically generated):

1. My week on Twitter
2. The Balance Between Prevention and Inspection

@basvg I didn't realize your project had THAT kind of sensitive information in reply to basvg #

@larsvonk het verschil is denk ik dat de politiek niet inspect en toch adapt in reply to larsvonk #

Possibly related posts (automatically generated):

1. My week on Twitter (2010-03-08)

User stories need to be clear and concise, and everybody (Product Owner and Team) should have a basic understanding of the story during the Sprint Planning. Just enough info to determine the approximate size of the beast.

After the Sprint Planning, there will be (should be) LOTS of conversation and confirmation. By definition. Because the requirement is still only briefly analyzed, it is a false expectation to be able to understand and code a user story right after Sprint Planning (of course, it happens, but it shouldn’t be the standard).

I sometimes come across teams that look back and conclude that they didn’t deliver what was expected and propose to be “more clear in the wording and details of the user stories”. Don’t try to go that path. It’s a slippery slope, and before you know it, you’ll be back reviewing detailed designs. You might say it’s an anti-pattern of agile.

I don’t care what the user story says.

Make sure everybody has a basic understanding at first and work together to deliver what’s expected. That’s my preferred strategy if you adhere to agile principles.

Photo taken from koalazymonkey’s photostream under Creative Commons license.

Possibly related posts (automatically generated):

1. Final Sprint Looks Like Kanban
2. Calculating Capacity of an Agile Team

Read it here: “Kort-door-de-bocht of elegant?“

Are you starting with Scrum? That’s good news!

• You have a Team: check.
• You have a Product Owner: double check.
• You have a Product Backlog:  …. right?

Product Backlog? Yeah, we have a list with things we could work on, and when (if?) we finish it, we’re done. But is that a Product Backlog?

The minimum viable product backlog (yes, I got inspired) is not just “all items we came up with that we could work on”. It is a filled, estimated and prioritized list of work items. There are three key points in this statement.

The backlog is filled

This means it should at least contain enough work items to fill the first sprint and include an extra work item to expand the product backlog. Most projects start out with a backlog with high level items for the entire system (that may be a dozen to a hundred or more).

The backlog is estimated

The team must have enough information to estimate the items on the backlog. The Product Owner should be able to explain the items, the team should be able to give them a relative size (using planning poker, for example).

The backlog is prioritized

The Product Owner should have a clear vision on the entire product (think big), but also on what to build first (act small). Not always easy. The book says “pick the story with the most business value” but that doesn’t make it easier for most Product Owners.

A useful technique in this respect is a story map. The story map works top-down from the high level work items. These high level work items are typically things a system MUST support in some way or another. It’s just the sophisticatedness of the solution that determines the size of a work item. When Product Owner and Team together work out the least sophisticated solution to all high level items, we have what we call the walking skeleton, or minimum viable product.

Building the walking skeleton is a very useful prioritization, because it proves the (functional and technical) feasibility of the product.

Why this post?

Too often teams “rush” into Scrum to find out after a few sprints that the product backlog requires major maintenance. This might cost more capacity than one would like, possibly affecting velocity and the sustainable pace of the team. To prevent it, make sure you have a minimum viable product backlog from the start, and make sure it remains viable throughout all development activities.

Some people like to compress these activities in a few days, other like it to extend it to an entire sprint (to get used to the rhythm). Some people like to call this preparation “sprint zero”, others argue that it might as well be the first sprint. I don’t care how you call it, just make sure you do the activities associated with a controlled start.

Image taken from yoppy’s Flickr stream under Creative Commons license.

Possibly related posts (automatically generated):

1. Kanban, Lean and Scrum Are Not Religions…

Many people are confused when they read it and ask me what it means. How can better be worse? Better is better, right? And certainly better than good enough, right? Wrong.

The statement reflects pragmatism. Simplicity. Or, as Einstein put it: “Any fool can make things bigger, more complex, and more violent. It takes a touch of genius -and a lot of courage- to move in the opposite direction.”

It feels counter intuitive. We always want to make things better. But think of this: a better solution might be, uhm…, better, but it has at least three major disadvantages:

1. It takes more time to make things better – we don’t have this time
2. It costs more money to make things better – we don’t have the money
3. It has a higher probability on errors – which cost time and money to fix

In software development, we tend to “gold plate” solutions and include all kinds of bells and whistles that will “certainly blow away our customer”. Will this customer really be delighted by those bells and whistles if it means that his project is over budget and too late?

The trick is to hit the sweet spot between “too little” and “too much”. The only way to know that spot is to get frequent feedback -early and often- from your customer. This is one of the core principles of agile software development: close collaboration between development and customers. Scrum implements this principle with the Product Owner role, collaborating closely with the team, delivering software in short Sprints, ending with a Sprint Review of working software.

Now you know what I mean with “better is worse than good enough”. Try it for yourself!

Photo taken from wallyg under Creative Commons license.

Possibly related posts (automatically generated):

1. Agile Design Is Not Generic
2. Kanban, Lean and Scrum Are Not Religions…

This post is for people running a private Samba server, wishing it was securely accessible over the Internet. Stop reading if you don’t know what Samba or SSH means.

Imagine the following situation: at work, school or a client site, you insert your USB stick, check your local hard drive and search your Gmail account to find out that the one file you were looking for is not there. You probably left it at home. Damn!

Sounds familiar? It does happen to me frequently.

A solution is to have access over the Internet to your private Samba server. No more worrying that you didn’t take a particular file with you, just access it from anywhere you like. But you also want that access to be secure. Can it be done? Yes.

What do you need?

• A server running Samba that also provides SSH access from the internet
• Windows XP on the client
• PuTTY on the client

How does it work?

In short, you have to install a loopback adapter and configure a SSH tunnel with PuTTY that uses the loopback adapter. If this says it all to you, you can stop reading. If not, please continue

Step 1: Install a Microsoft Loopback Adapter

• Go to Start -> Settings -> Control Panel -> Add Hardware.
• Select “Yes, I have already connected the hardware”
• Select “Add a new hardware device”
• Select “Install the hardware that I manually select from a list (Advanced)”
• Select “Network adapters”
• Select Microsoft -> Microsoft Loopback Adapter
• Click Next, Next, Finish and done with step 1!

Step 2: Configure the Microsoft Loopback Adapter

• Go to Start -> Settings -> Network Connections and look for the network connection associated with your newly installed loopback adapter (hint: it should say something like “Microsoft Loopback Adapter” under device name).
• The network connection is probably called “Local Area Connection #-something”, you can change that to something more meaningful. “Loopback For Samba” is great if you don’t feel creative.
• Right-click the network connection, click Properties.
• Uncheck “Client for Microsoft Networks” and “File and Printer Sharing for Microsoft Networks”.
• Change the properties of “Internet Protocol (TCP/IP)”:
  • Use the following IP address: 192.168.100.100 (any private address that does not interfere with address ranges on your other network cards is fine)
  • Subnet mask: 255.255.255.0
  • Default gateway and DNS can be left empty
  • Click Advanced, tab WINS: check “Enable LMHOSTS lookup” and “Disable NetBIOS over TCP/IP”.
• Click OK, OK, and you’re done with step 2!

Step 3: Create an LMHOSTS file

• Open an Explorer window and browse to C:\WINDOWS\system32\drivers\etc (or wherever your Windows installation resides).
• Create a new, empty text file called “lmhosts” (without the quotes and without an extension!)
• Put the following line in there:

  192.168.100.100 name_of_samba_server

Be sure to use the IP address you picked in Step 2! It is handy to use the same name_of_samba_server as you use on your local network. That way you can always refer to your Samba server with the same name, regardless of your location (at home, or work, or school, or …).

Step 4: Configure PuTTY

• I assume you already have PuTTY configured with a saved session to make an SSH connection to your Samba server.
• Fire up PuTTY, load your saved session and navigate to Connection -> SSH -> Tunnels.
• Type “192.168.100.100:139″ in the Source port textbox (the textbox is a bit small, but that doesn’t matter) (be sure to use the IP address from step 2) (use the IP address, i.e. do NOT use the name of the samba server!).
• Type “localhost:139″ in the Destination textbox.
• Click Add and re-save your saved session, and you’re done with Step 4

Step 5: Use it!

Fire up PuTTY and make an SSH connection to your Samba server. You’re now able to access your server, map drives, etcetera.

For example, try Start -> Run and type “\\name_of_samba_server”. You’re presented with a login box and/or an explorer window with all shares on your server.

Or type “net use h: \\name_of_samba_server\share” to make a network drive mapping.

Basically, you can use your server like you would as if it were on your local network.

Step 6

There is no step 6.

FAQ

• Why the loopback adapter, can’t I simply use my regular network adapter?
  Yes you could, but with a severe limitation: while PuTTY is running you would have access to your Samba server, but at the same time, not to your work/school/client network drives (and vice versa).
• Why the LMHOSTS, can it be done without?
  Sure, but then, I would have to access my Samba server with “\\192.168.100.100\share” while on the road and with “\\name_of_samba_server\share” while at home. The use of an LMHOSTS file abstracts that for me. It’s also quite handy for batch files that create mappings (they work, regardless whether you’re at home or on the road).

Well, that’s all there is to know about secure access to a private Samba server. Good luck!

This post is largely based on an old message on the Samba mailing list.

The image above was taken from Ella’s Dad flickr stream under a Creative Commons license.

It feels kind of awkward, to be planning the final set of user stories. Is this really everything? Can we really miss all that other stuff on the product backlog? Everybody is quite confident that we produced good results.

Nonetheless there are some oddities. While things are being tested continuously, any issues uncovered normally entered the product backlog. In this last iteration, if an issue turns out to be more important than stories already planned, we (team + product owner) agreed to reprioritize during the sprint.

This also means that the team is now even more disciplined about how many user stories to develop concurrently, because we don’t want the PO to drop a user story we’ve just started working on.

But… as the number of user stories decreases and the PO is allowed to reprioritize all work that hasn’t started yet, we might as well say that we’re doing Kanban!

As I said in my previous post, “Kanban, Lean and Scrum Are Not Religions…”, it depends on your situation what tool suits you best. For almost a year, we used Scrum. For the end game, Kanban seems like a better tool. Just do what works.

Possibly related posts (automatically generated):

1. Kanban, Lean and Scrum Are Not Religions…
2. I Don’t Care What The User Story Says

And please make sure there is enough ROI, dear Product Owner!

And attend the daily scrum to clarify any issues the development team has within the current iteration!

And prepare the next set of requirements for planning.

And… And… And so on.

Jeff Patton wrote an excellent article about the assumption that the Product Owner must possess super powers: The product owner and the product-shaped hole. Unfortunately, most Product Owners do not possess super powers. I might even say that not a single PO has them (since they are still exclusively used in comics and the like).

This post deals with one of the challenges a PO has: how to prioritize my backlog?

When asked to prioritize every requirement on a scale of 1 to 3, the following usually happens:

• 80% will end up as priority 1
• 10-15% as a priority 2
• the rest (if any) is priority 3.

That is not very helpful to determine what requirement(s) to work on next.

A useful approach in this situation is to limit the number of requirements that are allowed in priority 1 and 2. For example:

• 10 requirements are allowed priority 1
• 20 requirements are allowed priority 2
• the rest is priority 3

All priority 1 requirements must be ready for immediate scheduling in the next planning meeting. Suppose that 8 requirements fit for the next iteration, then all you have to do is:

• promote 8 requirements from priority 2 to 1 and;
• promote another 8 requirements from priority 3 to 2.

That is just a minor task compared to the task “rank every requirement against all others”. When you put the priority 1/2/3 boards on the wall with brown paper and postits, it provides visual focus as to what to work on next as well as a transparent overview of “what’s next” and “what’s almost next”.

Try it, you might like it!