Agile Development Process – An Architect’s view
There are only few companies left in the world who are not following agile development methodologies. Agile is basically an iterative development model and there are many frameworks being followed in industry, for example Scrum and Kanban. Many organizations are in the process of transitioning to Agile development methodologies from the traditional Waterfall model. I witnessed project teams making mistakes in Agile adoption. Let me share some of those mistakes here,
- Agile doesn’t mean Accepting Unclear Requirements
Anyone who is aware of Agile process will say that Agile process helps to get timely and regular feedback from customers and it was not possible with water-fall model. But Agile process doesn’t recommend starting the project without clear requirements or not understanding the requirements through affront analysis. Many teams commit this mistake, they start the work with whatever is known with the assumption that it can be corrected with the customer feedback. Also, some product managers take advantage of this iterative framework by not doing their homework properly to provide clarity to requirements. They tend to keep changing requirements in different stages of development in guise of customer feedback. This is a costly mistake. Such teams keep on reworking on a feature multiple times in different release trains or program increments.
- Agile doesn’t mean Architecture design can be skipped
Agile coaches recommend developing product features as vertical slices. For example, if a product feature involves back-end code and user interface then it is suggested that both are developed together by one scrum team. This contrasts with traditional approach where back-end teams developing back-end components, UI teams developing UI components, and both are integrated during system integration phase. It is imperative that vertical slice approach is needed for getting customer feedback, but the problem lies in not completing overall system architecture design before getting into vertical slice developments. The interactions and dependencies between two or more vertical slices in the product will not be known if the system architecture is skipped. Consider house construction as an analogy, we cannot start the construction of the bathroom first because we know the requirements of it very well. We should have completed the structural design, floor planning and electrical & plumbing planning before start of the construction. Many project teams make this mistake, they don’t complete the architecture design before starting development and foolishly think that system architecture design also can be incrementally done because it is AGILE!
- Definition of Ready (DOR) and Definition of Done (DOD)
In Agile framework, software development is split into multiple EPICs, each EPIC is split into features, each feature is split into user stories and each story is split into tasks. A feature is taken for development when it meets the conditions of DOR which typically means grooming completion along with other prerequisites to start the development, for example, availability of UI wire-frames if a feature involves user interface, etc... Many teams don’t adhere to this strictly, they start the development when DOR is not fully met and later do lot of rework. They sometimes start with unclear requirements itself. Similarly, DOD is also not followed in strictly. A typical DOD involves, design review, code review, static code analysis and dynamic code analysis, code complexity checks, unit testing, code coverage and verification test automation. Many teams skip one or other DOD items and later rework on it. The scrum masters are party to this crime more often due to schedule compulsions and urge to show good velocity improvement for that PI. This is callous attitude leads to failure of this process. Teams must remember that an embedded product, especially if it is regulated industry, cannot be released to the customers without meeting all functional & performance requirements. If all stakeholders are happy seeing only metrics related to execution, then huge surprise is waiting for them towards the end of the program.
I always believed that waterfall model is good, and all those drawbacks highlighted by Agile preachers now are basically mistakes in adapting the process. It is sad to see that teams make the same kind of mistakes in the following agile development methodologies and blame the framework or process. There are more pitfalls in Agile development than what I highlighted here. Follow one process very strictly and don’t do anything just for satisfying few people in hierarchy. You can fool around the numbers for some time but not for ever because it is embedded product development.