In the software industry, not in all cases but true for many, you usually report to a manager who has no advanced knowledge about the underlying technology used in a software project.

Usually this drives managers to value your work based on what they see on the screen rather than what's really required to get the project done. You're chained to show something to them and forced to work on poor design decisions to just get an ok, keep doing.

My concern is if it's actually unrealistic to think that more involved and engaged stakeholders shouldn't value you on what they see on screen, but by the actual already achieved project goals, either if they might have an impact on the UI or not.

In fact, when projects require not so useful demos, overall cost is increased, because preparing a project to work with quality requires testing, debugging and even last hour modifications that might be thrown away once the demo is done. Finally, there's a timing debt associated with this kind of project management that impacts on you because they delay their own timings without modifying them (wasted time is lost forever).

In the other hand, I'm not arguing that we should hold them 2 years until they can see something on the UI. IMO, I would say that agile project management with approaches like Scrum already define the sprint demo, but based on my experience, stakeholders don't want to get involved in regular project management, but they just want a global feedback with a demo that should look like a final product in terms of quality.

Side note

I want to be sure that no one could understand that my question is arguing that I shouldn't demo the UI. Furthermore, I'm not against showing it very often. But as some have already said in their own answers, sometimes it takes time to see some change on the UI while some other details are being implemented, fixed or improved.

So, that's why my question is about if it's unrealistic to get reliability not just by what you see on screen. Thus, it's implicit that UI demos are required. End-user feedback is crucial to succeed on delivering a good project, because after all the project is for the user.

4 Answers 4


Whether or not expectations are 'unrealistic' is highly situational and even opinion-based, so I'm not sure you could get a useful answer to your actual stated question.

That being said, if your real concern is 'what to do when stakeholders care only about the User Interface (UI)', then an approach that may help is to simply include functionalities in their entirety.

For example, say you have a requirement that 'Must be able to save an order, and review saved orders.' This involves both the UI of saving and reviewing orders, as well as the behind-the-scenes stuff required to make it actually work. If the back-end stuff isn't done yet, then neither is the feature, and as such the UI portion should not even be shown to the stakeholders at all. If they ask, then 'The feature isn't done yet.' Do not show them a mock-up UI, unless it is specifically noted as a mock-up, with everyone involved being aware that the thing is not actually working yet.

While providing a temporary 'functional mock-up' may make it look like a Team is moving quickly, in reality the overall project isn't going to go any faster - and may indeed be slowed down by the stopgap 'solution.' The best thing to do in a situation where upper management is expecting such a thing might be to explain to management the overall costs of such a strategy. While you're not going to be able to explain why technical debt does what it does, if you properly explain to any reasonable person its effects (increasingly slower development over time, greater chance of bugs, higher difficulty in maintainability causing problems with new hires, etc.), then he or she will almost certainly take such things into account, at the very least.

If you've done all you can to explain the costs of a stopgap mock-up to upper management, and they still don't understand, then either you haven't explained properly enough, or else you may want to consider looking for other employment, where management is willing to listen and learn. Note that this applies only if the management does not understand. Not that they've understood and just decide that their other goals are more important - that is their call, be it 'correct' or not.

  • Hey, thanks for your effort and advise. It's situational, but I've experienced this so many times and I'm tired of fighting against what I feel as a bad management practice. Your example is what I actually do already: I don't give false expectations to any company I've worked for. Dec 14, 2016 at 22:06
  • BTW, this ends up with a feeling that you're too slow. You know that most coworkers will mock-up the UI, lying if required, to get more time, and sadly, based on my experience in many companies, this kind of workers tend to survive more time on their job position, even when the project can't be developed with maintenace/quality in mind. Dec 14, 2016 at 22:07
  • It's a really hard problem and that's why I've asked the question. While there might be some subjective background on my question, I feel that it should be useful to know if it's just I'm unlucky or it's really unrealistic to expect that there're companies where everyone gets involved in a given project, and project advancement is clear to everyone because both stakeholders and the dev team participate in the decision and review process. Dec 14, 2016 at 22:10
  • @MatíasFidemraizer Updated my answer to respond to some of your comments.
    – Sarov
    Dec 15, 2016 at 0:28
  • I believe that your answer is very constructive, even when one of possible solutions is just moving forward to the next employment. In my particular case, I feel that I've done the steps you're proposing in your answer. I would say that it's not an issue with my current position, but it has been a constant in almost all job positions. Dec 15, 2016 at 7:22

