Software Development & Happiness

2011-06-29T09:07:00.000-07:00

In the past year and a half, I have had ample time to work on my Selenium wrapper and now things are working pretty well. Here are some things I have learned.

Selenium takes a long time to get working, largely because you have to solve a few problems:

How to make the same test run against multiple browsers
How to make the same test run against a development, testing, stage, and production environment
How to make a test run in a slightly different way on a different build of the test without having to do a bunch of hardcoding
How to make a test know what should appear on a page based on user type, state, version (so on).

Everyone has to solve these issue but, as of today, there is no solution that helps a person do this. If your company has an existing Selenium harness up an running, they have already solved this issue, but for those companies who don't (and thousands of new Internet companies are springing up as we speak) they all have to start from scratch.

Web pages are basically a collection of components. Selenium 2 started off in the right direction by building the PageObject pattern into their application. For a while, though, they left us hanging. Now they have a LoadableComponent built into their application, which looks pretty promising. They idea is that components can travel from page to page, so there is no reason not to reuse them. What you really want to do is define a bunch of components, configure which pages those components appear on under which circumstances, and then run your test and have it all just work

Lastly, websites have a few things in common. Generally
1. You can log in to them
2. You can join
3. You can search
4. You can purchase something

The steps for doing these are a fairly standard. It seems that you should be able to genericize these actions.

I am currently developing a yet-to-be-named, open-source project that will take care of all of this It is based on my work that I spoke about in the previous post. However it uses Selenium 2, TestNG and, soon, Guiceberry. I hope to have it done soon. I'll keep you all informed.

Selenium my way

2010-02-04T22:06:00.001-08:00

I was going to call this "Selenium, the right way" but decided that was a little arrogant, even for me.

I finally have the chance to start a fresh acceptance/regression automated test harness again and I chose Selenium RC. Why? The answers are obvious. It's free, version 1.0 is stable, it supports AJAX, can be extended to support Flash, plays nicely with all kinds of languages including the one I care about (Java), supports all the major and not so major browsers, and has matured into a first-class product since I first started noodling with it back in 2006.

I wanted our implementation to start with all the best practices. What's amazing to me is that, well, there's no one place to find examples of all those practices. So as a result of my adventures, I've compiled a list of all my digging.

Here's the environment I'm working on

OS: Windows Vista (snort)
Main Language: Java
IDE: Eclipse
Unit Test Framework: JUnit 4
Ant

Requirements:

Need to test multiple domains and subdomains
Need to support AJAX
Need to support Flash
Need to support various user roles (anonymous, regular, admin)

