61

The Kano model of customer satisfaction defines different classes of product features. Among them are

  1. Must-be qualities: If these are not implemented the customer will not accept the product.

  2. Attractive qualities (delighters): Features that the customer often doesn't even expect in the first place but cause excitement and delight when being discovered.

Attractive qualities obviously have a lot of business value. They make people buy a Ferrari for 500.000 when a used Fiat for less than 5.000 would meet all must-be requirements.

However, all agile processes I know strongly favor must-be requirements. These always get the highest priority. There doesn't even seem to be a place for attractive qualities in agile.

I do believe that agile processes are very useful in software development. But how can they be applied to create delighting high quality software products and not just the bare minimum that barely fulfills the must-be requirements?

Addendum: As the first two answers have pointed out, it does make sense to give must-be requirements the highest priority. But do we (and the customer) really always know in advance what the must-be requirements are. I have made the experience a few times that requirements which were given a high priority in the beginning, turned out to be much less important, if not useless, later. Therefore I believe one shouldn't slavishly focus on the must-be requirements.

  • 12
    Turning them into requirements? No joke. I agree with the Kano Model. However I have seen many times companies confusing qualities and delighters with empty and useless marketing that dies.once the project is sold. Turn these things into essential requirements. Plus agile methodologies are not immvoble dogmas. Whoever use agaile is free to adapt the methodology to higher pruposes. – Laiv May 20 '17 at 16:20
  • 8
    "But do we (and the customer) really always know in advance what the must-be are" - no, and that's why agile methodologies can deliver excellent software; they allow for that. You don't "slavishly follow" anything, and you can change priorities and revise the requirements as you go along. – jonrsharpe May 20 '17 at 17:55
  • 17
    "I have made the experience a few times that requirements which were given a high priority in the beginning, turned out to be much less important, if not useless, later. " - and that is exactly the point of agile - to react to this learning process. Waterfall processes cannot change priorities by definition. – Doc Brown May 20 '17 at 19:58
  • 21
    @DanMills: The Waterfall model, as originally described, was literally a straw man. It was an illustration of how some software development projects at the time absurdly claimed (that they intended) to do all planning before all implementation before all testing. The same paper showed that iterative development (including what we now call agile) was ubiquitous, but poorly managed because it was nominally against the agreed practice, and argued that it should be explicitly embraced and exploited. – Phil Miller May 21 '17 at 17:22
  • 4
    How to develop excellent software? Hire excellent developers. Development methodology is far less important than the people doing the development. – Mark May 22 '17 at 20:43

12 Answers 12

78

The formal answer is you misunderstood agile, agile does not dictate requirements, stakeholders do. The core of agile is not to carve your requirements in stone but rather have them emerge as you go, in close contact with your client, benefiting from progressive insights.

But that's all theory. What you have witnessed is indeed a common trait of many software production lines that adopted an agile way of working.

The trouble is, listening to the customer and swiftly responding to the customer's needs often soon ends up in not doing any thinking about the product or doing any design at all. What used to be a pro-active process fed by vision and expertise can and often will deteriorate into a passive, entirely reactive process fed by the customer's wishes. This will lead to making just the bare necessities that "will do the job".

The automobile would never have been invented if manufacturers at the time would have been "agile" because all the customers were asking for was a faster horse.

This does not make agile bad though. It is a bit like communism. A great idea that hardly ever works out well because people are just people, doing people things. And the method/ideology/religion lulls them into the idea that they are doing well as long as they are going through the motions and/or following the rules.

[edit]

Slebetman:

It is ironic then that agile evolved out of the automative industry (namely Toyota).

Remember the golden rule of automation? "First organize, then automate". If you automate a broken process, the best that could happen is that you accelerate everything that goes wrong. The people at Toyota were not idiots.

The typical reason for adopting any new methodology is that things are not going well. Management acknowledges it, but they may not understand the core problems. So they hire this guru that gives a resiliant speech about Agile and Scrum. And everyone loves it. For their own reasons.

