vrijdag 2 december 2011

off the shelf software and FPA

The Dutch Nesma counting guidelines 2.2 have an interesting section on off-the-shelf applications.
They identify three areas of functionality:
A - functionality wished for by the customer, but not offered by the application
B - Functionality wished for by the customer, and offered by the application
C - Functionality not wished for by the customer, and offered by the application
Visually:


A is functionality that the customer wants, but does not get. This means additional costs. C represents functionality the customer pays for, but does not need. B is the area for which the customer can make a price comparison.

This model, like all models is i.m.h.o. a simplification. Using MoSCoW prioritization, one might group all "Must" and "Should" into the area "wished for", but one might also decide to add the "Could" or even "Would" groups to it. This might give considerable differences. For example, functionality not listed as required by the customer, might turn out to be a secondary wish not listed. Indeed, an inspection of the functionality of some off-the-shelf applications might yield considerable new insights. The nesma counting guidelines correctly mention the problem of counting the information model when counting off-the-shelf applications. One aspect they do not mention is the current trend of feature lists. Feature lists, for those not yet acquainted with them, are lists with short summaries of functionality. They may be formulated as the features found on the box of the product. For example, a word processor feature list might be: * the user can easily enter and correct text * the user can do elementary formatting such as bold, italics and underlined. * the user can use several fonts and character sizes * the user can print the text * the editing is wysiwyg * the user can create mailings by creating a document and connecting it to a variety of sources and so on. Feature descriptions sometimes are too short to make an FPA count. The person performing the FPA count will have to do some inquiries about the nature of the features.

vrijdag 18 november 2011

Passwords - some practical remarks

There is a well known problem with passwords: they should be easy to remember, yet be long and complicated enough not to be detected by automatic password crackers.

The story is in the news today again for the umptieth time, with mashable reporting a list of the 25 most common passwords

Here are some of them:
password
123456
12345678
qwerty
abc123
monkey
1234567
trustno1
baseball
111111
iloveyou
Of course the guidelines for good passwords are well known:
  1. Use a combination of upper and lowercase, digits and other signs such as "_", !, & and so on.
  2. Don't use your name, names of relatives, or hobbies, birth date, and so on. Instead, do use combinations of words.
  3. Let your password have a sufficient length. Experts differ in opinion, and applications differ in possibilities. For instance, on windows 7 administrators can set the minimum password length anywhere from 1 - 14. Google apps recently increased the minimum length from 6 to 8.
  4. Use different passwords on different sites.
  5. Change your passwords frequently.
  6. Don't write your passwords down.

How, with these guidelines in mind, how can you choose passwords which on one side comply with these rules and on the other hand, are still useable in real life?

Here are some suggestions:
  1. Use something from your most recent holiday: hotel, restaurant, camping, guide, recipe, and so on, and mix this with numbers and other characters. For example, if "haggish" was a recipe you liked when on holiday in Scotland, you might choose "Scotland-Hag*2011*gish" as a password. This will encourage you to change password your password again after a next holiday. Not frequent enough, but it is a step.
    A friend of mine went to Argentina, and used the names of all the small villages there as the base for his passwords.
  2. Do you have a favorite song, poem or book? Use a combination of words, intermingled with numbers and other characters. For example, if you love the Rolling Stones, you might pick one of their songs: "You can't always get what you want", and choose a line, such as: I saw her today at a reception, and intermingle it with digits and other characters:
    "I08saw*her_today at a reception".
    If you change your password, don't just change the number, also periodically change to the next line of the song.
  3. Including year and month in your password has advantages and disadvantages. One advantages is that it is easy to remember, and another that it reminds you to change your password again. An obvious disadvantage is that these parts are easy to guess, and certainly this should not be the only change in a password.
Now there is something to say about the rule: Don't write your passwords down.. First, to have a different password for every site, virtually forces one to write your password down, or frequently to ask the site to reset your password.
Personally, I don't think the rule can be taken as an absolute. Certainly it is not good if an office employee has a yellow note at the screen with his or her password. A better wording would imho be: write your password down at a secure spot.
If you are at home, store your passwords of internet sites on pencil and paper in a secure spot - where it can be found easily, but not at first sight.
As for the office, unfortunately there are still many employers who don't have single login enabled for there applications. Ask your employer for it - the problem belongs to your employer. Meanwhile, you probably have one main account. You will have to memorize the password for that account, and maybe you have a private area where you can write note your other passwords securely in that spot. Or maybe you can synchronize your passwords, changing them all at the same time?
One secure spot to write your passwords down is a password store. They allow you to write down your passwords for numerous internet sites and applications, together with the name of the site or the application. They need a password to open, so that is the only password you need to remember. And oh, you will want to backup this utility frequently. One which is free and open source is Keepass.

