Part of the way through the show, a conversation took place that I couldn't get out of my head.

Here's the situation:

A business person is asking IT to implement a blog using a specific NoSQL database solution and we push back and try to examine why they want it, and oh by the way we have this great business opportunity for you (around 29:30).

Which reminded me of a related question I heard (I thought in the show, but apparently it must have been earlier in the day):

Why it is OK for the IT person to talk business to the business person, when it's not OK for the business person to talk IT to the IT person.

What bothered me the whole drive home is the built in assumption that the business and IT are separate entities. The panel went deep into value streams and hypotheses-driven development from here, but I think there was something wrong with the root of this story, where we accepted the separation of IT person and business. This may seem overly detail-oriented, but I think far too many IT people see themselves exactly this way.

And it's wrong.

Here's the flaw in this story (and every other place we talk about IT vs the business):

Joe Random Executive doesn't know all the intricacies of accounting, purchasing, warehousing, marketing, sales, law, human resources, or any of a dozen other areas. They will probably know a couple in detail, but they are no more an expert in the rest then they are in IT (and of course we assume they didn't have an IT Background). These are all skills or roles that get casually lumped under the "business" umbrella. Because somehow all areas but IT are business, while only IT is non-business.

Is this ego or laziness? Some of both. Only in the IT department do we somehow think our role gives us a magic ticket to be totally ignorant about the company we work for.

This is absurd.

It makes no more sense then suggesting that accounting is far too intricate to spend time learning how the business around them works. Or that the ever-changing logistics and supply market supersedes understanding the products we are purchasing or shipping. Or that knowing what markets we sell to has any importance to the lawyers. Or that our business growth strategies should take any time away from HR activities around screening and hiring,.

Maybe the whole company is siloed, but seeing it as IT vs The Business is silly (see Gene Kim's point 25 minutes in).

But wait, these are IT ops people talking, surely this is different, right?

I'll give you a hint, Gene Kim talks early on about how The Phoenix Project was influenced by The Goal (Eliyahu Goldratt), whose main character is a plant operations manager. So no, IT Ops, IT QA, IT Technician, you are no more off the hook then the enormous variety of lawyers a business may need to work with over the course of it's life.

There are two types of workers, and they aren't IT and non-IT, they are engaged and not engaged.

Are you doing your job?

Are you doing the job, or just playing with technology?

An engaged worker knows how the company works, at some level. They can discuss the strategies the business is executing, what their company does, and who their customers are. They may not be able to discuss these things with equal facility as the executives or experts in specific departments, but they can have an intelligent conversation about their business.

The not-engaged worker is just there to do a job and go home. They are the protectors of turf, the ones that deny every request they can get away with, or the ones that simply don't care.

So the reason an IT person (even an IT Ops person) can speak to a non-IT worker about the business is because "the business" is the common language they share. IT, accounting, purchasing, human resources, whoever ... when we need to discuss why something is important, we discuss it's impact on the the business, the strategies or targets it effects, etc. In fact, being in IT typically requires a higher level of day-to-day, cross-functional contact then any of the prior examples. More, not less.

Engaging the business has come and gone as part of many buzzy things, and in DevOps it's rising again. Regardless of it's current popularity, if you work for a company, being an IT person doesn't magically separate you from the goals everyone else is working towards. Engage, learn the business, help them succeed, you'll find that you're company is doing some really interesting things and works with some really interesting people. If it's not, find one that resonates with you and learn what they're doing. Either way, you're part of the business, an you chose whether you're competent or not.

Quality

Often in the software world, Quality seems to mean "Does it work or not". Occasionally there is the idea of a Definition of Done, and the definition of Quality includes additional documents, automated tests, formal communications, etc.

Dictionary.com - character with respect to fineness, or grade of excellence
Merriam Webster - degree of excellence, superiority in kind

If Quality is a scale of excellence, what level do we assign to "it works"? What grade do we get for "I didn't find any broken bits"? Why do we keep assuming "it isn't obviously broken" means we have achieved quality?

I ran into this post that examines a number of different definitions of quality and refines them all into:

1. A characteristic of a product or service that bears on its ability to satisfy and exceed* stated or implied customer needs, and thereby provide customer satisfaction.
2. Freedom from deficiencies.

Which is similar to my less formal definition of:

Quality is how well the product does what we said it would, from the customer's perspective

Quality is a scale, not an on/off switch.

• If the product has defects (ie, broken bits), then we have Quality problems.
• If we cut features at the end of the development cycle and don't tell the customer, we have Quality problems.
• If we have a breakdown in communications to the customer while explaining what the product does, we have a Quality problem.
• If the customer has difficulty interacting with the product, we have Quality problems.
• If the product behaves inconsistently when the customer is using it, we have Quality problems.
• If we deviate from our industry standards without informing the customer, we have Quality problems.
• If we deviate from their industry standards without informing them, we have Quality problems.
• If we have to argue with the customer over whether we built what they asked for, we have Quality problems

On a scale of "it destroyed our business" to "it was generations beyond what we could have imagined", "we didn't find any obvious bugs" sits firmly at zero.

Quality Assurance

So after a rather long-winded definition of Quality, what about Quality Assurance?

I'm not a quality professional, but most of what I hear or read seems to be using the definition of Quality Assurance that means we have testers testing our product before delivery. Possibly with some automated tests. Possibly even with some automated tests that can be run by the developers (not to be confused with forms of testing that are the developer's responsibility).

Sound about right?

Except this is Quality Ensurance. Testing the mostly finished product is designed to Ensure our product meets a specific standard of quality.

Assurance is a proactive term, "it will be good" vs Ensure's "we checked at the end and it was good". The purpose of Quality Assurance is to build confidence in the level of Quality (Assure) by driving improvements, so that improved Quality is a natural result. We Assure, are confidant of, better quality by helping it get cooked in from the start.

We are all responsible for Quality, but Quality Assurance is responsible for improving the processes, tooling, environment, and business to increase the Quality of our output. Inspection at the end serves as a good first step, so we can gather data to drive improvements, but if this is all you are getting from your Quality Assurance efforts, then you don't actually have a Quality Assurance effort.

Devlin's Post

So back to Devlin's post. He listed a number of points from the presentation and his thoughts on them. While I didn't attend and am therefore missing some of the context, here are my thoughts.

1. Risk Mitigation is the main job of QA

Absolutely not. The job of QA is to improve our ability to build Quality in as we build the product. This may have the side effect of mitigating risk, but that is a natural outgrowth of building something that engenders greater satisfaction from it's purchaser.

2. Cost of finding bugs is higher as you get later in the deployment cycle, so we should incentivize finding bugs early because we saved that money.

