It is not uncommon for me to see on blog posts, newsgroups, or presentations the phrase or comment that something is not, "in the spirit of Agile". In fact a project team could be doing many of the practices of Agile but, if it fails, the agilist will claim that the project was not Agile in “spirit”. And I was wondering, if that is the thing that was really wrong with the waterfall approach.

Consider it. It appears that many of the failings of agile or the miss application of agile is accredited to not being in the spirit. This occurs even when, if you look down a long checklist of practices, the team appears to be doing most all of the practices. However, because they were not empowered, or some other such factor, their experience is chalked up to bad execution, not bad methodology.

So maybe that is what is wrong with the waterfall approach. Sure, we have lots of practices that we were told to do, we have lots of activities the flow one from another, but we did we really understand its spirit? What would be the spirit of waterfall? I suggest this: the spirit of waterfall is “thinking”.

On the simplest level, the spirit of waterfall—thinking—is the look before you leap philosophy. Before you start doing something, think about it. Before I start doing design, I think about the requirements. Before I think about the requirements, I have a general understanding of what the heck this thing is supposed to be and the constraints I am under. Before I start doing code, do I have any clue about what the requirements or the design is? Did I think about it? Even better perhaps, as a team, did WE think about it?

“Thinking” of course does not mean solo cognitive work only. It means taking a rational approach that also identifies clearly the limits to what can be known and creating ways expose the unknown to make it known. (Flashbacks to Donald Rumsfeld are perfectly understandable at this point.)

On a more subtle level, the thinking was there as well. How much of the requirements were knowable? How much of the design was discernible? Those who ran the waterfall well (and yes, there were people who could run the waterfall approach well) were people who thought about those things. One of the big drivers that caused many waterfall/sequential projects to fail was that people didn't think about what was knowable and turned phases/stage-gates intended to be thinking/assessment points into document signing parties. They didn't think about what was right and, even if they did, they didn't share those thoughts with the stakeholders and steering committees; they just made sure the documents were signed. They knew that if the documents were not signed, there was heck-to-pay because the people on their steering committees didn't want to think either. And when the thinking stopped, the spirit of waterfall was defeated.

If we use the argument put forth by agile zealots that when you violate the spirit, no matter how many practices you perform, you aren't really doing the method, then we could say that a vast majority of sequential/waterfall projects—even if they were executing a lot of the practices—were really not doing waterfall. Oh it may have looked like waterfall, smelled like waterfall, they even went around touting the waterfall name, but without the “thinking” it really wasn't waterfall.

So perhaps the “not in the spirit” argument can give a new lease of life to the waterfall approach to software development. Probably not. “Waterfall” is mostly used as a pejorative word in the software development community. However I say, “Long live the spirit of waterfall!” We could all use a bit more rational thinking.

Recently, Mark over on the Agile Project Management Yahoo discussion list posted this little remark.

“A feature will take *exactly* the same amount of time whether the
estimates are "good" or "bad"!

“I swear I'm going to print that on a 10 foot banner and hang it over
my desk for our entire organization to see.

“As a community, I believe we spend wayyyyyyyyyy too much time talking about estimation. A "good" estimate is never going to get a feature done sooner.

“Instead of spending time talking about estimation, we should be focusing on the other engineering practices, e.g. specification driven development, continuous integration. At least they have a positive impact on delivering value.

Mark”

The question to ask is, “Is this true?” Does a feature take the time it takes regardless of how much time we think it will take? That is, if I have a feature that in its essence is one week worth of work and I estimate that the feature will take more than a week to develop or less than a week to develop, it will still take a week to develop, regardless of the estimate.

Or, more simply, does the quality of an estimate, its “goodness” or “badness”, have any impact on the work?

The first shot at saying that the quality of the estimate does have an impact on the work is Cyril Parkinson’s observation in a 1955 Economist essay: “Work expands as to fill the time available for its completion,” commonly known as Parkinson’s Law.

If we were to give my one week feature two weeks to complete, Parkinson’s Law would suggest that the feature would end up taking two weeks regardless of its nature.

Now, I am sure that there is some limit to Parkinson’s Law. If I gave my one week feature ten years to complete, it would most likely not take the ten years. However, it is just as likely to take more than its innate week.

Why do we hold Parkinson’s Law true? Mostly, it is an observation of our collective experience. We can think of trivial examples such as students putting off papers until they are almost due, a lowered sense of urgency while doing the work, increasing the amount of “polish” or tuning we do rather than stopping at “good enough”, etc.

Add to that the planning errors we make. Since I estimated my one week feature would take two weeks , I did not think I could get a second one week feature in this work period and set that second feature aside.

What is the impact of that? The answer depends of course but picking up that feature in the midst of my work period means that the tasks to incorporate that work must be picked up at a point that may not be optimally designed for doing that kind of task. Instead of discussing the feature with the customer who was present at the initiation, I must track the customer down and hold the same discussion, now out of context. Just that extra work of getting the customer, explaining the situation (the first feature was done in “half the time”), and then doing all the tasks I would have done earlier if I had a correct estimate makes the second feature take just that much longer than it inherent nature.

So I think Parkinson’s Law holds true enough for overestimation. What about underestimation? Is there an impact to the work when we estimate it at less time that it really needs?

I think that the answer here is also a definite, “Yes!” Several things conspire to actually increase the amount of time needed to build our one week feature. Some of that increased time is realized on the current work, some of that extra time is taken on as technical debt.

The current increase to my one week feature comes from planning errors and schedule pressure. When I estimate it will done in two days rather than the one week of its nature, I make plans based upon that estimate. Some of those plans involve coordinating activities with other people and resources. When I can not meet those coordination points due to my work taking longer, those plans need to be changed. If the people and resources are the typical in-demand things that they are, then it will take more time to establish new coordination points thus increasing my work on the feature. At the least, I have had the extra work of establishing the coordination points twice.

Steve McConnell also documents in Rapid Development that just the feeling of schedule pressure can drive up defects. We make more mistakes when we believe we don’t have the time to do the job as it needs to be done. These defects take time to correct and, thus, increase the schedule for my one week feature.

Some of the increased time to complete the feature can be deferred as technical debt. Rather than repeat my post on the sacrifice of non-functional attributes to meet schedules, I will note that we can meet almost any schedule if I am allowed to “relax” non-functional attributes of my feature. However, these relaxation of things like “maintainability”, “portability”, “readability”, “usability”, etc. are likely to come back in future feature work and increase the time then.

This concept of estimates having an impact on the work is nicely summarized in a poster that my employer, Construx, offers.

On the right we see the linear impact of Parkinson’s Law; on the left, the non-linear impact of planning errors and technical debt.

It seems Mark may be taking a simple case. However for most of us, the quality of the estimation does have some impact on the time required to complete a feature.

Is Agile, which was baby a few years ago, growing up to be just another moody development adolescent on the way to becoming a ho-hum mainstream adult? One of the fascinating (or darn scary) aspects of having children is watching them grow up. As they take on more and more decision making on their own, they begin to do things that, frankly, can make you cringe.

I bet that is true for the Agile thought leaders as well. How well are things like empowerment and high bandwidth communication maturing in global enterprises. Are companies turning Agile into something a true zealot would dislike? Have you ever wished your child didn’t mention they were related to you?

What started me thinking about this was a common implementation trick I see in Agile teams, the iteration zero.

In Agile, one of base “rules” is to deliver value (as defined by the value definer) every iteration. That is, every two weeks (or however long your iteration length is) you must deliver something the customer (whoever that may be) can use to meet their objectives (whatever those may be) in some, possibly partial, way.

The thought is that an architecture, while useful for the development team and an enabler of other activities, generally is NOT useful to the customer. The typical value delivery item is some amount of the end functionality actually working in executable code. One can also deliver a document that is required like a training manual but code is strongly preferred.

To pull this off from the very first iteration requires some slight of hand. A common strategy of by-the-book Agile implementations is to develop that executable code in a environment that is not the target environment—say an Excel macro. This will be done with only a small amount of the available capacity of the team while the rest of the team’s capacity is used to build the target environment.

While true to Agile’s values, I don’t see this strategy very often. More likely than not, the Agile team that needs to do some grunt work before they start delivering value will invoke an iteration zero.

In an iteration zero, the team builds the target environment, sets up the regression testing/build tools and, increasingly, does some requirements and design work all while delivering no value to the customer. Hence the zero.

Iteration zero is also often a different length than the follow-on iterations. While a common iteration length is somewhere from 2-4 weeks, an iteration zero can be a couple of months long. It takes time to get ready to deliver value.

Upfront work; what are those Agile thought leaders thinking? Doing requirements (some at least) and design (again some at least) before writing any code. Locking in architectures (mostly). Just like the old school development methods. Are they cringing?

Now, I have watched the Agile thought leaders spin this as this is what they intended all along. I don’t think it is what they intended. You can look at things like co-location going distributed and test-first returning to test-please. Not part of the original plan.

Agile is out of their hands. The child is making its own calls. Agile, as now touted by the thought leaders, is different. Maybe the thought leaders are getting wiser as well.

Each of the previous “done” criterion had the need for the individual applying the criterion to make a judgment call as to the “doneness” of the work item under review. This gives it the power necessary to determine “done” in contextual situations. However, if a person only used one of the criterion—Sufficient to Proceed, Appropriate for the Environment, or Sanity Checks—that check alone can not give a good assessment of “done”. Together they have the ability to guide the “done” decision. To confirm the individual judgment it is critical to get Feedback from Stakeholders. With feedback, we can correct and calibrate our expert judgment and become better assessors of “done”.