vrijdag 28 oktober 2011

FPA - Some changes are no changes

Or in other words: Some changes are free

The definition of a maintenance project according to NESMA is: A project in which functional changes with regard to an existing information system are realized. In the information system functions can be added, changed or removed.
The first conclusion is that technical changes can not be counted with this guideline. Organizations which offer maintenance based on fixed price/function points may have a problem here, unless they make additional agreements with their customer, which is done often. A good question is if bugfixing counts as a change. My opinion tends to be: This depends. If the bug is of a technical nature, the functionality is not changed. An example might be a programming error where the system occasionally crashes. If however, the system requires that data element z should be equal to a + b, and the bug is that z = a + b + c + d, then the functionality changes, and this should be counted as a functional change.

It is important here to distinguish between the question: ‘Should we count this?’ and the question: ‘Should we charge this to the customer?’. The first question can be answered from the counting guidelines, the second by the contract. It may well be that the change may be counted, but not billed. The reverse situation, that the item may be billed but not counted, is something I see less often.

A second conclusion is that we must differentiate between the documentation of specification of the information system and the information system itself. The specifications and the information system will generally not correspond 100%. What concerns us here is that we count functional changes to the information system, regardless of the documentation. This is why some bugs, if they are functional in nature, may and should be counted even if the documentation does not change.

FPA had several formulas for maintenance projects, that is, for changes to existing systems. One formula is for the size of the system:

PRODNew= PRODOld + FUNAdded – FUNRemoved + (CHANGEDNew - CHANGEDOld)

This formula is given on page 15 of the NESMA counting guidelines reference manual.

The other formula, which is given on page 18 of the NESMA counting guidelines, is the size of the project.
This formula is:

PROJECT = FUNAdded + FUNRemoved + CHANGEDNew


An example of both is given in between these two formulas, which is strange, as it introduces the project formula in an informal form before it is explicitly defined. Several conclusions can be drawn from this last formula. The first one is:
  1. 1) Any functional change to a function should be counted as if the function has to be build anew.
  2. This is of course not very accurate. There generally is not very much discussion about = FUNadded + FUNremoved. But CHANGEDNew is another matter. Changes may be big or small, and I know of at least one softwarehouse that varies the number of function points depending on the number of data-elements involved in the change. This will generally please the customer: they will pay less than in the case of a full count as prescribed by the NESMA guidelines. There is a considerable drawback imho: Counting a reduced number of function points for some small changes makes it doubtful if they can still be considered function points.

    It is understandable that some customers get upset if a customer has to pay for say a nearly identical extra data element to be added to 100 screens as if these screens should all be build from scratch.

A second conclusion is:
  1. 2) Non functional changes should not be counted.
  2. Cosmetic changes may be chosen as an example. A complete whole-over of the layout of a website might well result in 0 function points, while it requires a considerable effort to realize. Again: if these changes can be billed also depend on the contract. Contract definitions are very important in this respect. If the contract specifies that all functional change requests will be billed a E xx per function point, cosmetic changes might still be charged as they are not covered by the contract. If the contract stipulates that all changes will be charged at xx per function point, the supplier might have a problem.

In the long term, the effect of 1) and of 2) might cancel out each other, but short term fluctuations might be large. One way to solve this dilemma would be to agree that exceptional circumstances might be offered on a non FPA based estimate, but that is an option that would not please most FPA afficionados. Neither would it please the lawyers and management negatiotors, as it would be hard to define what is exceptional.

donderdag 20 oktober 2011

FPA updates

Some quick FPA Updates:
  1. In the Netherlands, FPA certification has been transferred from Exin to Cito. A quick look showed that the sample examination is still the same, with just a name change.
  2. There is an interesting discussion on linkedin about the pros and cons of Cosmic and FPA.
  3. The Nesma newsletter of october 2011 mentions that the yearly fall conference will be on November 11 in Scherpenzeel.
  4. At this conference Carolyn Mair, Senior Lecturer in Psychology at the Southampton Solent University (UK), will give a presentation on why experts estimates on the same subject might vary wildly.

vrijdag 9 september 2011

Simplified TRIZ