The developers may think "Hey, this might work. We would be more involved with business issues and we could provide input for filling this backlog. This could be an oppotunity to make sales and customer service understand what we do, why it is necessary, and we would have them out of our hair while we are transparently burning down what we agreed on." No more "stop what you are doing, this needs to be done now" by some dude you do not want to put off popping up at your desk.

Sales, customer service or the owner on the other hand may see it as a way to gain (back) control over this black box of a department that is presumably doing stuff that is necessary. They do not see what is happening in there but they are pretty sure the core of the problem is burried somewhere in there. So they introduce Scrum, install a product owner of their choice and all of a sudden they have all control, all the strings are in their hand. Now what?... Ehrr...

The real problem is often that the shop was not organized well in the first place and this has not changed. People have been assigned resposibilities they cannot handle, or perhaps they can but Mr. Boss is constantly interfering and ruining what they did, or (most often in my experience), crucial responsibilities have not been recognized or assigned to anyone at all.

Sometimes over time an informal organization will emerge in between the formal lines. This may then partly compensate for the lack of a formal structure. Some people just end up doing what they are good at, whether they have a business card to prove it or not. The blunt introduction of Agile/Scrum may ruin that instantly. Because people are now expected to play by the rules. They feel what they used to do is not appreciated, they get yellow little papers with little stories on it instead, the message will be: "whatever you were doing, no one cared". Needless to say this will not be particularly motivating on those individuals. They will at best start waiting for orders and not take any initiative anymore.

So things get worse and the conclusion will be that Agile sucks.

Agile does not suck, it is great for maintenance projects and can even be good for new developments if applied carefully but if the wrong people do not understand it or adopt it for the wrong reasons, it can be most destructive.

  • 4
    It is ironic then that agile evolved out of the automative industry (namely Toyota). Do what the original did: Toyota's "The Toyota Way" methodology does not define the "customer" as the person buying the car. Instead it's the product design/marketing department. It's the job of the product or marketing department to follow product design models like Kano. Agile's job is to implement and actually build the product. If you find yourself mixing methodologies then your boss doesn't really understand job roles. If you're a startup and have no choice then do them separately. – slebetman May 22 '17 at 3:09
  • 1
    A good question would be. How we (developers) can influcence on the customer to make them understand that thesedays, only functionality is not enough. I have had allways a hard time trying to influence on some of the decitions that were proven to be wrong or that lack on real sustance. – Laiv May 22 '17 at 6:29
  • 5
    +1 Best description of agile in the real world I have seen in a long time. – Paul Smith May 22 '17 at 16:22
  • 4
    I like to remind people that the word "agile" was not chosen by accident. The goal is to be able to respond in an agile manner to things that come up during development that were unexpected (such as a roadblock or a customer changing their mind). If your customer is static and your work comes with no surprises, then either agile is a poor model for you or you might pick up agile in order to be permitted to shake things up a bit. – Cort Ammon May 22 '17 at 17:28
  • 3
    @Kik I've done both in the some of the same companies and the results were dramatically different. Even when the Agile approach was run poorly, it became clear who/what was the problem and it could be addressed. Waterfall is not and was never a good idea, in fact the guy who 'invented it' did so in a paper explaining why it was such a terrible idea but people couldn't be bothered to read the whole thing, I suppose. – JimmyJames May 22 '17 at 20:54
74

There doesn't even seem to be a place for attractive qualities in agile.

You are comparing apples and oranges. In traditional waterfall, if your requirements say you need the must-haves, you get a Fiat. If the requirements say it has to be top notch, you get a Ferrari.

The same happens in Agile. If your requirements stop at must-haves, you get a Fiat. If you have stories for excellence, you get a Ferrari. All that agile really enforces is that you do the must haves first. Not build a super cool spoiler for two years and then missing the deadline for the engine.

