With All the Planning in Place - the Project Still Failed
With All the Planning in Place - the Project Still Failed
Zone Leader, John Vester, talks about being a part of a project structured for success, but in the end the project was filled with the all too common pain points.
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
Have you ever been part of a project - which started well before your introduction to the project - and wished you would have been around when the project was initiated? Often there were unfavorable decisions that were made at some initial point which had an impact on the work needed to complete the project at the later stages - becoming the source of your frustration. Some of the pain points I have encountered fall into one (or more) of these categories:
a technology or framework was selected, which did not pan out as expected, is difficult to work with now, and there is just not enough time to migrate to another option.
the lack of an automated test philosophy was not mandated, causing uncertainty in the code that runs the application.
code reviews were not taken seriously, causing problematic code to be pushed to the next level.
structure and design at the database level is sub-par, including the decision that was made to leverage an existing database.
I am sure many more examples could be illustrated. The point is, how often as engineers we wish for the opportunity to be at the ground level of a new development initiative.
There were several Agile teams, working on different aspects of the application. Each team had full support from the business, including a dedicated product owner. In short, the effort was intended to avoid those pain points so many had experienced over the years when becoming a part of an existing project team.
The Unexpected Result
At first, things ran smoothly. There was excitement across the teams, evident in their enthusiasm when demonstrations were presented during the end-of-Sprint meetings. Those demonstrations helped the teams understand what other teams were working on, providing an avenue to avoid the creation of duplicate functionality. Weekly developer meetings were held and communities of practice (CoPs) existed to maintain communication across the engineering team.
However, a little over a year later, the project which had so much promise ended up in a state which wasn't close to the intended expectations when the teams were formed at the onset of the project. The following pain points emerged:
building the application was time-consuming, often trying to figure out why tests were failing.
changes across the teams were beginning to collide with each other, from a deployment perspective.
the Java API become very bloated to the point where one monolithic application was being replaced with another.
the tests themselves had a tremendous amount of duplication and relied upon a specific state of data to function properly.
the database became overloaded as a result of meeting the needs of the legacy application and all the new functionality.
moving to the newer database solution was no longer on the roadmap, upon realizing the dependency on the original database design.
How Did This Happen?
In this instance, things had begun to get off track months before, based upon some decisions that were made:
the end-of-Sprint demos were discontinued, no longer providing insight across the teams.
weekly developer and CoP meetings had stopped, due to a lack of attendance - since team members preferred to keep working on their tasks.
the code review process was updated to allow teams to review their own code - which led to teams no longer understanding what other teams were working on.
in an effort to continue to push forward, code was duplicated on the test side, because it was a faster way to get the test written.
key talent was lost - either by a competitive landscape or individuals not happy with the management structure/decisions.
Basically, the teams began to work in silos, no longer staying in touch with the other Agile teams. The lack of communication and information proved to be a vital deterrent to the project's success.
As a software engineer, being a part of a new initiative is always exciting. While I was not involved with the early decisions for the project discussed in this article, I did believe that the project had a solid ground to stand upon. As with any project, there will be lessons learned, which is certainly the case with this example.
In hindsight, I believe the value of the end-of-Sprint demonstrations was a key factor toward the downward spiral that was met at month twelve of the project. When coupled with a loss of key talent on the project, the teams found themselves going in their own directions - with a goal of meeting the current needs of their customer. What further hurt the initiative was the fact that management no longer required teams to review the code of other teams. This further built up walls around the teams and the decisions they were making.
When the project was formed, the canvas was wide open for a successful application. Management provided the necessary technology and staffing to get the project on the right track. From the beginning, it was going to be the dream project. However, with all the planning in place, the project still failed. The project became no different than the many others we have all seen, throughout our career in Information Technology, that went south due to the pain points herein discussed.
Have a really great day!
Opinions expressed by DZone contributors are their own.