Today I was able to read some chapters from "Simplified TRIZ", by Rantanen, Kalevi, and Ellen Domb. ". St. Lucie Press. © 2002. . (accessed September 9, 2011) . It's only the first two chapters yet, but they did introduce me to some basic concepts:
  1. Contradictions. Every problem to be solved is aimed at solving one or more Contradictions. There are Tradeoff Contradictions and Inherent Contradictions. A contradiction often consists of a tool and an object.
  2. The Ideality of the system. A measure of how close it is to the perfect system.
  3. Unseen idle resources.
Let's try these on an example.
For example, how can we serve customers in a restaurant faster without increasing prices? The tradeoff contradiction is that we can increase the number of waiters, so that more customers can be served at the same time, but that costs money and the restaurant would have to raise prices. So something good (faster service) also means something bad (higher prices).
We could compromise: hire waiters only at peak times, or fire all waiters and hire them back at a more flexible rates and times. But TRIZ does not seek compromises.
In the ideal solutions all customers are served quickly and costs remain the same.
There is an unseen or hidden resource: the customer. If the customer serves as his own waiter, the cost is reduced and the customer can be served much more quickly. Now the concept of a self service restaurant is well known, but it took from 1948 to 1954 to get established.

Definition: A good solution is one that resolves a contradiction.. Another concept is that of Patterns of Evolution. Systems evolve according to certain patterns, and these patterns can be used in many ways to get new ideas and predict the evolution of the system. Finally, there are 40 innovative principles that give concrete clues for solutions. Let's have them in a diagram:

Figure 1.

zaterdag 3 september 2011

Innovation

TRIZ, theory of Inventive Problem Solving, based on the work of the russian inventor and researcher Genrich Altshuller, is slowly gaining the popularity it deserves.

I discovered a nice series of you tube movies, see http://www.youtube.com/watch?v=zcKy0psDlf4.

In addition my own employer Capgemini will be using the principles and has appointed qa special innovation officer.

vrijdag 15 juli 2011

XBRL (2)

Today offered a new opportunity to dive into XBRL. This time I concentrated on Taxonomies. What are taxonomies?

