This is an attempt to highlight how the practice of architecture is misunderstood in most of the Agile projects & the root cause behind them – so that you may avoid them at your organization/project.
Agile has always challenged people with the age old question – how much to design upfront? But is the confusion just there? Frankly, it doesn’t even start there! Anyone understands the need of an architect, but how do we position an Architect within an Agile environment? How does Enterprise Architects work in sync with a Solution Architect? How should business leverage the niche skills of an architect to ensure the scalability of the application? And how are the architects coping with the changing dynamics of development methodology? How does this practice work in an onshore-offshore environment?
We take a look in to the current challenges & answer to all the above questions. We try to ensure that Agile delivery makes the best use of architects and architects don’t shy away from Agile world.
Flaw at Onset
If we look from the very inception of a project i.e. the phase where we visualize requirements & float the RFP, we always acknowledge that the backbone of development will always be its architecture. Now, let’s step back & try to visualize how we place our requirement to the market & how they get interpreted.
While floating an RFP – just like any project, we strive to get the final figures from the vendor. In general, any response from a reputed vendor is acceptable, but the lower figures will excite us more. True! Situations tend to get more complex – if it’s an Agile project (well, we all wish to be Agile, isn’t it) – we tend to add some bells & whistles by adding the sizing constraint as well. How? Well, we often put a request of providing dollar value to Story Points. How does that help? Ideally – it doesn’t help us anyways apart from giving us a very high level understanding on how each module may impact us from investment perspective. Continue reading “To be or not to be – Agile Architecture”