There are two primary stakeholders that I like to use when getting feedback on “done”. The first is those that supplied me the information used in creating the work artifact. I want them to tell me if I understood and correctly interpreted what they shared with me.

For example, suppose I am working on a technical design and I want the business customer to tell me that I correctly understood and interpreted their business requirements. Asking them to look over the design and give feedback probably would not give me the feedback I am looking for as the design is fairly technical and my business customer is not. What to do?

I could, instead, work with the customer to write up a series of scenarios or stories and then walk through the design with me while I show how the design would satisfy that scenario. This walk through may not be with the business customer but other technical peers who can see if I have a viable solution to scenario’s problem.

The second stakeholder I am after for feedback is the consumers of work artifact. Each artifact produced on a software project should be created because other people or processes need the information to do their job. Even code is information to a complier to make the 1s and 0s. The question I ask these stakeholders is, “Do they have the necessary information to do their task?”

This one can be a little dicey since there are some people out there who may insist on so much content that they are effectively asking you to do their job. For those members of staff, you may need to step back and look at role definitions and job responsibilities. Then again, you may be much better at their job then they are, so go for it!

One of the great things of Feedback from Stakeholders is that there are both an early and a late indicator of how effective is your expert judgment of “done”. Both share the same early indicator in the feedback you get from the initial review. If the stakeholder tells you that it is incomplete, you need to tune your judgment on the “done” criteria.

Unfortunately, sometimes the stakeholders do a “review” and say that the work artifact looks great. I put review in quotes since the signatures were there but that is about it. I had a coworker once put a paragraph into a work artifact that stated that all those who read the said paragraph would be treated to free beer. Eight signatures later and no mention of the beer. Not even, “You better take that out.”

Fortunately, the two stakeholders have late or lagging indicators as well. For the suppliers of information I like to watch the requests for changes. If I see a lot of changes come through, that means that my process of getting information out of the supplier didn’t really do its job. Either I missed something or, just as bad, I forced them to make decisions they were not ready to make. Either way, I was not “done”, I was just pretending.

For the consumers of my work, I like to watch defect counts. If I had the right information but put it in a way that they made mistakes, I probably wasn’t “done” either. I will want to do some analysis to make sure that the consumer isn’t incompetent but I start by assuming they are. It is my job to give them information they can use, not a pile of stuff that they have to dig through just to find (or not find) the information they need.

The early feedback and the late feedback allow me to tune my “done” criteria. Sufficiently Complete, Appropriate for the Environment, and Sanity Checks are all tied together with Feedback from Stakeholders.

Now I would love to get your feedback on these “done” criteria.

For every work artifact we create there is often a short list of attributes or questions that can help us determine if the artifact is done. This short list reminds us of classic patterns that have risen to become accepted truth and classic mistakes that continue to dog us. This list of questions or attributes is what I call a Sanity Check, a quick look to see if the work artifact done.

For example, if I am remolding a kitchen, the question, “Does the stove, sink, and refrigerator from a triangle pattern?” should be a Sanity Check. I may choose NOT to have my refrigerator, sink, and stove in a triangle but I better have a good reason why not.

When I was a Quality Assurance Representative for the Department of Defense one of my tasks was to watch the manual testing of circuit boards. Those who have placed the probes and watched the oscilloscope know what a tedious job this can be. A Sanity Check called the “smoke test” often proceeded this long series of manual tests. If you applied power to the entire circuit board and it caught on fire or smoked, then don’t bother with the rest of the tests.

A key point here is that a Sanity Check can be quickly applied and the results determined on the spot. Scanning a list of questions or desired attributes should take only a matter of minutes, not hours. The items on the Sanity Check list should represent clear conditions that the violation of those conditions should put the item under review into question as to if it is really done.

However, failing a Sanity Check may not always be as clear as catching on fire. For example, one Sanity Check item for a software requirement is that has no ambiguity. While this is a worthwhile goal, I don’t believe that “no” ambiguity is a good thing. We already have a profession of people who try to write things with “no” ambiguity. They are contract lawyers and nobody really understands what the heck they have written. Here, the Sanity Check is more concerned that the people reading the requirement will have the same understanding as the people writing it. This is more of a judgment call than a hard and fast rule.

Sanity Checks are useful both as a done criterion and as a creation guide. Sanity Checks in the form of checklists can be used for peer reviews. Each reviewer uses the checklist as an aid to help find potential mistakes in the work artifact. By reviewing the checklist of twenty or so Sanity Checks prior to the start of a review and having it lying in sight while reviewing, a reviewer can greatly increase not just the number of potential mistakes found but also the number of categories of mistakes.

The author can also use the checklist as they create the work artifact. By consulting the checklist, the author can use that knowledge to help self-review and prepare the deliverable for other eyes. It can help the author side-step those classic mistakes that have haunted others.

While the core for many Sanity Checks for a given work artifact will be the same across companies and industries, there should be customization for each application. There are mistakes that your organization makes that others have never seen.

As with many things, Sanity Checks work best with experienced staff. Sanity Checks are mere statements that are designed to be interpreted by people. Their brevity requires a somewhat knowledgeable mind to fill in all the gaps and to make the final decision of the Sanity Check’s applicability.

Like the Sanity Check that blog entries should be less than 1,000 words.

When we create a work artifact on software project, we usually create it with the understanding that somebody else will need to use it. The who, when, and where of that somebody has a huge impact on whether or we can consider our work “done” or not. To be done, we must determine if the work is Appropriate for the Environment in which it will be used.

Think of two teams: Team A and Team B. Surprisingly, both are working on the exact same product, using the same technology, and the same development lifecycle. Team A has been working together as a team for about five years. They are co-located and have deep knowledge of the technology and the customers.

Team B, on the other hand, is a bunch of new hires straight out of college. They still have not all moved to headquarters yet so most of them are telecommuting. Team B has a basic understanding of the technology and has heard of the customer.

Since we are working on the exact same product, etc. you might expect that they should produce the exact same work artifacts. In fact, you might be able take a work artifact from one team, substitute it for the same artifact on the other team, and nobody would notice.

Absurd you say? Rightly so, but why?

You point out that Team A can probably take a bunch of shortcuts that would be dangerous for Team B. Why can Team A take shortcuts? Because I made Team A different from Team B in the two areas that are critical for being Appropriate for the Environment: Competency and Distance. The more competent you are, the less detail you have to have in your communication to get your message across; the more distance, the more detail you need.

Competency here is not about how smart a team member is, it is how much knowledge they have about the technology being used and how much knowledge they have about the needs of the customer.

A student in one of my seminars was a great example. He was a PhD in Geophysics that went on to get a Master of Software Engineering. He was responsible to create software for other geo-scientists. During the seminar he stated that when he gets a requirements specification from the non-software scientists, he would scan it, ignore most of it, and build what they needed. His customers were delighted. Since he understood both the technology and customers needs, he would get the the gist of what they were looking for and could move forward.

Contrast that with a client in telecommunications which was outsourcing to Russia. The client would send a specification to the Russian body shop, Russia would code it to spec, send it back, and it wouldn’t work. Russia understood the technology but not the customer. The client put more detail into the next specification it sent to Russia but it came back with the same problem: exactly to spec but not useful. Only when they reduced the detail and sent a designer (somebody who knew the customer) with the specification did they get useful software.

As competency–knowledge of the technology and the need–increases, the need to put detail into communication decreases. Team A, with abundance of both, probably has far less detail in its project plans, specifications, and even code comments. Would it harm Team A to put all the detail in? Probably not directly but much of the detail would be wasted effort and may impact morale (taking time to produce not needed stuff).

Distance, a second critical area, can be measured in at least four dimensions. Physical distance, of course, but also time, culture, and team size. One of key lessons that organizations have learned with distributed development is the inability of work artifacts alone to solve the distance factor. For example, bringing the team physically together at the start of a project is considered a best practice by many companies. Leading companies invest in telecommunications and travel to deal with distance issues.

It is somewhat ironic that we see a rise in Agile programming practices with an emphasis on little to no distance in the team and at the same time a rise in distributed development (some outsourced) that has a high distance factor. Enter the somewhat oxymoronic “Distributed Agile”. Sure, we can bring collaboration solutions to help lower distance issues, but Agile at a distance requires higher detail in our work products than co-located Agile.

The size of the team has a distance impact. As the grows, it is more and more difficult for each member share a common set of information. While a team of 100 may be co-located on the same floor of the same building, it is unlikely that they actually share a common understanding of the work at hand. In a sense, the large number of communication links creates distance.

Both Team A and Team B have to deal with the last two critical areas of Appropriateness for the Environment: Criticality/uniqueness and legal/regulatory. If there is a law that says you must, well, there you are. Criticality/uniqueness is a bit more subtle. If the item in the work product is critical for success or is different than what we have done before, then it is worth the time to put in more detail. Leaving the detail out, even competent people may assume that it is business as usual.

An example was some work I had done to remodel a bathroom with a contractor. The contractor, assuming business as usual, had quoted and planned to install a standard 24” towel bar. I had to make sure it was very clear that I wanted three towel hooks (three daughters) instead of a towel bar.

To say a piece of work is “done”, we must consider if the amount of detail is Appropriate for the Environment. To do that, we must look at

