What makes software valuable? Or, to be specific, when does software become valuable? To put it simply, software becomes valuable when the proper solution gets into the hands of the user. Software sitting on a developer’s computer, no matter how wonderfully it was designed or coded, doesn’t provide any value.

Your development teams are hard at work developing the best software possible. They are employing many of the agile practices that have been developed over the past decade or so, including implementing a rapid feedback loop through increased collaboration, developing in small iterations, ensuring transparency, and responding to change.

Including the Users

As part of that collaboration, are your teams able to access the users of the software? This can be difficult in corporate software development, and even tougher for commercial applications. To provide value, the software developed must be the proper solution for the user, which means gathering information and feedback from users is vital to the success of your software development teams.

In November, we released the TeamPulse Ideas and Feedback Portal. This is an excellent way to get input from users, whether they are internal or external. We have been actively gathering information from our Feedback Portal to continue to provide you the proper solution to help you be more productive in managing your projects.

Delivering Value

Ideas and requests are a great source for software improvement, but the value still needs to be delivered. How many times have you had an exchange similar to the following?

Customer: “We could be so much more productive if we had feature X”

Product Owner: “That feature is code complete and tested, we just haven’t released it yet since it’s not scheduled until the next quarter”

Nobody wants to be part of that conversation, on either side. Unfortunately, there are additional steps to releasing software beyond just writing it. Since each sprint’s goal is to deliver potentially releasable software, there is work that must be undertaken to make it production ready. When your software is a commercial application, there are even more steps involved. Just a few of those tasks include ensuring backwards compatibility (or providing a migration if it needed to be broken), regression testing, and updating user documentation.

At the end of a day it’s a balancing act between continuing to add features and executing a software release. Here at Telerik, our amazing team developing TeamPulse have been continuously improving and streamlining their processes, including releasing new versions. I am proud to announce that we are committing to have a minimum of six releases a year. Not three releases and three service packs, but six (6) full releases a year. All this and not sacrificing features or product improvements! You can read more about our 2012 roadmap here.

Now that’s Delivering More Than Expected.

Is there a functionality you would like to see in a specific feature?

Let us know in the comments below.

About the Author

Phil Japikse

is an international speaker, a Microsoft MVP, ASPInsider, INETA Community Champion, MCSD, CSM/ CSP, and a passionate member of the developer community. Phil has been working with .Net since the first betas, developing software for over 20 years, and heavily involved in the agile community since 2005. Phil also hosts the Hallway Conversations podcast (www.hallwayconversations.com) and serves as the Lead Director for the Cincinnati .Net User’s Group (http://www.cinnug.org). You can follow Phil on twitter via www.twitter.com/skimedic, or read his personal blog at www.skimedic.com/blog.



Comments are disabled in preview mode.