I’ve been working as an engineer inside Agile Scrum teams for many years, and I’ve been reading the ideas put forward by many thoughtful experts (see extensive bibliography at the end of this article). I want to add my perspective on the key questions that come up repeatedly in relation to improving all around excellence on continuous delivery and a constant focus on process improvement.
In brief, I have found that important and subjective parameters – those that cannot be defined with respect to “the process” – are frequently overlooked, and this is a big issue. Factors unique to every individual project implementation against a set of customer needs must be called out each time for their uniqueness. If not, the team is deluding itself that they are doing everything correctly by following broad principles and best practices that are useful, but not definitive or descriptive for enabling continuous improvement.
Maturity in software engineering is currently defined by guiding models such as CMMI-DEV, and ISO/IEC 15504, which accentuate the need to always establish, manage, measure and optimize “the process.”
CMMI-DEV is a framework for process improvement to guide improvements for a team, a group of teams, divisions or entire organizations. It helps set process improvement goals, monitor quality processes and track the essential elements to achieve effective processes.
ISO/IEC 15504 is a measurement framework for Process Capability and CMMI. It describes a clear mechanism for the translation of outputs from an assessment into standard processes.
Maturity within an Agile team is only achieved when continuous improvement takes place. To attain that, the team must define work processes, as well as normalise and quantitatively manage them. CMMI-DEV and ISO/IEC 15504 process models within Agile implementation “guarantee” that the process is implemented efficiently, as dynamic projects absorb change at small intervals by mapping that change within a systematic, disciplined approach to project delivery.
But, these frameworks overlook some critical human factors. For example, the teams that develop software using the above models are directed by well-defined and rigorous processes, but there is often conflict as Agile implementation encounters the operational friction of the growing size of the software development teams. Additionally, managing a process to achieve a high level of Agile maturity and effectiveness is always a challenge because there are real people involved; and this is true irrespective of team size.
A realistic, pragmatic focus on the people, rather than the defined process, is what really delivers success. This becomes apparent when relooking at the question of defining Agile maturity.
There are widely-held beliefs such as:
- Process maturity delivers increased product development efficiency
- Process maturity delivers increased product development effectiveness
- Process maturity delivers increased product development innovation
- Process agility delivers increased product development efficiency
- Process agility delivers increased product development effectiveness
- Process agility delivers increased product development innovation
Based on my experience and wider research, I realized that some measures of Agile maturity cannot be directly measured by either a process definition or as quantifiable project management competencies. Each team adopts working practices based on its circumstances and improves those practices based on the challenges it faces. Therefore, the nurturing of Agile maturity occurs mostly through idiosyncratic capabilities pertinent to the project, teams, and development of project work with respect to collaboration, communication, commitment, upkeep, distribution, acceptance of global togetherness of teams from various cultures, and the self-organization of teams. These are the human characteristics of what constitutes a strong team outside of the framework.
It’s also useful to think about the following: do you have a good leader, a clear mission statement, good opportunities for learning and self-improvement? Does the team complement and help each other? Is there an end goal for everyone to focus on? What happens to the team when that goal is achieved, and subsequent sprints are naturally less heroic and more prosaic?
The “Agile compass checklist” can help development teams identify which outcomes they have accomplished, so that a more flexible and “human” process to define future tasks is what the team uses to decide the metrics to be tracked.
These human factors should be considered and discussed by leaders, product owners, teams and managers every time – because the answer won’t be found within the CMMI-DEV, and ISO/IEC 15504. It’s up to the team to drive continuous improvement.
Here are some of the papers I used as a reference, in addition to my 8 years of work experience in Agile project implementations:
- Kohlegger, M., Maier, R., and Thalmann, S. (2009). Understanding maturity models results of a structured content analysis. In Proceedings of the I-KNOW 09 and ISEMANTICS 09. Available at http://goo.gl/hnw7uh.
- Fontana,R.M., Fontana,I.M., Garbuio, P.A.R., Reinehr,S., and Malucelli,A.(2014a). Processes versus people: How should Agile software development maturity be deﬁned? The Journal of Systems and Software, 97:140–155.
- CMMI Product Team (2010). CMMI for development, version1.3 (cmu/sei-2010-tr-033). Technical report, Software Engineering Institute, Carnegie Mellon University.
- Vidgen, R. and Wang, X. (2009). Coevolving systems and the organization of Agile software development. Information Systems Research, 20(3):355376.
- Ozcan-Top, O. and Demir¨ors, O.(2013). Assessment of Agile maturity models: A multiple case study in Software Process Improvement and Capability Determination, 13th International Conference, SPICE2013, pages130–141.
- Fontana, R. M., Reinehr, S., and Malucelli, A. (2015c). Agile compass: A tool for identifying maturity in Agile software-development teams. IEEE Software, 32(6):20–23.