[Editor's note] Software development and procurement professionals often have questions about existing software development methods, techniques, and tools. In response to these questions, Kevin Fall organized five software topics: Agile at Scale, Safety-Critical Systems, Monitoring Software-Intensive System Acquisition Programs, Managing Intellectual Property in the Acquisition of Software-Intensive Systems, and Managing Operational Resilience. The first article in this series focuses on the issue of Agile at Scale. This article is compiled by OneAPM engineers:
There will be a series of articles to introduce best practices related to these 5 topics. The first set of articles is divided into two parts, introducing the challenges in scaled agile development and summarizing 10 best practices. Due to space limitations, this article only introduces the first 5 of the 10 best practices, and the next article will introduce the remaining 5 best practices and 3 suggestions in the process of applying these best practices.
Challenges of scaling agile development
The concept of agile development has been widely used over the past decade and has also enabled software development teams to create better software. The main reason for this effect is that the agile development method can improve the transparency of the project progress, and users can also foresee the prototype of the product very early and communicate with the development team. However, achieving business goals is far from being as simple as developing good software. However, if you want to scale agile, you must first focus on the following aspects:
1. team size
Just imagine, what is the effect of agile development methods applied to a development team of more than 100 people? When this development team needs to cooperate and communicate with other departments in quality inspection, integration, project management, market operation, etc. to ensure the smooth delivery of products? Usually, agile development methods such as extreme programming are only suitable for small teams of 7 to 10 people, while large teams need to be divided into several small teams and need to cooperate with some non-developers. There is already some research on how to better address the collaboration problems that come with team size.
2. system complexity
Typically, large systems include more features and new technologies, communicate and integrate with other systems, and cater for the needs of different user groups. Need to figure out whether there are real-time, reliability and security requirements, and who are the stakeholders. Often complex systems require rigorous validation, which complicates rapid iteration in agile development.
3. Project planning
How long has it been used for system development? How long is the system maintenance cycle? Large systems typically require longer development and maintenance times than systems for which agile development is applicable, and require attention to possible changes and redesigns, and may be required to deliver different versions. Knowing these can help you decide what is the most important measure of project success for the project.
Best Practices for Scaled Agile Development
Every business situation is different, so how to apply these best experiments will need to judge whether it will benefit the business. Pay particular attention to the business purpose, existing processes and corporate culture of the enterprise, as all practices have their limitations and there can be no such thing as a panacea. It's best to choose these best practices so that they work with each other, and make some adjustments based on the actual situation of the enterprise.
1. [Teamwork][1] is the first priority
Scrum is currently the most widely used agile project management method. Simply put, a Scrum development environment requires only one Scrum team. This team needs to have the knowledge and ability to describe requirements, system architecture, design, code, and test.
However, after the scale and complexity of the project increase, a single Scrum team may not be able to meet the development needs, and then different small teams should be divided according to system features and services. If you have decided to use a project management method such as Scrum for a project, you can also use the Scrum method to manage each Scrum small team. This requires an additional collaborative team that has two responsibilities: one is to determine the information exchanged between teams, which is to resolve inter-team dependencies and communication issues. The second is to analyze and resolve collaboration issues and potential risks between teams. The members of the collaborative team usually come from various development teams, so that the members of the collaborative team can understand all the functions of the whole project, and there may also be some professionals involved in user interface design, system architecture, testing and deployment. This collaborative team facilitates the communication and sharing of goals, issues, and risks across development teams. But beware when the collaborative team itself grows larger.
2. Use [Architectural Runway][2] to manage technical complexity
Stringent security requirements and mission-critical requirements add technical complexity and risk. If a task cannot be completed in one iteration and cannot be broken down into smaller tasks for multiple teams to perform in parallel, this indicates that the task is technically complex. To address technical complexity, administrators must address the most important software architectural features early in the project, sometimes even raising the issue to the level of the entire enterprise, such as for infrastructure platforms or product lines.
Agile development calls this the Architectural Runway. Its purpose is to provide a relatively stable base for future iterations. Having a relatively stable base is important for multiple teams. The architecture of software can determine the importance of system features and thus their priority in development. By defining an Architectural Runway and extending it during system development, development teams can prioritize features in the Architectural Runway to meet user needs.
Architectural Runway can also help development teams identify technical risks early in a project and avoid technical complexity issues. In addition, system quality requirements such as security, availability and performance are determined as early as possible, otherwise major changes may be required or project delays may occur. When developing system functionality, it also increases the certainty that the functionality needs to be delivered if the required infrastructure is already in place.
3. Based on the combination of [feature development and system decomposition][3]
A common practice for agile teams is to implement a feature in all components of the system. This allows developers to focus on completing features that make sense to users, rather than waiting for other people's development to complete before they can proceed. This approach is called "vertical alignment" because each component of the system that implements this feature is developed independently in each team. But the decomposition of the system can also be horizontal, which is mainly based on the architecture of the system. This method is mainly used for some general service providers, because they can be reused more.
Whether developing for features or decomposing the system horizontally, the purpose is to arrange the development team according to the decomposition of the system and decouple it to maintain progress. When it is necessary to maintain a balance between agile stability and progress, the strategy that can be adopted is to first develop a platform for common services, and then quickly perform feature-based development in the form of plug-ins on this basis.
4. Use [Quality Assessment][4] to determine architectural requirements
Scrum focuses on solving feature problems faced by users, which indeed plays an important role in the success of the system. But when the focus is entirely on functional features, architectural requirements are often overlooked.
The advice here is to collect, document, communicate and validate potential system quality requirements when developing the Architectural Runway. This is especially important for large systems due to their long maintenance cycles. Quality requirements should be assessed early in the project to determine which architectural requirements should be met as quickly as possible or what shortcuts are available to deliver user requirements.
For example, for example, a system needs to meet 1 million users. Does this mean that it will satisfy 1 million users immediately? Or is it actually just a test product now? For example, systems generally use some frameworks. Understanding the system quality requirements can help developers determine which architectural requirements have been solved by the framework. Architectural requirements must be given the highest priority when addressing changes in security and deployment environment requirements.
5. Use the [Test Driven][5] philosophy throughout the lifecycle
If this one can be summed up in one sentence, it is to write tests before development. If only normal situations are considered in the development process, then later on, there will be an over-reliance on testing to find out what was overlooked in development. To avoid this situation, exceptions should be considered during development. If you can write your tests first, using test-driven development or acceptance test-driven development will make the other practices we recommend more productive.
Link to the original text: [10 Recommended Practices for Achieving Agile at Scale][6]
[1] http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=87764
[2] http://www.scaledagileframework.com/architectural-runway/
[3] http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=87764
[4] http://www.sei.cmu.edu/architecture/start/reasoning.cfm