• competency in the technology and the customer needs,
• distance: physical, time, cultural, and team size,
• legal/regulatory requirements,
• and the criticality/uniqueness of the item.

How do you determine the right level of appropriateness? That is far more of an art than a science. Often it is a matter of trial and error until you find the right spot. However, as a thought exercise and a discussion point, it can help you contextually determine when something is “done”.

Like this post.

A helpful way to think about a software project is to see the project as a series of decisions about what problem or opportunity the software will solve/implement and the solution itself. Theoretically the decisions start out large and granular and get refined and detailed as the project progresses. Code becomes that last place to make decisions before turning it over to the compiler. Of course in reality, software projects are more likely to see almost random decisions made at multiple levels of detail. At least most projects still tend to wind up at that last decision point—code.

With a serial decision making model of a software project, one criterion in defining “done” is to ask if the work item under consideration is sufficiently complete to make the decision the team or business needs to make at a particular point in time.

Here is an example. Let’s say I am at a point in the project where I need to make a reasonable commitment to the cost and duration of the project. What would need to be “done” in order for me to do that? A simple answer would be the requirements, the design, and some sort of staffing plan. But do I need all the requirements done and all the design done? Probably not. If I had

• identified all critical features with their key non-functional criteria (maybe also critical out-of-scope features identified as well)
• selected an overall architectural approach
• worked out key design elements
• secured commitment from critical staffing resources
• created a list of top risks

I could probably make a reasonable commitment. I do not need all the requirements completed to the last dotted “i”. I do not need every part of the design worked out in advance. I do need the work to go to a certain level of depth and refinement where the information is sufficient enough to make the decision at hand.

Sufficiently complete is about creating the information needed to make decisions at different points in the project. Could I have done all the requirements work before making a cost commitment? Sure, but much of it would be nice-to-have rather than truly needed for the decision. Also, given that much of that requirements detail will be out of parity with other work detail (like design), it is highly subject to change and may mislead the decision at hand. Think of the sufficiently complete criterion as creating just-in-time information.

The question you must ask to determine if a work item on a software project is sufficiently complete is, “What decisions do we want to or need to make on this project?” The decision points are often closely related to the software development lifecycle you have chosen. For a sequential project, I might need to make a decision if the requirements are sufficiently complete to start design. On a more incremental and iterative project, I might need to decide if a story would fit within my iteration length. To make either decision, I have to do some requirements work but not all the work. The requirements work will be sufficiently complete when I can decide the story will/will not fit the iteration (and a little design work will be needed too) or that my risk at starting design on the sequential project is low enough to proceed.

Some common decisions that any project must face are

• Why put our effort on this project rather than some other project?
• What are the problems/opportunities do we want to address with this project (and which ones do we not want to address)?
• Who should be a part of this project?
• What technologies/strategies should be bring to bear on this problem/opportunity?
• Does this project still make sense given the business case and what we know now?

And we don’t make these general decisions once but over and over again at various levels of detail or abstraction. At each questioning, some amount of work needs to be accomplished to get the information to make the decision.

Once you have found your decision points, identify what you must know in order to make that decision. When you have identified what you need to know, you then have the information to judge if your work is sufficiently complete.

In software development, like many other areas of life, we need to decide when some item of work is done. The decision of "doneness" has wide impacts as under-done creates creates defects, downstream rework, and lost opportunity costs while over-done wastes time and resource and incurs its own lost opportunities.

To be even more critical, in my review of documents from hundreds of clients I find that work items are often under-done in important areas and over-done in trivial ones. That is, the document cover, table of contents, document purpose statement, and sign-off areas have been vetted to precision. However, the requirement, design, test plan, or code contained within has defects both minor and major.

This may be explained by human nature as the trivial parts can easily be checked and confirmed. Committees or teams charted with creating common process and practices occasionally find that the only place where they can garner agreement and claim success is in the trivial. One instructor from my past called these the blah-blah pages; they just seem to go blah, blah, blah and not say anything really important.

What about that other part, the important part? Why can't the committees or teams which gain success on the trivial part garner the same agreement on these parts? Well I think the answer here lies not in human nature so much but in the nature of the problem. The issue is that the important stuff in software development, as in many parts of life, is contextual. What is going on in the project, the team, and the organization at the moment when the work artifact is completed all have an effect on the decision of done. You can't really spell out in advance what done looks like.

For example, let's look at the requirement written on a story card, "Make it faster". If I were to consult my requirement books, articles, and heck, even the class I teach, all would proclaim "Make it faster" a woefully inadequate and a completely NOT done requirement. Way too much ambiguity. No scale identified. Not tagged adequately. Not testable as it stands. And the list could go on. This requirement is doomed to cause a lot of defects and angst.

However, on my imaginary project where this story card has been written, the small team has been together for six years and through four releases. The story is was written shortly after the entire team had witnessed the prototype of the fifth version perform reasonable well but much slower than the fourth release did. Having a well defined target customer understood by every team member, the entire team knew what it would take to make that customer happy. For this team, the requirement "Make it faster" is in fact done. It is "good enough" to get the team to focus on the right work to the right level. There will be no defects or angst.

So we can't come up with a clear, complete, consistent definition of done for the parts of software development that really matter. Faced with this challenge, out committee and teams often take one of two paths. The first path is to create the "mother of all templates" and put in everything and every practice they can think of and give (often in small print, with dire consequences if actually attempted) direction that the template may be tailored. This offer to tailor is seen as the compromise to the reality of contextuality. Unfortunately, the compromise is not required as most implementers of templates know that if they do it all—make it over-done—then the process police will give them their blessing and all will be right in their world.

The other path that committees and teams often take to deal with not being able to define done is to slip into a "father knows best" syndrome. The person with the most experience in a given area (even if that means it is the recent hire who is the only one who claims to know the new technology) gets to define "done". So the entire team starts to do what the most experienced—or the loudest—person on the team does. Occasionally, like any flock or pack, there is a fight for dominance or pecking order. Most of the time everybody does it the same way that, by definition, fails the contextuality test.

Given the two paths I seen, what is a committee or team to do? Contextuality demands that doneness can't be defined ahead of time but the costs of not being done are so high. The answer, I believe, is not in defining "done" but defining how to determine "doneness" within a context. The process I use I call my "good enough" criteria. That is, I have four criteria I use to help me decide if the work artifact is done to a level that is good enough for what the project needs to do.

The four criteria are

1. Sufficient to Proceed. Is the work to a level that the next person who must take up the work has what is needed to do their job?
2. Appropriate for the Environment. Are the people who take up the work likely to understand it?
3. Sanity Checks. Has the work committed a classic mistake that can easily be detected by the review of a short checklist of critical attributes?
4. Feedback from Stakeholders. Do the critical stakeholders tell me that it is OK?

I find using the combination of these four criteria gives me insight into how done the work artifact is and is fully contextual. Process standardization zealots can take heart in the sanity checks and experience anarchists can rejoice in the feedback.

In future entries, I will explore each of these four criteria. Until then, I am anxious to hear how you define "done".

That's it, I'm done... for now.

Well, I better rephrase that. The functional part of a requirement is cheap. I can deliver the functional part of a requirement in as little time and in as small of a cost as you like if you let me control the non-functional parts of the requirement.

That is a heck of a claim.

So how do I back that up? First, we need to look into what is a requirement. This is a well covered territory but I have a slightly different spin on it. I maintain that a requirement has two main parts: a functional statement and the non-functional qualifiers of the functional statement.

For example, in the statement, "The system shall deliver the message within three minutes," the "deliver the message" is the functional statement and "within three minutes" is the non-functional qualifier.

In a statement such as "The system shall update the record," the only requirement bit–"update the record"–is the functional part. The non-functional part is assumed, such as "in my lifetime".

It is these non-functional qualifiers that determine the cost and duration of a task or a project. Without at least the critical non-functional qualifiers for a functional statement identified, I really have no idea how long something will take to build or how much it will cost.

Does somebody want a fast solution that consumes large amounts of memory or do they want us to spend time and money to make something that is more elegant and uses less memory?

In fact, you can think of any non-functional qualifier/attribute/quality as being on an abstracted scale that looks like this.

How much I constrain memory use is a choice. I can choose an aggressive point (B) or a more relaxed point (A). The issue is that since non-functional attributes are seldom specified, a project can base its early estimates on a point A assumption only to discover late in the project that the client had a point B desire.

This discovery, while impacting the cost and schedule of the project in a negative way, is NOT product scope creep. The product scope (function) is exactly the same, just how well that function performs has changed. This understanding of the difference between functional (scope) and non-functional (cost & duration) parts can help shed light on a lot of arguments in projects (Project: "It is scope creep!" Customer: "No it is not!"). It can be project scope creep but the word "scope" is usually used for product scope, not project.