So long story short: you get what you require. If you plan for a sports car, you get a sports car. Agile does not change that at all. If your agile process comes up with requirements for a Fiat, don't blame agile, blame the guys who require a Fiat only.

  • 5
    Very true, tools are agnostic, and amoral. If anyone knows of a process that is proven to get out more than what you put in, please let me know in the comments below. – Mindwin May 21 '17 at 1:25
  • 21
    And with agile you might be able to extend your Fiat project and get a Ferrari, or with a Ferrari project, still get a Fiat (with nonzero value) even if the project fails. – immibis May 21 '17 at 1:39
  • 7
    Yes, this is all true but also not answering the question. The point is that agile practices allow the commercial forces already in place in the opearation to creep into the software development process. This can easily lead to having a product owner who is the sales manager's side kick, or the side kick of some other powerful person in the company without much affinity to product development. This again typically results in the mediocrity described by the OP, he is not making this up. – Martin Maat May 21 '17 at 6:47
  • 13
    @MartinMaat I agree with you on the fact that a poor PO makes for a poor result, but I have seen so many poor requirements documents in waterfall, that I cannot agree that it's an agile thing. A bad job is a bad job... in any process. – nvoigt May 21 '17 at 15:28
28

However, all agile processes I know strongly favor must-be requirements. These always get the highest priority.

As they should - look at your Kano model again: if the must-be requirements are not satisfied, the customer will not accept the product. And then your delighters don't matter.

There doesn't even seem to be a place for attractive qualities in agile.

Nothing could be further from the truth.

Agile processes typically emphasize these points:

  • Frequent delivery of a working product that you can get feedback on.
  • Divide features into small parts that can be completed in a short time.
  • Implement those parts in order of priority.

Nothing prevents you from giving "delighting" features a high priority. It completely depends on the people who are in charge of determining priorities.

Now it is true that many such people prefer not to take risks and thus may not give high priorities to "delighters". But in a non-agile project that would still be the case.

  • 1
    "But in a non-agile project that would still be the case." I'm not sure I agree. Part of the point of doing the "must-be" requirements first is that it gives you room to cut things that are deemed less important, or push them to a later release if releasing the features you have by a certain time is deemed more important. Agile seems to put additional emphasis on periodically re-evaluating your stated requirements, which tends to lead to a sort of ruthless response to reality showing you that you couldn't get everything you wanted as fast as you wanted. – jpmc26 May 21 '17 at 6:55
9

Agile says nothing about what should be done first, only that code should be written incrementally, and kept in a releasable state as often as possible, instead of planned to be unusable for months until the next releasable state.

I have worked under both an Agile and a BDUF (Big Design Up Front) process, and while you can definitely get innovative, attractive features out of both processes, in BDUF, unsurprisingly, you have to plan for them up front. That means the innovations generally have to be proposed or at least sponsored by people with clout in the design process.

This is because you have six months (or whatever) until the next release, and project managers are stressed out about what is going into that release, because if their feature doesn't get in, it will be another six months until the next one. So there is a jam-packed list of features in a jam-packed schedule, and if the lowly rank-and-file gets caught working for two or three days on something cool they just think the customer will like, and it's not on the list, they risk the whole schedule and there will be hell to pay.

In an Agile process, we strive to keep the software in a releasable state, and project managers are less stressed out because if their feature slips they can just get it in two weeks. So if a developer comes back from a conference with a cool idea and spends a couple days on something, they aren't putting a six-month written-in-blood schedule in jeopardy.

Basically, you reap what you sow. If you encourage innovation and give teams enough autonomy to deliver, you will get it. If you constantly demand cutting corners in order to meet deadlines, you will get software to match, no matter your methodology.

9

Excellent software comes from two things:

  • Giving the customer what they require

  • Being a professional

There are all sorts of principles to follow when developing software. DRY, readable, SOLID, etc. that have nothing to do with customer requirements. The customer asked for a sports car. If the customer understood what it takes to make a sports car awesome they wouldn't need you. It up to you to figure out what else is important.