Incentivising is one way to improve the ability to build Quality as close to the source as possible, so it passes the Quality Assurance definition above. However, I think incentivizing drives the wrong behavior. Even the most honest developer could choose to spend their time finding bugs instead of building the product. And at the end of the day, what we really want is fewer bugs created, which incentivizing could prevent us from improving towards.

3. High Quality / Focus on Quality cost more money

Yes, but only in the short term. Producing Quality products is taking the long view, thinking past the immediate contract or deal that is on the table. Measuring the effects can be difficult, but that doesn't mean they are nonexistent. How much would you pay to turn your customers into part of your marketing and sales teams? How much more productive is the team that is proud of what they build? How much less do you spend manually inspecting for Quality at the end of the process when it's built in early on? How much do you save with a better understanding of requirements as your building the product, rather than after you have delivered? What is the value of being able to deliver a product confidently instead of worrying the customer may not accept it?

Technically, firing the quality team will also save you money. So will firing the development team. That doesn't make them good long term strategies.

4. Unit Testing should be a task for each development task

I feel the same as Devlin on this, if you're in an environment that doesn't include it as part of getting a task done, then, yes, it may be helpful to assign each task with a paired "so the unit tests" task until people get used to doing them together. But this isn't an end state, at some point there should be agreement that doing the tests is simply part of calling the work done.

5.There are Different Kinds of testers

Here I am going to have to diverge from Devlin again, but I'm pretty sure it's a context issue. I think the question of whether there are different types of testers depends on whether we are talking about types of tests or areas being tested. A manual tester at the end of our process is going to have very different skills then an experienced security tester, which will in turn be different than the skills of a usability tester.

7. Team Collaboration on testing

Again, this is an example of one type of improvement a Quality Assurance team could make in a business. This one may be more successful than the incentivising one above, but I think it's going to depend on the environment it's implemented in and, as such, isn't something I can comment on.

8. QA is the Whole Team’s responsibility.

I started out agreeing with Devlin, but I'm going to have to revise my opinion. I think the idea of continuous improvement should be built into the whole team, so that everyone takes responsibility for improving their surroundings, processes, and selves. And I think this directly feeds Quality, because the improvements we are making should be improving the quality of things, either as measured by the customer (product quality) or our coworkers, management, or even cleaning staff. So in a perfect world, building in improvements to improve Quality is part of the individual team members responsibilities.

However, I think there should still be someone who has overall responsibility for QA, either in the role of a manager or coach, to ensure that decisions are being made soundly on real data, ensure we aren't over-optimizing one portion of the business at the expense of another, and so on.

Thoughts?

A lot of people in the software world dislike Quality assurance, but I think this is because there are a lot of poor Quality Assurance efforts out there that never get past the manual test stage (and thus aren't actually assuring quality).

Regardless, if "It ain't broke" is the highest measure of quality in your company, it may be time to recalibrate expectations.

5:45 PM. After logging into the service provider dashboard, I find that the database services tab is completely non-functional. Attempts to connect to the database from home also fails. Various other troubleshooting directions are followed and also meet in failure.

And then some scheduled jobs in our development and staging environments kick off and also report database timeouts. It's getting increasingly unlikely that this is us, time to contact support.

6.45 PM. Calling support leaves me in a hold queue that is experiencing "longer than normal call volume". Maybe this isn't just me? I check the service status page and everything is green. Still waiting on hold. I check twitter and don't see any mentions.

7:10 PM. Lets check the public forums...ah, there's a few other people with this problem. I add my own personal story so we can help flesh out the picture of what's going on.

7:15 PM. 30 minutes into the hold queue and I just got transferred to a ringing phone. After seeing the forum post, I suspect I'll end up getting a canned "We know there's a problem, we don't know what it is or when it will be fixed, thank you for all your money" speech. So I'm a little surprised when after two minutes of ringing the phone simply goes dead.

By now I've added a few tweets to twitter with the appropriate tags, started looking at the SLA information for the service, and generally just continue to waste my evening in front of the computer instead of spending time with my wife and two year old.

And time passes.

8:10 PM. I've been refreshing the status dashboard every 10 minutes since I first opened it but this is the first change. Red notifications show up, along with hourly messages going back in time to 5:11 PM. I add a note to the forum and a tweet for anyone else waiting for some word from our service provider. The messages are fairly generic and innocuous, admitting that some customers may experience outages with given services and regions. We apologize for the inconvenience.

We couldn't be bothered to provide an update for 3 hours, but we apologize for the inconvenience.

Your business has been down for three hours and there was no official announcement you could point your customers to, but we apologize for the inconvenience.

Admit Your Service Outages?

I would bet we have all worked with companies or products that go to great pains not to announce bugs or outages to their end users. After all, admitting an outage means that the people that didn't get affected will know about it too, and that looks bad.

Maybe we're afraid of upsetting users that weren't online at the time, of losing customers, of warning off potential users, of providing inside information to our competitors, or getting negative press.

Been There...

I once worked with a manager that screened each outage email, broadcasting only the ones that he felt were important enough to be forwarded, which tended to be none of them. Our service levels improved amazingly in the short term. Unfortunately since we weren't keeping our users informed, each outage took longer to correct as we also fielded calls from end users thinking it was just a problem with their system. Which meant our mean time to fix outages went down and affected more people. Which meant that the overall public consensus of our service level got poorer, especially as people realized we were simply not reporting our outages anymore.

We lost credibility. Our service levels were reduced to levels we had worked years to raise them from. The trust our end users extended to us was heavily impacted.

Before that slow slide back into the mud, we had originally climbed out by being open about our outages. Every outage had been announced, often before we had a fix identified, with follow-ups when information was available. Users trusted us more because they could see us jumping on problems, hear us being honest and open with them, and see the problems getting taken care of. We didn't have to tell them how much things were improving, they saw it.

But we stopped admitting our outages, and for a short time we looked even better. Then we looked far, far worse.

Pretending Doesn't Make It So

Hiding bad news to protect your image is a short term loan with major long term costs. Your statistics are broken, so justifying and performing root cause analysis is that much harder. You are limited in what you can ask or discuss with your customers, because each one has to be treated as a potential leak. Your support services are put under a lot of strain and probably built with a higher focus on cost reduction than quality of service.

In short, all of the energy you are spending to look awesome is actually moving you further away and unlikely to be fooling your end users.

Back to Saturday Night

Saturday night, a well known service provider had an outage that shut down our business for 3 hours and 31 minutes.

For 3 hours we were in the dark and then, when an update was provided, it was backdated to look like we had been kept in the loop the whole time. Countless hours were wasted as we and many other customers tried troubleshooting a problem that wasn't in our systems. The support center was overloaded (or just not responding). And at the end of the night a degree of credibility and trust was thrown away.

Someone had an opportunity to shine, and instead chose to make a bad situation that much worse.

Then I got better.

But it took a while.

And I'm not done.

Code is for Other People

We don't write code for the computer. We write code for ourselves an hour later, after we we have fallen out of the zone and have to debug it. We write code for 2 months from now on a Friday afternoon when it's the only bug keeping us from our weekend. We write code for 2 years from now when the axe-wielding psycho of a maintenance developer hits the blame button to see who volunteered to be his newest, bestest friend. Or trophy. Probably trophy.

When we're producing code, we have to be mindful that there will be a person consuming our code and stop focusing on just getting it out of our head. When we come back to this code in 6 months we want to be able to read it easily, be able to safely make assumptions about elements in it, understand the intent as well as the concrete implementation, and do so with the least amount of re-reading possible.

Be Consistent

Code standards tend to get a bad rap, especially among younger developers. They're seen as unnecessary extra work or as limiting creativity. I remember thinking this way at one time and agree that over-prescription can be wasteful (but c'mon, over-prescription of just about everything is bad, that doesn't mean we can't take something for our headaches).

