If not prototyping then what?
Over the years, I gravitated towards using prototyping as part of my job quite heavily. It brings practical problems of its own which I hoped to resolve by reading this forum, but I am finding out that prototyping the way I do it, and even much more lightweight one, are seen as bad practice. I am open to learning a better way, but not sure where to start. So, I will describe our general setting and what I use prototyping for, and will ask your advice how to improve.
We are a product company developing scientific software. The product is licensed to clients, and sometimes clients directly pay for new features (projects lasting several months, involving teams of 2 to ~10 people).
The company structure relevant for everyday work is:
- "Scientists": know the domain, work with clients. I guess partially "business analysts" but without requirement analysis training; partially "account managers".
- "PO": used to be a true PO, but the company grew, and now he is mostly overseeing that individual features are aligned among themselves and with the product, somewhat picks which customer projects we will take.
- Developers: don't really know the domain, know 50% of the product, the other 50% in any task turns out to be some legacy that nobody knows.
Now to a particular example. We have a project with a client. It is unclear who is accountable for, seems like the whole team. Our culture dictates that we wear any hat necessary, and so since "PO" isn't really involved in it, we take over his role as well. I have been trying to pull most of this weight in several projects for a couple of years, now in this one, too. Informally kinda "project lead from the development side". If there are no tasks for development, it's my problem, so I try to define some ways where to move -- tactics, not strategy.
The client tell what they want very vaguely, nor do they know if what we propose will work for them or not. I have never seen anything quite like this, but so it is. They can assess if what we provide does the trick or not when they play with it, and all of it, all parts integrated. They ask for our expertise. Scientists associated with this client we work with now mostly delegate our questions to the client and have no opinion of their own. Communication with the client happens in one weekly 2-hour meeting, high-profile and low-throughput.
(Having written till here, I am stunned how dysfunctional this sounds, and yet our company taps itself on the shoulders how smart we work...)
Given this, what we started with was heavy prototyping: sprints of prototyping, installing it on our project server, waiting for feedback, integrating prototypes in a prototypical way. By "prototyping" I mean we cut every corner, discard everything off the main track, do no automated nor manual testing (by QA), do not create documentation. After two months (4-5 sprints), we had some solution that was deemed good enough. Actually, there was never a formal confirmation, but we waited for some time, saw that they tested it and did not complain, and claimed it victory. The problem is, all this time we had huge chunks of unfinished functionality.
Once we had our confirmation and certainty on the final design, we split it into tickets and implemented it. This seemed like a breeze from the process point of view, but still took 4-5 months (because legacy and because our prototype was as stripped down as possible).
I cannot imagine how this could have been done without such prototyping: I mean, working for ~6 months without being sure we are doing the right thing, and yet polishing it to handle all cases, doing unit-tests, moving through QA, documenting, all with the risk of throwing away large chunks later... I actually thought, as probably the rest of our organization does about its ways, that it was an efficient agile way to do things: collaborate with the client on somewhat working software (not prod-ready though), discover as you go, correct the strategy based on the feedback...
Still, this does not sound elegant, and I seek advice about how this can be tackled differently.
I understand it's quite a convoluted question, but can't really split it into smaller chunks yet. If you think there is another resource where I could ask it, please advise. Our organization as I said thinks its ways are the best, so from that side I do not get any help. Can't hire a SCRUM coach just for myself :)
Thank you.
Take a look at "The Lean Startup" by Eric Ries (2011), and what it has to say about the role of quality and design in an MVP (Chapter 6).
Think about the effect of cutting quality (i.e. incurring technical debt) on the validated learning loop, and the point at which it would begin to slow empirical feedback down in your situation.
Scrum is based upon empiricism. That is a philosophical theory that there is no inherent knowledge and everything is learned from sensory experience and empirical knowledge. There are a lot of ways to interpret that. This explanation from Scrum.org is especially relevant to this conversation.
When agilists refer to empiricism, we are simply recognizing that there are categories of problems that are too complex to be solved by reason or analysis alone. While simple problems are straightforward to solve, complex problems require that we experiment our way to the solution.
What you have described is what I would call an empirical way to arrive at a solution.
You mention a lot of job titles in your description and their involvement in the process.
One thing you need to remember is that Scrum is a framework, not a process. It is something that provides some guidance, practices and a support for organizations. As a developer you should be extremely familiar with frameworks and how you can use them in many ways but benefit from the supporting structure and boundaries.
Second thing is that the Scrum framework does not provide any job titles or job descriptions. It provides 3 specific sets of accountabilities that need to be present in any group of people that use the framework. Those are Product Owner, Scrum Master and Developer. These accountabilities do not have to be given to a specific individual with a job title that matches the Scrum Guide. In my experience, they will often be covered by individuals with varying job titles and in some cases, even spread across multiple people. For example the Product Owner accountabilities could be shared among people with job titles like Product Manager, Business Analyst, Product Architect, Engineering Manager or even Sales Representative. The Scrum Master could be shared among Project Managers, Engineering Managers, Program Managers, or Delivery Managers. The Developer could be a Software Engineer, Database Administrator, DevOps Engineer, Quality Assurance Engineer, Product Architect, or Engineering Manager. Notice that some of the suggested job titles I mentioned are in multiple lists.
Third thing is that prototype is defined as usually understood to be a first model of something upon which other things are built. They often are built to prove a concept and then will be used to as a starting point for building the eventual product.
By "prototyping" I mean we cut every corner, discard everything off the main track, do no automated nor manual testing (by QA), do not create documentation.
I believe your definition describes a prototype. It is also a great way to get initial feedback on what is needed.
I cannot imagine how this could have been done without such prototyping: I mean, working for ~6 months without being sure we are doing the right thing, and yet polishing it to handle all cases, doing unit-tests, moving through QA, documenting, all with the risk of throwing away large chunks later...
Here I start to disagree with you. I CAN image how this could have been done differently. The idea of providing at least one usable increment of value in each Sprint is how Scrum uses empiricism. You can build what the customer needs right now based upon feedback given every Sprint. That is also why a Sprint is timeboxed to 1 month or less in the Scrum framework. It allows for quicker feedback so that you can adapt as you go. In waterfall practice, you find out what a user needs/wants now, then put together a plan to build it and deliver it to them much later. In the "olden days" and in some situations today, that works. But the way that the world changes today, it is often that case that what is needed now is not what is needed next week. So, being able to build, inspect, get feedback, adapt and move on is an important aspect of what is needed today.
Where I see a problem with what you are doing is that you are approaching your work without thinking of the quality or ability to maintain it. The practice of adding low level testing does not take a significant amount of time. Unit, integration and system tests can be added along with the functional code and often is all the testing you need. My 30+ years background includes software engineer, software testing, and release management of a LOT of different codebases across a wide range of tech stacks (including mainframe COBOL). I can not tell you how many thousands of releases have been made based upon the "build" completing successfully with all low levels testing passing and no further testing being done. In fact, on many occasions as a Quality Assurance Engineer/Lead/Manager I have spent more time reviewing and creating those tests than I have doing through the UI total regression testing. If you have good low level coverage, the regression is done every time code is checked in.
I actually thought, as probably the rest of our organization does about its ways, that it was an efficient agile way to do things: collaborate with the client on somewhat working software (not prod-ready though), discover as you go, correct the strategy based on the feedback...
I agree with you to a specific point. After your first acceptable iteration with something that is "not prod-ready though" you have to take the long term effects into consideration and start building things that are "prod-ready". Otherwise you are building something that is fragile and difficult to maintain going forward. You have to be ready for the stakeholders to come to you a year later and say "Our business needs have changed and we need to modify the application we are using today".
You never mentioned that your organization is or wants to use the Scrum framework. You only mention that they want to be agile. I would say that the scenario you described is agile. It is using some aspects of the Scrum framework (i.e. sprints, getting feedback directly from client) but I would not say it is using the Scrum framework. I may be missing something you didn't provide. An organization can be agile without using the Scrum framework. Being agile only means that they are able to adapt quickly to changes as those changes are recognized and they are willing to build something that is needed now based upon the information that is available now instead of building something based upon suspected needs in the future. If this is working for your organization, I would not suggest changing it.
HOWEVER, your concern about unfinished work is valid. Technical debt is very much like financial debt. The more of it you have, the higher the chance that you will have to declare insolvency. It is possible for a software application to arrive at a point where it cannot continue as it is without needing a period of restructuring, consolidating, or reducing. If you look at corporate history and the impact that bankruptcy has had on many companies and people, you can start to build a picture of what technology debt can do. It is also a very good way of illustrating the situation to other people. Even non technical people can understand it. It doesn't mean that everything fails and goes away because many entities have been able to recover from bankruptcy. But it does mean significant periods of time where there is no focus on new ways to make money and all focus is on how to save what you have. Imagine an extended period of not building new products or enhancing existing ones but having to focus on rebuilding what you have in order for it to survive. I doubt that your customers or company leadership would like that. So using a day or two of effort now to build things better would save a lot of time and effort later at a much higher cost.
Prototyping is a valuable tool, especially in uncertain and exploratory projects like yours. However, it's essential to align prototyping with Agile principles to ensure it serves client's needs effectively.
As @Danial mentioned, Scrum focuses on incrementally building a product with regular feedback and collaboration, rather than delivering a complete solution only at the end. To enhance your process, I suggest considering a Minimum Viable Product (MVP) as a starting point.
Begin by identifying the core functionality that delivers the most value to the client. Use this as the starting point for your prototype, ensuring it's lightweight yet functional enough to gather meaningful feedback. From there, iteratively refine and expand the prototype in manageable increments, focusing on closing the most critical gaps with each sprint.
By prioritizing the MVP and incremental enhancements, you can avoid the prototype becoming too large and unwieldy.