The Rust-Covered Iron Triangle
15 years after the agile manifesto and well into the DevOps movement, too many project managers are faithfully using antiquated processes to address challenges in a rapidly-changing world. Satisfied to continue a long track record of delivering uninspired, costly, stale-on-arrival software projects while telling business sponsors to pick only two qualities from a rust-covered iron triangle. It's not surprising that when confronted with process disruption, these traditionalist have become as inflexible as their tool-set.
"We shape our tools and afterwards our tools shape us." - Marshall McLuhan
At a time when organizations should be leveraging Continuous Integration techniques to remove humans from the release pipeline, they instead, add layers of approvals and "quality gates" to ensure the opposite effect. Throw in a group of Business Analysts to translate english requirements from product owners to the english speaking development team, make sure configuration instructions are typed into a ticket by one human so another can execute them and don't forget a review board staffed with senior IT managers to approval all production changes. After all, history has proven extra humans enhance quality.
When we send humans to do a machines job, eventually mistakes will be made -- like losing $460 million in 45 minutes.
With 77% of enterprises already practicing modern DevOps and supporting methodologies like agile/CI, what is holding back the late adopters? Comfortable market share, leadership echo chamber, a change-adverse organizational culture or just a high tolerance for pain?
Whatever the reason, when your competition can deliver value fast, cheap and with high quality it may be too late to catch up.
I believe organizations need to move towards CI but as you know it takes time to ge there. Automate as much as possible to eliminate the human error factor. Delivering quality releases into production will prove to the slow adopters that CI works and those barriers will be removed.
This only works when there is true faith in the development team to deliver quality at the dev level. Once that is achievable and the incorporation of certain automations are in place such as unit and QA testing then this is achievable. Process is usually in place to fix something or some people. When there is quality at its lowest level and every level thereafter then there is room for this which is ultimately the goal. Time to market becoming less and less.
The Iron triangle still applies in Agile just as much as it does with Waterfall. In Agile you are fixing time and resources in short iterations and the scope is always variable. The only way the Iron Triangle will ever go away is if you can get the organization to agree to give you a blank check on time and resources to accomplish the scope they eventually want. I just don't see that ever happening in most large organizations. Senior executives will always demand an answer to 2 questions - How long will it take and how much will it cost me? CI hangs off your ability to automate and makes a lot of sense when you have a relatively homogenous code base/application set with a large user base. In a lot of enterprise environments though you have the opposite situation - relatively small user bases and a large sprawl of different applications and platforms. In those cases the cost of getting to CI is enormous and it doesn't make sense to have a one size fits all approach. When you see a stat that 77% of companies are using dev ops, CI and Agile methodologies it rarely means they are doing it everywhere or that it is being done in pure form. Most companies are hybrid shops with some Agile and some Waterfall processes going on.