The other interesting thing that you can start to see is that there is constant movement toward the more aggressive end of the scale (we all want the more aggressive stuff, don't we?). This movement to more aggressive qualities drives innovation and technology. Functionality doesn't drive technology, non-functionality does.

For example, we have had ways to communicate before smart phones. The function "send a message" has been the same since personal runners and smoke signals. To make the "send a message" function "easier", "more friendly", "more convenient", "more accurate", and perhaps to combine a bunch of other existing functions into a "more portable" package–all of which are attributes that are non-functionals getting more aggressive–is what has driven communication innovation and given us smart phones. The function is basically the same.

This use of the word function is more precise than some popular use. I often hear teams talk about "adding functionality" when, in truth, they are not; they are just making some non-functional attribute of an existing function more aggressive. Is adding a camera to my cell phone adding functionality or merely changing the packaging of two existing functions to make it more "convenient", more "portable"?

I really don't think we invent new functions very often. Mostly we just repackage them to improve the non-functional attributes.

Because the scope (functionality) is often the only part that is specified, project teams faced with impossible schedules often fall back on the same trick. Instead of cutting scope which is highly visible to the customer (and all the non-functional attributes attached to each scope cut), the team will instead cut back on the rarely specified and somewhat hidden non-functional attributes of the specified functionality.

That is, instead of delivering at point B as planned, the project team slides the non-functional attribute toward the relaxed side of the scale. This movement toward a relaxed value will decrease the cost and schedule without changing the claim to deliver the function. The typical sacrificial non-functionals attributes are "maintainability", "reliability", "serviceability", and "portability".

So, back to my claim that I can deliver any functionality (the functional part of a requirement) in as little time as you like IF you allow me to relax the non-functional attributes. It really is not such a bold claim after all since the functionality probably exists today in some form and I can just grab that off the self.

Worse case is that I can say that the output time (a non-functional attribute) will take three million years (a very relaxed value). Just be patient.

Now, about my payment . . .

I have a love/hate relationship with software metrics. While I acknowledge that well designed, well collected, and well utilized measures on software projects can be of huge benefit to the project team, most of us suffer under the burden of measures that are non-designed, ad hoc collected, and not utilized by the team.

Let's take a quick look at those three areas of software measurement: design, collection, utilization.

Design

The starting point for any useful software measurement is in the design. Most software measurement gurus I know point to Vic Basili's Goal/Question/Metric (GQM) approach for designing useful software measures. In this approach, you start by articulating a clear goal you want your task/project/organization to achieve.

Well, right there is were the measurement woes begin. It is not common to see well articulated goals in software development in general let alone associated with the measurement program. What I see at clients' sites is often more like a general wish than a goal: "improve productivity", "reduce defects".

Where I have seen at least a measurable goal, "reduce defects by 50%," no mention of what kind of defects we cared about. The team previous to the "goal" implemented small enhancements requested by the customer by adding them to the defect database. With general defect reduction now the goal, the team started arguing with the clients about what was a "defect" and forced all small changes into the bureaucratic change control process. Not only did the released quality not change but the customer was even more upset than before.

Truly sick sigma in action.

There is a lot of information on how to write good goals out there. The more interesting question is that why, with all that good information, do we still not have well stated goals in general and software measurement in particular?

My take is that good goals require both resources to achieve and accountability. Both are in short supply when the focus of the organization is almost entirely on getting the product out the door. You need slack to do good measurements and our getting lean and mean leaves no room for any goals than "ship it".

Collection

After a reasonable design is in place (and that may take a few iterations) it is time to move to collection. Here, sick sigma metrics fail in two areas: practice and accuracy.

"Practice makes pretty useful" should be a mantra for software measurement. Given a well designed metric, the people collecting the data still require a lot of practice in identifying instances of the metric. Without the practice the data collected will end up comparing apples and applets. Close but no banana.

Take the common data collection item Line of Code. What is a line of code? Does it include comments? Only executable statements or physical lines? What about actual function? Would we count it differently in C++ than COBAL?

Or how about Defect? Do I include defects committed in requirements but discovered in design? How about defects in areas that the specifications simply did not address? How long after initial customer acceptance do we still count the defect for our metric?

While the design should address some of these questions, only practice in the world of messy reality can help a software measurement. To paraphrase Fred Brooks, plan to measure several times, you are going to throw the first few away anyhow.

The second area that sick sigma falls down is accuracy. Sick sigma substitutes precision for accuracy. The metrics produced by sick sigma are very nice down the fifth or six decimal point. Unfortunately, they are wrong.

The data collection in almost all of our human systems can only achieve a rough level of precision. With overly precise measure we make it harder to collect and easy to dispute. Instead we want measures that are easy to collect and harder to dispute.

For example, say you are collecting effort data. Sick sigma implementations would have each technical professional record down to 10 or 15 minute increments twice a day how much time was spent on task. Not only does this high level of precision make it irritating for the data collectors (the technical staff) but the wide variation of knowledge work will result in people recording more the time they spent in the office than work on task. This makes it ripe for dismissal as useless.

Instead, if had them round it off to the nearest hour at the end of the week, then we could present the data as imprecise but accurate; it tells the right story. The question of effort data is not, "did we spend 17 hours or 18 hours" on a task but, "did we spend a small amount or large amount" of time. Here, rounded off data that is accurate but not precise can tell us what we need to know. Attempts to dismiss the data as inaccurate is far more easier to refute since it isn't trying to be precise as well.

Utilization

The last area where sick sigma hinders software teams is in the utilization of the measurements. In sick sigma organizations the data collected disappears into a metrics black hole. I call this "measures for the merely curious" since it never seems to change anything. This usually covers almost all metrics that are requested by upper management.

Data collectors should only collect data so decisions can be made and actions taken.

What we need to do is feedback the measures to the data generators/collectors as quickly as possible. That is where the main action is so that is where information can aid in making decisions.

The best case is that the data is immediately visible on a common wall where the data generators see it on a regular basis. I recall one shop where code growth, earned value, and defect counts were all kept on a wall in the midst of the development team. Once a week this information was updated and the team made decisions based on the data. This is not so different from what many agile teams are doing today.

Healing Sick Sigma

Using GQM, getting practice, telling the right story, and using the information locally are all ways to heal the wounds caused by poor metrics.

By the way, any resemblance between "sick sigma" and "Six Sigma" is . . . uh . . . purely coincidental, yeah! that's the ticket. If you want to know my views on the latter, drop me a line and I will sure to trend the results, Pareto the feedback, and analyze it to seven significant digits. Then I will stick it somewhere, I am not sure where (and not there either), but it will be colorful!

Steve McConnell put up a post on his lack of a real estimate for a child's fort and how that was related to a software project. I have a similar example of an agile bathroom remodel.

The Story

Our existing bathroom had a small problem. Water was leaking through cracks somewhere in the older tile, grout, or plumbing. Since repairing would require us to go to the studs to find any water damage, we decided to update the entire small bathroom.

The agile approach was to work out the details of the requirements as we were building the bathroom. We started with a planning meeting where we listed all the major goals/stories and preferences. We then planned to meet at the end of each day where I would be shown what the contractor completed that day and talk about what was planned for the next day. As I saw the completed work, I would give additional detail of what I wanted on the remaining work. My wife was home each day to act as the on-site customer.

So here are how the increments (simplified) went down:

1. Tear out the existing tile, grout, and walls and determine water damage (limited, whew!).
   Check.
2. Install new Moentrol pressure balancing valve and solder the copper piping to the shower head and water supply.
   Check.
3. Install the (expensive) waterproof backer-board imported from Germany to create a watertight seal around the shower.
   Check.
4. Install (medium priced) tile using mortar applied directly onto the imported waterproof backer-board and installing (expensive) decorative tiles and trim in the shower.
   Check.
5. Install (expensive) epoxy grout that gets very hard but is waterproof and does not require sealing.
   Check.
6. Install the (high priced) Moen Kingsley faucet.
   WHOA!

It should have looked a bit like this.

Notice there is a little bit of a gap between the handle and the escutcheon (big silver plate). Probably a quarter of an inch or less.

This is what mine looks like (it really is silver, though, like the previous picture).

Notice how much larger the gap between the handle and the escutcheon is? When measured, it is over half an inch! Every time I see it I think, "Hey, I need to push this thing on the rest of the way!"

You should see it when it is pulled out to the 'on' position; over an inch. It looks like one of those long needles on a seismograph. Maybe not a bad idea for where I live in the earthquake prone Pacific Northwest. I will know about every tremor in the shower.

So what are my choices as the customer at this point? My choices are one of two:

• OPTION A: Move the Moentrol valve further back into the wall. To do that the contractor would need to grind out the (expensive) epoxy grout, chip out the (medium priced) tiles and (expensive) decorative tiles & trim, and cut out any of the (expensive) imported backer-board that wasn't ripped out with the tile and mortar removal. We might not need to unsolder the copper piping. Once exposed, we could then move the valve further back into the wall. After that, we would need to reinstall new (insert cost here) backer-board, tile, decorative tile & trim, and epoxy grout. Please note that this would increase the cost and schedule of the initial repair project by at least 60%. Please also note that given the patch job in the backer-board, tile, and grout that a leak into the wall is more likely—just what we were trying to fix.
• OPTION B: Learn to enjoy my unanticipated Moentrol Washcloth Holder™ feature.

The Project Analogy

While I know of many successful agile projects, I also hear something like the following phrase way too many times. It goes, "We were working an successful agile project when it was suddenly canceled due to outside factors." Those factors range from mergers to business changes. But, I ask myself, if these projects were delivering value, why where they canceled? Sure, some business changes would lower value but canceling a project is pretty rare, even in non-agile settings that are NOT delivering any value at the moment. So why?

My guess is that the customer received a Moentrol Washcloth Holder.

Sure, the functionality is absolutely correct. The faucet functions just like a faucet should. The story is satisfied. But the solution just isn't right and it isn't what was expected. Turns out that this expectation about the solution concerns non-functional "quality" requirements, not the functional requirement well captured by the story. Further, it is a horrid truth that non-functional requirements are designed into the solution, not coded in at the last moment. Our development approach didn't deal well with this particular non-functional requirement. Our emerging design was not easy to change. I did not see the design flaw coming.

Few development approaches (Evo exception noted) deal well with non-functional requirements. Software development has a functionality bias.

Faced with a Moentrol Washcloth Holder, the customer's perception of value plummets. Costs have not changed, functionality has not changed, but the desire to defend and promote the project has suffered a tragic blow. The excitement is gone and any other interesting work sounds better than another Moentrol Washcloth Holder.

The Reflection

Could we have foreseen the non-functional requirements failure? Where did the failure stem from so we can prevent it from happening again? I called the Moen help line to find out about the expected gap between the faucet handle and the escutcheon. Their representative said that he has heard that the average gap is about 1/2 inch.

"But," I protested, "it looks really stupid. Like it is not all the way on."

"You need to clear the back plate [escutcheon]," said the rep. Now, I only play a mechanical engineer on TV but I figure two chrome covered pieces of metal embedded in a wall will not expand more than 1/32 of an inch. I really don't need 1/2" let alone the 5/8" I got. Bad valve design on Moen's part.

That could be fixed with good instructions about how deep to put the valve in the wall. The detail of the Moentrol valve installation instructions that is appropriate to the discussion looks like this

My contractor tells me that it means that if you have a thin wall (like a inserted fiberglass shell) to push the valve back behind the wall. If you have a more normal wall like mine, make the valve flush with the outer wall. To me, it doesn't talk about the critical information at all: the stem length. Bad installation instructions on Moen's part as well.

All this could be corrected by a knowledgeable contractor. Knowing that the valve design creates a long stem and knowing that the installation instructions do not reflect that the stem is longer in this Moen product than in past Moen products, they could have compensated. In fact, one of the contractor's employees stated after the fact to the contractor something to the effect of, "Remember the last one we put in, how it stuck out this far?" Bad implementation by the contractor.

Finally, as customers, we had an unpleasant encounter with the contractor's choice of fixture supplier so we decided to purchase this particular faucet based more on the sink faucet than the shower. That is, we never saw a prototype of the faucet shower. Bad due diligence on my part.

In reflection, the contractor could have raised a risk based on past experience and called for a spike. I, also, could have asked for a spike to check out the shower faucet since I knew I hadn't seen it anyplace except the manufacturer's web site.

We could have done a better job a risk management by attacking those non-functional requirements through prototypes (spikes). We needed more up-front planning. It may not sound as agile as many like but, there you have it.

So, on the next job I will hopefully apply the lessons learned. That is, if I don't cancel for fear of another Moentrol Washcloth Holder.

When is the right time to give up on a project, a design approach, or a requirement? What factors do you consider in coming to the decision that it is not in the organization's best interest to continue forward with the current approach?

I know that the economically oriented folks will suggest that we look at the net present value discounted over the useful life period minus the initial capitalization and number of pizzas ordered per developer. Sure, that is a fine rational way to do it. However, it has the fatal flaw of relying on human beings to generate the numbers and eat the pizza. In my years of playing with numbers, my conclusion is that the world "playing" is the correct choice. You can come up with just about any result you want.

The economic approach also misses the emotional side of the equation. The project was needed to drive the revenue (or cut the costs) necessary to meet some commitment made to the organization in the annual goal setting exercise. If the project does not deliver, some director or VP will not meet their numbers and that director or VP will look bad. (If we talk about not getting a bonus, then we are back at the fatal flaw of the economic model.) People do not like to look bad so they hang onto the project, the design approach, or the requirement long past its pull date. At which point, they still won't meet their numbers but then the director or VP can blame the poor developer for not living up to the developer's commitment. That the commitment was extracted by force is quickly forgotten.

Don't forget the stigma of being labeled as "negative". If we even suggest that the current approach is not working, the goons from the Corporate Office of Positive Thinking come to pay us a visit. They encourage us to try harder, to work through the challenges, to be a team member and give 1,837% to the effort. Any thing shy of 1,837% is a defeatist attitude and you should probably rethink your career choice.

There often is a lot of pressure not to give up.

So how do you finally make the decision?

The most common answer my exhaustive research (asked a couple of people) has uncovered is (drum roll please) fatigue. As in I am too tired to keep trying.

Case is point is my latest decision to give up on compact fluorescent lighting (CFLs). Yes, I know CFLs are god's gift to lighting and I must be an environmentally insensitive global warming jerk for stopping my use of CFLs. However, I have reached my fatigue point with them. You see, I have this really bad habit of turning of lights when I leave the room (blame my father) and CFLs hate that. They don't like turning on and off. Every time you turn them on and off, they shorten their life span.

So, I found myself leaving lights on (and having the echo of my father yelling at me) or end up paying more for a light bulb that a) didn't last as long as a incandescent and b) put out less light. On top of that, I have a garage full of the damn things waiting to go to the hazardous waste site since you can't throw them away.

