Why Agile and DevOps suck…

There’s no doubt that Agile and DevOps practices have some serious issues in our industry, especially at large enterprises. Let’s take a look a quick look at why.

The genius of another project...

Typically someone in management has an idea for a project. They then spend the next few months convincing their peers to allocate budget for the project based on a fixed scope and timeframe, to which their performance is tied.

Most of management think of agile as scrum, so next a Project Manager (PM) or former PM is assigned as a Product Owner (PO), a Technical Lead or Business Analyst (BA) is assigned as a Scrum Master, a few Developers and QA/Testers are assigned as part of the development team and a Solution Architect (SA) is assigned to design and govern the overall architecture.

The project kicks off. Now the real fun starts...

Because the project (and PO’s performance) is primarily based delivering the scope on time and budget the PO resorts to traditional ways of managing the project. They fear the consequences of disappointing stakeholders and senior management so they try to be all things to all people and overcommit.

This all but diminishes the Scrum Masters role, forces the development team to work towards unrealistic deadlines and eventually turns most of the Scrum events into status meetings. As a result the development team sacrifice quality and accumulated technical debt, delivering buggy software.

Concerned about the quality of the development the PO gets the SA to review the technical implementation of infrastructure components and code. The SA identifies poor configuration and coding practices, and also that the development team have not thought about how the solution will be deployed to the Production environment.

While the QA team are working in the team they are only involved in the process once the developers have finished coding and have limited interaction with the PO. This being the case their understanding of the PBIs is limited also and due to time constraints the developers are not producing unit tests, regression tests are still being completed manually, and non-functional testing are been determined as out of scope.

So how are we going to release this to production...

At this point the SA reminds the team of the enterprise standards that all projects need to adhere to before deploying their solution to a production environment. Typically this includes having the Security Team complete a static code review and penetration testing the environment, as well as having the QA team complete the non-functional and fail-over testing.

The only other thing to mention in this scenario, is the PO is often not empowered to make decisions but rather acts as a Proxy PO to senior management.

Does this sound familiar...

If this situation sounds familiar you might be wondering what can you actually do about it. Well the truth is that you have two options; cut and run, or dig in and except that the change is going to be slow. When you cut and run it is worth noting that the grass is not always greener and should you end up in another large enterprise, it is more than likely you'll end up in a similar situation. 

If you dig in, be prepared for the long haul; a never ending shortage of people based challenges. In saying that, the best opportunities for growth are the most challenging. When taking this path remember that you are trying to change management styles that have existed for decades so be patient, think about the big picture, create transparency and visibility of issues and constraints and enjoy the small wins. Rome wasn't built in a day.