Part of our job is to maintain standards that the customer never experiences unless things go terribly wrong.

If you're doing it right then agile tends toward the fiat only when that's what the customer really wants. Not when that's what they figure they have to settle for.

Waterfall is different because once a misunderstanding about a high end sports car requirement has settled in it tends to stick around. Agile can cope with new information and adapt if it turns out what they really need is a bullet bike.

Waterfall is still in use in many shops to this day. These shops are successful because their requirements change less than 2% in a year.

Your job isn't to just give the customer what they want. It's also to take care of things you know you wont get any credit for at all. Things the customer will never bring up unless you let things go horribly wrong. These things had better be well chosen or you'll take a lot of crap for wasting time on them.

Any idiot can build a bridge with an unlimited budget. A professional builds a bridge that just barely never ever falls down.

Therefore I believe one shouldn't slavishly focus on the must-be requirements.

Sure you should. Except when estimating your time. Because those must-be requirements aren't the only consideration.

  • What I meant by "not slavishly follow" is that customers do know what they want in terms of business needs but they often are not able to come up with detailed requirements that make sense because they don't know enough about software development. They typically do provide some suboptimal list of requirements and it is part of the job of the software producer to discuss it with the customer and suggest improvements and alternatives to him. – Frank Puffer May 21 '17 at 16:44
  • @FrankPuffer very true, in fact it's because of that disconnect that it is so important to iterate often. You can have all the meetings you want but nothing comes close to letting the customer use your software. That's when you start to learn what they really mean. – candied_orange May 21 '17 at 17:30
4

Ok,

In Agile the programmer may create the software, but in the end it's the productowner that creates the product. (by using the software developers.)

So about "attractive qualities", that's up to the productowner.

If the productowner mandates "sexy design", that can be made a requirement. The developer shouldn't have to worry about these choices.

Also, software is so different from actual physical products that I think a lot of the Kano model does not apply. For instance, why do I facebook? Only reason: because my friends do. How to put that in the next sprint........ And also, one of the most attractive qualities in software, is that it actually does what it's supposed to do. (And that's where agile helps a lot :P)

3

My experience agrees with the above comments -- there is nothing inherent in Agile which precludes the development of excellent software -- however there are several aspects of how Agile is often (mal-)practiced which lead to software which is only "good-enough."

  • Agile puts an emphasis on getting something working ASAP; however this means making simplifying assumptions and cutting corners, particularly in the not-user-visible infrastructure. There's nothing inherently wrong about this, if the cost of correcting the simplifying assumptions is low; however all-too-often this "technical debt" is not removed before a product goes into production;
  • Agile preaches that at the end of a sprint, you should always have something which is as close to shippable as you can make it, so that stake-holders and project managers can decide that "what they have" is good-enough to push into production. Again, nothing inherently wrong with this, if you've cleared all your "technical debt" (or at made your peace with how much you have and where it is.) However, in my experience, far too much technical debt goes into production with a promise by a manager that "we'll clean it up once the pressure to ship is off", which rapidly turns into "it's in production, we have to be very careful about what we change now", which eventually turns into "You never told me we had that exposure! We've got to do a better job next time!" Ben Frankin's lesson about "The bitterness of poor quality remains long after the sweetness of low price is forgotten” seems to never be learned;
  • However, even with trusting managers and well-disciplined developers, there is the common problem that simply too little proper analysis, design, and design review occurs prior to the start of the sprint in which the implementation is expected to be initiated and completed. The failure to thoughtfully consider alternative UI metaphors and designs is large -- it is usually too costly revise this significantly after a project is started; the failure of junior teams to study their competition's products carefully, or to prioritize the definition of and implementation of infrastructure technologies such as I18N, notification frameworks, logging, security, and API versioning strategies (for example) means they will ultimately have higher bugs, lower productivity, and will accrue more technical debt, than if they had just spent the first 2-5 sprints up-front doing the requisite training, analysis, design, and prototyping. In short, Agile teams must resist the license to hack;
  • I've had a second-level manager (of over 100 developers) who discouraged his developers from taking the time to write down their planned designs, even at the most basic level. His reasoning -- "I want people to talk with each other" -- which was ironic because they were in 5 different time zones and 3 countries. Needless to say, there was a lot of finger-pointing about which team was going to have to work lots of nights-and-weekends late in the project once they figured out that everyone thought the other guy was responsible for implementing some functionality (or re-implementing because the supplier and consumer's designs just didn't mesh.)