I got tired of messing with them so I gave up. Is this the most rational way of making the choice? Maybe not. However, I do think it is the most common way, whether CFLs or software projects. I wish there were a better way but this is the one that seems to work.

A couple of posts ago, I shared a concern with distributed agile development. A similar thing happened to me recently with another question from two different clients who work on a highly complex mobile operating system.

"Can you be agile in highly complex environment with emergent system characteristics across two thousand developers?"

And I had the same response as to the distributed agile question.

"Uh, yeah, you could go agile... I guess."

Why can't I get the easy questions? The fact is, you can't go for an pure-play agile approach across such a large organization with critical system-level characteristics. You have to put into place more planning than a pure-play agile process would desire.

"But," my more hyperactive agile friends would say to me, "you are not having success with a pure play plan driven approach either." (Ever notice that some arguments for agile have to do mostly with what isn't working with something else?) Yes, my hyperbolic prognosticators, there are a lot of issues with a highly plan-driven approaches as well.

So my answer is to do both.

As with any big project, you first have to break it into lots of smaller teams. This is just to get things done. How do you break it apart? Well you have to do some planning. Often, you create the smaller teams along the architectural lines (up front analysis) to have high cohesion, low coupling between the teams.

On the smaller individual team, we do something very close to the pure-play agile side of things. The team has a backlog of work. That work is done in short increments/iterations. The team defines the tasks to complete the work on the backlog. The team calculates its own velocity. The design of the functionality the team is working on may emerge over time. Feedback (as much as you can get) from critical stakeholders or their representatives is solicited.

To coordinate those teams we have a mix of planning and agility. First, modify the idea of a scrum-of-scrums. Attempting to "roll up" status at the same level of abstraction has failed in my and my colleagues experience. (Perhaps somebody, somewhere, got it to work once, probably while involved in some sort of substance abuse.) In the modified second level meeting, individuals who have participated in the smaller team status meeting "scrums" report at a higher level of abstraction. The "scrum of scrums" report is at the release level, not the task level.

To report at that level of abstraction, each member of the second level of status translates what they hear from the daily status meeting to a meaningful statement of the status of the release/milestone. Eight completed iterations out of ten does not necessarily equal 80% when a translation is involved. The human ability to consider multiple variables and intuition plays a part as well.

Planning also happens by placing items in the product backlogs of the small agile teams. System architecture or its equivalent watches over the product backlogs to 1) make sure system-wide characteristics are considered and included and 2) modify the timing of some backlog items to make sure that cross-team dependencies are worked in an acceptable order.

For all practical purposes, system architecture is one of the critical customers of the individual small teams. The system architecture group writes the stories and the tests of the system wide characteristics and can put those stories into the product backlog. In the customer role, system architecture's acceptance tests are the system tests.

So we have planning where we have to and agility where we can. No, it doesn't fit into the agile camp or the planning camp. I like to think it fits into the common sense camp. I guess common sense can be complex.

What does it mean to be a mentor? While I can fancy myself as pretty knowledgeable in a couple of areas (mostly the proper way to eat an Oreo© cookie and how to make my wife angry), mentoring somebody else in that knowledge is another matter.

As a Certified Software Development Professional (nice big IEEE title) one of my professional duties (nice IEEE ethical stance) is to mentor others. I think this is reasonable and, actually, I am in favor of establishing a more formal apprenticeship program for junior developers. Software engineering, like most engineering, is both an art and a science. We can teach the science in school but you have to have experience to really gain the art. And that experience should be guided experience. So, while not trying to promoting the art side too much  (there are known reasonable practices), we should all occasionally sit at the feet of a master.

Much as I may support it, software engineering doesn't have a craft guild to enforce an apprenticeship program. So what we have left is mentoring.

A lot has been written over the years on what a great thing mentoring is and that everybody should have one. Most of what I have heard is more about how you should get a mentor. Of what I have heard (which may be surprisingly little), most of that consists only of the advice to meet.

So, what do you do when you meet with them? Ah, that is where the advice starts to wear thin. It seems even thinner for the Mentor than the Mentee(?). I know there is a pair here in the relationship so, what is the Mentor side to do?

So, I have come up with a list of ten things a Mentor and a Mentee can meet about.

