Are the days of fragile architecture no more?
In the beginning was waterfall, and it was flawed. Then along came iterative approaches, and whilst these delivered many examples of satisfied customers and project success, could the breadth of benefits initially claimed by Agile evangelists have been a case of slight overreach? Was Agile failing to address a growing perception its interface centric approach and focus on rapid delivery chose fancy yet flaky over scalable and resilient?
Naturally, product managers were attracted to the speed with which they could excite customers with proofs of concept (PoC) that too often did not get re-factored for production deployment. The days of vaporware were gone as a working demo could be completed in the same time as a marketing PowerPoint. But is what is good for some customers good for the consumer? Many Agile practitioners I know lamented the pressure they were under to productise or deploy the PoC once the product owner had prematurely showcased it to executives or customers and over promised on delivery. The team knew the limits of the capability and wanted to rebuild with quality before progressing.
The problem was once the user or customer (paymaster) was co-located, focus rapidly shifted back to the front-end and the mindset to feature delivery. This focus on front end functionality, as if it was accepted that system infrastructure would become more robust iteratively or as a consequence of added functionality, was cause for some concern with purist Agile. Hybrid methodologies were one way to mitigate the risk to baseline quality and this approach accepted as the PRINCE2 / Agile methodology is formalised.
By specifying non-functional requirements and acceptance criteria metrics up front and enabling the team developing the architecture to remain insulated from anyone with front-end requirements until the underpinning quality was established, the project can ensure that when time and money constraints start to bite and product owners are required to sacrifice stories, quality wont suffer.
Also, the perception was Agile the methodology was focusing on doing the enjoyable things and not the harder, less alluring background and documentation work that are the foundations for resilient and high performing architecture. Past incremental points, the more demanded of the architecture, the less it meets business needs. Agile did not seem to devote enough attention to specifying, monitoring, and finding where that point was. The consequence was that Agile solutions seemed to suffer performance wise much more than their waterfall counterparts.
But has Agile finally overcome the weaknesses that kept the Agile vs waterfall debate so active. SAFe (Scaled Agile Framework), certainly adds clear focus to architecture development which will benefit the customer and consumer in the long run. Whilst all of the approach may not be for everyone, with the top level pipeline (or Agile Train) processes trying to re-spin something that was not broken and some of the terminology just a little too buzzwordy, integrating Lean and Kanban elements has certainly provided it with a resoundingly successful pedigree.
Whether you adopt it wholesale or selectively, SAFe provides a wealth of valuable business components for you to hybridise or experiment with.
Naturally, product managers were attracted to the speed with which they could excite customers with proofs of concept (PoC) that too often did not get re-factored for production deployment. The days of vaporware were gone as a working demo could be completed in the same time as a marketing PowerPoint. But is what is good for some customers good for the consumer? Many Agile practitioners I know lamented the pressure they were under to productise or deploy the PoC once the product owner had prematurely showcased it to executives or customers and over promised on delivery. The team knew the limits of the capability and wanted to rebuild with quality before progressing.
The problem was once the user or customer (paymaster) was co-located, focus rapidly shifted back to the front-end and the mindset to feature delivery. This focus on front end functionality, as if it was accepted that system infrastructure would become more robust iteratively or as a consequence of added functionality, was cause for some concern with purist Agile. Hybrid methodologies were one way to mitigate the risk to baseline quality and this approach accepted as the PRINCE2 / Agile methodology is formalised.
By specifying non-functional requirements and acceptance criteria metrics up front and enabling the team developing the architecture to remain insulated from anyone with front-end requirements until the underpinning quality was established, the project can ensure that when time and money constraints start to bite and product owners are required to sacrifice stories, quality wont suffer.
Also, the perception was Agile the methodology was focusing on doing the enjoyable things and not the harder, less alluring background and documentation work that are the foundations for resilient and high performing architecture. Past incremental points, the more demanded of the architecture, the less it meets business needs. Agile did not seem to devote enough attention to specifying, monitoring, and finding where that point was. The consequence was that Agile solutions seemed to suffer performance wise much more than their waterfall counterparts.
But has Agile finally overcome the weaknesses that kept the Agile vs waterfall debate so active. SAFe (Scaled Agile Framework), certainly adds clear focus to architecture development which will benefit the customer and consumer in the long run. Whilst all of the approach may not be for everyone, with the top level pipeline (or Agile Train) processes trying to re-spin something that was not broken and some of the terminology just a little too buzzwordy, integrating Lean and Kanban elements has certainly provided it with a resoundingly successful pedigree.
Whether you adopt it wholesale or selectively, SAFe provides a wealth of valuable business components for you to hybridise or experiment with.