It really all boils down to whether the project manager and stake-holders want to deliver a high-quality product. If they are committed to doing so, Agile will enable it. OTOH, because Agile puts the schedule decision-making solely in the hands of the stake-holder and project manager, Agile makes it difficult for a development team to deliver an excellent project without that support. In short: accountability for product quality lies almost solely at the feet of the project manager(s).

1

TL;DR

In fact, agile development helps you to increase the software quality, keep the customer satisfied and deliver a highly valuable product.

Agile development was introduced by a few smart guys to address the problems which many software projects faces in traditional processes.

The key values of agile development as defined by the agile manifesto (1) are,

  • Individuals and Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to Change over following a plan

Hence, agile development doesn't prevents you to create high quality software. Agile development supports you to deliver high quality software.

But do we (and the customer) really always know in advance what the must-be requirements are.

That's the whole point. By focusing on individuals, the customer, working software and requirement changes agile development helps you to figure out what the customers wants before the final product is delivered.

That's a reason why agile frameworks like Scrum having short iteration cycles which outcomes are working products. You can already validate your work at a early stage against the expectations of the customer and adjust the goals/requirements on demand. An agile development helps you to make sure to realize the must-be quality of a product.

Back in the days - it's still true for today - many software projects developed in traditional approaches failed, weren't successful or causing customers displeasures because the must-be quality was not reached.

Furthermore, agile development also helps you to reach Attractive Quality. Reflecting the product after each iteration enlightens new requirements which weren't concerned by the customer at the project start (attractive qualities). This keeps the customer satisfied.

I would also like to mention the Reverse Quality - attributes which leads to dissatisfaction - of the Kano model.

In every project there are requirements which seems to be good ideas at the project beginning. After a while they change to the opposite and causing disappointments.

In a traditional software development process you will recognize such requirements in the final product after a long project run. Too late to avoid customer disappointments and to change them a follow up project is necessary.

Agile development helps you to identify non working or dissatisfying requirements early and to change them during the project.

As I said, agile development helps you to increase the software quality, keep the customer satisfied and deliver a highly valuable product.

1

I am rather late to this party, but I'd like to share another angle on this subject:

But how can they be applied to create delighting high quality software products and not just the bare minimum that barely fulfills the must-be requirements?

There is a temporal aspect in agile software development which results from the iterative approach and considering customer feedback, which are two important elements of the agile methodology. Example: Features which are identified as attractive quality in iteration t might become a must-be quality in the next iteration t+1.

Applying agile methods can dynamically change the quality category of a feature. If you compare the planned features of iteration t with the finished features of some later iteration t+n you will experience exactly what you mentioned:

I have made the experience a few times that requirements which were given a high priority in the beginning, turned out to be much less important, if not useless, later.

With this temporal aspect in mind it is plausible that agile methods can produce delighting high quality sofware products while concentrating on the bare minimum. The iterative approach paired with customer feedback changes the rules of the game over time.

Conclusion

How to develop excellent software with agile methods?

Apply an iterative approach and listen to customer feedback. Ditch one of these elements and you will get a less successful form of agile software development.

1
   > How to develop excellent software with agile methods?
  • When producing a customer specific individual software:
    • find a customer where cost doesn-t matter because "delightful" feature costs extra money and the customer has to decide if he wants to pay for this.
  • When producing Softwareproducts:
    • "delightful" features are good to attract new customers and the cost to implement a "delightful" feature is not so important if the product is sold more than 1000 times.
  • In an environment where "good enough (cheapest) is best" you will not get the money to implement "delightful" features