To me this situation looks more of a Perspective of Done than what is shown/not-shown on screen. Thus the solution lies in effective communication. IMO, your aim should not be to show something new on UI in every demo, rather should be to add value and progressing the overall product aiming at end user, may be via improved performance, better call flow, integration of some automation test cases, etc. etc. which are not really interest areas of the UI centric stakeholders.

This is what I'd follow if I were in your place. It may not be directly relevant/applicable/acceptable in your scenario but I wanted to give you a perspective and have you derive your own solution:

  • On those days when you do not have any substantial change on UI, start the meeting on a positive note by explaining upfront in the format - "Today's demo may not show much on UI but the benefits for User are as follows". Generally, this trick of benefiting end-customer, chance of beating the competitor, acquiring more audience for the product, automation, etc. entice the stakeholders.
  • Also create a one-slide PPT along with working software demo when you have made a backend centric progress during the sprint. Talk about the benefits achieved through bullet points in the PPT, and compare it with previous version of product's behavior.
  • Try to be number oriented. E.g., "new call flow takes X sec lesser than the previous flow. It might not be visible on UI directly but benefits the end user."
  • In case the stakeholders are available locally, engage them in short, water-cooler talks and mention your overall work in informal discussions. It looks like their lack of knowledge on your technology. They are not able to understand the complexity of your overall task. These water-cooler, elevator talks will give them perspective but in digestible quantities. Next time, they will be more inclined to listen to your non-UI centric demos in the formal meetings/demos.
  • This is exactly what I do everyday. Sometimes you feel that these water-cooler informal meetings are useful (you think so) but later you realize that the more info you provide to stakeholders, the more chances you provide them to build a wrong perception about the project. I'm not saying that I think that this should be that way. Uncountable times I've heard one of most popular sentences: aren't you adding too complexity? I feel that this could be done in few days because it's a very basic requirement and ok, you're doing fine, but I want to see something on screen! Dec 15, 2016 at 7:29
  • BTW you're advise is very very useful not only for me, but it's a guidance to be a good teamworker. Dec 15, 2016 at 7:31
  • Yeah, I know the battle between non-technical ignorants and technical people has been there since the birth of software industry. But sometimes you cannot just magically bring up something on UI when it is not meant to be there. Having half baked work on UI, just for the heck of having it there is actually product debt. Don't give up on educating your stakeholders, and don't mold your ways too much just for pleasing them. It is them who need to get matured. Face them and reply to them when they say "it's a very basic requirement.. but I want to see something on screen!" Good luck!
    – mehtak
    Dec 16, 2016 at 9:05
  • Hahaha, yeah, you're right! ;) BTW This battle really, really hard. While the described situation is happening now in my current position, it has been a constant across all project I've been participating during past years. I would say that we need to avoid a Graphicality (in terms of Mortal Kombat :D) Dec 16, 2016 at 9:13

I understand where the question comes from, and I see that kind of concern a lot from engineers who I work with who sometimes feel that people who don't understand the code they are writing can't appreciate what they are doing.

There is some merit to this, and I would suggest that any project manager who works in IT should do everything they can to understand as much of the underlying technology as possible. If not, they are neglecting the foundation upon which their entire career is based. There is another side to this though.

Why are you making this software? Who is using it? What are they doing with it? What are they not doing with it that you want them to do with it? If you analyze these questions, you will realize that 99% of the time, ANYTHING you are likely to be developing in the form of code is going to be used almost exclusively via a GUI. Users will interact with everything you do and every part of the system through their monitor, touchscreen, etc. Obviously there are things like embedded systems, IOT (internet of things), control systems, etc, where there is little or no user interaction with your application via a UI, but almost everything we do in the IT field boils down to something being displayed to a user VISUALLY and something being sent back to us via a GUI. Doesn't matter if it's a smartphone, a PC, or even a refrigerator, it's the same principle.

So, given that, a focus on being able to demo elements of your software visually to someone who wants to see something on a screen is NOT completely out of line! Ultimately, put yourself in your user's shoes. What are they going to see? What are they going to interact with? Clearly, that should be demo-able visually. I don't know what part of the project you are working on or what stage of the SDLC (Software Development Life Cycle) you may be at, and there are places where the work you are doing might be partitioning a database to optimize performance and there will be no change to a UI element or user-facing functionality. Of course even in that case, you can demo it visually! Run a little demo of a "before" and "after" average load time for your analytics dashboard the way it loaded before and after your database partitions, etc etc etc. There is almost always a good way to show a non-technical customer or manager what you did visually.

