Agile - when "working software" is NOT primary measure?

During one of the initiative as product development lead we (my team) implemented vision of data visualization platform. First, started visualization platform to support only Agile SDLC - many models for various scenarios, criteria for calculations, complex normalization algorithm across teams, aggregation mechanism for program and portfolio level views, etc.

Team did many POCs, build vs buy analysis, etc. Environment was very supportive for innovation and we started with ‘start up mindset’ and fast proto-typing. Release 1 - Initial Solution leveraged MEAN (MongoDB, Express.js, Angular, Node.js) stack and created working proto-type. During time to be ‘production ready’ – team quickly realized constraints (primarily in shared services & support teams) such as lack of needed skill-set. Release 2 - We adjusted our solution architecture to align with available skill-set, swapped MongoDB for Cassandra (better fit for our need of time-series data and in-house support) and Node.js for Java EE based back-end.

After successful launch, many other departments / LOBs reached out to leadership with positive feedback, potential business value, and requested to expand platform for other teams that follows traditional & hybrid SDLC. Release 3 - third major change to solution architecture and underline platform – as new data sources, more complex scenarios, data calculation and validation mechanism got impacted heavily. We did each major ‘working software’ product release within 3 to 4 months.

I believe upfront enterprise architecture (EA) could help in such scenario. Matured EA practice can guide such product development to align upfront and avoid costly rework. Sometimes associated governance slows down pace.

Getting ‘working software’ almost every quarter – was one of the key success factor in evolving and fast feedback cycle for our product. Also, the novelty of technology and jazzy UI kept many stakeholders engaged including development team. Please note, all 3 major product releases included “working software” completely aligned and accepted by product management. However, we still needed 3 major re-write of significant part of solution. Not sure, if it’s due to lack of product vision or our relatively early success led scope change.

For us, key take away were:

• Executive support is VERY important factor for success.
• Keep architecture modular so we can swap out components as we evolve. Take help from EA practice as necessary.
• Don’t start BIG – sometimes starting small (just for few Agile teams in our case) and then address new requirements per real customer feedback and need in marketplace – is better. Way greater chance of analysis paralysis when starting BIG. Basically, smaller & frequent bets have higher probability for success.
• Architecture must be scalable to address both success & failure of product launch and to evolve or pivot.

I would love to know your thoughts. Feel free to leave your comments below.

Note - Perspective expressed in this post is my own and NOT of my employer.