The question of “How much process in Agile” is very difficult to answer. In fact while coaching various agile teams, I get these questions very frequently and these questions are being asked by all the roles of the team. Every time I give the same diplomatic answer “It depends” . In this post I would try to elaborate my perspective of “It depends”. The number of process steps in the agile mode of software development depends on the competency of team members (team experience and skills), maturity of the team, the business domain and the criticality, the management approach, trust of the team, team motivation and other similar factors.
- Competency of team members and maturity of team members How much requirement elicitation and requirement documentation to do, how much design modeling and how much detailed design document to be prepared and many other aspects depends on how much experience the team has and the skills the team members possess. In some teams where the team is very competent, just writing the user stories from the user perspective is enough for the further coding and testing and for the final release. Whereas in some other team where the team competency is not that high it needs further detailing of the user’s perspective and it needs to further have the design details until the class level details (in oo based approach). In a team which has very good skills on the design, there may be no need to detail down the Architecture further. Just having a brainstorming on the overall design modeling is enough. Team can further come up with the solution by themselves.But if the team lacks in skills on design patterns, refactoring skills to make design better then there is high probability that the design which is getting developed lack the overall perspective. The amount of documents and the amount of process depends on the competency of the team. So team should spend time in improving the competency.
- Business Domain and the Criticality The amount of review, coverage and the code inspection to be done in a mission critical system is quite different from an application system. If we need to achieve zero defects quality, then it needs high level of attention. Well, as mention in the first point, it has a very high dependency on the competency of the members which the team has. I see a pattern in various teams where there is a kind of acceptance for the level of quality, also termed as , AQL (Acceptable level of quality). For a mission critical system , every 1 defects is very costly and it can even pose danger to lives of people. So zero defects is not a choice but the requirement in this context. Another example is an online shopping system where a minor defect may not cause that much harm as the former. The level of process stems also changes based on this. Also it highly depends on the AQL.
- Trust in the Team Trust among the team members is an important factor for deciding the process steps. Some examples- Team conducts manual logical code reviews, whether records for the code reviews should be maintained. It depends on the team trust and how responsible the team is in ensuring that the team agreement is followed with the right objective. Every step in the process is added to ensure repeatability. If the team members can ensure without the records then it is good. Processes in team becomes less heavy if every team member trust on each other and completes the activities as agreed upon.
- Some mandatory practices that is recommended for the Agile Teams Simple Design, Automated Testing, Automated Inspection, Continuous Integration , Collective Code Ownership, Iterative Releases, Customer Demo are some of the practices which Agile Teams should follow. In my opinion team also should not do very detailed design if it is not required. Each team to use common sense based approach to decide this rather than written rule. If rules are there it is good but there need to be enough flexibility to change the rules.
- Not a right idea to remove the existing process, governance completely It is recommended that teams change the existing process which is working well and take a step by step approach towards adopting agile. Governance is something which is here to stay irrespective which process model we follow. Governance helps in the management visibility and attention. It is good to have governance as it ensures that there is enough mechanism in an organization to ensure that all projects deliver successfully. Agility is all about people and the amount of process to be followed also depends on the people who are doing it. Teams should use the common sense based approach based on the team dynamics, business situation and domain for defining the process. Nobody can give any silver bullet solution for this. Only best practices can be referred.
- References
No comments:
Post a Comment