Is it unrealistic to develop a software project and get reliability not just by what you see on screen?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.