Guest Commentary – Software Development: A Partnership between Developer and Customer
by Chris Jenkinson
Raise your hand if this sounds familiar: You’ve got an important software endeavor, you compile your requirements, you hand them off to a developer or project manager, and months later you get a monolithic application. If you’re lucky, it was on time, on budget, and met your needs, but according to the 2013 CHAOS Manifesto from The Standish Group, only 39 percent of surveyed software projects in 2012 met those standards. Forty-three percent of projects were late, over-budget, or missing features. Eighteen percent were cancelled outright and never used.
What leads to these results? Often the culprit is size. The same report says that small projects have a 20 percent chance of coming in late, over-budget, or short on scope, but a large project is more than twice as likely to fail in this way. A large project is even 10 times more likely to be cancelled than a small project (38 percent to 4 percent). Every professional discipline has their own version of the Pareto principle (the 80-20 rule), and software is no exception: focusing development time on the 20 percent of scope that delivers 80 percent of the user value is a clear path to success.
How do we break this cycle? At FORTE, we employ a transparent, iterative software development approach to ensure we are delivering the most value for our customer, whether that customer is internal or external. Our transparency comes from charts, graphs, and other forms of metrics that are updated in real time and available throughout our organization for anyone to see. We iterate in short sprints that allow us to check our progress on deliverables early and often so that nothing falls through the cracks. This type of approach offers many benefits to our customers beyond just the value of the final application.
First, it increases the trust and communication between the customer and the development team. Too many software teams take a black-box approach, where requirements are fed in and the first time the results of the investment are seen is when the entire product is finished. The process of how those requirements become product is seen as “software magic” that outsiders are not privy to seeing.
We break down requirements into easy-to-read user stories to ensure that we understand the needs of our customer, and we use that story for development. Internally, we break down those stories into smaller units of work so that how we do what we do is no longer a mystery. Nothing is more frustrating than not seeing any progress until the software is complete, so we seek regular feedback to ensure that we are delivering the value that our customer envisioned.
Second, it reduces the risk of investment. With the user stories in hand, product owners will be able to determine which stories provide the most value so that we know which ones to focus on first. With estimates applied to the user stories and regularly reported progress, the risk to the deadline can be quantified with actual numbers instead of the traditional gut check. The effect of any scope creep to the project timeline can be visualized and explained to stakeholders. Any potential delay is known at a much earlier date, which allows us to take the right approach to course-correct.
By seeking feedback on a regular basis, we reduce the risk that time was spent with an incorrect understanding of the customer’s needs. By spending the minimal amount of time possible and getting our progress in front of a stakeholder, we can gauge whether the application is moving in the right direction and either continue down the path or change direction with minimal impact on the timeline.
Using the tools created for this process, everyone can be sure we are providing valuable software that solves the challenges that our customers face in a timely manner. Software development shouldn’t be a sit-and-wait process, but a partnership between developer and customer to guarantee the most valuable return on investment.
Chris Jenkinson is Senior Software Engineer with MHI Member FORTE. #forte
