Long before agile software development started to mature, LSG leader Alan Sheppard recognized that there were significant challenges in the way things were done. Organizations struggled to create and manage a product when trying to balance the software developers’ approach, the business expectations, and the conservative risk managers’ requirements. Too many people couldn’t see eye to eye on how to approach and address the engineering of a large mission-critical product.
Some software developers had shiny object syndrome and never finished what they started, despite starting many tasks. Other developers could not adapt to the varied skills of their peers.
Some business owners or leaders just wanted it done, regardless of whether or not “done” was feasible. Others in the business world truly never knew what they really wanted done, and the right visionary people were too high up to get involved.
Some wanted every pre-defined feature and/or requirement available plus all sorts of new requirements. Those new requirement requests typically came as a result of developers explaining a perceived bigger, better, cooler way to do something.
In the midst of all these different expectations and approaches, the key end users often worried that the system would no longer be funded after the initial go-live, so everything would have to be rolled into one opportunity. Back then, the mindset of having multiple, ongoing opportunities didn’t exist.
Most expected the design phase to be a one-time start-stop effort, yet parts were moving all over the place during the entire project.
Then there were issues with accountability where stakeholders would blame the software developers if anything went wrong instead of focusing on measuring progress and quality. And if something went wrong, software developers would blame the end users for miscommunication about the requirements.
As the project continued, tensions would rise in the development team due to irrational constraints from a list of hopes and wants that conflicted with hard deadlines and limited funding.
Back in the late ’90s and early 2000s, IT software projects took big hits due to poor poor project management and software development processes. People in the industry learned many extreme lessons, yet some of these same obstacles still have to be addressed today.
LSG has been pro-agile and pro-scrum development since 2007, and we work closely with all of our clients to create clear expectations and efficient implementation of software development projects.No tags for this post.