2

We're working on a kind of CMS, a fast, hosted, centralized website builder like Weebly. We also use Scrum development model. But there seems to be some problems here. Our sales manager always come to us, complaining about the design of the application, or UI elements, or stuff like that and hinder development process by making re-works again and again. Examples are:

  1. Why do you have item actions like delete and edit in grid items? Just have list actions as a toolbar on top of grids. No item action.
  2. Why red color? Use green. That's what people like.
  3. Use tree for contents, not grid.

My question is really simple. Is it considered productive, or even normal for sales staff to interfere in application analysis and design?

Improve this question
2
  • 8
    Are you sure the sales team is "interfering"? Typically, a sales team is keeping an eye on market conditions, competitors' products, and the needs of users and perspective users, and will typically be part of the process that is driving both new product creation as well as upgrades to existing products. They should be present and involved in requirements engineering and acceptance testing.
    – Thomas Owens ♦
    Jul 17, 2011 at 18:26
  • 1
    Just because you don't think the color matters doesn't mean it doesn't. You may think red is a great color for a heat map for when a category is strongest (fire is hot and red thus, high heat should be red), but to many people see red as danger or error and that correlation is stronger.
    – unholysampler
    Jul 17, 2011 at 18:41

6 Answers 6

Reset to default
9

What you see as interference might simply be them trying to put over new and/or changed requirements. Your example of the colour issue is a prime example of this.

However, your other examples could be seen as interference - especially the way you've phrased them.

What you need to do is arrange regular meetings to discuss the direction and design of the product, but you must get them to state their requirements as either end user requirements ("the user must be able to select all their widgets") or sales requirements ("we must be able to show this data as pie chart") rather than as implementation details. In general it shouldn't matter how you implement something as long as it serves its purpose.

There will be times when the requirement matches a specific implementation detail - e.g. showing a hierarchy as a tree.

Improve this answer
2
  • Thanks @ChrisF. Yeah, I also think that they should be declarative, not imperative. Implementation details should be in jurisdiction of development team, i.e. Scrum Team, not Product Owner, or Stakeholders. 1 Upvote :)
    – Saeed Neamati
    Jul 17, 2011 at 18:17
  • I accepted this answer because of the declarative nature of requirements. In Scrum Team + Scrum Owner, designer should be the ultimate authority for UI, developers should be the ultimate authority for implementation (including front-end technologies), and testers should be the ultimate authority for feedback. Other ideas and suggestions are all welcomed, as much as they are not dictated. Nobody goes to doctor, while asking for his own prescription. Doctor is the person who knows what to prescribe, not the patient.
    – Saeed Neamati
    Jul 18, 2011 at 7:15
13

Absolutely.

The whole point of scrum is to get the product owners feedback at the end of every sprint to make sure you are building the correct things.

The sales manager should not be interrupting you in the middle of a sprint. But when you do the presentation at the end he should be there and you should be writing defects for each and every one of his complaints (he is acting as the voice of the user).

Then when you have your sprint planning meetings these defects should get prioritized with the rest of the product backlog and brought into the sprint backlog as deemed fit. Note the Sales Manager should also be part of the product backlog prioritization (at the product owners discretion). BUT not part of the sprint planning.

Engineers are notoriously bad at implementing interfaces for users (you think differently to your user). The sales team has to sell the product and presumably he knows what sells. His advice on UI layout (how it looks not how it is implemented) should probably be considered better than yours unless you have dedicated UI expert on the team or you are copying some other common interface that is well known and used (in this case you better be able to show it in use).

Note: This is also a useful way to stop repeatedly updating the same thing. Make a backlog item for it. make sure the product owner has seen it if they disagree or think the sales manager is wrong that should be noted in the backlog item and the item closed. If the sales manager now brings it up again you can point him to the backlog item saying this subject has already been discussed and decided.

Improve this answer
3
  • Does product owners of big projects like Office, interfere in designers' work and say something like make buttons as big as twice their current size. What you said seems to work in declarative fashion. Saying something like I don't feel easy with this form is a defect and should be addressed by scrum team. But I think a sentence like Use button instead of image here shouldn't. In other words, designer is someone who has the power and expertise of creating something appealing, and developer is the person who knows which implementation is the most fastest and least expensive.
    – Saeed Neamati
    Jul 17, 2011 at 18:25
  • 5
    @Saeed Neamati: Projects like Office have a dedicated UI expert who is integrated with the Dev-Team so that is not a fair comparison. Obviously this is a small shop. All advice should be noted and prioritiesed in the backlog. That does not mean the work will be put into the sprint the Dev team still has that control, but you need to document that there is an opinion that your interface is wrong (or could be better). So Use button instead of image here should be noted (hopefully it will have a minimal priority). Big things should have been decided at design time (after the presentation).
    – Martin York
    Jul 17, 2011 at 18:30
  • 1
    A big +1 for this answer. There is a natural planning cycle to Scrum/agile development and writing individual defects not only gets them prioritized properly but if the sales manager gets mad/annoyed at having to write individual defects then he Might get the idea that each one takes time to implement against the total schedule =)
    – Patrick Hughes
    Jul 17, 2011 at 18:39
7

Ideally your requirements should be coming from the customer, but the sales staff is also a valuable source of feedback, and the fact that your sales staff is funnelling their requests through the sales manager (and not just inundating you with individual requests) suggests that they are trying to be helpful to the process, and not merely interfering.