1. At the first meeting, exchange names, cell phone numbers, and favorite sports (just in case the talk about software begins to lag). The Mentor should set up the first few meetings at least as the Mentee is probably still trying to figure out how to use the corporate scheduling system.
2. Work at establishing a growth plan. For a starter on this, look to the Professional Development Ladder from Construx. Any good ladder, like Construx's provides a balance of knowledge and experience. One does not want a lopsided Mentee.
3. At the same meeting or another, tailor the ladder for the Mentee interests and the companies needs (keep a balance). For example, if they want to get into embedded, then you can select readings and activities that focus on embedded programming in the construction cells. Or, even better, have the Mentee focus a lot on how to test the heck out of it.
4. Establish a realistic time-line to do the reading/training and activities. Many a Mentee has burned out due to trying to go too fast. In truth, many of the books one should read can put an insomniac to sleep, instantly. Many doctors use software engineering books as a last resort treatment for sleeping disorders.
5. Keep a look out for projects/project roles that will help them complete required activities. As a more senior person in the organization, you probably have more insight in upcoming projects. For the roles you think they are ready to take on, recommend the Mentee or have the Mentee volunteer. If you are really good, you can recommend a few activities that the Mentee will fail miserably. You can then sit back and say what deep things we can learn from failure while you laugh behind their back.
6. Set up a schedule of meetings (monthly or quarterly) where you get together and talk about what the Mentee has done/read/attended. It is your job to make sure the Mentee gets the main concepts and points of the reading/training. No, you don't give exams, you speak from your experience in going through the same material. (Uh, you did read some of this stuff yourself, didn't you?) You also confirm that the Mentee did "good enough" job in the activities.
7. Don't make the Mentee do anything. You just recommend. If the Mentee doesn't do it or doesn't want to, it is their career. This is not a parent/child thing.
8. I try not to let it get into any kind of grip session. It is easy for the Mentee to get frustrated if the reading is difficult/voluminous. Keep it positive. You can recall what a pain-in-the-#@!! it was for you to read all that stuff.
9. Give feedback to the Mentee's line manager around performance review time (if you are saddled with that) about what a great person the Mentee is. Of course, it is due mostly to your fine talents as Mentor but, hey, the Mentee deserves a raise for all the hard work. (You probably do to but that is your's Mentor's job to mention.)
10. Don't be afraid to tell a Mentee that they are not progressing in their development. We all get comfortable at certain stages and the demands of the day job can overwhelm. It is the Mentor's job to jab at the Mentee from time to time to keep the Mentee moving. It is kind of fun, too!

If that doesn't set the stage for many a fine Mentor/Mentee meeting, I don't know will. Perhaps I should ask my Mentor...

I had an interesting discussion recently with two different people about moving toward a more agile development practice. The first was a potential client who had a small team in California. The second was a with the office staff of a services firm who wanted to better understand what agile is all about.

The interesting bit of the interesting discussion was the type of environment the groups wanted to deploy agile methods into: highly distributed development teams.

Uh, yeah, you could go agile... I guess.

So what does distributed agile really mean? Sure, I can do development incrementally and iteratively. Sure I can buffer the requirements so that all the real requirements work is done in a just-in-time fashion. Sure, I can let the team define and allocate the tasks necessary to meet the iteration/release goals.

But am I really being agile or am I a pig with lipstick?

I have concluded that one of the main driving forces that makes agile, agile is the constant in-your-face, here-are-the-facts, you-gotta-know-this feedback that permeates the agile team. Team member to team member, team to product owner, product owner to team. Agile is a do a little and get feedback, NOW!

Even with all the cool communication technology in the world, we really can't pull off that kind of feedback in a highly distributed environment. Heck, even the cool technology in StarTrek couldn't pull this off. The technology needed to make us truly agile is face-to-face people. Even then face-to-face is no guarantee. Face-to-face feedback can be limited, especially when I put the headphones on. Good face-to-face communication has to be cultivated.

Doing task cards over a web interface on three different continents is not really a substitute for the group standing (or sitting) around a table and a stack of cards. The job at hand does get done but little of Alistair Cockburn's osmotic communication is happening. Worse, feedback is delayed until the next scheduled meeting time. With limited up front work, agile relies on feedback at every stage of development.

My advice to those two groups was basically the same. Get the team together, for a least a while, to learn about each other. That will make the communication more personal and informative. Use things like instant messaging buddy lists and webcams to make the team feel the "presence" of all of the members. That will help them think like a team rather than associated individuals or, even worse, a local tribe. (A big problem with the "we code here and they test it at night there" approach. You can create software but are you agile?) Finally, try to partition the work so that at least some level of local collaboration and face-to-face can occur. Don't make every event have to span the location gap.

So is distributed agile really agile? It does meet the self-definition of agile that seems to be applied by the agile fanatics. It is a variation of the Forest Gump definition of stupid: "Mama always said that agile is as agile does."

Even when it may not be.

My daughters like to square dance. They seem to, for whatever reason, really like the petticoats: the layers of fabric that make the square dance skirt get really poofy (as if poofy is a word). To support my daughters, I dance with them since there is a general shortage of males (even if we don't have to wear the skirts). I tell you this because it will help make sense of the next paragraph.

I challenged the caller of the square dance club (person who tells the square dancers what moves to make) to make a "singing call" to a song of my choice. A "singing call" takes an existing popular song and substitutes square dance calls for some of the lyrics of the song. It turns out to be a generally fun way to dance. I tell you this part because it will help make even more sense to the next bit of the story.

The song I picked was Foghat's Slow Ride. I had heard this song many, many times since it came out in 1975. In fact, I had heard it REALLY LOUD several times which may have something to do with my mild hearing loss. (Truth be told here, I still play it kind of loud on my iPod.) This was, in my circle of friends, a really cool rock anthem that we could shout out to while we drank our beer.

Now if you asked me what the song was about, I would have told you (having heard it many, many times) that it was about drinking beer (that is what we typically were doing when we played it REALLY LOUD) and maybe about motorcycles (we liked those too). But mostly it had really cool guitar riffs and allowed us all to look like idiots playing "air" guitars while spilling our beer.

The caller, who had a similar circle of friends and had spilled beer doing air guitars in the past, took the challenge. The first order of business was to get the lyrics so he could sing the song and find the places to add/substitute square dance calls. Now finding lyrics is pretty easy with the Internet.

It turns out that the Slow Ride lyrics are not about beer.

Or motorcycles for that matter.

In fact, Slow Ride is probably not something I should have a respected adult be singing to my pre-teen and early teen aged daughters.

I tell you this story because I believe this is a great analogy for how many requirements come into software projects. I knew this was a great song because I had heard it so many times. It was just a plain, innocent, jamming kind of song.

But in truth, I really didn't know. I never did the research to find out what the song was really about.

Neither do a lot of our stakeholders. One of our jobs as software engineering professionals is to help or stakeholders discover the truths beneath their beliefs. That is what requirements analysis is about. In my work with stakeholders, the requirements analysis process is often the first time they had thought deeply about the problem. Their expertise – based on doing the job many, many times – is perception biased. They know what they know.

Just like I knew. It should be "... rock all night", you know. A song about motorcycles would be really cool.

I am thinking of going on a crusade against functional requirements. Why? Functional requirements are overblown, over-specified, over-referenced, over-exampled, and we need to get over them. By the over-focus on functional requirements by tools, books, and pundits, we cajole our customers to attempt to detail and confirm the functional requirements down to the gnat's eye.

And this is just wrong, wrong, wrong.

As you know, a functional requirement is a requirement that describes the thing the system must do, action to take, rules to enforce, information to remember. Not necessarily a bad thing and certainty not worthy of a crusade. To see where we go over-the-top, we should look at an example.

"I want to be paid."

We can translate that to the functional requirement, "the system must pay the employee." So far, so good. I am cool with this. I like getting paid. Then we development folk will whip out our models (class, activity, use cases, state diagrams), hold massive interviews, and try to get the customer to state functional requirements to capture in big specifications (or tiny stories) like:
- The system will collect the hours worked
- The system will calculate the gross pay
- The system will calculate the deductions
- The system will calculate the net pay
- The system will transfer the funds into the employee's personal account

Boring!

Maybe the last one needs a bit more of a look but the others didn't really surprise anyone. That is the thing about functional requirements: for the most part, they are pretty darn obvious. So instead of stopping there, down we drill until we get things like:
- The system will set the paid flag on the employee periodic transaction

From bored to disengaged.

We have moved from the nice stuff that is obvious to the stuff the customer really doesn't care about. All the customers care about is that the software does those obvious functional things in a correct and useful way with minimal effort on their part. These requirements—requirements beyond the functional—are not obvious.

I always cringe at the image of those early smart software development folks who were looking at all the requirements that were NOT functional and said, "What should we call these? We know they are not functional. They are.. are... NON-FUNCTIONAL!" So if functional requirements are important (if obvious), non-functional requirements must be non-important! This is backed-up by the fact we don't have many models, tools, or techniques to explicitly elicit these non-important requirements.

Sigh.

Since these are not obvious and we do not have great means of eliciting them, they tend to be ignored. This is to the peril of most of our projects since it is these non-functional requirements that determine the cost and duration of the project. Contrary to popular belief (and many books), functional requirements do not determine how long a project will take. They only identify the sets of non-functional requirements that need to be scaled and goals defined.

Yes, I can, in a gross way, control scope by taking sets of non-functional requirements (tied to a functional) in and out of the project. But I can meet any arbitrary set of functional requirements in any amount of time if you let me dictate the non-functional requirements. Heck, we do it all the time when management requires us to put an unachievable amount in of functionality in a unrealistic short time frame. We just relax the non-functionals; especially maintainability, serviceability, interoperability, usability, and reliability.

Think Zune.

You too can take up this Don Quixote charge against the windmills of functional requirements. The next time you are tempted to create another functional "story", think instead of how-well that boring story should work. What would make a customer *like* that story. If you do that, you have will have served your team well.

Unfortunately, you probably also damaged a source of green power. Sigh.

At Construx I teach both the Estimation seminar and the Advanced Quality seminar. One question I usually get during the Estimation seminar goes something like this, "How can I estimate how long quality will take?"

Now this is a fascinating question in that it is so wrong and yet so important to the people asking it. Let's look at the "so wrong" part first. The question as stated assumes that quality can be added on during some activity, like icing a cake. "We created the software," a swaggering project lead may say, "and now all we have to do is give it quality!"

"How long will that take?" asks the confused but kindly business partner.

"Well, that is why we took the estimation class. We estimate between two to five quarters." At which point the kindly business partner outsources the entire staff.

Perhaps the question is so wrong because it is the kind of question that is not designed to be answered by a direct answer but by another question. Perhaps a good response is, "How poorly do you plan to do requirements, design, and code?"

It is also so wrong since nobody has actually defined what quality means on the project. Do they want to know when key use scenarios work 90% of the time? 95%? 99.99999%? When we have reached a defined level of brokenness? (Um, I mean number of outstanding defects.) Maybe the questioner wants to known when we have spent enough time doing "quality"? Perhaps the questioner wants to be able to defend themselves later. "We spent this much time on quality, how could you possibly complain?"

It is the need to plan, however, that makes the question so important. My seminar attendees are in charge of testing and they need submit their staffing needs and time-line to the primary planners. Will they need four weeks with eight testers or ten weeks with fourteen testers?

The trick, I think, is to change the question. A better question, one that might be answered, is "How long, given our past performance, will it take to find 95% of the defects we insert?" Let's break that down.

Past performance. We can not even begin to estimate "quality" unless we have some idea of how many defects we create. Most organizations have some sort of defect tracking system and a management infatuation with defect numbers so this shouldn't be too hard to get. And even if you don't, you can bootstrap this with estimation techniques.

Defects we insert. We also need to have some idea about our defect detection rate. Let's say that the project will insert, based on past projects, about 500 defects. The test groups finds, on the average, 2 defects per staff hour. Simple math tells us the project needs about 240 staff hours to find 95% of the defects.

If the project has better than average data it can step this up and say that the 500 defects are broken into 50 requirements defects, 150 design defects, and 300 code defects. Now, the quality lead can ask the development lead how long it takes to correct, on the average, a requirement/design/code defect. This is a great trick for the quality lead as it puts the, "how long does quality take" problem back on the development team!

Finally, if the project has that better than average data, the quality lead can start saying, "I plan to use peer reviews (or collaboration or formal methods ...) at this point to find 45 of the 50 requirements defects." This takes a lot of pressure of the end testing game and a much better way to "do quality".

To me the "how long does quality take" question is the same ilk as "what is the sound of one hand clapping". The primary purpose may be to lead to a better question, not to come up with an answer.

I don't like being late. I have never gotten into the habit of arriving well after the party starts (under the euphemism of being "fashionable", like you couldn't get your clothes on) nor sending birthday cards after the fact (though I do admit the belated birthday cards are often funnier). I tend to arrive to meetings a few minutes early, be one of the first guests at a party, and make my trains. (With my recent trip to Switzerland, being on time really helped with the train thing.) Sometimes, if I am running behind, I will just cancel the item I am late for (as if I never really planned to go) and be really early for the next thing.