While you are right that working up such a demo is sometimes time consuming, and you might be more efficient without having to do it, it also focuses you back on the end user, which is sometimes extremely helpful. That's one of the foundational principles of the agile scrum process. Delivering something significant (ideally) every sprint that can be SHOWN to someone. Sometimes looking at things from the perspective of your end user is also a very helpful problem-solving exercise too.

  • Good answer too. As I've already said in my question, I'm not against demos and having to demo the UI often. Just the opposite. I'm against random demos out of planning because thinking that agile process is just for developers. Agile is for all involved people in a project. This is really what gets hard to manage (random demos). Dec 15, 2016 at 20:42
  • I've edited my question with a side note to notice I'm not against UI demos. BTW, my edit doesn't affect your answer, I added more info just to clarify it :) Dec 15, 2016 at 20:48

The Agile mindset is that clients, stakeholders and users do not really know what they want until they actually see and use it. It is all about the value the product delivers, how can they measure this value if they cannot use it?

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The demo (review) is not to show what you have until now, but to deliver a working piece of product! In my book it's not a product if it doesn't contain the final UI with styling, works end-2-end and is deployed on a product server. If enough value has been delivered. The users should start using it as soon as possible to gather even more feedback. Products evolve best by using them, not by designing them upfront. 65% of the build features are never used by users, why build them?

I love vertical software development for a couple of reasons. Creating software end-2-end gives much better insights in uncertainties (e.g. what works and what doesn't on your scale). Don't postpone integration until the end, this always leads to missed deadlines. I am always amazed how users do not really need features when you continuously estimate and compare effort versus value. If you keep delivering a usable product the users will really know what the next most important feature should be.

Focus on Minimal Viable Products. Question yourself what it means for something to be a product. It should be shippable to actual users, not? Now start shipping often.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Now I understand that delivering a product without all the features feels like a waste, certainly when you are pretty sure you have to rewrite parts, because of known features on the roadmap. Still waiting until the end to find out your product isn't going to be used, because it lacks user- or market-fit is a lot more waste. Keep in mind a lot of products never ever see the daylight. This is one of the reasons YAGNI is an important Agile principle, build only what you need.

Simplicity--the art of maximizing the amount of work not done--is essential.

To minimize waste your product needs to be maintainable, extendable and understandable for developers. I advocate Clean Code and any developer and project manager should watch the first episode. Technical excellence is often skipped in projects, because the developers, the managers, the project managers and Scrum Masters actually have no clue how to make software professionally, unless you're lucky. :)

Continuous attention to technical excellence and good design enhances agility.

  • 1
    Things got harder when the client is the own software company where you work for, and it's a project which will never get to clients, because the users are the coworkers. Obviously, then coworkers are clients, but I say that things go harder because there's no actual pressure to get things done, but there's an extra pressure that's even worse: company is investing in an internal project which won't get direct profit in terms of money in the short-term, but it's just because the company wants to organize their work better. Dec 15, 2016 at 9:54
  • 1
    There's even other issue here. I've been hired many times to lead a tech transition from bad practices and obsolete tech to a new tech stack, and the big fail on these projects is that the biggest problem is that a tech transition isn't just that, but there're a lot of changes to make before on the company in terms of management. And this is the point where I find that companies tend to prioritize "I want to see something" over collaborating to succeed. Dec 15, 2016 at 10:00
  • Obviously, some day there should be some result, something to touch and play with it. Playing around with the project is an important step to rely on the project itself. BTW, good software projects have more work on the software architecture side rather than what you can see on screen. The problem gets even more and more worse, when a company wants such transition and you end up assuming too many project roles, and you're alone. Dec 15, 2016 at 10:03
  • That's why I think... Is unrealistic to think that more involved stakeholders don't think about what they see on the UI but they should be excited just by being part of the project? Indeed in the road to finishing the project, they'll see a lot of screens, interactions and fancy animations, but if they limit their vision to "what I see is what's important and I don't care about what's the software development process", companies usually throw away the project at some point because they fill things are slower (while it's not the actual situation of the project...) Dec 15, 2016 at 10:07
  • BTW, the YAGNI reference is very important, thank you for your contribution! Dec 15, 2016 at 10:10

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.