Jonathan Fries — October 17, 2019 Software development is the core focus of any digitally transforming organization. A lot of time and effort in these organizations is spent thinking about and communicating the concept of product development. Customer-centricity, continuous delivery, and automated QA are just a few of the things that are necessary for product development. For many IT teams, developing products can be fun, invigorating, and meaningful. Why settle for just a project or deliverable, when you can do product development and play with all the shiny toys available to you?
Except there is a problem with this train of thought: a lot of software development isn’t product development. This doesn’t mean that it’s bad or wrong. It just means that it’s something different. After all, a tool that you develop that helps your accounting team process more transactions faster is still a very important business outcome, but it just isn’t a product.
At Exadel, we frequently do both (for ourselves and others) and it is important to understand the difference. There are times when projects would be better thought of as products. There are also times when a project is just a project, and thinking about it that way will make it more successful.
Here are some important considerations in developing a project as a non-product:
- Understanding Your Users
It may be easier to understand your users when you are dealing with non-products. If your user is two cubicles over or sitting in an adjacent building, you can easily reach out to them and understand their needs. Just make sure you do it. - Design Considerations
We’ve seen this cut both ways. You may think that your internal, technical, or administrative users have fewer UI requirements than customers do, but what about all the specialized processes that have been developed over the years? You will need to ensure that you can maintain efficiency in your internal work and not make things slower, harder, or more expensive. A grid sounds easy to develop until you realize that your accounting team expects it to function exactly like Excel. Suddenly, it’s not as easy as it once was. - Internal Deployments
Deploying to internal, firewalled networks can provide some simplicity that may not be available to externally visible sites or apps. This is no excuse to slack off on security though. Ensure that even if you are deploying internally (or to a virtual private cloud) that you follow best practices for security. - Testing
You may have a more limited scope for testing. For instance, you may be able to dictate browsers or devices to an internal audience, which can greatly simplify things. Of course, sometimes you can’t. If the CEO has an iPad (and uses it), then you should probably test that dashboard on an iPad and make sure it works, even if the rest of the company will access it on a laptop.
From an agile development perspective how should you approach such a project? Here are some tips taken from the agile playbook that can make it easier:
- Product Owner
We’ve seen clients spread the task of product owner around to more people for internal projects. This can even give a less seasoned person the opportunity to try out a new role and gain skills without the higher stakes involved in true product development. - Sprints
It’s best to stick to a regular schedule when it comes to sprints. They are still a valuable tool to get feedback from your (internal) customers. - Testing
For an internal project, you can reduce the barriers to testing earlier. Often with products (and often for good reasons) organizations are hesitant to embarrass themselves by showing early work to clients. This isn’t the place to debate that, but, at least with non-products, you have no such barrier. Show the unpolished version as soon as you can. Sometimes an unpolished version will get people so excited that you can ship much earlier than expected. - Backlog
It’s possible to approach this with a little bit of a lighter touch also. You may have more regular access to the Product Owner, or you may have the ability to refine on the fly. Make sure you REALLY have this ability before you accept an underdeveloped backlog though, it can come back to bite you.
Sometimes big wins come from tools that will never see the light of day outside your organization. Making your co-workers faster and more successful—even delivering delightful things that make customers happier indirectly—can yield big advantages. So, don’t neglect the agile approach for all these non-products, just adapt them to the situation and deliver great value for your organization.
Business & Finance Articles on Business 2 Community
(51)