In a Scrum team the Product-Owner is responsible to choose which features to implement. So it is up to him (and up to his budget) to define a "good enought" or "excelent" software

1

You raise some good points. But I don't believe these problems are restricted to agile processes / methodologies.


There are differing opinions about what are essential vs. non-essential features. To use your example, someone buying an auto might consider attention-grabbing as an essential feature and therefore consider a Fiat as not meeting this must-have requirement.
More realistically, a software product might need to have certain functionality to meet the needs of its actual end users ... but it might also need to have certain other features in order to get sold. Because the person authorizing the purchase is frequently not an end user.
So a feature which is "non-essential" to the end user(s) might be essential to selling the product ... and therefore also essential to the company creating the product.

All of which just boils down to the fact that it's crucial to have a good product development team to set requirements and priorities appropriately. But that's not only true for agile shops.

It's also important to have product owner(s) / stakeholders who are authorized to make decisions. If your product owner's decisions are constantly being overruled by someone else, I'd be the first to agree that that's a problem, but again, it's not a problem with agile.

There are other things you want in your product owner(s) ... one description I've heard is "C.R.A.C.K." (collaborative, representative, authorized, committed, and knowledgeable). A product owner lacking in any of these areas can spell trouble for a project. But I first heard this acronym in a waterfall environment, so clearly the pain of bad customers / product owners is not restricted to agile shops.


What agile can (help) do is bring some of these issues to the surface.

For example, the XP literature is IIRC fairly explicit about having the "customer" being knowledgeable, accessible to the team, and authorized to make decisions. The term "product owner" implies some level of knowledge, commitment, and authority.

If you find yourself in a situation where most of the delivered functionality consists of delighters instead of must-have features, it's much easier to raise that issue (and much easier to determine the cause) when you are delivering working or near-working software every 2-3 weeks than when deliveries are months or years apart.

If you're working in small iterations -- and reviewing the backlog frequently (including revisiting the prioritization) -- that gives the team an opportunity to learn from previous mistakes. "This feels like it's really important now, but remember the dynamic navigation we were sure we needed that we didn't end up using?" As others have pointed out, those discussions are much less likely if everything has been planned up-front.

By contrast, the up-front design methodology assumes (by default) that understanding of the product and features is static. That has not been my experience: having something tangible to work with almost always changes the business people's understanding of the problem. Hence the emphasis on rapid feedback. (The developers' understanding changes as well, but that isn't going to affect priorities.)

Deferring some of the planning also allows you to respond to changes in business needs. "You know that web site you're building? We really need that to be a mobile app, capable of disconnected operation." This isn't something that was asked about specifically ... but wouldn't you want your process capable of responding to changes in the business landscape (at least in theory)?


Agile does not say "don't build non-essential features". It does say "allow the business to decide which features (not) to build".
... and (equally important) "allow the technicians to tell you how long a feature you want is going to take to build".

1
  1. Must-be qualities are often hard to determine. People have them in subconscience. Agile iterations and client participation help to find most of must-be's. That is the power of agile and it is foolish to neglect it.
  2. One-dimensional qualities that mean promises that must be fulfilled, are supported by waterfall OK, untill they are not changing. Here being agile only helps, but not so powerfully.
  3. Attractive qualities are nice features. They could become must-be's in the next generation. But in the current generation they are not even in the agreement - or else they would be One-dimensional qualities. Those agile methods that suppose client representative participation support these qualities very well. For we can change the scope lightly during the work. We can bargain on improvement one place for some compensation in another. In waterfall it is practically impossible. Without a great organizational delay we could only ADD features for free. It is possible, if some extra time is previously put into budget.

So, agile processes can support the Kano model, some of them do it greatly, and definitely much better than the best waterfall projects.

To do it greatly in your understanding you should set agile processes with a responsible client representative participant.

protected by gnat May 21 '17 at 21:22

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.