The majority of code standards boil down to naming things consistently and being consistent in how functions and whitespace are structured. We do this so we can make quick assumptions about the code as we scan a file, identifying scope or type of variables, locating blocks of code, determining level of nesting, etc. Sure there is some extra work when we initially adopt a standard, we lose some time as we get used to new naming patterns and structures, but once we get used to the standards it becomes just the way we do things, no more.

And as far as creativity goes, unless you're taking part in a code obfuscation contest, focusing on being creative at the code structure and variable naming level is a sign that you've lost sight of the bigger picture, namely that you have an entire program to be creative with. Or you're too busy trying to express your inner hipster, one of the two.

Ugly Strings are Ugly

I'm not a fan of inline SQL. It tends to be written poorly, doesn't get tested for syntax errors until the first time you hit that code path, can be nearly impossible to locate when you decide to change a field name in the database, and often gets written in a solid block of unformatted text.

And the same happens with varying degree in HTML, LINQ, Perl, ... really anything that resembles 50 lines of content without a carriage return.

Even with guidelines for structuring our code, we need to be mindful of the blobs we produce. These blobs are difficult to read, adding to the level of frustration and time wasted when a future developer has to work with our code (Who wrote this garbage code!? Oh, me, argh). If the blob is truly a string, it deserves good formatting and consistent capitalization just as much as our code. In fact, I would say being consistent is even more important here, where color-coding and syntax checking tends to be unavailable.

And it's ugly. We may have saved 30 seconds and got the job done, but it's not worth taking pride in.

Well, I Can See What You Were Trying To Do...

I once reverse engineered some business logic out of a chemical cooker simulation program written in the early to mid 80's, revised 3 times by other developers, and utterly lacking in comments. There were no unit tests, there was one comment in the entire codebase (and it was wrong), and I often ran into cases where I could very clearly see that the developer was doing math, but couldn't figure out why he had chosen to use set V_T = f(V_T+1) when everywhere else we were calculating V_T+1 = f(V_T).

Why were we projecting back in time with that one variable? Turns out someone had swapped the naming scheme for current and future state variables, what a pain that was to figure out. Probably saved them a few seconds to not correct it and a few more not to comment their intent, but it cost me two full days to back into what they were intending to do and determine it was a spelling error. Who knows what it cost maintainers in the 20 years in between.