1. What is a taxonomy?
Basically, a taxonomy defines [u]what[/u/ should be in a report. The taxonomy is not the report itself, and it does not define the layout. It does define the elements that should be reported.

2. What about the layout of a report?
For the layout you can define a stylesheet.

3. What are the properties of elements in a taxonomy?
- data type:
- period
- balance
- nillable
That does not include any relations between elements, for that we have links.

4. What are the properties of links?
- references
- labels
- presentation
- versioning
- definition
The term presentation is slightly misleading, as it suggests it defines the way an element is shown. Actually it defines the place and sequence in which elements should be shown.

4. What is a linkbase?
A linkbase is simply a collection of links.

An element without links is called an unbound element.

Short descriptions:

  • A reference link describes the relation between an element and the reporting standard such as IFRS
  • A label link describes a link to a humanly readable description. For example, machines may not have trouble in using ifrs-ci_CashCashEquivalents, humans usually prefer something like Current Assets Label links may depend on the role of a link. One of the usages of role is to provide description in different languages. Another is to make a difference in description depending on value, for example loss for negative values and profit for positive values.
  • A presentation link can not be used for layout, but can be used for defining relations between elements. Examples are Parent-child, or Order-Orderline. Another usage is to define the requirements that the presence of element A requires the presence of element B.
  • The versioning link is used to define the changes in a taxonomy over time.
  • The Calculation link describe show values of elements should be added or subtracted. It creates a relation between a summation element and a contributing element. It can be used as the base for the Formula linkbase.
    An example of a calculation link:
    <link:calculationLink xlink:type="simple" xlink:role="http://www.example.com/">
    <link:documentation>string
    </link:calculationLink>


5. What is a dimensional taxonomy?
A dimensional taxonomy allows the user to group data according to different dimensions. Examples are reporting by product (group), by geographic region, and by period.
Defining such taxonomies is not easy and may lead to high implementation costs.

vrijdag 8 juli 2011

XBRL (1)

Just this week I heard that I might be assigned to an XBRL projecty, so time to have a look at it.
A fellow worker, Paul Diddnes, was kind enough to lend me "XBRL 4 dummies", by Charles Hoffman. This post contains the gist of what looks most important to me. In addition, I read some other stuff, mentioned at the end of this post.

1. What is XBRL?
Basically, XBRL (eXtensible Business Reporting Language) is a data interchange format, based on XML, and used in financial / business information. It is used widely by US SEC, and is also used by governments in the Netherlands (mainly Belastingdienst), Australia, Japan, India, China, and so on.
You may also think of XBRL as a reporting language, and the language defines meaning to its elements through something called taxonomies.

2. What are the advantages?
Current IT systems do exchange information, over a variety of protocols, in many different formats. XML is on the rise, but there are still many systems around that use apis and system specific formats.

3.Is it a fad? After all, it has been around for a while, and i don't hear any real success stories.
The book does not go into this, but I don't think this will go away soon. Many IT systems still use their own couplings: use tables directly, or views on its tables, export .csv files, exchange xls files, or any commons file format, or exchange custom handshake formats, apis, and are barely making the step to webservices and xml. This is the current step, and using XBRL is an extra step. Companies are not yet up to this step. Also, the early adoption by regulatory institutions, does not add to its popularity. It is perceived as an obligation, not as an opportunity.

4. What is a taxonomy?
A taxonomy can be regarded as a dictionary, and defines the meaning of the concepts. Examples of concepts are Net income, Sales, and so on.

5, Can you give an example?
Sure.
<gaap:NetIncomeOrLoss
contextRef="Period-2011"
unitRef="Euros"
decimals="Infinite">12345
</gaap:NetIncomeOrLoss>

<gaap:NetIncomeOrLoss : Gives a concept from the taxonomy gaap
contextRef: gives some context of the value 12345, in this case the period.
12345: the NetIncomeOrLoss
</gaap:NetIncomeOrLoss> : closing of the tag. Like in XML, every tag should be opened and closed.
unitRef: the currency of the value.

6. Are there any success stories?
Actually, yes. US Federal Deposit Insurance Company was an early adopter, and took time to collect and communicate information about its XBRL implementation.
They realized:
* TCO down from $65M to $39M, saving $26M
* Reduce time for making information available from 45 days to 2 days

7. Whats that about semantics?
We have syntax and semantics. Syntax is about form, semantics is about meaning. The example above shows form: 1 atom, one tag with data. Semantics is about meaning. That is why XBRL has context. Of course the example above still does not give you all the context you would like, without taxonomy available, you don't know it its expected or realized, and from which company or organization.
The taxonomy does allow rules: Assets MUST equal total liabilities PLUS total equity.

donderdag 23 juni 2011

Communication - or lack of it

Dilbert.com

Communication can fail in many ways. The Dilbert above is an example of how too much communication can result in the opposite of what is intended.
But often the first failure in communication is to communicate at all.

In the literature you can find abundant examples of how communication can go wrong. IT is a subject area where Communication is crucial, yet somehow especially hard.

Let's try to give some obvious cases:
The most obvious one is NO communication. This one comes in many disguises.
1. No communication by lack of preparation. An employee is fired on the spot, and leaves. Now this aint much of a problem in a warehouse, but an employee working on a datawarehouse system probably has lots of knowledge in his head which was never documented in designs, or fragmented. Now the manager firing the employee will probably realize that a newly appointed employee taking over has some problems, as the situation is pretty obvious.
These kinds of situations are sometimes unavoidable, but one precaution organizations can take is making sure that documentation is up-to-date and that userids / passwords can be recovered by a central department, or institute policies that managers always have useris/passwords of all servers and systems.

2. KT is easy, isnt?
An employee takes over the maintenance of a system as an employee leaves for another company. The manager plans a series of KT (Knowledge Transfer) sessions between the two employees. The manager may feel that after 5 sessions the new employee should be able to take over the job seemlessly. He may be in for a disappointment. The new employee, depending on training and experience, may be able to perform many of the regular tasks if his predecessor, but may run into a few problems when a major overhaul is in place. It is very likely that some essentials have been missed during KT.
Now job transfer is something unavoidable, but one should realize that a series of job transfer sessions is always incomplete.

3. Listening is hard
During design, a designer may think that he understands that requirements documented. While reading or listening, our minds make up images based on the words of the author / speaker, AND based on our own experiences.

For example
Speaker: I bought a new car.
Listener: pictures a standard person car.
Speaker: It's a very big one.
Listener: pictures a small van.
Speaker: It's a beautiful red one
Listener: pictures a red van.
Speaker: and all its wheels are well balanced
Listener: expands the image from a van to an 18-wheeler.

One thing that you can do to make your communication clear is to communicate as much as possible, to repeat information and to check with the listener what he understood.

4. People who are quarreling. One of my first employers, a management consultant, was hired because a certain administrative proces took weeks for every oprder to complete. He quickly discovered that two people, sitting in different rooms, but who were at consecutive posotions in the process, were at odds with each other.
Now a normal request in the process did not cause much trouble. A took the form, approved it, and sent it on to B. B. could do his task. But if something was not OK, he scribbled something on the form and sent it on to B. B simply returned it with something like 'not clear'. That could continue for weeks.
My employer redesigned the process in such a way that A and B were no longer consecutive in the process, and things moved a lot smoother.

Though this example sounds exaggerated, little or no communication due to quarrels or irritation appears more often than one may think. While writing this post I was asked to solve a functional design discrepancy. One designer, let's call him J, had written a functional design. He had received a new document code C12012 for a certain document from another designer, W.. He sent his document around to several people for review, and got some comments back. W, who was responsible for the system that received the documents, reviewed that the code should be C12012, not C12012 Attachment A.
Somehow this review was not received by J. Hence he did not update the functional design, and the system was configured wrongly.

Now IF J. and W. had been friends, J. would have asked: hey, why didn't I receive any review from you? But as a little bit of irritation between the two designers had built up over several years, J. didn't take the trouble to walk to W.'s room. He just went ahead with the review comments he had received from others, assuming that was all. And so an error crept into the configuration, which was somehow not discovered during integration test, went into production, was withdrawn, and a patch had to be made. The total correction effort, due to complexity of environments, was several weeks. All this could have been prevented with some extra communication: "hey, i got the reviews of others, but not yours yet? You had no comments?"

5. Assumptions are the mother of all ....
If some crucial bit of information is missing, the reader/listener will either ask (if he realizes he misses something) or assume. The latter can be very dangerous.
One trick to kill assumptions is to ask the listener to rewords what he understood, but that wont work for readers. A pitfall to avoid is using half-worded sentences, like : DVB message as existing stream of FUS.
Actually this sentence combines to things. First, it uses 2 abbreviations which are not explained. Second, the message of the sentence is not clear. Is it a requirement that all DVB messages are like existing FUS? Or is it a general property that holds for most DVB message? Or are the messages totally different, but are their flows similar? The sentence has several short comings. The most obvious one is that a verb is missing, and you should always beware of 'sentences' without a verb.

6. Lack of context.
I recently read a design that started with:
The ATM will be changed to direct the MQ in such a way that XHT will no longer obstruct THX.
Gr8, guys and gals. With some guessing i can deduce that ATM does not stand for Automated Teller Machine. But it would have been a lot easier to understand with something like:
This design concerns the way messages from the systems XHT, THX and ATM are routed over the enterprise service bus (ESB). For the functions and details of the XHT, THX and ATM systems please consult the documents [2], [5] and [13] mentioned in Appendix B.
This sentence describes context. It does not give the aim (why are we doing this?) but it does give a setting.
Frankly, I never find the reason: "Oh, but every one knows what ATM stands for" a valid excuse. ALWAYS give a setting, there are bound to be times when the stuff is going to be read by people who don't know the setting.

maandag 4 april 2011

Prioritiy

"Everything has priority number 1"
"These features are all 'must haves', I have limited myself to the bare minimum"

Who does not recognize these reactions from his or her users?

Why do we put priorities? The general reason is inside the old rule about supply and demand: There is always more demand for features than time to realize them. This applies in all stages of an IT-system, and broader, in all stages of projects and products. In IT, it not only applies to features, but also to other requirements, to change requests, and to the solution of bugs.

The IREB foundation mentions several ways to determine the priority of requirements, and, surprisingly, not the most well know method of prioritization of all, the MoSCoW scale.

The first method is assigning a high/medium/low scale. Many development tools use such as system.

A second way, not mentioned by IREB, is the MoSCoW method. Basically, MoSCoW is an acronym of the the four levels of priority:
* Must - A Must have, without this feature the system/product has no valid reason tot exist.
* Should - should have this if at all possible in this timebox, the difference with "Must" is a matter of time. For example, not all reports are needed at the start of the operations.
* Could - These are often viewed as 'nice to have', and often a few minor things which cost few resources are taken up.
* Would - things which we would like to have if we had sufficient time - which we usually have not.

A third way is Carl Wiegers prioritization matrix. Basically he lists all features, and assigns each of them 4 values, ranked on a scale of 1-10:
- relative benefit
- relative penalty for not having
- relative cost
- relative risk
These four numbers are processed for each feature, and the result gives an indication of a features value.

The Kano model mentioned in a previous post roughly classifies features in three groups:
* Base factors: the factors without which a product will not be bought. For example, a laptop without screen, or a car without wheels. A customer wont mention them, he will take them for granted.
* Performance factors: those factors for which more is better. For example the number of colors in which a customer can buy a car, or the number of years of guaranteed problem free service of a coffee machine.
* Excitement factors: Those attributes which make a customer say: "wow!". These factors tend to degenerate into performance factors over time. For example an autopilot in a car would be a wow factor now, but may be common place in 10 years. An IT-system which gives AI powered hints might be a wow now, but the users will get used to it in a few years - if it takes them that long to get used to it.

Another way is to use a matrix with two different dimensions on the two axis. Two dimensions which spring to mind are impact or profitability, and effort.



In the example matrix to the left features A-F have been plotted in effort vs impact. A and E ave moderate high impact and moderate high effort. Features D and F, in the upper left quadrant, have low effort but high impact. It will be clear that these features should be considered as high priority.

Another good combination of dimensions to pair of, are impact and urgency. This one already has a name, it is called the Eisenhower matrix. For example, an incident with great impact may still have low urgency. It is essential to have clear, unambiguous definitions of both. For incidents in the operation of an IT-system, impact may be defined in terms of the number of users being affected. Urgency is easier to explain in medical terms: bleeding, suffocating and starvation may all cause death, but suffocation is the most urgent, followed by bleeding, with starvation coming last.
Let's have a look at some examples for IT systems and features. Let's define impact as related to the number of users affected, and let's define urgency as:
- essential to primary process, no workaround
- essential to primary process, workaround available
- not essential to primary process
Feature A specifies that every user will be able to print reports with the first sheet on special company paper. Obviously it scores high on impact, but urgency will be low - the first sheet on special paper is not something that is essential to a companies primary process.
Feature B specifies that the customers can purchase items through the website, and that this is the only sales channel. It will be clear that this scores high on both impact and urgency.


Sources:
* http://en.wikipedia.org/wiki/MoSCoW_Method - MoSCoW method
* http://www.processimpact.com/articles/prioritizing.html - Carl Wiegers priority matrix.
* http://it-maintenance.blogspot.com/2010/11/kano-model-explained.html - Kano model
* http://ireb.de/ - ireb.
* http://beanoriginal.net/deadlines-and-the-urgency-side-of-the-eisenhower-matrix/ - eisenhower matrix

vrijdag 1 april 2011

7 requirements myths

James Robertsen gave a presentation on March 31, 2011 for the Dutch chapter of IIBA, the International Institute of Business Analysis. James is always good for a nice presentation, and this presentation was no exception. His subject was: “Requirements myths”.

Myth 1: Requirements are about requirements.
Truth: Requirements are about a business problem. Don’t look where the light shines (which is usually a software problem), look beyond the software for the business problem behind the software.

Myth 2: Listen to your customers.
Truth: Your customers don’t come up with innovations. Ford: “If I had asked what people wanted, they would probably have said: ’faster horses’”. The same applies to Steve Jobs: he never held a customer survey in which people came told him they wanted an iphone.

Myth 3: Testers test software.
Truth: Testers should do end to end testing. They should also test the project plan, the vision document, the requirements, and so on.

Myth 4: Always write a complete set of requirements.
Truth: The 80/20 rule also applies to requirements.

Myth 5: Allow time for debugging.
Truth: Debugging is at the end. Instead, spend more time to get your requirements right.

Myth 6: Start with use Cases.
Truth: Start with understanding the problem.

Myth 7: With agile you don’t need requirements
Truth: You need requirements engineers for your vision document, your initial requirements set, your conversations, and your testing.

On a personal note, I am not enthusiastic about all of them. Some of them can hardly be characterized as a myth. For example, take number 5, allow time for debugging. No doubt I have been on the wrong projects for the last 20 years, but I have never seen projects where software was perfect and faultless when delivered by the programmers.

Something similar applies to myth number 3: Testers test software. Imho testers do test software. It is good to have a fellow worker review your products, and this has become standard practice in most big organizations. Lost of defects can thus be prevented. But he does have point when he says that testers can also have a look at the early documents. Personally I prefer to send early documents also to testers - if they are already known.

Other things are what we in the Netherlands call "Open doors", things which are obvious. Myth number 7 is such an example.

But I think he does have a point with some of the others, such as the complete set of requirements (myth 4) and stressing the business problem (myths 1 and 6).