Does the sales staff act as a liaison between the customer and the development team? If so, then the sales staff is doing its job. Is the sales staff also a consumer of the software? Then they should be able to provide feedback on the design. If you're doing things right, you should be eating your own dog food anyway.

That said, the design decisions themselves should not be made by the sales staff. The sales staff is merely one of the stakeholders; they should be able to influence, but not dictate, the design process.

You should listen to your salespeople; they are the ones that have to listen to customers tell them why your software is good or bad, and how it should be changed, because they are talking with the customers all the time, so they are theoretically in the best position to provide constructive suggestions.

Encourage your salespeople to provide good, actionable feedback; changing the color of a label to fuschia may not be the best use of anyone's time, but reevaluating the entire color scheme based on feedback from customers that the overall scheme is hard to read, might be.

Improve this answer
1
  • I specially liked the idea of eating your own dog food. It's very very logical and moral. One upvote :)
    – Saeed Neamati
    Jul 18, 2011 at 6:56
3

In Scrum, only the Product Owner can decide what will be built and in which order. So you should just point change requests to your PO so she can prioritize them in the backlog as usual.

Having said that, there is nothing wrong with input from sales dept or anyone else. They probably meet with the users a lot and have valuable insights which you might benefit from. In the end, it's up to your PO to manage (and juggle) feature requests, be it from customers, the team or sales.

Improve this answer
4
  • What if PO is Sales manager too? In that case she becomes the God! I think something's wrong here. What about programming knowledge of scrum team? What about expertise?
    – Saeed Neamati
    Jul 17, 2011 at 18:28
  • Then politely remind the Sales Manager / PO to use the process and remind him that all changes take time away from the total schedule. If your PO squanders the team's time with wasteful revisions the documentation will show that in short order. The PO doesn't need technical expertise because the members of the scrum set the schedules for each task, tackling them in priority order.
    – Patrick Hughes
    Jul 17, 2011 at 18:43
  • 2
    @Saeed Neamati: The PO prioritizes the backlog. They do not decide what goes in the sprint (that is the dev teams job). If you are not building what the PO wants you are wasting both their time and yours. But they should not be interfering in the middle of a sprint.
    – Martin York
    Jul 17, 2011 at 19:26
  • @Saeed: The PO is responsible for ROI and it's important that person can make the correct choices. Selecting the correct person for the PO role is critical as you say as that person must be able to judge input from several sources (clients, stakeholders, sales, devs etc), which make it a very demanding role. Just looking to satisfy the interest of one party (sales in your case), is probably not the best way to spend your organizations time and money.
    – Martin Wickman
    Jul 17, 2011 at 22:12
3

It sounds to me that sales isn't properly represented/integrated in your development process. Are they a stakeholder? If they are not, then their input/concerns should likely be funneled through a stakeholder. However, it is possible that they should be a full-fledged stakeholder.

Ultimately, as developers, our responsibility is the technical design of a product (and its implementation). The rest of the design is not our area of responsibility. Lacking a design (not necessarily just graphic) we will fill the void, because we have to. However, that does not mean that it is the best design for the product.

If changes to this design are a problem, then that be must investigated and addressed. Maybe development needs to point out the voids that must be filled before work begins. Maybe development needs to provide for some variability. Maybe issues need to be addressed earlier. (Maybe issues aren't being addressed properly.) Maybe sales needs to understand the impact of their change requests.

One concern I have is that you've phrased this question in a adversarial fashion. It is sales that will be bringing in the money to pay for this development effort. The mindsets may be vastly different, but we have to find a way to cooperate or there won't be anything to sell.

Improve this answer
3

There's a difference between meddling/interfering and making suggestions. There's also a difference between valuable suggestions and useless ones.

If you're being actively interrupted while working on code, that counts as meddling or interfering. In such a case, you have every right to get the salesperson out of your face. Additionally, if your decisions are being undermined by constant second-guessing at meetings, if the salesperson is making an effort to undermine your authority or question your competence, that's certainly unacceptable.

However, if you are simply hearing lots of opinions when you present something, this isn't meddling. It's just unwelcome advice, like you'd hear from a friend who sits on your deck furniture drinking your beer while watching you teetering on a ladder while you paint your house.

It's quite possible that the salesperson is well-meaning and just wants what he/she thinks is best for the customer, even if the suggestions sound silly or capricious.

By making suggestions, your salesperson may be hinting at weaknesses in your design or interaction model. Or they may just have their own personal axe to grind.

If there are solid justifications for changes, it's worth trying to find a way to respond to feedback, even if your actual implementation doesn't end up literally incorporating the specifics of the suggestion; it's quite possible that you'll learn something if you listen. Just keep in mind that the words used in those suggestions may not refer to the actual problem; they're just a proxy to an underlying issue that hasn't been adequately understood yet.

I've sat in meetings where an executive wanted to fiddle with how many pixels to the left some control was instead of discussing what business logic needed to be there, and we certainly found this not a good use of his time or ours. But I've also listened to people complain about the look of something or what type of control was used and it was really a roundabout complaint about how something worked, not what it looked like. Keep in mind that users usually don't know what they want until they've gotten it; if you think of your salesperson as a proxy for an user, there's a good chance he suffers from the same problem.

So don't feel obligated to accept every suggestion, but don't be so quick to dismiss every word coming out of your salesperson's mouth.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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