Agile Development for ''Non-Products''
What does this mean?
Join the DZone community and get the full member experience.Join For Free
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?
You may also like: Why Is Going Agile the Best Option for Software Product Development?
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.
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.
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.
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 are taken from the agile playbook that can make it easier!
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.
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.
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.
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.
Multi-cloud strategies have completed shifted the way IT organizations work. With so many options available to IT professionals, the flexibility and security of a proper multi-cloud approach are hard to argue with-and by leveraging tools like CrossKube, you can make your multi-cloud strategy pay off in big ways.
Published at DZone with permission of Jonathan Fries, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.