Some Agile pundits claim that Agile does not need either pre-analysis or architectural input. Agile benefits from both. Anyone who has managed large programmes knows that there has to be an overall architecture, the deliveries from each project need to fit together and be delivered in a co-ordinated manner – the dependencies between projects demand this. This is part of the architect role.
Analysis is more subtle. At one extreme simple Agile projects can be done with no prior analysis – the analysis can be done “in flight” having developers working with subject matter experts (SMEs) to define the requirements – coding directly.
This is not very efficient where parts of the application are not simple – say involving complex calculations. Taking as an example calculating someone’s pension, the calculations (algorithms) have invariably been coded before and have undergone not just testing but years of deployment so that they are trusted. They may have been coded in an old language. Where such complexities are known to exist it makes sense for there to be a short analysis phase prior to the Agile project starting to identify the islands of complexity and how they are going to be tackled. One option is for the calculations to be left alone and “wrapped”. This is safest but may introduce performance or perpetuate maintainability problems. An alternative is to re-implement the algorithms using a modern language (e.g. Scala).
Since Agile projects are usually working to a fast delivery schedule it makes sense from a quality perspective to ensure that the difficult bits (the Slartibartfast code) are not rushed. They should therefore be set on a different track and the pre-analysis stage used to ensure that all the requisite information is gathered before the Agile project starts. Tools for analysing existing code such as Empear are a valuable part of Analysis.
Defining the “islands of complexity” is one area where pre-Agile project start analysis is useful.
A second area is where changes to the (UX) User Experience have an impact on operational processes.
A good example comes from fashion ecommerce, which is where the most complex and critical UX issues arise – a fraction of a percentage change in conversion rates can make a big difference to profitability. Before buying a customer needs to know whether their size/colour is available and if not when it will next be in stock (a pre-order). The ecommerce company needs to know their warehouse stock, what stock they have in-transit to stores and in-store, and when new stock will be available and how accurate that information is. Was it accurate last night or 2 minutes ago. Getting this right is good. Getting it wrong is bad (and costly). The analyst needs to understand what is good from a business perspective, what changes need to be made to operational processes, risks etc. and to work with the architects to decide what is possible in what sort of timeframe.
Using the fashion commerce example again, suppose that the size/colourway is available in a store 10 miles from the customer. Do you ask the customer if they want to order it and collect it? If yes, you have made a sale. There are other options (e.g. ship-from-store) but each has a cost and an operational impact/risk that needs to be assessed, as well as an impact on the UX (User Experience) design. This work is best done by the analyst in pre-start phase. The alternative is that they are “discovered” during the Agile project and left to later. This is less efficient. Good new process can increase earnings, so do it sooner.
The reality is that UX is a team issue, the analyst and architect are intimately involved and more importantly the process by which the UX is determined needs to be Agile. One way of doing this is to give key stakeholders a weekly review. This in turn has implications on the development process – it presumes continuous integration/deployment.
UX in a global context is very difficult and multi-cultural teams are needed. Although the UK is one of the most multi-cultural countries on earth it is hard to find all the skills here (Xerox had an excellent team) so getting UX right adds complexity to the development process.
Agile projects tend to have small teams. In Scaling Agile it is critical that an overall architecture is maintained and this especially pertains to code reuse. Organisations that have lots of complex code need to embed processes for sharing that code, ensuring that the code for a complex calculation is only written once and maintained centrally. This is a problem where there are many teams, geographically distributed. Microservices are one potential answer – very much like NAG routines with added encapsulation.
Identifying which Agile projects need pre-start Analyst effort, and who should do it is part of the chunking process.