There are two things we need to know when we look at a piece of code: what does it do and what it was it intended to do. We can determine what it does by reading the code, but there are many cases where we have to guess at what it should be doing. I've learned to start with the assumption that implementation and intent aren't in agreement (all the while hoping I'm wrong).

Good naming schemes that identify intent, unit tests, function-level comments, good commit comments. These may seem unnecessary now, but 6 months from now they will be critical, whether it's to maintain a piece of code or copy it for reuse.

Error Messages Make Hulk Angry

No one likes getting an error message. An error message is the sign that no matter what we were doing, something has gone terribly wrong and we are now a whole lot further from being done than we thought we were. Obviously what we need in this tense moment is an incomprehensible or sarcastic message from the failing application to really put our mind at ease.

No?

How about this then. We develop some software, send it out in the world, and one day receive a call from an annoyed end user about the error they are receiving. The message simply says "Null reference error", maybe with a brief joke about cheese or a reference to a technical manual for the definition of null reference. Because we all love those "oh crap, I don't even know where to start" moments.

No?

Having been on both sides of this issue, I know neither is fun. In fact, I'd love to stop learning that lesson any time now. Error messages don't have to increase our stress levels this much. Unfortunately there is a tendency to add the least amount of time for error tracking, compound that with poor error messages, then just live through the frustration when the situation is kicking our butts later.

Better error messages aren't that difficult, though, we just need to put more thought into them. We need to keep those two users above in mind when we're crafting our message, and keep in mind the situation they will be in when this message matters. As the end user, we need help staying calm, information on how bad the situation is, a description of what our next steps should be, and the knowledge that everything is under control. As the developer, we need information about the root cause and all the state information we can get our hands on, to speed up detection and resolution.

It doesn't really take longer, especially if we invest in our error reporting infrastructure. Most applications could afford to spend a week or more here, given how many hours/bug of debugging time we will end up saving in the near and long term. But more importantly, unnecessarily upsetting users and developers during an already stressful moment is a double loss that will hit us with every bug, exaggerating an already negative situation.

There's More

There's more to this than consistency, clarity, explaining intent, and providing useful error messages. But it all starts with being mindful that when we code, we are not just writing something to jam through a syntax check and successfully compile. The code we write needs to be clear to the future reader and allow them to understand it with the least amount of re-reading and cross-checking. It needs to be aware that it has an audience, both future developers and end users. Good code is judged, not just on it's performance characteristics, but more importantly on it's ability to age gracefully, minimizing maintenance costs and the number of people it upsets along the way.

Using a combination of free tools, I was able to record my short video with a webcam overlay, compress it for faster upload, and upload it to to YouTube for sharing.

Capturing the Recording

The trickiest part is capturing a recording with the webcam overlay without having to shell out money for something like Camtasia. I tried a couple products, but eventually found a free product called CamStudio that allows you to add text or video overlays while it's recording the screen or a window.

Steps:

1: Download and Install CamStudio
The download link is available from the CamStudio frontpage. The download is a standard windows setup. Starting up the application presents us with the application:

CamStudio

2: Tweak the Recording Settings (first time only)
CamStudio fails to encode the recording if it is over 2GB. By dialing down the framerate of the video (initially 200fps), we can continue to get good output but extend our recording window.

• In the top menu, go to Options, Video Options
• Slide the slider at the bottom until the framerate reflects 40 frames/second or less

Recording Settings Dialog

Note: You may also want to go to "Options", "Program Options", "Directory for Recording" to specify where the files will be saved.

3: Open the window you want to record
In CamStudio, select the "Window" option from the "Region" menu if you want to record a single window (which I do), or select the appropriate option for your case.

I'll use a browser with the LessThanDot site as the example window I'll be recording.

Recording - My Target Window

Note: If you are recording fullscreen, you will want to go in Option, Program Options menu and select the option to minimize on recording start, then review and/or set keyboard shortcuts to start and stop the recording.

4: Turn on the Video Annotation (after plugging in your webcam)

• In the top menu, go to Tools, Video Annotations.
• Select your webcam from the dropdown and press OK

Warning: Cancelling out of this window with a blank selection will give you errors if you try to reopen the dialog, you're better off restarting the program.

Recording - Video Annotations Source

4: Position and Size the Video
Right clicking the open video gives access to additional settings for the video window.

• "Video Format" - Modify the dimensions and pixel depth of the webcam overlay
• "Edit Text" - Remove the "Right Click to Edit Text" text on the webcam overlay
• "Edit Image" - Lets you tweak the shape and border of the overlay
• "Edit Refresh Rate" - Lets you dial down the refresh rate of the webcam if you are having performance problems

Recording - Video Annotations Options - Circle w/ Border

5: Record
At this point we are ready to start recording. Press the red record button (circle) on the toolbar and select the window you would like to record. The window will have 4 green indicators placed around the outside and recording will start immediately.

Recording - In Progress

After recording the video will be replayed for you. My first video is slightly over 4 minutes at 1140 x 836 and came in at 760MB, although following some of the suggested settings on forums could probably reduce this without adversely affecting quality.

The next problem is that a 740MB file would take a while to upload.

Post-Processing

In order to upload the video to YouTube I needed to get it a lot smaller, and I wanted to do so for the least amount of quality loss possible. To do this I will use VirtualDub to process the initial file into a lower resolution and much smaller sized file.

I can't guarantee these settings as well as the ones above as I reused saved settings from prior projects, but I'll outline the main settings I used and the gotcha I ran into.

1: Open your file
The first step is to open the recording. This will simplify the settings when we get to the resize step.

VirtualDub can display the input and output streams side-by-side, but they may will probably be too large to fit on the screen. Right clicking on the input or output, you can select a zoom level for each stream. 50% worked well for me.

VirtualDub - Opening the Video

The option for which panes to see is in the "View", "Pane Layout" menu.

2: Select codec
VirtualDub supports multiple codecs, in my case I used the Xvid codec with the built-in "General Purpose" settings.

• From the top menu, Select "Video", "Compression"
• Select the Xvid codec (it may be a separate download, can't recall)
• Select configure if you want to change from the the defaults

VirtualDub - Codec Selection

2: Add a "Resize" filter
VirtualDub works by passing video through a series of filters. We will specify the "resize" filter to reduce the resolution.

• From the top menu, go to "Video", "Filters"
• Press "Add", find "Resize" in the list and add it
• Before changing the size, Set "Aspect Ratio" to same as source and set Codec-friendly sizing to multiples of 4, my Codec mode is bicubic, -.75 (which should be the default)
• At this point you should be able to tweak the height or width and the other dimension will respond accordingly

VirtualDub - Resize Filter

Note: On closing the window, you can see the resolution rounds to the nearest multiple of 4 in the filters window

2: Audio
I set my audio to direct stream copy ("Audio" menu, "Direct Stream Processing"), though unfortunately I can't say whether it makes a difference for this processing job or not.

Note: if I was an expert at this stuff, I probably would have purchased professional software by now

3: Preview
At any point, you can preview the output video just by using the player controls at the bottom. The program will do a temporary processing job on the fly to show you the video.

4: Save
Saving is as simple as going to the "File" menu and selecting "Save as AVI". When you save, the application will process the full video based on the settings we have added.

My original 5 minute video went from 760MB to 74MB. Part of this was the reduction in resolution, but part was running it through VirtualDub. If you don't want to reduce the resolution, running through VirtualDub will still give an improvement (740MB to 114MB in the above case). An interesting experiment I'll try next time will be to use Xvid for the original recording to see if there is the same level of difference before and after running through VirtualDub.

And Done

This wasn't a terribly complicated process, although there were a few gotchas that were annoying until I figured them out. The recording software and recording may not be as polished as it would be with a more expensive product, but I still feel it came out better than just recording the screen alone.

CamStudio:

• Exiting the video annotation selection dialog without a selection upsets the app, just restart it
• Recording more than 4GB will cause the encoding to fail

VirtualDub:

• Due to the settings I am using, selecting a resolution that is not divisible by 4 will give a cryptic error message

This may not be the most expertise-packed post, but it was enough to create a video with a webcam overlay. I will gladly take a slightly lower quality video of a speaker or instructions if I can also have the webcam overlay for visual queues.

A little later I was introduced to the idea of a project charter, a brief 2-page document that simply outlined the goals and expectations of a project, a "what will you have when I'm done" document. This did a better job, throwing out the crystal ball and admitting that it only knew the goals and some constraints, not the details of how it would look when we got there.

At some point I was introduced to XP user stories and defining the user's expectations as acceptance criteria at the feature level, focusing on small distinct pieces of work and providing the necessary level of detail at the last responsible moment.

And at some point, after an on-again, off-again relationship with unit testing, I was able to use TDD and BDD on projects, both of which work at even lower levels, defining what the behavior will be of a feature or code unit when it's code complete.

Definition of Done

The consistent thread through the lessons above was defining what "done" means at a project, feature, behavior, or code unit level.

A requirements document provides a very deep definition of what the project will look like when it is complete. Unfortunately this only works if you will have a limited need to make changes along the way. Often what we think we need up front requires some hands on use to see what we overlooked, whether the hypothesized feature helps us meet the goal as we expected it to, and whether it makes to our end user.

A simple project overview, like the charter above, can provide the overall goals and the general shape of the solution, without trying to dive too deep into the mechanics of how they will be achieved. It defines the goals of our project, serves as a measurement to determine if we are done, and helps prioritize the features we are going to implement.

User Stories operate at a lower level, defining a single feature and what the end users expectations are for that feature. User stories detail expectations from the end users perspective, so discussing or prioritizing them with an end user occurs in terminology they are familiar with. User Stories provide us with the "Why" and room to ask deeper questions.

With BDD or TDD we define what done means at an individual interaction or code unit level and can then create code that meets that definition. They provide confirmation that we have built exactly what we have set out to build, that we have met our definition of done, and that we will have some protection from derailing that work later on.

Multiple Facets of Done-ness

As critical as it is to understand what the customer or end user is actually asking us for, having a good definition of "Done" doesn't stop with the customer's direct expectations. We also have non-functional requirements that apply to large portions of the project as well as internal processes and practices, all of which should be considered when defining what "Done" means at a specific level.

Non-functional Requirements

Non-functional requirements span across many or all of the features we build into the system and can be difficult to track. Part of creating a definition of "Done" for a feature should include scanning the list of known non-functional requirements and adding the appropriate ones to the list.

Building an AJAX feature on a web page that talks to a 3rd party web service? Probably need to include the general requirements around responsiveness of the browser page and how to degrade or error out the service when the 3rd party service inevitably goes missing.

Process and Practices

We probably have a process we want our features to follow as we build them. In some cases this might be so easy it doesn't need to be included, in others we might have a more complex process we need to follow. A feature isn't done at "coded and thrown over the wall", if there are quality steps, levels of unit test coverage, static analysis to prevent us from dirtying up the codebase, and so on, those should be included in our definition of "Done".

Along with our ongoing process, we can also use the definition to drive longer term changes into our process or codebase. Want to add test coverage to a legacy project? Add a requirement that completing a new feature requires meeting a target test coverage and 3 tests in an older part of the code base.

Being "Done" with a feature means the feature is ready for delivery and we won't be coming back to it in 6 months to try to bolt-on performance improvements to meet metrics we knew about in the beginning.

Benefits of a Definition

Why are we spending so much time on something that seems like just extra work?

There's a difference between "I know what we have to do, lets just go do it" and having a good definition of "Done". If it is truly that obvious, making a quick bullet list will only take about 5 minutes. If it takes longer, it wasn't as obvious as we thought and we've already uncovered some benefit.

End User Context: Having the end end user define their expectations helps uncover the parts that are obvious to them, but foreign to us as IT people, employees of a different company, whatever. This also helps us build something that better fits the end users needs and expectations and provides us with information we need to help them make good technical decisions.

Focus: With a definition of done, we have a laser focus on what needs to be done. Instead of building a general solution to meet what we think they think they want, we can build directly towards their criteria. That's not to say we're going to get it perfect on the first iteration, but we can build a leaner solution that more directly meets their expectations. This means fewer iterations and corrections with a smaller and easier to modify code base.

Get Stuff Done: Ever get on one of those projects where it feels like it just kind of keeps on sluggishly flowing past and tasks are only done if no one has asked about them in a couple weeks? Yeah, I've been there too. Having a definition of done not only helps you better define when it hits that magic "Done" moment, but also keeps those one day tasks from turning into 6 month, under the radar, mini-marathon projects. Want an additional feature on top of the original one? We can totally do that too, but lets make a task for it so I can make sure I understand and capture your expectations. That other task is done, done, done.

Prioritization: How important is "add a button and text input to screen X"? Yeah, I don't know either. So how are we going to get the end user to help prioritize these things without someone pulling out the "they're all number one" phrase? Instead of trying to prioritize screens and buttons, the end user is prioritizing their own needs and expectations. This can help the end user prioritize, consider scope reduction of less necessary features, or potentially modifying a deadline to get all of the truly critical elements.

Bake Enough Quality In: Whatever your non-functional or process criteria are, trying to add them at the end of the project rarely works out well. If you need a certain level of performance, make this part of the criteria along the way. Afraid the focus will shift from getting things done to premature performance tuning? Create a looser "acceptable performance" level that is used during the main development, then tune from there afterwards. We don't want to waste time on premature optimization, but without at least a minimum acceptable bar you will quickly find out just how horrendously slow something can be written to run.

Don't Bake Too Much Quality In: A lack of definition doesn't automatically make everyone faster, the opposite can happen as well. Without a definition, each person on the project (and the customer) is left to define their own level for non-functional or process criteria. These are not likely to be the same. So the customer has one non-communicated level of performance expectations, the project manager has another. One developer is slamming code out as fast as they can with "as long as it compiles" as a performance bar, another is spending days trying to squeeze an extra 10ms out of a process. Defining "Done" in this case not only helps raise the bar and communicate consistent expectations, it also frees up time from any of the members of the team that have more stringent personal definitions they fall back on.

"Done" for the post

This post was inspired by posts from Howard (not published yet?) and Alex (Bad Medicine - How Prescription Becomes a Problem in User Stories) as well as ongoing conversations we've been having.

It may seem like wasted effort to put a definition of "Done" together, but I have yet to see an environment where the long term cost wasn't much greater (and my personal IT experience spans consulting engagements, 4 SaaS products, and over 75 projects). Not every website needs to load at Google search speeds, but the team needs to have a clear bar to aim for, even if that is "under ten seconds", and the customer needs to know and be OK with this bar.

A definition of "Done" doesn't need to have crystal clear requirements in infinite detail, "web-scale" performance guidelines, and so on. Be pragmatic. It's more important that the end user expectations are captured and understood, that the relevant non-functional requirements (when the 3rd party service goes down, so does our entire product, and it's OK) are included, and that somewhere we have captured the teams expectations for practices and process. Aim for just enough and be aware you will still have surprises.

This is a tricky question for me, mostly because my memory is poor and I'm having difficulty bending google's time search to my will.

LessThanDot

My first LessThanDot post was a wall of text in April 2009 that talked about bringing transparency and a definition of success to all projects, no matter how small. Since then I have added 78 more posts, finding out along the way that if you write a post with the word "Model" in it, you will get enough traffic to bring the poor LessThanDot server to its knees (and a whole lot of disappointed readers) and that apparently standing at one's desk is far more interesting than sarcasm and cat pictures.

I think the last one was the most surprising.

But further back...

But before my LessThanDot posts I kept a private site with 10's of hits a month. Or maybe a little less. My first post on this site was dated in August of 2002, a Classic ASP tutorial on creating files that incorporated multiple pages.

Did it count as my first one? I don't know. Benefits of a poor memory, I guess.

I am proud to see the site from 2002 was (mostly) HTML table-free and still looks roughly correct 9 years later (despite all the objections since that browsers just aren't ready for table-free layouts, bitter? naah).

Happy 2012!

Last year I posted 40 posts, including one with more than 25 pictures. Eventually I'll get around to making some new goals for this year and look forward to seeing what everyone else at LTD posts in the coming year.

I was in the indifferent group, but then I tried it.

Where I Started

After finishing The Clean Coder recently, I decided to give this kata thing a try. I started out with a fairly simple problem in a language I was comfortable with and spent 15-30 minutes each night trying a different variant or constraint. What I found was that even the act of setting up for a kata was a learning experience, in one case learning an entirely new unit test framework before I could even begin.

Fast forward a couple weeks and I think this is becoming a regular part of my ongoing development. I've even taken to synching my local mercurial repositories up to my BitBucket account so that others can take advantage of the pre-setup projects and test scenarios. (I haven't quite embraced the throw-away aspect yet, but I suspect I won't be keeping all of my repetitive attempts.)

In the past several weeks I've gained a lot more practice with mercurial, played with some concepts in C# (like Continuation Passing Style), and started digging into unit testing JavaScript. I've learned markdown simply by spending an hour or two formatting a series of text documents (an uninspired exercise, I'll admit) and .. well, for the not much time investment I can already see that this will be a good habit to add.

Why (or How) it Works

So why, then, do people do this? Obviously it takes time to write a program, no matter how small. Robert C. Martin, author of The Clean Coder above, swears by this practice. Jeff Atwood is another who wrote about katas. Dave Thomas (first kata link below) introduced the term as co-author of The Pragmatic Programmer.

But where is the value in repeating a simple exercise?

The Challenge

The first thing that struck me about code katas is their similarity to forum questions the LTD group used to hijack, back in the day. Someone would come up with a perfectly reasonable solution to a somewhat reasonable problem, then 2 or 3 of us would turn it into a 30 reply post, each trying to find a shorter, faster, whackier, whatever-er method of solving the same problem. In fact, the reason I learned how to use python and perl in classic ASP web pages was due to challenges like this.

The value of short, varied approaches is it forces us to stretch our knowledge of a language or syntax. Playing with constraints (performance, code length, memory limits, etc) help us explore more about a language or technology and choosing a short exercise as a base means we spend most of our time in that exploration, rather than in the act of retyping a solution or having to build a large structure to work with.

Focus

By selecting a fairly simple problem, we can choose to focus on any other aspect of programming that we want. Besides introducing rules or constraints to make the program more challenging, we can also use repetition of a simple, known problem to better get to know our tools or learn new supporting tools. Examples include improving use of keyboard shortcuts, trying out methods like TDD, and training ourselves on new habits or standards. By working on something we already know the answer to, we are free to play with the aspects of how we get to that answer.

No Loss

The last benefit to a programming kata is we can throw it away when we're done or even stop it halfway and simply delete it. Whatever aspect we have chosen to focus on or challenge ourselves with, this is still a small bit of practice code. Rather than trying to learn something new with a piece of code we will eventually have to support, we can play in a sandbox and put it away when we're done.

Where Can You Start

So, if you wanted to try this out, where could you start?

• CodeKata.PragProg.com - Dave Thomas has listed 21 programming and non-programming exercises
• Forums - Find a forum question that requires more than 5 lines of code for an answer. Write it, reinvent it, mix, repeat
• Coding Dojo - A catalog of 23 katas
• Project Euler - a series of challenging math problems that make excellent practice problems
• TopCoder - Though it exists as a programming competition, the sample and practice problems at TopCoder make good katas (if you can get the crash-friendly interface to work and find them, that is)
• Blogging - Writing about a topic forces us to explore and better define or communicate it

The best way to start is to pick something you feel like you can finish in 15-30 minutes and try to do a variant of it every day or two. If you feel like you're not getting any value out of it after a week or two, you can stop; your time investment has been low. If you do start seeing some value in it, though, you have another tool for keeping your skills relevant and sharp.

The five that initially occurred to me are Simplicity, Authenticity, Communications, Consistency, and Leadership. By the time I was done the post I had considerably more, but I don't want to spoil the show for you.

I'm obviously in no way affiliated with Netflix, Gordon Ramsay, or the BBC and I hope that if for some reason he finds himself trawling through IT blogs he doesn't take offense at this post.

I watched a few episodes of the US show and found it to be missing most of what I liked about the UK version, so if you've only seen the US version this whole post may confuse you.

Simplicity

In many episodes we see a restaurant struggling to serve such a large variety of items that it has no chance but to do them all poorly. The kitchen has no way to be prepared, as every evening is radically different. This struggle then forces them towards false economies of purchasing pre-prepared foods, freezing in advance, and generally cutting corners just to keep up. Simplifying the menu allows the kitchen to focus, wait until that day to prepare, and operate in a smoother manner.

Now think about it from an IT perspective. In the IT world we have a habit of over-complicating our solutions. We see the technologies shifting in new directions, new products coming, open a book and see architectural patterns for software development, patterns for building infinitely scalable networks, and so on. We try to provide service from an infinitely large menu filled with options we have never really tried. We add functions and unrequested features as a matter of course, ignoring the complexity and extra costs these add in.

That approach doesn't work in the restaurant business and it only appears to work in the IT trade because no one gets violently ill when we deliver half-cooked systems.

"Don't get to clever". A professional chef manages the size of their menu to what they can deliver and a professional IT group has to do the same. We need to build a simpler menu that focuses on delivering what the business needs and what we can provide rather than trying to deliver anything and everything on the market (and doing all of it poorly). This doesn't mean leaving off new technologies, but we need to make sure we've tried them and have a good grasp of their strengths and weaknesses before putting them on the menu.

Authenticity

To appeal to the customer, they have to identify with our product. In several episodes we see Ramsay polling the person on the street about menus, dishes, and once the color of the restaurant. What we end up seeing is a gap between what the customer wants or expects and what the restaurant is providing. In nearly every case, coming into better alignment with the potential customer is part of the recovery. The restaurant shifts to local produce and meats or to more authentic dishes. The menu and food changes to become more consistent with their area or it's theme and capitalizes on the authenticity to build customers.

With IT, authenticity is just as important. It doesn't matter whether the server is a Dell or HP, whether the end user asks for an ERP or scheduling system, whether we prefer an MVC framework or Silverlight application. What matters is working within the context of the business and what our potential users can receive value from. We need to work with our business to determine if an ERP is the best choice or if maybe a small business finance package would be a better fit. Are we using a new framework because it benefits the users or our ego? COTS or homegrown? Does the value of a feature outweigh it's cost? Is it a quality product or did we buy it based on the quality of the bar they took us to after that tech show?

Business alignment and helping the business make technical decisions is part of our authenticity as IT people. Helping the business make good, sustainable IT decisions is part of helping the authenticity of our business. Attempting to forcefeed the business solutions that satisfy our ego or laziness is not part of our job descriptions.

Communications

Kitchens are stressful places and provide numerous places for communication to break down. The chef stops communicating to their team and in minutes the team is idle while the chef melts down trying to run things on their own. Communication between the kitchen and the floor breaks down and not only is the customer impacted, but the floor doesn't know when to start pushing the faster dishes to ease pressure in the kitchen. Communications to the customer fails, bringing more pressure back on the floor staff, flows back into the kitchen and very quickly things spiral out of control.

And it's the same in IT. Not only are the communications between stakeholder and IT person critical, but we have to be aware of the other critical communications lines. Individual failures can quickly propagate inside our group and business, coming back to increase pressure when we need it the least. A good start is having a consistent method of communicating expectations and information. Without a consistent method it just turns into a room full of people generating a muddled background noise. Clear communication of delivery expectations, clear communication of expectations to the team, clear acceptance of delivery, clear updates to end users and stakeholders... These help to focus our efforts and drive repeatable behavior, trust, and a reduced level of stress.

Chaos is stressful and tends to feedback into itself. Clear, consistent communication keeps chaos to a minimum, ensures important information reaches the right ears, and helps keep us focused on the tasks at hand.

Consistency

A key to return business is the ability to deliver meals in a consistent manner. The consistency of the food helps set the customers expectations and build trust, while an inconsistent meal generates mistrust and is guaranteed to disappoint the customer. Part of delivering consistent food is tasting every dish before it goes out, testing each one to make sure it is up to the chef's expectations before it reaches the customer.

In IT we have a habit of delivering inconsistent solutions. Applications are released that perform poorly in the real world, never having run outside of the developers machine. Networks and services are provided with no measures for quality, performance, scalability. Usability and user experience are add-ons at the end. We spend time on unnecessary features and rush the necessary ones...the list goes on. If no one is tasting the product, if we don't have both a guide for what "good" is and test against that expectation, then we won't be able to tell when those systems are failing to live up to our expectations. We can say they're the best systems in the country, but it's just wishing.

We need to define our expectations, test our systems against those expectations, and be consistent with our delivery. Wishing our systems are good makes all the time and energy we have put into them a waste and guarantees that we will be delivering inconsistent systems.

Leadership

No matter how many improvements he helps make in a restaurant, the critical element for Gordon is to help managers, chefs, and owners take control of their environment and lead their people. Without this final ingredient, the new behaviors will not stick and the restaurant will soon slump back into it's former ways. With chefs he stresses the importance of leading and teaching the less experienced members of the kitchen, with house managers he might point out the same about their waitstaff. A restaurant that stands still will become dated and slowly degrade, as they start cutting corners and providing poorer service.

The parallel with IT should be obvious. Just as a restaurant requires leadership to keep moving forward, so does a good IT group. Without good leadership, we get in the habit of cutting corners, watching the clock, falling behind in our skills, falling out of line with the company values... Good leadership is what keeps the positives from falling into disrepair, turns groups into teams, and is the difference between a slow decline into a greasy spoon and a restaurant that delivers consistent, authentic, simple foods that delight the customer and guarantee return business.

There are only two directions, improving and deteriorating. No matter what improvements we make, if we don't have good leadership in place to promote those improvements, promote the values of the business, grow and respect the team, then any attempt at improvement is likely to fall by the wayside.

We May Not Work in the Kitchen...

We may not work in kitchens, but we do work in environments that can be very stressful, where every customer sees themselves as a chef and outages have to be corrected at 3am. We tend to add complexity where we should be removing it, we have communications problems, we have disconnects from our 'customers', we have difficulty delivering consistently, and we treat leadership as something that is granted at the wave of a new title.

I picked five elements in the show, but these are not the only parallels I saw. Management, passion, pride, respect, continuous improvement, keeping our eye on the "plot" ... IT doesn't have to invent everything from scratch. At the end of the day we are in an industry of people, delivering solutions to people, for problems that people created. All of the people-side issues exist all around us, in hundreds of different industries, we just need to step beyond our egos and be open to learning from them.

This isn't a new process or even a sales pitch on how you too can implement my process and save thousands. It's simply a walk through of the challenges that led to the process, the tools and practices I incorporated, and the steps I followed to build a lightweight process.

*Software Developer: It seems every developer position I've held has had a different definition of 'Developer' (and 'Programmer', and...you get the point). The positive side of this is lots of great experiences, the negative side is all the fun things I got to use/do and never again.

Building a Process

Just as we do (or should do) when building software, we need to have a purpose. Often the largest, clumsiest processes occur through a lack of focus or a desire to focus in every direction (ultimate flexibility, no limits, etc). That lack of focus leads everyone to add their own bits to the mix. One person adds what worked in his last project, someone else adds something she always wanted to try, more pieces are added to cover ever eventuality or risk that can be thought of....and Colossus is born, moving so slowly that all involved often think they are moving backwards and could be beaten by a 2 man team in a garage.

The purpose of process is to provide consistency and ground rules. A good process is an enabler.

I know, that sounds odd (and many of you probably think you are totally against having any process), so lets try a comparison.

Say we're working on a software development project and we are required to deliver code documentation as part of the project. Once upon a time this would have required a great deal of time to put together, keep up to date as changes occurred, etc. It probably would have been a full time job on any team over 3-4 developers. Then someone came along and said "Look, if we comment every function like so, then I can write a script to extract those comments and automatically build the documentation."

In the software world we call this a "convention". Incorporating conventions into our practice allows us to automate or get some extra value out of something simply because it's been done in a consistent manner (possibly with an extra step or two sprinkled on top).

Process is not inherently bad. Like writing software, there is never only one answer and even using the latest and greatest of tools you can build a ghastly, unmaintainable mess.

So Back to My Process

So recently I started the new job and I was given responsibility for adding some new capabilities to a system. I had the freedom to define my own processes, determine how I was going to get the work done, and so on. The critical deliverable was only delivery of working software, added in a manner not inconsistent with the existing platform.

My focus for the process is:

• Know as far ahead of time as possible if I was diverging from initial estimates
• Collect just enough data to re-estimate completion if order of tasks changed, interruptions occurred, etc
• Have a sense of accomplishment, see the work getting done
• Have a way to track how much of my time is spent on interruptive tasks, scope additions, etc

So this is my bare minimum set of requirements from my process, my focus.

Then we have some challenges:

• High potential for variability/change
  
  • I am new to the company and have a poorer feel for what they need than more experienced employees
  • The company hasn't had this type of system before, so the requirements will be more changeable and will require greater refinement along the way
  • I don't have direct contact with stakeholders or end users
• Limited experience with tools (existing, in-house architecture/codebase)
  
  • I am not comfortable (or was not) with the system I was adding onto
  • Standards are limited to finding existing examples to duplicate
  • Expected to convert some existing components for wider use w/ my portion without disrupting their existing functions
• No automated testing - the framework is challenging for unit testing
• Live environment - though my pieces of the system would not be live for weeks or months, the system is deployed weekly and existing portions would be used and revised
• I am a team of one - limits flexibility, easier to get "stuck in the mud" without someone to pull me out, limited to my own experiences

So having a focus and an understanding of my initial challenges, I built an initial process.

The End Process

From the focus and challenges above, I pulled together a minimal process. Let's look at that process then circle back around to the "why was that piece chosen". This process borrows heavily from Lean and Scrum processes, incorporating the idea of iterations (or sprints), a visual board, and a burndown chart.

I started by identifying the major features we were looking for in the system. Once I had these (through a series of conversations and prototyping), I had my manager prioritize them and help group them into potential releases. Initially this proved to be 3 major releases and a few extra features that would be prioritized after the last release.

Spreadsheet of prioritized features and releases

I put all of these features into a spreadsheet, along with their priority and a rough estimate in ideal days. In a separate page of the spreadsheet I broke down each of the features into individual tasks and estimated those tasks in hours. There was a little variance between my individual task estimates and the feature estimates, but they averaged out.

Spreadsheet of features broken down into tasks

In a third tab, I created a list of the available workdays for the project, an iteration code, a number of hours available for each day (initially 6), a calculation for number of hours remaining in the iteration, and an empty column for the number of task hours remaining. I then created a pivot chart for this table, grouping by the iteration so I could easily display a burndown chart of the expected hours being done against the actual tasks being completed.

Spreadsheet for tracking actual vs estimated work against tasks

Burndown chart from tracking data

The last spreadsheet step was to load up my first iteration without overloading myself. Adding an iteration code to my task list tab and some calculated fields (visible in the task spreadsheet screenshot above) let me total up how many estimated hours I was loading into the iteration.

Simple graphs of available capacity vs assigned tasks

After setting up the spreadsheet, I setup a visual board in the corner of my whiteboard. I created columns for tasks that were ready to be worked (tasks assigned to the current iteration), tasks in progress, tasks completed and waiting for the weekly deployment, and tasks that were completed and in the live environment. Within a couple days I also added an express lane at the bottom for bugs and high priority feature revisions.

Pictures of visual board over time

The sticky notes were kept fairly simple. The color indicates the type and each has the name of the task and the iteration code written on it. Though I did not implement WIP limits (Kanban) on my columns, I have unofficial numbers in my head to help me limit task switching.

As the iterations progress, I calculate how many estimated hours of work I get done per day and update that value in the third tab of my spreadsheet. This ratio of estimation hours to real hours then helps me project forward and see if I am on track for the final release, need to refine some tasks to reduce their estimated time, or potentially have some time to pull in tasks at the end.

How I Got Here

So I started with a focus and some challenges and ended up with all of that (which is actually a fairly lightweight process, it just took a lot of space to write it up). Here's the connections:

Why Iterative?

I chose to use an iterative process to help manage the risks for variability and my own limited experience. An iterative process would help me course correct far sooner and take advantage of my growing experience in the company and with the software instead of trying to base the entire project off of my knowledge on day one.

So the iterative process was chosen to help reduce the impact of risks involved with my knowledge of the software and my understanding of the requirements, as well as refinements that were expected to occur along the way.

Why a spreadsheet? Why estimated hours?

I chose to use a spreadsheet and this method of estimated vs real hours to address measurement of actual execution against estimated and provide an ability and data to re-estimate tasks as time progressed.

Can I have your spreadsheet?

Below is a link for the sample workbook I put together for the images in this post. Being an example, it hasn't actually gone through the process of being used, revised, marked up, etc like the actual one I use.

Download the workbook

It has no instructions, no notes, and is in XLSX format.

Why such small tasks?

Why did I break down the features at all? They're only a few days worth of work, couldn't I have just used those?

Well yes and no. By going with smaller tasks I can usually move one or two tasks from doing to done in any given day, which feeds back into my feelings of productivity and such. Smaller tasks also help me find out I've gone off the rails sooner or that I missed something critical. Additionally, smaller tasks are easier to move around, if I intend to do task 1A-1C but a bug comes in, I can wrap up my work on 1A, do the bug, then come back to 1B with a much lower task switching cost then if I was switching inside feature 1.

Small tasks also feed back into estimates, force us to evaluate the features more deeply, bring future issues to the surface early enough that we can start asking questions before we get to do-or-die time, etc.

Seriously, Sticky Notes?

I chose the visual board for several reasons. The first is that seeing the work flow across the board helps give me a sense of accomplishment. Good morale and a sense of accomplishment help keep me from getting bogged down or feeling like I'm not making progress. The visual board also gave me a way to see the level of revisions that were occurring and the impact they were having as the iteration progressed.

The final advantage was that the board reduced the time it took me to switch tasks, at any time I could glance at the board and see what I was working on last, what I would likely be working on next, etc. When I go into work after a 3 day weekend, it will take me longer to boot up my computer than to determine what I was working on. I also have a visual of how many tasks I am trying to work on simultaneously, and that causes me to try and limit that number, reducing task switching. In Lean terms, I have reduced my changeover time, some of the waste involved in those changeovers, and the number of changeovers that occur (splitting releases into features into smaller tasks also reduced my batch size).

What's Missing?

The only challenges that my process did not address were a method to limit the risk of working on live software without a safety net (other than manual testing). I did address this, but that's probably for another post.

Wrapping Up

The most critical part of creating a process is to know why your creating it. Without a focus, without knowing the goals and risks, you run the risk of creating something that costs more than it solves. Like programming or any other skill, selecting and building a good process is easier the more you do it. Pay attention not just to what does work, but also to what doesn't. My process is not perfect and it will have failures, I intend to learn from them. But I'm also learning from the processes I see others following.

If you are interested, here are some random links on related topics (plenty more in my Delicious bookmarks).

• The Uncertainty Principle OR How to Choose the Right Methodology - Kosmothink
• Waterfall v Agile: How Should I Approach My Software Development Project?
• Time Boxing Strategies to Help You Get Things Done in Your Project
• Methodology Doesn’t Matter
• Visual Management for Agile Teams