Lots of requirements. Lots and lots and lots

A story about what will your ‘Yes’ answer cause in the long run.

Lots of work. If it was about fire being once here and once there. But the fire burns always, everywhere and every single day. We develop a number of system customizations and our app is no longer what we wanted.

Why is it like that?

Weeeeell, at the beginning we had imagined a universal product that would provide our clients with a variety of options. One product for clients of different size.

I see. And did it work?

No, the code began to be very complex, the requirements were against each other and the system could not be maintained. One change will cause some of our clients to stop working. And because of that, we’d rather keep them on the older versions. And we pray that they will not want a version that was published on the web. When it happens, it’s all going to go wrong, we’re not going to have the time to test it and then fix it.

To be honest, we’re fed up with it. Always stuck in the same circle.

Hmm, and how about dividing product into multiple ones?

Huuuuh? Are you mad?

Why is it like that?

The situation is not even caused by a small group of people, or as most people think, by a poor management, but:

  1. Bad strategy. The product is from the beginning for everyone. For both small and large clients. With absolutely different needs.
  2. The product should help the client with a complex value flow. That means to do everything. The product has become brutally complex and difficult to maintain.
  3. The product uses many user roles. With different experiences of using IT. Some would need advanced features, others could become lost in them.
  4. Clients directly suggested the behavior of the product, its properties. The team was very glad that clients are communicating and doing the most for them. Basically, the ‘NO’ answer is non- existent. No question Why? What’s the problem you want to solve?
  5. The product was not designed modularly. The extensive architecture has caused a Mikado code (you won’t even find spaghetti in here).
  6. No proper Git setup, misuse of versioning principles. Changes not committed as changesets but through separate files.
  7. The product usage has not been measured. Features that were only used by one or two clients were expanding. Literally. Others get it as a free update. It’s nice to have but they still won’t use it.
  8. Due to complexity, users started to get lost in the product. But never mind, we’ll write up a manual, record a video and make a call center
  9. The old branches were not cut down and because of that energy didn’t go all to way up to the fruit. Unused features were not removed.

Entropy grew and grew. When the product became unstable, clients started to be unsatisfied with the quality and durability of supplies, developers were nervous and resigned. No time for re-factoring nor challenge, interest, fun. And so they began to leave the ship.

Advice?

  • Map your clients and users. E.g. with the help of Lean Canvas or business model canvas and value proposition.
  • Design a product in a way, so the user can easily upgrade to the higher version by plug-ins, modules. We built the ScrumDesk Start that way. Scrum support is available for beginners. As they grow, their products are more complex and that’s why the hierarchy of requirements, roadmaps, custom fields are needed. Later, they can buy the ScrumDesk Product management features.
  • Start using Git (or something similar) as soon as possible. Learn the Git workflow.
  • The product owner should break the requirements into small pieces. Verify that the problem of a given segment is dealt with.
  • Measure usage since the very beginning. Basically, it should be a default part of the task. In order to be able to evaluate which parts to further develop.
  • The already programmed products do not need to be refactored. Slow but sure wins the race. In each sprint bit by bit. First, make modules, design the interfaces, then start to change the modules. 20% of properties used by 80% of the time.
  • Try to develop small features. Deliver parts regularly, best daily. That way you can quickly find out if the changed code works.
  • Invest at least 20% in development. If not, in a year or two there won’t be any income.

The most important is to meet with the users and listen to them. However, don’t do everything as they say. Try to understand what they need to deal with. In the end, solutions can be easier and more expensive. And they themselves will start to understand that less is more. That you’re their partners who help with their business and not only suppliers, who encash.

…So, how less?