I, however, appear to be in the minority. Many people appear to enjoy being late. Most of the companies I visit joke about the five (or fifteen!) minute rule for starting meetings late. Not that there are many with me to make the joke at the scheduled start time, just one or two other people who desire to be on time. Most people seem wonder into parties, dinners, movies, plays, etc. whenever the mood strikes them. There are full industries, like furniture deliver staff and plumbers who take being late to a professional level.

Don't get me started on airlines...

With this seemingly mass movement towards lateness, why do people get upset when the software project is late? Should it not be expected, if not desired? Can software be "fashionable"? Maybe there is an "acceptable late" and an "unacceptable late". A five minute late airline departure from the gate is not a big deal; a fifty-five minute late departure typically is. Being an hour late for a birthday party can be OK unless, of course, it is a surprise birthday party and it is your birthday. At that point, everyone is pretty pissed (both UK and US versions of that word).

Maybe it all has to do with expectations. Are there expectations of time that include some degree of lateness as acceptable? (I have heard of places where being on time is NOT expected!) If I set the expectations appropriately, then being late is the right thing to do. If it is expected that meetings start late, that the party really doesn't get going until 2200, that the train will leave no sooner than posted, then perhaps nobody gets upset.

If this thinking about expectations is correct, then we should start setting expectations of lateness when we are asked about when the software will be done. We can say, "Well, here is the target date but it is likely to be late". We can talk about the software's completion being no sooner than 4th quarter 2012. A good way is to say the software is going to be really late then list al the things the person asking the question can do to make it come in sooner. Now it is a shared responsibility and the asker can manage their own expectations.

Perhaps setting late expectations can lower the frustration felt when fully-functional high-quality software development takes the time it needs to be fully-functional and high-quality. As long as they don't turn around and ask me if I expect to get paid for this.

One of my secret passions is to kill the man (or woman) who started to use the terms verification and validation in the software world. I know you are hiding out there and when I find you, I will do justice.

I mean, first of all there is this horrible trick of using two words that sound soooo close in English. We don't use many of those 'V' words in this language on a day to day basis so just starting out with a 'V' pretty much means we ignore the rest of the letters. I think I only know about five 'V' words off the top of my head: Valium, (beach) Volleyball, Vacant (my head), and those two nasty beasties listed above. And they all mean the same thing, "time for beer."

And then there are the software related definitions of those two words. Verification: did I build the thing right; Validation: did I build the right thing. Or is that the other way around? I can never tell. I always need to look it up since it is just switching a word here and there. Not that starting the word with a 'V' helps me out much (see previous paragraph). It is like asking if I drank the beer and was it the right beer. Well, by definition, if I drank the beer it was the right beer!

And in the shorter phrase "V&V", which one comes first? Is there a rule on that? Is that rule as critical as the one about not wearing socks with sandals?

Wouldn't it have been better if we called it Requirements Confirmation and Design Confirmation? First of all, we would a nice alignment with the activities that typically produce the needed stuff for the V&V and the V&V itself. Second, we would have words that are completely different and therefore much harder to confuse. The drawback with this solution, of course, is that nobody really gets the difference between requirements and design. (Somebody just said to me the "what vs. how" thing again today and I almost did justice on them!)

There has to be a better way! I will find you V&V instigator! I will vilify you! You will wish you were virtual! I will vanquish the pain you have caused virtuous software developers. Very truly I tell you, vultures will think it vain to feed on the bits left. Victory is ours.

V on!

Steve McConnell (my boss) is bragging about his company since it got voted the best small company to work for in Washington State. He is so proud that he needs to do the bragging in three parts!

I have to admit, it is a pretty nice place to work. Did he mention the free beer? Anyplace that has free beer is a great place to work by definition. Not to mention that I am writing this in my private office while wearing shorts and listing to the blues. Unless, of course, I get too distracted by trying to decided how to spend my many weeks of paid time off. (I am thinking August is no longer good for me.)

Now that I have you all jealous, of course Construx is a great place to work. There are only sixteen of us and we are all contributing professionals. I think you can do things as a small, flexible company that you just can't do other places. What may be more interesting are the common things that make a company a worst company to work for. Not the weird things done by a psychologically disturbed pointy haired boss but the irritating things that happen day in and day out that can make a place a living hell.

Here is my short list:

• Bodily noises from the people who work around you that are better left to the pages of Mad magazine
• Food or drink at a work station that has been there since the disco age
• Print jobs that a) use the last of the paper or b) jam the machine and were launched by a person who just went on a three week vacation
• Anybody who works around you whose teenage children have more ethical lapses than a presidential administration
• Any client or manager who begins a request with the phrase, "It is just a ..."
• The rattle made by the air vent in the ceiling in which you have already stuffed 37 post-it notes
• Application dialogs that tell you that the system has crashed/needs to be restarted and then asks if it is "OK"
• Meetings scheduled for the end of the day because that is, "the only time everyone is available" -- because we want to go home!

Anything else?

In our 10x and Agile seminars, I talk about the role and purpose of incremental and iterative (incremative) development practices. On the surface incremative development is kind of wasteful. I mean, it is like asking me to drive to the grocery store and a I stop on each block, call home and ask my wife, "I am one block closer to the grocery store. Do you still want me to get the milk?" By the time I get there, buy the milk, call 10 more times on the way home, ("Do you still want me to come home? What do you mean you are having doubts???") the milk is spoiled and the tea is cold.

There is waste even if my wife were to say to me, "I think I need something at the grocery store, but I will not know until I see it and I am not sure what store I want to go to. Get in the car and start driving." There is wear, tear, and overhead costs in starting and stopping the car. We will take more time to buy the thing-she-may-end-up-buying-but-won't-know-it-until-we-get-there then if she knew what she wanted in the first place. Heck, I may even drive the wrong way and have to retrace my path since I need to guess a bit to choose an initial direction. Why even start a trip like this? It doesn't make sense.

