IDBS Blog | 5th January 2016
The Story for Delivering Excellent Software
As an IT company
I want to make excellent software
So that lots of customers will decide to buy our products.
This is what we call a user story; a product requirement written from the point of view of the specific individual it aims to please. Sounds like a simple story for success right? Unfortunately as stories go this one is pretty much as big as they get, so let’s try looking at the key aspects of what is being said to try and break it down to manageable pieces.
Excellence doesn’t just happen overnight. Every consumable producer probably wants to produce something that is considered excellent, and if wanting was all it took then as consumers we would never have to worry about buying second rate products. I bet though that the cautious amongst you will always go out and read product reviews before you buy something. That’s because there is no guarantee on quality. To produce something that is truly excellent you need three things:
- The right people. People make products. The right people who are fully engaged and believe that what they are making make the best products.
- The right tools. You can have the best people in the business but give them a sledgehammer to mount a picture on the wall and the outcome will not be pretty.
- The right processes. Build and test something in the right way from the start and you are less likely to have problems further down the line (just ask Volkswagen). This also gets more important the larger the organisation becomes to reduce redundant steps and pinch points that can lead to unnecessary waste.
Customers are demanding, but they are always right. As a producer you can’t dictate what it is a customer wants, but you can listen to them to understand their needs and react to them in how you develop a product. This can be both a blessing and a curse. Like a plant growing towards the light it can help a product flourish in an area that previously hadn’t been considered, or it can leave you stuck in a niche so specific that the plant will no longer grow under any other conditions.
In order to strike the right balance between these two outcomes the most important tool for the producer is feedback. Early feedback can confirm your hypothesis that the product or feature to be added will fill a genuine need. Further feedback can then hone the delivered product to meet the most important aspects of that need to ensure the widest possible customer base. This requires regular conversations with a range of potential customers and careful analysis by those leading the development to choose the correct areas of focus.
Why would someone buy a something? They have a need that is not being met by what they currently have. Why would someone buy your specific something? Your specific something meets more of the requirements of their need than competing products within the customers price range. How do you make your product meet the maximum number of customer requirements? By careful prioritisation of feature delivery. Whatever the product is there are always more features that could be added to it, to improve it given time and money, so the real trick is to deliver a product that contains the right features at the right time for your customers and accepting that you can’t please everyone.
So what we need to complete our story’s goal is the business to be set up in the right way, we need to listen to our customers and then we need to prioritise the delivery of features so that we produce the right product, at the right time. This year at IDBS has all been about trying to achieve these goals.
The shift in the development style from a waterfall approach to an agile approach has allowed us to streamline our processes to deliver our products faster and on time. The company has invested heavily in new tools and technologies to ensure we stay relevant in a fast moving and dynamic business sector. IDBS has always had great people, and the flexible nature of our new processes has allowed us to put the right people in the right places to deliver the quality expected of us by our customers.
The agile development style has promoted greater interaction with our customers through forums such as IDBS Connect and working groups set up around strategic topics, such as chemistry. Going into 2016 these interactions both internally and with our customers, will continue to grow and spread into new key business areas.
Another aspect of the shift to agile has been the dramatic expansion in the Business Analysis team within IDBS. Our job is to act as a conduit between the high level road maps and fortnightly software deliverables, the Product Managers and the feature teams. We collate feedback, write the requirements and we prioritise the order of things to be delivered.
For 2016 then everything appears to be in place for us to complete our story. Let’s go make something excellent.