It seemed to me like this would be a pretty common setup. Well, I couldn't find examples of how to do this stuff. I can't find the quote (I think it's Annie Lamott) that likens the Internet to an overstuffed, disorganized garage ("I know it's in here somewhere") but I was definitely feeling that way. So I put together this list, not just for myself but for any other souls who have a similar setup.

PageObjects
Most of the basic examples tell you to simply record your steps and output them to your language of choice using the IDE and then paste that snippet into your code. Sure, that's cool, but it's not very scalable or extensible. The out of the box snippets your IDE gives to you are cool, and they're a great place to start, but they are brittle. If you want a robust set of methods that will be like building blocks for other tests, you'll have to do a little more than just paste in what the IDE spits out. Here is a great paper on how to make your test code less brittle.

To deal with this, the Selenium people talk about using the PageObject model. But if you aren't using Selenium 2 (which is in alpha as of this writing) then you're out of luck getting an example from them. Having just spent the last year on the bleeding edge, I wasn't excited about depending on alpha software. Furthermore, the PageObject model has it's share of detractors, including Gojko Adzic (one of my heros).

Based on my reading, I took the approach outlined here and here, which is somewhat of a hybird model of PageObjects and the action groupings Adzic speaks of. Basically, I have a bunch of PageObjects. But I also have what I call a Macro object, which includes all the PageObjects and contains methods that assemble them together in often used configurations (like go to the homepage, click the sign-in link, and once on the sign in page, enter user and pass and press continue).

CSS Selectors
Buried in the Selenium documentation is a helpful tip - CSS Selectors perform better than XPath for locators. It's true, they burn. I found a few a sites to help with CSS syntax. Unfortunately, CSS is not as fully featured as XPath and for those really tricky locators; you can still use XPath, but favor CSS Selectors.

Ultimately, the best way to control this is to use the id attribute of your element, but the test department doesn't always have control over that. In may case, the front-end developer always tries to make my life easier, but is not always able to offer me my ideal solution based on technological constraints.

Suites and Tests
I really don't get why people don't have any Suite examples. It seems to me you want your suite to do a bunch of setup (like initializing the Selenium object) that is going to exist for the test and then have your test up. So I found an example of how to do this here.

The disadvantage of this is that you never run individual tests (because you don't have a Selenium object to start if it's in your suite). Instead, you invoke the test from the Suite level, so you always need a suite. And, if you're debugging tests, you'll orphan a bunch of controllers. Not a huge deal in my opinion.

I extended both SeleneseTestCase and TestSuite because there are things I need to do in them. Specifically, I wanted to make the Selenium object available to all my PageObjects without having to pass it in specifically, so I simply created a static reference to it in my AbstractTestCase and created the getter and setter. My test suite sets up my AjaxSelenium object and sets it in the AbstractTestCase and also initializes my properties using my properties file, which it gets from the Java ClassLoader.

Extending the DefaultSelenium Object
The Selenium doc says you don't have to do this. However, Selenium RC doesn't implement the "waitFor..." methods from the IDE that you absolutely need if your site, like most of the sites on the Internet now, uses AJAX. I found that the best way to support AJAX is to extend the DefaultSelenium Object and found a great example right here.

Note, this code throws the ElementNotFoundException. It apparently comes from HTMLUnit, which I'm not using. So I just created my own.

JUnit
The Selenium community clearly prefers TestNG, probably because it has matured faster. JUnit is just about caught up. I decided to convince my team to upgrade to JUnit 4.7 because I read somewhere that it has better support for parallel test runners than 4.6, the version that the concept was introduced into JUnit. Since I eventually want to run Grid, I thought it best to bite the bullet now.

The Elusive UI Map
The Selenium documentation refers to a way to reuse locators through the use of a UI Map. Most searches on UI Map and Selenium lead to the UI-Element extension. Some people really like this extension, but I am not a big JavaScript/JSON fan, so I find it annoying and frustrating to use. I decided not to incorporate UI Map because most of what it offers I'm getting from my use of the PageObject model. The way I decided to deal with locators was to simply hard-code them into the methods for the page objects. I felt this was easier than creating namespaces for all of them in my properties file. I think this also makes it easier for me to find problems. Instead of digging though a properties file to find a variable, I simply find the method that failed from the stack trace in my custom ElementNotFoundException and fix the locator.

Firefox and self-signed Certificates
I don't claim to understand anything about security. All I know was that this was a pain in the butt. Here were the instructions I followed to get around the issue.

Incorporating Selenium into your Development IDE
There are complete instructions for how to integrate your code into IDE so you can run your tests via the TestNG or, in my case, the JUnit runner. However, I had a difficult time finding out how to make it so that I could start the server from within the IDE. Finally, I found some helpful instructions. Then I just turned it into an Ant script, which includes the server bit of my workaround for the Firefox self-signed certificate issue. Note, if you use the Ant Script, you'll still need to create the cert.db file by following the directions above if you have self-signed certs.

Properties file
Standard practice. There are some basic properties I need to run my tests (like user/pass stuff). I put all this in a properties file and have the AbstractSuite load it up, as described here. In addition, I create base properties and subdomain-based override properties because the data values vary from machine to machine.

Constants
I created a Constants interface for the things I wanted to share and simple had my AbstractTestCase extend it.

Handle Download Dialogs
Supposedly, Selenium 2 will do this because it has WebDriver. As I said, I didn't want to deal with Selenium 2 yet. So this got me around the problem

LoggingSelenium
If you want any sort of decent reporting, you'll need to download LoggingSelenium and set this up. There's a nice example here. Note that if you use the AjaxSelenium above, AjaxSelenium will need to extend LoggingDefaultSelenium

Other Good links

* Ajax, Selenium and Fitnesse
* FlashSelenium - This was the best link I could find on this. We are still implementing so this may merit further blogging.
* Data Driven Testing with Selenium - I have yet to try this one but it looks promising.

Solving Problems with the Business Quality Analyst Role - Part III

2010-01-08T12:49:00.000-08:00

With automation divvied out to the developers, prioritization and requirements clarification with the Business Owners, and project management in the hands of the scrum master, what's left for the BQA to do?

The way we built the role, the BQA does the following:

Write stories and acceptance criteria – Forget the old documents (specifications and test cases). All that is needed is a story that contains the requirements, acceptance criteria, and any necessary technical/implementation details. The BQA can gather this info from Business Owners, Designers, and Architects and
assemble initial proposals of what should be included in sprints/milestones/releases – Since the BQA has the most information about the stories, it makes sense for the BQA to drive this effort in collaboration with Business Owners and Tech Leads.
Drive the demo – The BQA walks the team through the features because they are the most familiar with it, having written the requirements and tested it.
Advocate for testability – Testability features can be a huge time saver not just for testers but for the team at large. While not every feature needs accompanying testability features, an experienced tester will recognize which features will benefit from being more testable. As a BQA, one can advocate for testability early, keeping in mind that where testability is concerned, good is usually good enough.
Write Documentation – While Agile favors conversation over documentation, there is nothing saying that documentation should be eliminated altogether. In fact, for some people, the very act of writing something about a subject increases their ability to learn about it. I feel that the BQA, being the hub of information, is the best candidate to document features, particularly when it comes to documentation on how to test a feature.
Act as an alarm system – Traditionally, QA holds off on saying anything about a problem until a defect is reproducible. On an Agile project, this strategy may result in information that comes too late. The team is relying on everyone to raise the alarm as soon as you notice a problem. Time is of the essence. Since the BQA is central to the process, it makes sense for them to raise alarms as soon as possible when they notice problems. Note, I don't mean that BQAs should always file defect reports when they notice problems (see my earlier posts on this).

Business Analyst Anti-patterns

Working in vacuum – You've spent a few hours by yourself without talking to someone and you're feeling stuck. You probably need to collaborate.
Too much detail – You've built a table of acceptance criteria that took you 2 plus hours. It's long and complicated and no one understands it. You probably need to simplify
“They can take it out later” – This is waste. You can also put it in later. Don't include it and confirm this with the user at the demo. Save the story for later so that any work you have already put in can be reused.
Not spending enough time at the beginning – In part two of this article, I talked about letting things marinate and making sure you thoroughly understand how a feature is supposed to work. Some analysis and story writing takes much longer than we anticipate. Collaborate with your team if your exploration into a feature is producing new information.

Problems we encountered with making testers into BQAs

BQA was the bottleneck – At the beginning of the project, you need to write the stories before you write code. We simply didn't know how many people we were going to need to write the stories and we underestimated. We had two BQAs for about 15 developers. Eventually we got to the point where there was BQA for every 5 or so developers. This was still a lot of work but was manageable.
Testers tend to be less outgoing about their work – Most people in a software organization don't care about how testers do their job, only that they report the results and that those results are accurate. As a consequence, testers tend to be less reliant on other teams outside of development for information and tend not seek help in other areas of the business. Business Analysts need to talk to everyone so if a tester who is becoming a BA is hesitant to seek information outside of the development group, they are not going to be effective.
Testers naturally do things wrong – Given a minimal set of instructions, testers tend to get the instructions wrong. In part, this is what makes a good tester. But many testers also need to learn that there is a time to follow directions and a time to break the rules. Also, many testers could stand to ask for more help and clarification when the directions don't make sense to them. When testers are doing Business Analysis, they will need to follow directions and get clarification. It doesn't serve them to find bugs during the analysis phases of the project.

Solving Problems with the Business Quality Analyst Role - Part II

2010-01-07T15:49:00.000-08:00

If I'm a tester, how can I become an Agile Business Analyst?

Some of the skills you'll need are those you may already have. Here's some of the concepts I learned as I was improving my skills as a Business Analyst and, at the same time, increasing the quality of my project.

The “Funnel” – When writing stories for a feature, start big and get smaller. Don't start with details. In fact, don't even bring in details until you have a set of story titles that cover the feature.
Be concise – If you can say it three sentences, see if you can say it in two. Think of your stories in terms of journalism. Be sparing with your words. Your audience, the business owners and developers, don't want to spend more than a few minutes with your story. Interestingly, you can also start applying this principle to defect reports.
Know your feature – Particularly if you are rebuilding a feature that already exists, don't rely on other people's description. Prove to yourself that the requirements you have heard are accurate. Better still, if the feature exists, play with it before you talk to anyone and know what it does so that instead of asking how it works, you are confirming how it works. This makes you look good. If you don't have the technical ability to determine how something works, create a task to have someone do that for you. The situation you don't want to be in is to find out that something doesn't work the way someone told you it did and you didn't bother to confirm. That's a BA foul.
Define the boundary in your story titles – Story titles separate distinct pieces of functionality from one another. It is important that your story titles clearly summarize the functionality and that they distinguish that functionality set from other functionality sets in the feature.
Be clear – This is particularly important when dealing with offshore teams. Avoid vague language. Use bulleted lists to help you convey your point. You don't want someone offshore to get stuck because you used the wrong preposition, and believe me, it can happen.
Collaborate – You are not alone, other people will help you. Find someone you can check in with often. Find people to check your stories for clarity, particularly if you are working with an offshore team. Have them check to make sure your story titles describe distinct functionality. Ask them to check for accuracy. It takes a village.
Prepare – Don't play a story until it's ready because the team needs it. Wait until you feel it is ready. Sometimes, a story needs to marinate. This is not always easy because sometimes there is pressure to “feed the team” particularly if the coders have devoured the sprint backlog and are ready for new stories. I'd urge you to resist the temptation. After a while, your gut will tell if something is ready.
Get visual – I like to use charts and diagrams to explain a piece of functionality. Visualization is also a great tool for learning about a feature and can help when you need to describe something. A picture is sometimes worth 1000 words.
Be on the lookout for patterns – As you are building your story titles or writing stories, you will likely notice that some pieces of functionality follow the same rules as others. When you see this, it can help to take an Object-Oriented approach. Rather than transcribe the same rule into each story, have a set of Global Business Rules that you can refer to from within your story. That way, you can reference them when possible. And if those rules change, you will only have to change the rule and not the individual stories.
Analyze, Verify, Recommend, Prioritize – This is the pattern for getting a feature ready for development.
- Analyze – Find out how you think the feature works.
- Verify – Talk to other people to confirm that feature works the way you think it does.
- Recommend – Write the story and make recommendations about how to resolve problems and/or retain scope.
- Prioritize – Work with the team to determine the order of the stories.

In the next part, I'll talk about the duties of the BQA and some BQA anti-patterns.

Solving Problems with the Business Quality Analyst Role - Part I

2010-01-05T15:46:00.000-08:00

Several Agile Thought leaders, most notably David Anderson, have proposed combining the Business Analyst and Quality Assurance role. The idea harkens back even to Goldratt, who suggested moving Quality Assurance further up in the production line, to improve throughput. Gerry Weinberg has suggested that quality starts at the requirements gathering phase, where it is important to apply the scrutiny and attention to detail that a good tester brings to his/her work.

Combining the roles of Business Analyst and Quality Assurance makes theoretical sense and solves the ever lingering problem of what to do with testers in Agile projects who aren't coders. However, the implementation of such a role comes with its own special problems. At my last company, Tacit Knowledge, we found this out when we introduced the role on one of our projects.

Why would you do this?
Our reasoning was simple. We were having problems finding resources who were both experienced QA Leads who also knew how to code. We decided to stop looking. What we had on staff was QA Leads and Business Analysts. So we paired them.

We all know that the ideal Agile Product owner is indeed a rare bird. Another motivation behind this role was to be realistic about Agile Product Owners. Part of the BQA's role is to write the agile stories, a task typically left to the Product Owner. This relieves the Product Owner of that task and allows them to focus on requirements clarification and prioritization, which, in most organizations, is plenty of work for one person.

Who fits the role?
We found that the role required a combination of testing skills, business analyst skills and project management skills. People who are accustomed to wearing multiple hats and who were flexible in terms of what skills they needed to bring to the table at any given time were generally successful.

An accurate job description of our implementation of the role would entail the following:

Analyzes information gathered from business sources and/or existing code base and collaborates with team to clarify ambiguous customer requests or answer questions
Harvest requirements and translate into development-ready stories with testable acceptance criteria with the right amount of detail just in time
Facilitates meetings with business, specifically requirements meetings and demos of working
software
Facilitates meetings with developers to introduce features and clarify requirements
Advocates for testability
Identify problems early in the process and collaborates effectively with team to determine resolution
Takes large sets of functionality and breaks them out into smaller, logical and iterative pieces
Prioritize requirements for sprints, releases and milestones in collaborative effort with business owners
Provide requirements clarification for development
Creates concise documentation (cheat sheets) to aid in validation
Validates acceptance criteria
Coordinate business acceptance of completed development
Remind the project community to focus on the project goal
Select and insert appropriate tools to assist in defining project goals, requirements, or communicating project progress.

What are the advantages of combining the two roles?
One of the major advantages to the role is that it reduces some of the waste that is inherent in the system. Testers tend to have to do a certain amount of Business Analysis for themselves, either because the acceptance criteria weren't clear enough to be tested or because the requirements changed by the time the feature got to the testing phase. By combining the roles, you invariably end up with testable acceptance criteria when the feature enters design or development. In addition, a tester can identify testability features that will pay off in the long term. This reduces the amount of waste produced in the development cycle. Finally, because the tester is already familiar with the feature, the testing takes less time.

What are the problems?
Unfortunately, not every tester or Business Analyst makes an effective BQA. The BQA role requires the right mix of flexibility and diligence. Generally, testers tend to be a little too diligent for the role and Business Analysts tend to be lax when it comes to the testing piece. Testers are reluctant to give up their diligence because the trait is highly prized in traditional testing departments. Most testers have seen other testers fail due to a lack of diligence. But what works in testing can prove to be a hindrance in Business Analysis where people often have to trade-off attention to detail to get a feature moving through the system.

In the next part, I'll talk about how can you make a business analyst out of a tester.

Towards an Adaptive Software Development Task Workflow Based on the Theory of Constraints – Epilogue

2009-12-17T09:24:00.000-08:00

I had lunch with a former-colleague, Brian O'Rourke. He said he had read the blog and had missed how the workflow I described was tied to Kanban. I explained that, in part two, I briefly discussed how each phase had it's own Kanban system by virtue of having a bunch of tickets in the “Ready” state.

What Brian pointed out to me is that there is a simple way to adapt the proposed workflow so that it clearly represents a Kanban system, and you can do it on a whiteboard. It would look like this:

	Ready	In Progress
Analysis
Requirements
Design
Development
Testing
Acceptance

Once you do this, you simply move the story cards around on the whiteboard freely. This is an adaptation, of course, of the traditional "Agile wall" concept. It simply brings a different level of organization to the idea. Most agile teams organize their Agile Wall by feature. I tend to like to organize my feature work differently.But that's for a different post.

There are a couple advantages to having this system on a whiteboard.

These days, tools are either story oriented or defect oriented. There's very few which do both. I'm sure that will change soon, but right now, the business-side of the operation tends to track their work in a separate tool from development. The proposed table is a no-tech way of getting everyone to see everyone else's back log
There is no limit to the transitions – Since it's not in a tool, stories can simply by moved from backlog to backlog. Any rule enforcement would happen at the daily standup meeting (assuming you are having one and many people are, regardless of whether they are Agile or waterfall)

The disadvantage comes when you have a remote team, since they have no access to the whiteboard. I'm not going to go into whiteboard solutions here. You'll need to experiment with this. Suffice it to say that I don't believe tools should be a limitation, but rather they should enhance the work of the team. No one should spend a lot of time administering tools or keeping their data up to date.

Another disadvantage of this is that it probably would not work so well in a waterfall methodology, in that you would probably tend to get clumps of stories that would quickly become unmanageable (although, that would be a great illustration of the problems with the waterfall approach).

Assuming you don't have an offshore team and aren't using waterfall, I see no reason why Brian's nifty proposal wouldn't work like a charm.

Towards an Adaptive Software Development Task Workflow Based on the Theory of Constraints – Part III

2009-12-09T11:04:00.000-08:00

In my last entry, I outlined the happy path of the workflow. Now it's time to talk about "retrograde" transitions.

A “retrograde” transition occurs when a task has to go backward in the workflow. In my implementation there are 7 such transitions but 3 are essentially the same (Clarify Requirements), having the same target with different sources.

Any retrograde transition whose target comes before the development phase in the happy path could generally be called a “Clarify” transition.

The transitions I've outline here are:

Needs More Information – Occurs when the person writing the specification, typically the BA, requires more information from the product owner to complete the specification. This could be called “Clarify Analysis” but that seems unclear to me.
Clarify Requirements – Occurs at several points in the workflow when anyone doesn't understand the specification. Requirements gatherers tend to be the hub for project information, hence the number of transitions back to the requirements gatherers is large.
Clarify Design – Occurs when the technical or user interface design is unclear. I'll talk about disambiguating between technical and UI design later.
Not Working to Specification – Simply put, this is a defect. I'm not going to go into detail about how to handle this situation and what to do when; That's for another entry.
Needs Product Owner Analysis – Occurs when testers determine that a feature is so messed up that whoever wrote the specification couldn't possible have the right information.

I'm not sure this last transition is necessary but I've included it as an example. You could, in theory, link all "In Progress" states to all "Ready" states, just so that the team is empowered to make those transitions. However, that implies that every member of your team has all the information to make the correct determination for each transition. I don't like to force people down one path or through one group since that creates a bottleneck. On the other hand, specialization -- when used wisely -- can create efficiencies so it may make sense to limit the number of retrograde transitions. Whatever works.

There are two possible drawbacks to using this workflow:

When going backwards in the workflow, we tend to want to assign a task back to the person who worked on it originally because that person has the most context and therefore is the most efficient choice for getting the work done. For this reason, you may want to allow tasks that got into the "Ready" state from a retrograde transition to be "Assigned". Yes, I know; This contradicts the rule I stated in the previous post. And a rule like this can get confusing because people might just start directly assigning tasks in the happy path if they see Assigned tasks in the "Ready State". You probably wouldn't want to enforce the rule through automation because it would likely take lot of effort to code and doesn't give you a huge return. So I suggest creating a filter to monitor "Assigned" tasks in "Ready" states to make sure that direct assignment happens only for retrograde transitions.
“Ready for Design” could mean that a task is ready for technical design, UI design, or both. Typically, design work is done by separate teams and can happen concurrently without dependencies, though each team can also be dependent on the other. I don't know of any task tracking databases that allow you to represent concurrency of work in this way. Most teams handle this by assigning whoever is writing the specification to coordinate with designers and technical architects and manage the status of the tasks in the Design phase. I don't see a way around this. However, I still think that it is important to have separate statuses for the Design phase. These statuses allow the team to distinguish between the designers backlog and the backlog for whoever is managing the designers work. It also allows the person who is both managing designers and also contributing in another phase to indicate when their contribution is ready for the next phase.

Regarding the rule about having no more than one in-flight task at a time, I use filters to track this. I'm a big fan of filters. On my last project, I created a filter that allowed me to see if team-members had multiple tasks assigned to them. It's usually impossible to get this down to one task per person, so I am generous and allowed 3. I regularly sent out a note to team-members who had more than 3 tasks assigned to them at once to ask them to update their tasks. This typically worked very well and most people complied by updating their tasks or talking to me about why they had such a large number of in-flight tasks assigned to them.

I must admit that I have not yet had the opportunity to try this workflow out. If any you know of any teams working with such a workflow, or if you are inspired by this one and get the chance to work with it, please let me know.

Towards an Adaptive Software Development Task Workflow based on the Theory of Constraints – Part II

2009-12-07T11:55:00.000-08:00

In my last entry, I described a methodology-independent workflow for software development, the purpose of which was to help team members identify where the constraint is in their life-cycle. The workflow is intended to be phase-oriented as opposed to being tied to specific job duties. By phase, I refer to the typical phases of a software development life-cycle: (e.g. Analysis phase, Requirements phase, and so on).

The best way to understand the proposal is to imagine an assembly line. Products move through the assembly line in a linear fashion. As the product gets stuck in a particular phase in the assembly line, the people working on the product in that phase develop a backlog, since the people working in phases before the product got stuck are still working and producing product. Also, the people who work in phases after the product got stuck become starved for work. Furthermore, once the people working in the stuck phase are able to produce more, the people in the phases downstream might become overwhelmed and develop their own backlogs.

Since the software industry is filled with many talented people who are able to perform multiple roles, it makes sense to put people who are not particularly busy to work in areas where the team is constrained. However, that usually takes a lot of effort to coordinate. The workflow proposed here makes that information available through a Kanban-like system. What this means is that tasks are not assigned directly to the people in the team who are designated as the specialist for a particular phase of development. Rather, tasks are put into a status that indicates what phase they are ready for. The benefit is twofold:

It allows the team to see how many tasks are ready to go into each phase, thus allowing the team to identify the constraint (the longest backlog)
It supports the idea that team members other than those specifically identified for that phase can work on tasks in that phase to help alleviate any constraints. This notion happens to also work very well to support the practice of “self-organizing teams” prevalent in many development shops using the Agile methodology.

In order to better illustrate this workflow and some of the typical transitions that a task might go through, I have created a graphic. Please note that I have not covered all possible transitions nor is this particular graphic intended to be a description of every software process everywhere. Rather, consider this a specific implementation based on my experience in the software industry, which has largely centered around building e-Commerce web sites.

The pink circles are the Ready states. It is through counting tasks in these states that the team will find the size of the backlog for a particular phase of the life-cycle. The amber circles show that work is in progress for the particular phase. The bold lines indicate the “happy path” of a task through the life cycle. The transition from any Ready state to its corresponding In Progress state is probably “Assigned”. The transition from any In Progress state to the next Ready state is probably “ Complete”. Note also that there are no connections between two Ready or In Progress states. Again, the idea is to prevent team members from directly assigning work to others.

It is important to note that this system will work best when team members work on only one task at a time. If any team member has several tasks in progress, this more likely means that some of the tasks are blocked, possibly another phase of development. In this case, the team member should unassigned the blocked task back to the Ready state of the appropriate phase.

I have created two paths to the Ready for Development state, one that goes through the Design phase and one that bypasses it. It is my experience that Design is sometimes performed for a set of tasks. Tasks that get played later in the time frame benefit from the Design phase having been completed on similar tasks and do not require design.

Note also that I did not create transitions for Acceptance phase back to other phases. In have never seen two teams handle this in exactly the same way, so rather than suggest something that applies to a small set of people, I am going to simply state that one can do one of two things:

Create the necessary transitions and allow Acceptance testers to determine which phase a particular task is ready for or
Designate a person or group to help Acceptance testers make that determination. That determination can be it's own separate phase or not.

In my next entry, I will add details about the "retrograde" transitions in my specific implementation.

Towards an Adaptive Software Development Task Workflow based on the Theory of Constraints – Part I

2009-12-01T11:25:00.000-08:00

Whew! That was a mouthful. I'll probably need a couple of days to explain this one.

If you're going to use a defect tracker, it will come with a built-in workflow that probably will not accurately reflect your process. The allowable workflow statuses are typically something like these:

New
Unconfirmed
Assigned
Resolved
Verified
Closed
Reopened

The problems I have with these statuses are:

They imply ownership but do not state that ownership specifically
- New is probably a product owner issue but may be able to be assigned directly to a developer.
- Unconfirmed probably needs some triage but may also need requirements and those tasks may be owned by different roles or individuals.
- Assigned usually means that it is assigned to a developer but doesn't tell you if that task is in progress
- Resolved usually means that a developer completed their work on this
- Verified usually means that it passed testing
- Closed – QA usually ends up doing this after the task is in production but what it means is not clear.
Most of the statuses represent the developer workflow and to that extent, the statuses are too granular because they tell me things I don't need to know (why do I care if something is reopened?).
Other roles in the workflow are under-represented. Testers often end up doing project management because they're tracking tasks in the defect database and have to work with product owners and business analysts whose statuses aren't represented. How do I know if a business owner or product owner is in the process of looking at a task? I have to ask them because they can't indicate this via status in the defect tracker.

Good defect trackers allow you to modify the workflow but most force you down a particular path. Bugzilla, for example, was made for open source software so its workflow is particular to that paradigm. For some reason, many other bug trackers have lifted this insufficient workflow from Bugzilla and it has spread like an infectious disease.

Some former colleagues of mine – Matt Short, Dennis Britton, Sueryun Kim, -- and I got to discussing this problem one day a little over a year ago and came up with something resembling the following idea (forgive me folks if I'm putting words in your mouths). We wanted a workflow that would allow any team member to accurately assess the task backlog for each role within a software development team. We're all fans of the Theory of Constraints (TOC), a management philosophy which says simply that a team can go no faster than it's slowest member.

To picture this, imagine a boy scout troupe on a hike in the forest. They must travel 10 miles in 5 hours to reach their destination, meaning they must walk rate of 2 miles per hour. If one scout is only capable of traveling 1 mile per hour, the troupe will not make its goal. This slow boy scout is called the constraint. So under the Theory of Constraints, a good troupe leader will do everything in his/her power to identify the constraint and help that team member go faster, since the success of the team depends on it.

If you look at a software development task from the perspective of the Theory of Constraints, every task has only two possible statuses for every stage of the life cycle, it's either ready to enter that stage or that stage is in progress. If that stage is complete, then at the same time, the task is also ready for the next stage until the final product is released.

If you combine these status with the stages in a typical SDLC, you get a list of the following statuses.

Ready for Requirements Gathering
In Requirements Gathering
Ready for Analysis
In Analysis
Ready for Design
In Design
Ready for Development
In Development
Ready for Validation
In Validation
Ready For Acceptance
Closed

Optionally, instead of closed, you may have:

Ready for Production
In Production (Complete)

There are a couple of advantages to using a workflow similar to the one described.

It is easy to understand and explain
From a TOC standpoint, it allows you to easily create a report to identify your constraints
It is not specific to a particular software development methodology. Anyone using waterfall, RUP, Agile or any other methodology could easily use this workflow and still have better information than they currently have on the status of their release.
It is generic enough to cover most tasks in order to avoid separate workflows
It supports self-organizing teams and Kanban in all roles if everything that is in the “Ready” state is set to unassigned.
It is flexible because it doesn't assume that particular stages are attached to particular roles which allows anyone to pick up a task in any status.

Tomorrow I'll talk in greater detail about the workflow transitions and how Kanban fits in to all of this.

QA as Headlights

2009-11-30T15:48:00.001-08:00

Most people in software are familiar with the metaphor of “QA as gatekeeper” and most of the software companies I have been in suffer from putting QA into the position of deciding whether or not a particular release candidate should be released to the public. More often that not, this eventually leads to the Director of QA getting fired. Why is that?

QA doesn't have the information that business owners have about what is important to the release and what isn't. Rather, QA has information about what the risks are with the current release. But it doesn't have all the information on the priority of abating each risk. The product owner usually has that information.

I like to think of QA as being like headlights on a car driving down a dark country road at night.

Your headlights on your car allow you to see what is ahead of you so you can react appropriately. If an animal runs across your path, your headlights allow you to see the animal. But the driver decides how to react, whether to brake or swerve or run it over. All are valid options but the headlights don't have the information to make that decision. Likewise, QA's performs its function by showing the team where the problems are and providing the team with information so that it can come up with the appropriate response.

If one of your headlights burns out, you'll have less information. Maybe you still have the information you need and maybe you don't. But police don't ticket drivers for having burned out headlights for the fun of it – having burned out headlights increases the risk of accidents. In the same way that you can drive with burned out headlights, you can understaff your QA department. Doing so doesn't guarantee an accident, but it certainly decreases your visibility into the health of your release.

You can drive too fast for the distance you can see with your headlights. When driving on a dark road, you want to use your highbeams. This allows you to see farther down the road, giving you more time to react to hazards. Likewise, you need to give your QA team ample time to complete their tasks. The less time you give them, the fewer hazards they spot accurately. Let's say that with your low beams, you can see that there's ice on the road for the next 300 ft. Does that mean there will be ice on the road for 400 - 500 ft? That's a risk regardless of whether or not there's visible ice in front of you. And if you're going 70 mph when you see that ice, you'll have less time to react to it than if you were going 40. Fortunately, in software development, we have this thing called “overtime”.

These days, cars are getting smarter and some of them will even park your car or start beeping at you or even brake if you're getting to close to another car. However, none of us want our car making decisions for us because our cars, at this point in technological development, have no way of having enough information to make a fully informed decision. For that same reason, you don't want QA to be the gatekeeper. QA has part of the story. QA may even have a lot of the story. But it doesn't have the key part of the story, that being what is most important to the customer. Of course, you could ask QA to take on this piece, but that would divert them from assessing risk and you'll need to hire more QA folks if you go down this path.

A typical complaint about QA departments is that testers miss things, which is to say they sometimes fail to illuminate a particular problem. I don't believe this is the case as often as it is stated to be. As you can see from above, there are many reason why your headlights might not illuminate something. However, there is always a possibility that a QA team gets all the necessary time and resources it needs and still misses something. It shorts out. This happens. Mistakes are understandable and good management will try to understand all the factors at play in a particular mistake before pointing fingers at the testing department, which is usually everyone's favorite scapegoat.

The Agile Carrot and the Waterfall Stick

2009-11-05T14:49:00.000-08:00

I have noticed a disturbing and pernicious trend in development similar to the old bait-and-switch.

One of the benefits of working with Agile practices such as “inspecting and adapting”, documenting just-in-time, developing iteratively, demonstrating working software, and measuring velocity is that your team becomes more productive at the outset of a project in comparison with a waterfall project. If you are doing it right, you not only realize quickly when a project is doomed to fail but also have real numbers to prove it in the form of burn up charts. Some product owners consider this a benefit but others consider it a nuisance. Those who think it is a benefit are those who are willing to trust their team and then, ideally, do one of two things:

Adjust expectations appropriately.
Make any/all recommended changes the team suggests and wait to see if the outcome results in an increase in velocity before announcing that the project is back on track.

Those who consider advanced warning a nuisance are those who have a fixed idea about when needs to get done by when and aren't interested in anyone who contradicts that.

At the beginning of a waterfall project, most people are still recovering from the last death march, taking it easy, thinking that they have time to kill. And why should they bother working? They know they're headed toward the next death march, so they should take their time off when they have it.

In an ideal agile project, you proceed at an even pace throughout, assuming that your team has committed only to what their velocity will allow. Because you only commit to your recent velocity, you can be fairly certain (assuming decent requirements analysis) that your team will hit its goal.

Some people have asked themselves why they can't have both: a productive team from the outset that goes on a death march at the end of the project.

What would that look like?

A recent example I know of goes like this. A team accepts a project and estimates that, given certain parameters, they are willing to commit. They start demonstrating at the end of each sprint. Preparing for the demo costs the team a little bit of time that they could otherwise spend developing, but they know that although they lose development cycles, they gain transparency.

The product owner starts to change the nature of the agreement, which is expected. The team notices the scope increase and warns the product owners that they will be unable to make their commitment, given the velocity.

Product owners ask the team how they can increase velocity. But here is where the problem starts.

Let's say it takes me an hour to drive to a friend's house but my friend wants it to take less time. I could drive faster, take an alternate route, leave earlier, so on. But I have no guarantee that any of those things or even all of them combined will decrease the amount of time it takes to get to my friend's house. I could run into a strong headwind, or traffic, or maybe get stopped by cop for speeding. Any number of things can go wrong. And even if my trip time decreases, I have no guarantee that the next trip will take more, less or an equal amount of time. It is the same with software development.

Back to our example, let's say the team suggests removing specific impediments. The product owners agree to do so and, voila, velocity increases. Because velocity increases, the product owner feels comfortable with increasing scope even more. The team, however, continues to demonstrate at the end of every sprint, serving to show in the customer's mind how far away they are from actually hitting what only the client knows is the actual goal. The team continues to show their burn up numbers, but everyone realizes that there is hidden scope.

Finally, the product owner no longer wants to be reminded how far away the team is from the goal and decides to stop attending demos or even asks the team to stop giving them so they can get back the time they spend preparing for them.

The team gives up the demo with a bit of short-lived relief. It's not always easy to cut a branch every two weeks and then put on a dog-and-pony show. But the team loses its ability to determine if that time gain has any affect on velocity. Without that transparency, which is the cornerstone of Agile practices, the team's ability to estimate becomes unreliable and the death march begins.

Above all, Agile requires discipline. Anyone who has been on a failed diet or exercise regimen knows that discipline is easy to lose. Agile is not a silver bullet. It is a set of practices that used together and regularly have been known to lead to happier, more efficient teams. However, like a good diet or exercise regimen, it is only effective when it is maintained. Constant vigilance is required on behalf of all the team members to maintain the discipline.

Good testers file fewer defects

2009-11-04T21:33:00.000-08:00

I have known of testers who brag about having a high defect count. I have also had QA Managers who wanted to measure me by the number of defects I found, their assumption being that the more defects I found, the better I was.

Just because a tester has a high defect count doesn't necessarily mean they are a good or effective tester. There are two reasons for this:

You can only know a good defect by it's Resolution.
Better Quality Assurance upstream reduces the number of downstream defects.

Let's go through each point.

You can only know a good defect by it's Resolution.
Those who brag about high defect counts may be missing the fact that most defect databases allow you to resolve your defect with something resembling the following statuses.

Fixed
Won't Fix or Works As Designed
Duplicate
Cannot reproduce

Any defect that is resolved in anything other than Fixed should not be counted toward the tester's valid defect count. In fact, testers should do everything they can to avoid filing defects that might get closed with “unfixable” resolutions.

Now, the fact is that some software leaders encourage their testers to file any and all defects they find. But what these leaders fail to realize is that a considerable amount of effort goes into resolving even the smallest of defect. If a defect ultimately doesn't get fixed, the effort that went into resolving it is wasted. Good developers follow up on every defect, even if they suspect it is a duplicate and that follow-up takes time.

Testers who file defects with little or no consideration to how it might be resolved usually end up creating more work for the team. Even good testers file defects that don't get fixed, but the ratio should be reasonable, somewhere in the region of 80% fixable for a seasoned tester.

One of the main reasons testers file defects that don't get fixed is through lack of communication. They simply don't bother to talk to the developers, business owners, or fellow testers to determine how something is supposed to work, whether the application is configured correctly in the testing environment, or whether a defect has already been filed. In most of the companies I've worked in, this sort of cross-departmental conversation isn't expressly discouraged but it's not encouraged either. Its common to find an environment where testers are siloed. In an environment like that, it's up to individual testers in this situation to strike out on their own and make the difference, to be a great tester instead of a good or mediocre one.

2. Better Quality Assurance upstream reduces the number of downstream defects.
In today's software projects, there is Quality Control and Quality Assurance. People quibble over this terminology but they really are two different things. Quality Control is the process of testing the product and reporting defects in order to determine how risky it will be to release a given candidate. Quality Assurance is the process of reducing the likelihood that defects will occur during the software development process. Most software QA departments these days do both but with a heavy emphasis on Quality Control (or testing). It is my contention that those departments who emphasize testing would do better to focus on the earlier stages of development, particularly in requirements gathering.

On my most recent project, we combined the role of Business Analyst and tester. While this approach has its disadvantages, an advantage was that the testing was easier, since the person writing the requirements was also responsible for testing. The defects counts were also unusually low. I believe the main reason for this was because if the developer had a question about how something was supposed to work, they asked the person who was going to be testing the feature what they expected. In addition, a round demos and a final round of pre-production User Acceptance testing (with user proxies) assured that the Business Analysts got the functionality right.

But even if your company isn't about to combine the roles, simple communication goes a long way. See my post on How To File Awesome Defects Reports for more tips on how do better Quality Assurance. This is a large topic and several people have written excellent books on the subject. My favorite is Gerry Weinberg.

Separating Severity and Priority: Why it matters

2009-10-27T15:29:00.000-07:00

I am passionate about these two fields. A few defect trackers (namely JIRA and FogBugz) are at the forefront of an unfortunate trend to merge these two fields into one.

Most people will tell you that Severity is about the technical side and Priority is about the business. More accurately, Severity is about the amount of risk a particular defect or feature threatens the development or testing cycle. Priority is about the importance of a feature or defect to the release. Grouping them together for any reason, even if it's to make defects easier is to file, is short-sighted. My projects have suffered because of this configuration. Both fields need to be filled out accurately, preferably by two different people: one from testing and the other from the business.

That's because they are not always the same. The classic example of a trivial but important defect is a misspelling on the home page. Technically, nothing is broken. But you might hold up the release to fix this defect. An example of a critical but unimportant defect is one in which an old version of the Opera Browser doesn't support your FAQs and crashes. This defect meets the critical criteria. Do you want to hold up the release for it? I'm guessing you probably don't.

One often hears that a defect of the highest severity (let's say Blocker for now) will also usually be a high priority to the business. The problem lies in the word “usually” which we think of as being about 95% of the time. However, in going through the defect database on my most recent project, this number was just below 80%.

“So, big deal,” you say.

If you have a 20 days left on a project and your developers are only working on the tasks of highest importance for 20% ( or 16 of) those days, you won't hit your release date. It's frustrating to be on a team that is managing by Severity, knowing that the team is wasting crucial time fixing things that aren't important to the release.

The main problem with using Severity to determine Priority is that you make your testers the gate keepers for your release. A tester's job is to assess the risk of releasing a given feature, not to hold up the release because they can't test. It is up to the business to determine whether or not they want to live this with this risk.

Don't get me wrong. I love JIRA and I even own the Atlassian T-shirt. Fortunately, JIRA allows you to modify the out-of-the-box configuration, though changing the incorrectly-named Priority field does require digging into the resources bundles and some restrictive IT departments may not let you do that so easily.

I suggest making the following changes to your defect tracking software if it is easily modifiable:

1. Replace the Severity field with “Risk to Testing/Development” or add the field if it's not there. The field should have four values: Critical (crash, data loss, security threat, poor performance), Difficult or No workaround, has easy workaround, cosmetic. The field should be multiple select because these categories are not exclusive.
2. Separate “Blocker” out into it own checkbox since it is orthogonal to “Risk to Testing”. When you are calling something a Blocker, you are saying that you are unable to make an accurate risk assessment on the actual functionality.
3. Replace the Priority field with “Rank of Importance to release”. To make things simple, you could go with the MoSCoW ranking system here: Must have, Should have, Could have (also known as “nice to have”, and Won't have (a.k.a deferred). However, I recommend forced ranking. Good product owners will make sure they force rank frequently and accurately. This is painful to do unless your defect tracker has either good, built-in support for this or a working plugin.

Patrick Lencioni's quote from “The 5 Dyfunctions of a Team” is appropriate here. He says, “If everything is important, nothing is.” Unless the team knows what is most important, people will likely pull in different directions and the team will not be as productive as possible. So the best way to make sure your team hits it's stated goals is by prioritizing frequently and accurately.

How to file awesome defect reports

2009-10-25T14:31:00.000-07:00

Even if you are not a tester, you can file awesome defect reports, but why would you want to?

The clearer and more accurate a defect report is, the more likely it is that developers will fix them quickly. If developers fix your defects quickly, people will realize you are a person who can get things done.
If people can quickly understand your defects with a minimum of context, they will see you as a clear communicator.
If you take the time to make sure that you have a defect and not a misunderstanding, people will take your defect reports seriously as soon as they see them.

So how can you do this?

1. Don't file your defect until you are sure.

Rather than a defect, you could have:

A configuration issue
A data issue
A requirements issue
A duplicate
A known fixed issue

The first thing to do when you find a defect that you are not sure about is to collaborate with your team: specifically developers, testers, business analysts and product owners. Someone may advise you to file a defect report simply so that the work can be tracked.

The best developers want to know about your problems even if you can't reproduce them. There is always a chance that the problem is in the code. I don't recommend filing an unreproducible defect unless the developer requests this. However, you can let them know where you saw the problem. While testing, you should always have your application log open so that you can give the developer as much information as possible. On occasion, this situation will result in an awesome defect.

2. Write awesome summaries.

You always need to convince people that the defect you found is worth fixing. The Summary for your defect report is like your defect's elevator speech. People from all levels in your company may be reading it, all the way to the CEO. I suggest:

Avoid the passive voice – Make the subject clear (e.g. the user, the browser, the interface, the database, etc.) and be specific about the action.
Never use words like “broken” and even avoid the word “crash”. Neither is specific.
Put your summary in the negative – Describe what the system should not be doing. It doesn't always make sense to do this, but sometimes it helps to explain what the expectation is.
Prepend the summary with the area of the application – Do this unless your team members are meticulously using a component field or something else to filter their defect reports.
Summarize the error – In the case of stack traces or database errors, put the actual error name in the summary (e.g. NullPointerException, OutOfMemoryException, ORA-06152 etc).

These are not hard and fast rules, and not all of them can be applied to all situations, nor should they be. Use them as guidelines to help you be more clear.

3. Write awesome descriptions.

Descriptions at the minimum should contain:

Numbered steps to reproduce – this include specific machines, credentials and environment specifics such as OS and application versions and build numbers.
Expected Results.
Actual Results.

In addition, the following information will make your defect even easier to work on:

Screenshots – This is assuming that your application has some UI.
Logs – If you don't know how to get to these, have a developer tell you. Or better yet, ask them to document how to do read logs for your application. If worse comes to worst, you can tail the log and take a screenshot, but text is usually best.
Video – Applications like Jing make it easy for you to make a video of exactly what you are doing to reproduce the problems so that no one has to come to your desk. This is particularly helpful when working with remote teams.

4. Find awesome defects.

This is easier said than done, right? Here's some of the things I do to find great defects:

Exploratory Testing – Otherwise known as old-fashioned, ad hoc, manual testing, exploratory testing is the big buzz in the testing community. I find the best way to do it is to lock myself in a quiet area with a partner and time-box the exploration. If I have enough hard disk, I like to use video to capture the session. The partner is key because they can confirm or deny if I saw what I think I saw and correct mistaken assumptions.
Ask the same question to multiple people – This is my favorite method because it's so easy. You simply ask everyone how something is supposed to work. When you get different answers, you have may have found a defect.
Ask the developer about what area of the code they are most concerned about. Good developers want you to find their defects and will tell you exactly where good ones are, what they didn't have time to finish, or where their unit test coverage is weak.

Filing multiple defects in one report decreases your effectiveness

2009-10-23T15:17:00.000-07:00

On a recent project, a business owner filed a single defect report (bug) that contained at least six distinct defects. What was interesting was that he actually numbered each of the defects, so he knew that they were separate. When I wrote to him to request that he open them as separate reports, he responded by asking if he could just keep the report as it was.

My answer was that he could do whatever he wanted to do. However, I went on to recommend that he file separate defects for the following reasons.

1. Clarity
Have you ever received an email that has more than one topic? Of course you have. We all have. We all know that emails that contain multiple threads confuse readers.

But defect reports are not emails. Emails are conversations, so some confusion is forgivable. But defect reports are essentially work tickets. Good defect reports describe the problem that needs to be resolved and the criteria that will be used to determine if the resolution is satisfactory. The clearer and more atomic they are, the more likely it is that the work will be completed.

Clarity helps you too. You will gain respect from peers if you learn to communicate clearly. Furthermore, if the defect reports you create get resolved quickly,a this will also reflect on your reputation to get things done.

2. Efficiency
If you assign a report with six defects to one developer, one developer will work on them consecutively. If you break those defects out into six reports, six separate developers could potentially work on them simultaneously. By separating the reports, you move the locus of the control of work from yourself to the team.

Furthermore, if the developers you work with are able to complete more tasks in a short amount of time, this will also reflect on your reputation for getting things done.

3. Determine importance and assess risk
Traditionally, defect reports contain two very important and distinct fields: Severity and Priority. Severity is used by testers to assess the risk of a given defect to the project. Priority is used by the business to determine how important something is to the next release.

It is highly unlikely that any six defects are equally important or severe. When you file six defects in a single report, you have undoubtedly given an inaccurate picture of the severity and priority of all the defects.

As it turns out, the defect report in question contained one defect with a severity of Blocker, but the rest were Moderate or Minor. The business owner decided to split it down the middle and classified the report as Major, which meant that his Blocker was not getting the attention it needed.

Fortunately, the business owner took my advice and separated the defects. It was a good thing too. When he split the defects out, his Blocker got immediate attention. The remainder were either appropriately prioritized for the next release or deferred.

Also note: In some situations when a developer resolves a defect, the resolution reveals yet another defect. Some people file that defect in the same report. I recommend closing the resolved defect and opening a new defect for two reasons:

It's always confusing to have more than a single defect in a defect report.
Closing the defect gives the team a sense of completion and is good for morale, even if it is a bit of an illusion.

Note to developers: I have seen developers recommend that a tester file two or more defects in the same report because they are in the same area of code (e.g. the same class). I would strongly discourage against doing this because by doing so, you are setting a precedent. Only developers know if two defects are in the same area of code. But by asking someone to file a defect report like this, you set yourself up for defects that contain separate defects which are in different areas of code because they affect the same functionality.

Are developers right-brained?

2008-10-05T10:55:00.000-07:00

Lately, I've been thinking about how software developers are like artists.

When I worked with my father setting tile during the first Bush's recession, I used to get annoyed with him because he would not talk to me while he was setting tile. Eventually, I stopped taking it personally and realized that my father wasn't ignoring me out of spite but rather to prevent context-switching. The fact was that his work forced him to go into his right brain because setting tile, while it looks like simple manual labor, is highly spatial, and spatial thinking is a function of the right brain. Language is a function of the left brain.

While we think of software development as mathematical, logical, analytical, and dealing with symbolic abstraction (all the domain of the left brain) there is something about it that undeniably makes it difficult to switch into a conversation when one is "in the zone" on a coding project. (BTW, being "in the zone" or in the "flow" state, as Mihaly Czikzentmihaliy called it, is one of the 3 major components of happiness)

Maybe there is not a majority of right brained activity, but one cannot deny that having a conversation with a developer while he is in the zone will definitely force him to switch contexts.

I have been think of this in light of being a scrum master, whose job it is to make sure that the developer stays flowing. As a scrum master, I imagine that my team members are all encased in individual eggshells and it is my job to make sure that those shells don't crack. They way they crack is when someone talks to them about anything that doesn't have to do with their immediate task.

I told this metaphor to a colleague of mine, who extended it by saying, it is also your job to nurture that the developer in the eggshell, to make sure it has everything it needs to grow. I'd say that you have to make sure that you take on anything that makes it harder for it to grow (distractions, unnecessary beauracracy, so on) because that will make the shell crack.

So far, so good

2008-09-21T14:34:00.000-07:00

At this point, I'm enjoying the new being in the new role we've created in our company. The role is a cross between business analyst and tester. It works well on many levels. Firstly, the business analyst has direct conversations with the product owner and as a result, is able to translate the requirements to stories the developer can understand and that, are at the same time, unambiguous. Secondly, if there is ambiguity, it is caught immediately by the person who wrote the story, the tester who also happens to be the business analyst. This removes quite a bit of the game of post office that often happens at the end of a project between the tester and the business analyst. So far, and we're only in the beginning of the project, we've caught several misunderstanding that otherwise would have probably made it through to testing and, knowing that testing is often crunched for time because of understaffing, might have made it through.

None of the ideas we're trying out, as it turns out, are new. I'm currently reading David Anderson's book "Agile Management for Software Engineering - Applying the Theory of Constraints to Business Rules". The book was written in 2004 and implies many of the processes we are implementing at my current client's site. Oddly enough, I've also been thinking a lot about bottlenecks and which resources are the actual resource constraints and which are simply insufficiently buffered resources. The reason I've been thinking about it is because a few of my colleauges and I have developed a new workflow for our story-tracker that, once implemented, will allow us to easily track the amount of work queuing up in front of a particular resource or resource group. I've been postulating that instead of testing being the bottleneck, that development will actually be the bottleneck. Anderson says that typically development is not the bottleneck but that specialists (such as IAs) will really be the bottleneck since their availability tends to be a constraint. I'm waiting to see how that plays out.

I'll be writing more on this book on the company blog when I'm finished with it.

Penn Station

2008-09-14T10:04:00.000-07:00

My esteemed colleauge, Dennis Britton, organized the first of, hopefully, many brown bags for Business Quality Analysts. The Business Quality Analyst, BQA for short, is a new role we've created at Tacit to address some issues we all face in software development. One of those issues is that requirements that go directly to developers without being reviewed to remove ambiguity often come out defective or just plain wrong. A goal of the BQA is improve the quality of input through development. The implication here is that any stories that go through development and do not actually meet customers requirements are not throughput. Why not? Well because they're going to have to go through development again. That's probably another post entirely. Moving on.

Many years ago, my family went to visit my in-laws when they still lived in the DC area and while I was there, I made a trip to visit a friend in New York. On the way back to DC, I departed from Penn Station and went to a deli there to grab a sandwich. When I arrived at the order counter I told the guy what I wanted a turkey sandwich.

"What do you want on it," the guy asked me.

Being a typical laid back Californian, I paused and then asked, "Well, what do you got?"

The guy responded gruffly, "WHAT DO YOU WANT ON IT?"

I decided not to be a smart-ass and say, "Olive tapenade," figuring that what I'd get in that case would be a big loogie in my turket sandwich.

I repeated this story at the brown bag because this situation looks very much like some requirements gathering processes, with both parties not really stating what their boundaries are.

Amy Lightholder, who was also present at the brown bag, suggested the idea of offering a "menu" of sorts to stakeholders, to give them an idea of what is possible. I like this idea and think I might use it when the time is right.

I'm blocking the flow

2008-08-22T22:57:00.001-07:00

I decided to take a stand today.

I have been "going with the flow" for about a week now. But today I decided to block the flow. Why? Because there was a big waterfall behind me and I didn't want my team to go down it.

Nice metaphor, eh? Came up with that myself.

The tussle was over the JIRA Priority field, which ticks me off because it's misnamed, but that's not what the issue was over. The project manager of the project I'm on wanted to use it to tell the developers which bugs she wanted fixed by a particular date by misusing the Priority field - everything set to blocker needed to be fixed by x date, everything marked as minor was preferred to go by that date.

I decided to take a stand because the client hired me to fix their process. I stood by and watched my client make a mistake the first time, but I wouldn't be doing my job if I continued to stand by and watch them make the same mistake.

What mistake are they making?

If I give you 30 cooked noodles, some red and some green, all with their own distinct properties and tell you to put them in a bag one by one by the time I count to 30, you will start putting them in the bag based on your own criteria, not on mine. If I tell you I want you to place the 20 red noodles in the bag, you will place the red ones in. But what if there isn't enough time to place all the red ones in the bag? What if you don't know how long it will take you to put the noodles in the bag (some of them are very slippery). You might want further criteria. Furthermore, what if it turns out that the noodle I want the most, more than any other noodle, also happens to be the slipperiest and takes 20 seconds to put in the bag. If you started on that noodle after 15 seconds of your time had elapsed, only what you put in the bag within those first 15 seconds would be what I got and I'd be unsatisfied because the slipperiest noodle was not in the bag and I'd wonder what you were doing with all your time.

If you don't prioritize your queue items, you are delegating prioritization. Rank prioritization will happen whether or not you decide to control it or not. Ultimately, someone will choose which bug to work on 1st and which one to work on second. You are fooling yourself if you mistake and estimate for a commitment. Especially if they are not based on velocity.

I made my point and, for now, it appears that my client is going to go with my recommendation. But I don't think this one is over

Testing is never completed, just abandoned

2008-08-21T20:07:00.000-07:00

So when do you abandon?

My co-worker Dennis Britton said this to me today while we were, well, comiserating. I may have heard this before but I think I've never heard it in quite the same way as I heard it this morning.

I've been reading "Getting To Yes" and I think it's helping. I had some very good interactions today with the project manager and basically told her that I wanted to help. We have had some disagreements about the bug tracker, but now that I have can modify the way it works, I have some power to implement my ideas.

One of the most helpful thoughts in the book is the idea of not focusing on the past when negotiating. Let people vent, yes. But when moving into the real negotiating stage, focusing on what happened is not going to get you anywhere. Fortunately, this notion is also a real time saver in my case and much better than combing through historical data in the bug tracker to try to prove my point. Forget it. I'm just going to focus on interests.

If everything is important, nothing is

2008-08-19T08:35:00.000-07:00

I stole this quote from the book I read over the weekend, "The Five Dysfunctions of a Team," by Patrick Lencioni which I also blogged about on my company's corporate blog.

If I had to take one quote from this book, this would be the one. As those of you who know me personally know, I am feeling this lately. I've been working on a project where the task priorities have been shifting with the wind. On the days I can approach it with a sense of humor, I feel like I'm living in a Monty Python sketch.

If everything is important, then nothing has any individual value. If everything is important, when resources become constrained, which they do, the team doesn't know what to concentrate on. If everything is important, then there's tension because you know that, ultimately, something is important than something else and you have to guess if it's what your working on that's the most important thing. When everything is important, blame can thrive, because no one can really be held accountable so any one team member can easily become a scapegoat.

My second favorite quote from the book is this one. "Politics is when people chose their words and actions based on how they want others to react rather than based on what they really think."

My question is this; now that I've given up fighting, how do I not be political?

Transparency

2008-08-15T07:39:00.000-07:00

Yesterday was good day. On Thursdays at the company I work for, all the consultants work from the home office. It's a good day to connect with people, learn about other projects, get ideas and otherwise feel good.

Our managing director ran a retrospective for the project I'm currently working on. That was really effective. It gave the team a chance to pat itself on the back for a job well done and, at the same time, prepare for the next phase of the project. We also talked about things that maybe could have gone better and, well honestly, there really weren't a lot of those. Honestly. The team did a great job.

I was talking with one of my colleagues afterward about the retrospective and I mentioned that I really liked working for this company. I said it was because of the transparency. The consultants have a lot information about how the company is run, we all give one another immediate feedback so, as far as I know, there's no secrets, and upper management is accessible. I've never been in a company like that.

So when my colleague asked me, "Is there anything you don't like about the company?" I responded that sometimes I'm not comfortable having so much transparency. What I meant is that having so much information is sometimes scary. I'm accustomed to being blissfully unaware of the internals of the company I work for. Having that information gives me more responsibility. And with responsibility comes accountability.

My colleague had what I think is a really healthy viewpoint, which is that if there is anything anyone didn't like about the company, they could say so and at the very minimum know that someone would discuss it and, if valid, they certainly address it.

Losing the battle

2008-08-13T22:49:00.000-07:00

The old saying goes, "Sometimes you have to lose the battle to win the war."

I've learned a lot in the past few weeks on a somewhat stressful project. I've been trying to help my client make their process more efficient and effective, but this last project got the better of me. I ended up in a bit of a contentious relationship with the one of the people running the project and on a few occasions lost my patience. I know I'm not alone and that's somewhat comforting. I did manage to maintain my composure throughout, barely at times, and there were definitely more skillful ways to handle some of the situations I encountered.

Today, I decided that I'm losing this battle. I introduced some Agile concepts to the group I was working with and I feel that aspect of the project went very well. In addition, the team experimented with lighter weight documentation, though not as light as I prefer, and exploratory testing. That went well.

Giving up the battle was somewhat of a relief, though it is still a bit frustrating to see my team continue to make what I see as mistakes and I have to remind myself that I'm not fighting anymore. There will be more challenges, but this one is over and I need to learn from it.

So what did I learn (again)
1. The bug tracker needs to be there from the beginning
2. Doing something and then providing evidence of its ineffectiveness (and suffering through that) is sometimes better than fighting, even though you know how it's all going to turn out in the end
3. Even a little bit of forced ranking is better than none
4. Iterate early and often

Fortunately, I'm still in the good graces of everyone I work with except one person and I'm going to try to take that exceptional person to lunch. I've decided that I'm going to befriend the people who make me the most upset. Because they're the ones who can teach me the most.

It's ugly but it works

2008-08-12T13:01:00.000-07:00

I've had a busy week and didn't realize it had been so long since I last posted.

Lately, I've been dealing with aesthetics. I'm still in the middle of that high-visibility release. But now, the issue I'm dealing with is that the product owners are not willing to release the product with what amounts to aesthetic bugs. So I'm learning.

It is difficult, maybe impossible to quantify the cost of UI problems, but they can cause.

* Delays of development schedule
* Increased costs of production
* Poorer results among users who may be frustrated, make errors, or perform poorly.
* Increased calls to technology or domain-knowledge centers
* Higher maintenance.

Software that looks good can be easier to learn and more appealing in that unquantifiable way. So when does the business learn to live with the ugliness in order to release and fix in the next round? How much does it cost to postpone a release because of ugliness (in terms of rolling back code, impacting other projects, etc.)?

Paul Klipp (Confessions of an agile activist) has something to say about this. He now takes care of all the graphic stuff in the first iteration, the justification being that customers will judge a book by its cover.

I don't know the answer. My bias is back to the agile manifesto: I value working software. But these people who want everything to look good have a point, especially when your business is making people look good.

Getting Hit By A Bus

2008-08-01T14:51:00.000-07:00

In my industry the phrase goes, "God forbid (so and so hot shot developer) should get hit by a bus." This is usually said to justify the reams of documentation that people produce in order to make sure that knowledge transfer happens.

From here on in, I promise I will never use that phrase. Why? Because I don't believe that the amount of effort (read cost) that goes into creating documentation and maintaining that level of documentation pays off frequently enough to justify itself. This is for many reasons, one being that there is often little to no quality assurance done on these documents to make sure that they are actually understandable. My experience is that the majority of them aren't: they are written in vague language, are missing steps, aren't up to date, and don't give justifications for why particular steps in a process need to be performed. When you write a document because you are worried about the slim chance that you will lose knowledge because one person is a (note I said "a" and not "the") repository of knowledge for a particular subsystem, you commit a few errors. 1. There is a very slim chance the person in question will come to any harm in the immediate future unless of course that person is aware of or exhibiting symptoms of an illness. 2. Even when people become hospitalized or ill, usually they are able to communicate about their knowledge, with exception of rare situations in which people have lost their memory, or are on life support. Yes, someone might be heavily sedated. That is more common. But drugs wear off. 3. The person in question is probably not the only person who can understand or who has knowledge about a subsystem (note: I have only once in my life, just last week in fact, encountered a subsystem in which no one knew what was going on except for someone who was no longer working for the company)

I do advocate drunk documentation, a term my friends Chris De Giere and Jon Herman came up with, which basically says that you should document a process so that someone who is drunk can follow it because chances are that when the system breaks (usually around 10:00 PM) the person who is called to fix it will be drunk. Drunk documentation requires proof reading, and exacting QA, but it also requires minimal documentation. Only what is necessary should be added. Don't gold plate.

So how does this all relate to QA?

The QA script, that is the well-known document (usually an excel spreadsheet) that contains step-by-step instructions on how test every subsystem in the application is rarely used and hardly justifiable. The only time it is pulled out is when someone wants to regress something or you want to throw bodies at an at-risk project. Chances are usually that the system has changed such that at least some, if not most, of the test cases are out of date, incorrect, or useless. So in order to use the documentation, initial QA on the document needs to be performed to how much of the existing document is relevant. What is not relevant needs to be explored. What was the original intent of this test? Is this test still needed? If so, how does one perform this test with the current functionality? So there's potential for a considerable amount of overhead.

I have come to the opinion that some QA documentation is useful. Basic descriptions of how to perform standard tasks, get to particular environments, and which "secret codes" one needs to set up tests or get them to pass should definitely be documented in drunk documentation. However, no decent QA will ever follow a script (even if they tell you they do). What they do is use the script as guideline.

All this is old hat to anyone who is up on QA rockstars like James Bach and Cem Caner. The expert suggest using "patterns", referring to software Design Patterns. Caner, whose background is law, talks about how lawyers have "pattern" books that help them try particular cases. These books contain guidelines on where and how to probe a witness. QA could use books like these. How many of us have tested a persistent cart, a JDK upgrade, or a third-party ratings and reviews integration? My guess is a lot. Where did the bugs get found, what were the pitfalls. This is what I want to know when I start testing. Not the exact steps on how to log in over and over. That requires too much patience. I can figure out how to do that. I'm smart. I only need to be told once or four times how to do something (I need to remember to write it down that first time if there's no drunk documentation)

This year at (C)AST, an attendee mentioned gathering these QA Outlines/Plans/Patterns on a website but I don't know where it is, or who he is. QA is so good at creating reams of useless documentation. I'd like to see us gather something useful. Can I hear an Amen?

Sugar v. Salt

2008-07-30T22:47:00.000-07:00

I am constantly amazed at how much sincerity and compassion manage to break down barriers in the work place.

In my current position, I lead by example. I'm a consultant, so I'm not in a position of authority, although I am seen as a subject matter expert, which gives me some clout in many, but not all cases.

In the past few days, I have had the opportunity to introduce my methodology to one of the client's departments that has not yet been exposed to it. Some members of the team are enthusiastic, but others are resistant. An example of the resistance is that I held a standup meeting this morning at 9:00 for a high priority, high visibility, at-risk project. The standup slowly became a sit-down meeting. I was frustrated and kept motioning with my arms for people to stand up, but no one did, not even those in the meeting I considered my allies.

A little polite digging revealed the issue. One of the attendees at the meeting, a project manager, had called the meeting at a particular time in order to take advantage of a window of availability of a remote resource. The meeting started late (9:10) due to some team members (including the remote resource) arriving late. I was allowed to start, explained the ground rules for the meeting and started in. The PM, accustomed to digging into problems as soon as the surfaced and concerned about time, wanted to dig into problems. After she was done with the first problem, I explained that this meeting was a status only meeting and that we would dig into any issues after the meeting as necessary.

I left after the status portion of the meeting (9:20), as I was not needed in the conversations. Unfortunately, many of the team had to leave at 9:30 minutes later for another daily meeting. This meant that the PM did not get sufficient time to do her PM thang. She was frustrated.

We chatted afterward and this came up. I noticed she seem frustrated but dealt with her as politely as possibly. I understood why she would be frustrated. I asked her to give the status meeting a week, but she said that was unacceptable. Rather than get angry with the hand, I told her I was uncomfortable with abandoning my format. Miraculously, we quickly determined that our meeting had dual purposes and decided to split the meeting. This has the unfortunate effect of some of the team being in two meetings, one of which may be long and tedious. However, what I think was most successful about the encounter was that no one lost their cool despite the emotional charge. I will be leading a status meeting at 4 with only team members and no PMs (unless they want to come but they'll probably just listen in since we'll be holding it at a common area near their cube). The unfortunate thing about this time is that I'd like to have the remote resource at the meeting, but she will not be available at that time so I will try to get her status before she leaves for each day.

Afterwards, I talked to the team members and determined I still had their support for my format. I apologized for losing the battle, and told them that I hoped that our afternoon meeting would be effective to the point of making the morning meeting blatantly superfluous in a few days. If that happens, I'll take the 9:00 slot over, thus getting back my remote resource.

So, I'm crossing my fingers.

The cost of bad communication

2008-06-10T22:46:00.000-07:00

Forgive me if this post sounds grumpy. I haven't been taking care of myself lately, mostly because I just got this great job and I want to spend all my time working and worrying about how things are going.

I had a long lunch with one of my fellow consultants who has been implementing Agile for a while and has a lot more experience than I do in the kinds of projects our company performs. He mentioned a specific company to me and a specific person who is well known in Agile. This person apparently has a reputation as someone who is difficult to please and who has little patience for things he deems as beneath him. He has been known to walk out in the middle of meetings he feels are a waste of his time. He justifies this, in part, as a cost cutting measure.

Now, this is someone who is in a position of power, a person that other people want to impress. Other people care about what this person thinks of them, their ideas. And, as far as I can tell, he is at least a little emotionally unskillful.

This got me thinking about the cost of emotional carelessness at the workplace. My co-worker said that if anyone could put a price on that, the person in question could. Personally, I doubt that.

But try as I may, I couldn't find much in the way to help me quantify this. I do know from personal experience that emotional turmoil between people at work, particular when one is higher up the org chart than the other, can have devasting effects, and usually result in many extensive conversations involving people's friends, managers, HR, and all this conversation, and decreased productivity adds up.

I was once the target for a bit of poor communication, nay criticism, that, though partly deserved was not delivered skillfully, accurately or helpfully.

Fortunately for my client, I am very skilled emotionally and I'm a consultant. I didn't take the comments personally, even though they were delivered in a personal manner. But it again got me thinking. What if I wasn't as skilled and I were a salaried employee and this person who delivered this message, that appeared to be aimed at denigrating and intimidating me, was someone further upstream from me.

The answer is I'd be uncomfortable. The remark would certainly have made my stress level go up more than it did. I might have spoken to some co-workers about it. I might have gone to HR about it. I'd would certainly be less productive. So what was the aim of the comment? Was it meant to make me less productive? I'm guessing not.

What is the cost of bad communication?

The Agile Playground and Forced Ranking

2008-05-31T21:50:00.000-07:00

Today was work day at my daughter's preschool. My family was the first to arrive and was I ever pleased to see that the head teacher had posted what amounted to a product backlog hanging up on the wall when I got there. Of course, usually at these school work days you have to go try to track down the principal or a teacher to find work to do.

I decided to use my work skills to take this product backlog up a notch. There were 15 items in the backlog, and of course I could have picked any one of them. So I took the teacher who had created the backlog aside and essentially coached her into a forced ranking. What I mean by this is I made her put each item in a ranked order. I wasn't going to let her say things were equally important. I was prepared to say, "If we only have time for one or the other, which one stays and which one goes." I know the term forced ranking has a human resources connotation. I don't mean it in that context.

There were 4 major categories, each with 3 to 4 tasks. As it turns out, the most important task was to extract the bushes, first near the sand box, second near the gate and lastly in the far corner. This was awesome because we all, of course, wanted to plant flowers but that was the 3rd priority.

As it tends to, the forced ranking brought some immediate problems to the surface
1. We were going to need someone to haul away the brush (taken care of with a call to Hector's Hauling Service)
2. We only had one chain saw and didn't need that many people for the task

So my wife and I started in on the sandbox, priority 2, and the next problem came up. We had nothing to contain the gravel we needed to scoop out. My wife drove home to get some spare buckets in the basement left over from my days as a tile setter while I ran around playing scrum master, making sure no one was blocked on their tasks. When I saw two people standing around together and noticed that the 1st and 2nd priority tasks were in progress and at capacity, I said, "It's appears that you can plant flowers." They really liked that.

I found that these simple adjustments made for efficient team work. I had a great time and there was a good spirit. Everyone knew what they were supposed to do and no one sat around chatting (because if they did I suggested they self-organize and see what the next item on the product backlog was)

All in all, we completed 10 of the 15 items on the backlog, and 2 of them didn't count because they were dependent on the sand being delivered and it wasn't going to be delivered until Monday.

Hooray for forced ranking

$foo and Happiness

2008-05-28T22:18:00.001-07:00

Okay, so when I talk about software development and happiness, what I'm really talking about is happiness in the software development context. In my mind, this blog could just as easily be called "Plumbing and Happiness" except for that I happen to know a hell of a lot more about software development than plumbing. But the principles of happiness I am studying are applicable to anyone.

Teach a man to teach a man to fish

2008-05-25T21:22:00.000-07:00

Everyone knows the old proverb about giving a man a fish and teaching a man to fish. You hear it every time you get a new job, and of course, since I just got a new job, I've been hearing it, too.

Personally, I have problems with this saying, not because I disagree with it because I don't. I grew up in an environment where I didn't get a chance to learn things and I ended up with learned helplessness. And obviously, that's what the people who chant this old phrase want to avoid engendering in those asking for their help.

No, my problem is that most people mistake "RTFM" for teaching a man to fish. I've seen this done to others, myself and I, god forbid, may have done it myself. Now, I'm not much of a fisherman, and I'm one of those people who actually learn how to do things from books, but I'm pretty sure that I'd remain a lousy fisherman if I simply read the book.

In my industry, people learn to do things by reading. To me that's amazing given that the quality of the literature one has to read in order to learn how to do things usually is pretty poor and is sometimes written in broken English or omits important details unless you happen to read the comments or the hyperlink that no longer works. Ugh. However amazing it is that people learn to do things from crappy documentation, the fact remains that the ability to do this in a talent that people in my industry have to varying degrees.

My point is that telling someone to read the manual is not teaching them to fish. It is the equivalent of showing them where the lake and the poles are, to extend the metaphor. I already know where the lake and the poles are and that doesn't make me any better a fisherman. Telling someone to read is a poor teaching method, and it is especially frustrating when the documentation you point to is poorly written, or assumes a particular level of expertise that the student may not have. It is maddening when the student asks a question that he knows will take you 10 seconds to explain and you recommend a document that takes two hours to read and, at the end, the student still doesn't have the answer because the documentation was either not understandable, or worse, not complete.

When you teach someone you watch them perform a task, correct them when they stray off course, ask them what they are learning, encourage a job well done. It is time intensive. It requires that you pay attention to your student and make sure they are getting what they need. Back to my post about the differences between apes and humans, if you tell someone to read the manual, you are not much improving the situation of apes, who teach simply by repeating a task over and over without encouragement or correction.

But how do you ask to be taught fish when someone who says the equivalent of "RTFM" is probably doing so because they think they are teaching you to fish because the likely answer you'll get is a sassy "I'm not going to do it for you?"

Here's the range of possible answers someone might give when intending to "teach a man to fish" going from not as skillful to more skillful

(sigh)
RTFM
RTM (no F)
The answer is documented, but let me help you find it in case it's not as documented as I think
The answer is fully documented, but let me know if you don't understand anything and I'll be glad to assist you

Can't we just get along?

2008-05-24T00:29:00.000-07:00

I have been fascinated by the QA/Developer relationship for a long time, which usually ranges anywhere from tense to abysmal. I believe that I have actually figured out how to make it work, at least from the QA perspective.

Software developers are a lot like most artisans, in that in order to do their best work, they need to go into a "flow" state, get in a zone. Simply put, they need space to be free of distractions they don't want (they may still choose distractions they do want).

Part of the tension arises simply from the natural process of sequential development. QAs typically contact developers at two pretty horrible times in the cycle. The first is during QA planning. During this time, developers are typically hammering away at the looming features for the upcoming release. They're tense because they're under pressure to finish the code to hand it off to QA. And the second time QAs need to deal with developers is after feature complete, when QA gets the code for the first time. And typically, at this time, developers are beginning to work on the next set of features for the release and really need to concentrate.

Developers need a lot of time to concentrate.

So what does the QA do? They interrupt the developer's flow. And to add insult to injury, they typically interrupt by saying something to the effect of "I think I found a bug."

So, now that we know this, it's easy to tweak the interaction. Here's some simple hints for you QA folks:
1. IM - Developers are much more happy to respond to an IM than they are to take off the headphones and stop listening to Rammstein in order to hear "I think a found a bug," even if you're sitting bullpen style and the guy is right in front of you.
2. File proper defect reports - Don't do shorthand even if you think the developer knows exactly what you're talking. One reason to do this is because a less than thorough defect report forces the developer to go even more out of his flow. The other reason is that you never know if another developer will get assigned to that defect or possibly you'll get sick and someone will not be able to regress a defect because you left lousy instructions. If possible, paste a direct link to the problem in the defect report. Always leave step by step instructions, include the machine name, build number, any specifics such as logins you used. Always put expected results and actual results and mark them clearly (usually with EXPECTED: and ACTUAL:). Attach screen shots. Attach log snippets or exceptions. If you're a senior/lead, dig deeper into the problem and see if you can find the line code that's the issue
3. Don't call them bugs - Developers really don't like that word. It makes them shiver. But for some reason, they are okay with defect. I worked at a place that started jokingly calling them "opportunities." Whatever works.
4. Be polite - Ask them if they are available to talk before barging right in. If they aren't and you're blocked, explain the situation. If they tell you they're working on some other super important thing, ask them if there's anyone you can talk to either to get the answer you need or to get their time. Be nice about it, not threatening. If they can't tell you who to talk to, you may have to escalate, so explain that they've put you in a bad situation and that you may have to escalate the problem.
5. Oh, and last but not least: stop doing sequential development.