I only have that "waste", however, when I truly have a deterministic outcome. If I can know the final destination, the straight line always will be faster. It is when uncertainty creeps in that I need to be incremative. With uncertainty comes the need to gather information to lower the uncertainty. The "waste" of incremative development is a known cost to buy information and avoid the potentially much larger unknown cost of guessing wrong.

Being incremative is all about lowering uncertainty by getting and acting on feedback. The incremental part of being incremative determines how often I get feedback. Since I have high uncertainty about what the other bozos on the road are going to do, my increments are often very small as I constantly scan the traffic. I don't let my eyes leave the view of the road for long (unless, of course, I need to send a text message on my mobile). The iterative part of being incremative determines what I parts I do over and can change based on the feedback. As I spot a bozo in a red truck coming into my lane, I change my acceleration, vehicle direction and the amplitude of my horn. Based on what the traffic does around me and my desired route, I will change the vehicles parameters many times.

But here is the punch line. Both certainty and uncertainty can live side by side on the same trip. I can be certain of my desired destination (I want to go to the store) but have uncertainty about the traffic, road conditions, etc. on the way there. Saying my trip is completely deterministic because I know I want to buy milk is naive. Saying it is completely uncertain because of the traffic is simplistic. It is both and I need to approach it that way.

So the trick in incremative development is to find the right balance, the point where I buy just enough information to lower the risk to an acceptable level. Too much, and I have unnecessary waste; too little, and I likely to have large undefined costs.

Like when you brought home the non-fat when your spouse really wanted the whole. It's back to the store again! (Note: bad iteration!)

So, I was driving along, making a right turn into a driveway like I have done a thousand times before. I did what one always does when making a right turn: I checked carefully for pedestrians and watched the driveway to make sure nobody was coming down it. I then signaled my intentions and proceeded. Unfortunately, this right turn was occurring in England. Did you know that right turns in England cross on-coming traffic before entering a driveway? Well, I and another car added more evidence to the theory that two pieces of matter can not occupy the same space at the same point in time. In making that right turn, context mattered.

Context matters with requirements and design work. The context actually determines if something is part of the problem space or the solution space. The same exact statement (e.g. the menu must drop down) is a solution requirement if the context is that I am to build the user interface; a problem requirement if the context is that I am to build the database only. In fact, I am starting to believe that any kind of specification without a clear understanding of its context is basically worthless.

Context matters when picking lifecycles. I recently was teaching our Agile seminar and describing the basic Agile approaches. "But," said the students, "we have twenty interdependent technology streams with 300 developers building a core proprietary OS on three continents with at least five 'equally treated' stakeholders who need direct access to the developers to work out interface details to the UI and other hardware components while maintaining backwards binary compatibility." Well, out of the box XP isn't going to cut it here.

Context matters as we determine solutions. In fact, one of the great failings of software development is that we often design our solutions more on the function to be performed rather than the characteristics (qualities/non-functionals/attributes -- select the name you like) the design supports. A solution that would be functionally fine if the context were that maintainability didn't matter may be worthless in a context that has long term support concerns. It is my observation that this kind of context is rarely described in a project.

Speaking of the project, context matters there, too. Which side of the "iron triangle" -- schedule, resources, or functionality -- is the side that is fixed and which side will adjust? (Clue here for managers: you can only fix one and your project will have a higher chance of success if you don't change your mind five or six times during the project.) I will select all manner of practices for one context and different practices in another.

In fact, context matters with any "best practice". The word "best" doesn't make it immune to the reality of the context. While it may be best somewhere, it could be a "worst practice" for your project. How do you know the difference? You can't until you fully comprehend the context and that usually means trying the practice out. (A *** Vitale moment: "Plan-Do-Check-Act time, baby")

I hope you take all these ideas in the right context.

It used to be a common feedback I would get when I taught Construx's Software Estimation seminar. I would show the bright developers how to estimate their software projects several different ways and they respond with the whine, "This is all fine and good but our management won't let us."

I would question them as to why they they thought management, who had hired me to come show them how to improve their ability to estimate, would then turn around around and tell them that they can't use these techniques. This did not make sense to me at all. I know management can be a little strange at times but even they can't be that clueless.

The bright developers would explain to me that if they used the good and wise techniques presented in the seminar that they would come up with estimates that far exceeded the desires of the managers who had asked them for an estimate. In a sense, when presented with an estimate that didn't match the already made commitments made further up the chain, management has said, “Estimate THIS!” and held up a single finger, not the index.

In reality, management didn't want an estimate at all. They wanted a plan, or more like a miracle, that would allow them to keep the boastful promises made in the heat of a compensation impacting meeting. Management's ability to get promoted, secure a bonus, shine in front of their peers, or to get a raise depended on the developers' ability to spin gold out of straw. The problems is that the developers don't have a midget running around with a hard to pronounce name who can do that. Instead, all they can do is mix the straw with mud and hope to make enough bricks to be useful.

I said I "used to" get this feedback, I don't as much anymore. That is because I realized a few things I need to do when teaching estimation. The first is to make the bright developers understand that management has nothing to do with the estimate. The purpose of the estimate is to give knowledge to the development team, not to the managers. With this knowledge, the development team can make appropriate decisions, including looking for another job. The second is that it is rational for managers to want miracles. Heck, I would like to win the lottery. My odds are pretty darn low I know, especially since I don't buy lottery tickets, but I would still like to win. Wanting a nice thing is a reasonable act. However, wanting something -- even in a rational manner -- does not make it so. The third is that when the rational targets of the managers exceed the estimate calculated by the developers, there is going to be pain. Maybe not outright torture, but discomfort to be sure. The only choice we have is when will we experience the pain; early pain from staying with what is possible or late pain from not delivering on the commitments.

So I present the seminar not so much on how to calculate a date (given a feature set) or a set of features (given a date) but how to come up with enough facts and data that allow the bright developers to have a professional discussion even after an manager says, "Estimate THIS." I think this is the key challenge for estimators because our "standard" estimation technique of taking our best guess based on our personal memory of having done something sort of like this in the past has as much validity as an Elvis sighting. If we have facts and data that has at least the appearance of empirical consistency we will be in the position to respond with something like, "I understand you want that straw spun into gold. I would like that too. I must point out that this is not possible given our current development capabilities. I am happy to walk through the data with you, if you desire. Given this reality, I would like to suggest one of these three brick alternatives we could make within the constraints you have presented." It is probably best to leave out the "Your mama" we want to lead with.

In a nutshell, we estimators have to take our professionalism up a notch when faced with a rational but unachievable target. We need an analytical estimate based on historical data to back us up. Only then will we be able choose the early pain and, with practice, allow it to be only a minor irritant.

I was teaching an Agile seminar recently when the image of a PEZ candy dispenser popped into my head. Why, PEZ candy, I thought, is just like an Agile project. You work things in priority order by taking what is off the top of the stack of similar sized bits of work. We know that they are similar size since we broke down the bigger ones until they at least fit into the iteration length. Like PEZ, the product owner could rearrange the candy flavors however they liked until I put one into my mouth. Then it is either spit it out or eat it, no changing the flavor.

This metaphor may be the perfect thing for solving the Agile name problem. A few of the "founders" of Agile have suggest that the name "Agile" was not the best choice. I mean, who really is saying their development methodology is "rigid"? Also, there isn't a good name for the opposite of Agile. Boehm uses a term like "Plan-driven". Others have used the term "traditional". I have used the idea of "deterministic". But if I rename Agile to "PEZ Development", that opens all up all sorts of useful comparisons.

Waterfall can become "Jawbreaker Development". One big, hard lump that, no matter how long you suck on it, never seems to go away. Of course, we all know somebody who said that they actually finished a jawbreaker in their lifetime. Sure they did. I think they just licked at it for awhile before it got lost behind the clothes washer. As kids, most of us took out a hammer and broke our breaker. It was much easier to consume as a chunk here and a splinter there. Once we got tired of it, the rest could be thrown away.

Spiral can become "Tootsie Roll Pop Development". You start out with the hard stuff. By slowly spinning it around and around in your mouth, you take care of all the hard things that can break your teeth. Once that is gone, the soft, easily consumed center is quickly dispatched.

All the well run sequential models (staged delivery, design to schedule, etc.) are "Chocolate Bunny Development". Of course, here I am referring to the large, solid chocolate bunnies given in the spring at Easter. You can substitute your favorite holiday large chocolate item if you wish. Usually consumed in series of scheduled times (like after dinner or, for me, when awake), you keep eating it until it is gone or you run out of time (your Dad takes it and eats the rest). Also a common feature of this type of candy is a decision to eat in a certain order. First go the ears, then the feet...

The old code-and-fix model can be "M&M Development". Sure, its fun to eat but you just don't stop. Not even when the bag is gone, you just go get another one. There is no way to eat a few. You also never really know when you have had enough.

Evolutionary prototyping is "Salt Water Taffy Development". Pick one up out of the pile of brightly colored taffy and taste it. Most of the time you spit it right back out because it tasks like, well, salt water. But, you try again until you find one that is edible. Then you stop since you know it is not wise to press your luck.

I think that this general renaming of software development can really help us identify the best of each set of practices. It can help us get out of the "my way is good" and "your way is bad" syndrome. By using this naming standard we can see that there is something sweet about each way of approaching software development. It can also remind us that too much software development before dinner can ruin our appetite.

And you can be the Candy Man!