In our previous blog, we defined what we mean by Digital Service Delivery. Delivering these solutions to our stakeholders and customers is hard and the overall industry success rates are dismal. Before explaining how to avoid these challenges and uncover how to be successful with Digital Service Delivery, it’s important to understand what makes Digital […]
In our previous blog, we defined what we mean by Digital Service Delivery. Delivering these solutions to our stakeholders and customers is hard and the overall industry success rates are dismal. Before explaining how to avoid these challenges and uncover how to be successful with Digital Service Delivery, it’s important to understand what makes Digital Service Delivery hard in the first place. The reasons are many, but some of the most common problems are below. Do any of these sound familiar?
After months and months of coding an application, the team declares it done (but still needs testing). The application is passed on to the testing team to begin integration testing. Of course, the testing team discovers that nothing is working. A lot of the initial findings are setup and configuration issues, and after several weeks of figuring things out, the application is finally up and running in a test environment. Now the testers are going through their manual test scripts and are reporting bugs and thus begins a long cycle of testing, debugging, fixing, testing, and debugging again. At this point, the project is already behind schedule and the number of bugs being found is high. The focus shifts to only fixing the critical and high severity bugs in order to be able to get the application to a production ready state.
After fixing all the high severity bugs, the application is deemed production worthy and it is passed to the deployment team. The team now spends months and months prepping and configuring the production environment and trying to figure out why what is working perfectly fine in the test environment is not working in the production environment. Basically, it’s a repeat of the cycle that the test team went through to get the application running in the test environment.
Even though we spent a month testing, due to prior delays in schedule, testing is always cut short to make up for the lost time. Additionally, the capacity of the testers is limited due to the fact that most of the testing is done manually and the testers have to test and re-test after every change. Between developers not properly testing their own code, testers having limited capacity to do proper functional and regression testing, and by a short testing cycle short – the resulting end product is of poor quality with a lot of bugs slipping through to production.
After going through this very long and painful cycle of product development and finally delivering the application to production, the team discovers that the client is not satisfied with the solution delivered. Not only are there quality issues, but the solution delivered does not properly address the client need. Some of the features delivered are no longer needed, are hard to use, or are incorrectly implemented from a business perspective.
The combination of these pain points leads to long concept to deployment cycles and results in unsatisfactory solutions and unhappy clients. It also makes a team’s ability to respond to market conditions and the changing needs of clients very slow. Many organizations have looked at Agile processes to help overcome some of these problems and in our next post, we’ll take a look at the true value proposition that Agile brings.
Top 4 Challenges with Implementing Digital Service Delivery is the second in an 8-part series “Succeeding with Digital Service Delivery” from Excella Software Development Lead Fadi Stephan.
Part 1: What is Digital Service Delivery
Part 3: Is Agile the Answer?
Part 5: Lean Discovery Practices
Part 6: Agile Delivery Practices
Part 7: A DevOps Mindset
Agile experts think great product owners act as entrepreneurs for their product. Product owners and...
You are probably familiar with some form of the following: Should we be using story...