Agile... Again

Some people have pointed out that the reason I don't like agile methods is because I am trying to sell services which depend on "traditional" requirements. The reason I like "traditional" requirements is because I don't like screwed up projects. Everyone is trying to sell something and the Agile gurus are no different. The problem is that Agile methods and "traditional" requirements gathering are not necessarily clearly defined and both sides use a lot of straw men to prove their points. In addition, I feel that agile methods with their focus on waiting until the last minute to make decisions will doom many projects to failure. We have run into a number of companies with large IT organizations that tried Extreme Programming only to abandon it after a multitude of spectacular project failures.

Agilemodeling.com (http://www.agilemodeling.com/essays/agileRequirements.htm) has a pretty well written set of techniques for requirements gathering that I really like, however the author starts out by stating

Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains. The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the requirements change anyway, and the developers eventually end up going directly to their stakeholders for information anyway (or they simply guess what their stakeholders meant). Agilists know that if they have the ability to elicit detailed requirements up front then they can also do the same when they actually need the information. They also know that any investment in detailed documentation early in the project will be wasted when the requirements inevitably change. Agilists choose to not waste time early in the project writing detailed requirements documents because they know that this is a very poor way to work.

I disagree pretty strongly with the comments.

Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains.

I simply don't think it is misguided to ask developers to understand what needs to be built and to build it to a specification. The developers we work with are professionals. They take part in the requirements definition and absolutely develop what is agreed upon.

The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it,

A requirements document can never completely specify a system. However for the highest risk areas, getting all parties to agree on the way the system should work is crucial. The easiest way to ensure that all items are reviewed is by using a list in the form of requirements. If you have a small project maybe you don't need this, but for the projects we work on with many stakeholders it is absolutely critical.

the requirements change anyway,

We have found that true requirements don't change often at all, in the same way that true business needs don't change that often. If you find that your requirements are changing a lot, then you probably did not define the right requirements originally or maybe you incorporated too much design.

and the developers eventually end up going directly to their stakeholders for information anyway (or they simply guess what their stakeholders meant).

When the stakeholder/user population is large, I think we would all agree that this method does not work. It can take a significant amount of time to distill what actually needs to be done on large projects. Most developers lack the facilitation skills to drive these conversations.

Agilists know that if they have the ability to elicit detailed requirements up front then they can also do the same when they actually need the information.

This comment simply doesn't make sense. The key question is when do you actually need the information? Well if you have multiple business stakeholders who have to come to agreement on how something should work, you would want the information as early as possible because you simply don't know how long it may take to get agreement. Simply put, why wouldn't you plan up front?

This wait until the last minute philosophy of Agile fits right into the personality of many developers. It is the same philosophy that drives most people to procrastinate. Planning is hard work, but there is no doubt in my mind that using detailed planning is the right method to run a software project.

The Cult of Simplicity - Part I

A February article in the Harvard Business Review entitled Defeating Feature Fatigue (excerpted here) really struck a nerve with me. The dilemma that the authors call out in their paper is captured perfectly here:

Adding features improves the initial attractiveness of a product but ultimately decreases customers' satisfaction with it. So what should you do? If you give people what they want, they will suffer for it later...

What goes unsaid is that if you don't give people what they want you will suffer for it now in the form of dwindling or non-existent sales. There are wonderful examples of the feature-explosion vs. simplicity battle all around us. One of my favorites is the video that shows what the iPod packaging would look like if it had been designed by Microsoft instead of Apple. Sure it's a parody, but what makes it so brilliant is that it is devastatingly on target. The different approaches that these two companies take in the real-world was discussed during this panel at Austin's SxSW conference. Designers from each company provided some background on the design process for Apple's OSX and Windows Vista (Longhorn).

Apple Designer - We focus on key things that people want to do. What’s used most frequently or is most important? Do not let edge cases get in way of major tasks. This makes it harder to do some less important things. We had a good sense of our audience and what they are trying to do so we were able to prioritize.

Microsoft Designer - Windows is definitely “wordier”. It spells things out a bit more. The Mac is beautiful if you want to do one or two things. Windows pulls all the drawers out at once and asks: "what do you want"?

What's the best approach? The HBR authors offer 5 pieces of advice:

1. Consider long-term customer equity
2. Build simpler products
3. Give consumers decision aids
4. Design products that do one thing very well
5. Use prototypes and product-in-use research

I find myself particularly partial to 1 & 2 from this list and recently came to realize that I am actually witnessing firsthand a fantastic case study of a company that is violating both - Adobe with its Acrobat Reader program. My frustrations with Acrobat Reader's ever increasing bloatware have been growing for a while now and I finally realized just how bad the program had become when I read this post, titled Learn From Adobe - Don't Annoy Your Customers.

Remember little ol' Acrobat Reader? It used to be that you could just download and install a compact file that included the entire product. What an amazing concept...a universal file reader that would allow companies and individuals to publish read-only documents with complex formatting and layout completely intact. Just a few short years later the small file you initially download from Adobe.com now is just an installer that will manage the actual download and installation of the 27 MB worth of product for you. The Help menu for Acrobat Reader v7.0.8 actually has 12(!!!) entries in it. A far, far cry from the simple product it once was. As for Adobe's consideration of long-term customer equity, I think that this post from Des Traynor captures the feeling quite well:

Some young children constantly demand attention, and will do incredibly annoying things until you stop and listen to them. Then they complain constantly until they get what they want. I imagine being a parent is a frustrating experience at times, but ultimately the most rewarding thing you can do.

Dealing with Adobe Acrobat is exactly like that, except it never grows up, makes you proud or leaves home. The only reward is that hopefully someday, I might not need it.

Don't get me wrong, I am not a luddite and I am just as susceptible as the next person to wanting the latest bright and shiny widget v3.6.9.10. As a Product Manager I am also fully aware that there is always "just one more little feature" around the corner that key client XYZ "really needs." At the same time, however, I find myself wanting to drink big gulps of the kool-aid being proffered by the Cult of Simplicity. Can't I have my cake and eat it too? I believe the answer is yes and we don't have to go any further than our friends at Adobe to see how it could be done. We will discuss one possible approach next time in Part II of this post.

Requirements for Complex Systems

I feel very strongly that the more complex your business process is, the more well-defined your requirements must be. The analysis of these requirements also becomes more and more important and less and less possible by the SMEs and end-users.

The reason for this has to do with the definition of 'complex' used in the context above. In this case, 'complex' refers to the number of connections between different parts of the system.

The more connections there are, the more impact a change or addition will have to the overall system.

This is an important difference from the traditional idea of complexity. It is not the sheer number of actors, use cases, and requirements that determine how difficult a system is to analyze. It is the number of connections and dependencies between these objects that leads to difficulty in analysis and documentation.

A system with a large number of use cases is 'large' as opposed to 'complex'. The documentation for such a system may be much more extensive, but if the use cases are relatively isolated, the process will be easy to understand. The green figure represents a 'large' system while the blue figure represents one that I would consider 'complex'.

How, then, should you document and analyze requirements for complex systems? The key is in segmentation and use of internal references.

Segmentation of requirements ensures that you don't have too many connection points within a set of requirements. You try to have as many connections on the 'ends' as possible. In use case terminology, you should have more connections in your preconditions and postconditions than you do in the body of the use case.

Why? When reviewing and analyzing properly segmented requirements for a complex system, you can separate the analysis into two buckets - the individual subroutine-like components and the connections between them. Without this division of information, you will be forced to analyze a very complex flow and may never truly understand what is going on. Breaking the problem down into consumable 'chunks' gives you much greater confidence that you understand what is going on. You can verify each section independently and then circle back and verify the connections between them.

Internal references in the requirements are self explanatory. You should err on the side of too many internal references. I commonly insert a reference in a requirement that points to the requirement directly above it.

This strong referencing ensures that as one requirement changes, you can find all of the affected requirements quickly and accurately.

A requirements management tool can help with these references tremendously.

The next time the process flow for your system looks like a bowl of spaghetti, think about breaking down the problem and defining the relationships between the requirements at a more granular level.

Requirements Gathering without Software Development

There's been a lot written about software requirements gathering as a component of the software development life cycle. Proper requirements are critical to being able to build the right piece of software for the right cost on the right schedule.

But what about software that you are going to buy? Does gathering requirements still make sense?

Requirements gathering still has a significant role to play when a company is considering purchasing software. However, it's interesting to look at some of the differences between requirements being gathered in support of a software purchase vs requirements being gathered in support of building software.

Let's look at some of the key differences in the context of a non-software company that is looking to deploy a large, complicated piece of software to run a factory.

1. The software "life cycle" is different.

Traditional software life cycle might look like:

Requirements -> Development -> Testing

…with possible iterations depending on what model you are using.

When you are buying a piece of software, the life cycle looks more like:

Requirements -> Evaluation -> Purchasing Decision

In this case, the evaluation is similar to, but not identical to the testing phase of a more traditional software development effort. In a traditional software development effort, testing is done to ensure 100% compliance with requirements. In the evaluation phase, tests are used to evaluate the degree to which a piece of software meets your needs.

Note that some software purchasing will require software development in order to cross gaps left by purchased software. I don’t want to discuss this case here, since that only adds a traditional software development cycle to the end of the purchasing decision.

2. You probably won't get exactly what you want.

Unlike software that you are developing or having developed, a commercial piece of software probably won't meet all of your needs, because it wasn't developed using your requirements. This means that you'll be faced with trade-offs in making a decision between different software suppliers.

3. Prioritization becomes much more important.

In order to make a sensible analysis of the trade-offs between suppliers, you need to have a much clearer understanding of how your requirements are prioritized. You'll need to clearly delineate not only which requirements absolutely must be met, but also the relative weightings of requirements that aren't as important to you. The traditional “high”, “medium” and “low” prioritizations may no longer be sufficient.

4. Cost may not relate to complexity

In traditional cost analysis of requirements, you analyze the requirements, run the requirements by your developers to make an estimate of the cost based on complexity, and determine the feasibility of the requirement based on its cost. If you are analyzing requirements for a piece of software being purchased, the cost comes from the supplier, not from the complexity of the requirement.

5. It is possible to over specify the requirements

At some point in any requirements gathering process, you reach a point of diminishing returns (fewer real requirements gathered per time spent). In gathering requirements for a piece of software you are purchasing, it's likely that you'll hit this point earlier than you would if you were gathering requirements for building software. Since the supplier software wasn’t built to your requirements, getting more detailed requirements won’t necessarily improve your ability to get the piece of software you want. Detailed requirements may still be important for performing gap analysis with a potential software purchase, but the value of that gap analysis should be weighed into the decision on when to stop gathering requirements.

Top Ten Signs You Should Not Pursue a Career Writing Requirements

#10- You cannot quickly understand new concepts.

Fear not, this doesn’t mean you are stupid. It just means you think through problems in a way that does not lend itself to good requirements gathering. In the role of a requirements expert, you have to be able to think on your feet, grasping new ideas from the business and immediately be able to converse about them in depth with the team.

#9 - You don’t have patience to deal with customers.

All requirements come from a “customer” of sorts. So even if you are not a consultant or dealing with outside end user customers, you are always dealing with some sort of customer that you must be willing to hear. This means when they do not know what they want, and they change their mind ten times, you need to be able to focus them and come to agreement – not get frustrated and run away.

#8 - You have low attention to detail

If the previous line didn’t jump out at you as an error, then you probably wouldn’t enjoy working with the detailed nuts that did notice it, because they will forever point out such errors in your writing. Attention to detail is important, to ensure the document is easy to read and the low level requirements are not missed.

#7 - You’re not willing to work hard.

By working hard, I really do not mean working long hours, because frankly you cannot concentrate at this type of role for long hours and still be effective. What I do mean is that you need to be able to think intensely about problems, write requirements in great detail, identify gaps and inconsistencies, and facilitate groups of people to consensus - all while juggling lots of balls in the air without letting a single one drop. No one said the job was easy!

#6 - You hate working alone.

Writing requirements inherently means a lot of heads down writing and reviewing, which you will have to do alone. If you cannot stand the quiet time by yourself, you will go crazy trying to do this and unfortunately produce poor results by shortcutting it.

#5 - You hate working with people.

Writing requirements involves gathering requirements first, and this means you have to work with people. So, while you do have to tolerate working alone to write the requirements, you have to also enjoy working with people to discover the requirements.

#4 - You cannot form a mental model of all the pieces.

You can use models to help identify the requirements. You can use models to help cleanly articulate the requirements to others. But at the end of the day you also have to be able to keep a clear model of the requirements in your mind. Without this mental model, you will not be able to look at the requirements as a set, to identify missing and inconsistent requirements.

#3 - You are unwilling to bend the rules.

Don’t worry, I don’t mean breaking ethical boundaries here, but rather the rules around writing requirements. Not everything fits in a perfect world where we can define boundaries and never cross them. Sometimes we need to cross into design when writing requirements. Sometimes we need to let IT help suggest requirements to the business. I like to suggest guidelines for writing requirements, but then use them only as guidelines and apply good judgment to each project.

#2 - You only see grammar and spelling errors when you review requirements documents.

When you review requirements, if all you find are grammatical and spelling errors, then either you are working with a fabulous and unheard of requirements expert, or you are missing the important issues. A true requirements expert needs to be able to find inconsistencies and holes in the requirements. These issues are arguably where most missing requirements lie, leading to failed development projects.

And the number one sign you should not pursue a career writing requirements…

#1 - You don’t like to write.

This is pretty obvious, but you have to enjoy writing. Writing requirements does in fact require you sit down at a computer and churn out good requirements. In theory you could verbally dictate them and have someone write for you, but that will not sufficient within most organizations.

Oh and in the spirit of scope increase, which so frequently plagues the software industry, the final sign...

#0 - You think that all software projects should be developed using agile methods.

In this methodology, you will not get to write many requirements. I’m by no means an expert in agile, but there is clearly less upfront product definition, and therefore less requirements work. In the end, agile developers attempt to get to the requirements their own way, but it is not by writing requirements documentation before developing.