Seven ways to get you to see Agile practice

For the concept of agile practice, perhaps a lot of people are not very clear, in fact, the experience of agile practices and pitfalls can be divided into the following seven aspects: characteristics of the team, people, waste, local optimization, software quality, testing automation, process, we will come together to comb the seven aspects for your reference.

Feature teams (Feature team)

It's a long process to achieve a real feature team in your organization, when a local end-to-end group is implemented in an organization, the evolution requirements of the larger End-to-end group appear, as the new bottlenecks in the organization are displayed, which is why agile does not solve the problem. But one of the reasons that makes the problem appear more obvious.

In the restructuring of the organization, the product has a very large old code:

1. The functional tests included in the early feature team were not complete, and external testing was important for the protection of these feature team;

Over time, Feature team for their own Feature automated testing and improve the testing capabilities, released to the external product quality will be greatly improved;

2. There will be many dependencies on external groups, especially in different countries, and the waste of communication, handover and waiting will be great;

3. Development and testing bottlenecks are more pronounced when reliance on the development and development sectors of the product is reduced;

4. When the dependence of various functional departments in the product is reduced, the bottleneck between products and products will be highlighted.

Imagine how many processes are required from the customer's request to the final submission function, especially in large organizations, end-to-end means more than a dozen processes or more, and how many of these processes in the Feature team means how flexible the Feature team is, Agility is essentially about reducing the cost of interdependence, waiting, and passing.

An organization is a huge system, the Feature team transition process means reducing the limitation of the entire system.

In the process of evolving to the feature team, breaking the original more than 10 or dozens of component team into a new feature team in relatively short time, the risk is that:

1. Group maturity: maturity requires time and some wrong costs;

2. Long-term growth and short-term project plans for the group: relocation of groups familiar to a particular field for the project's progress;

3. Efficiency of the organization's output: How to rationalize the use of existing experienced and new recruits, the basis for building new structures will reduce the overall efficiency of the organization's output;

4. Uncontrollable and disorderly: how to make these groups of High-quality release products in the transition process become uncontrollable.

The balance between ideal and reality is a problem faced by the feature team, and drastic changes mean severe pains.

People

Our transformation is based on the SCRUM+XP approach, the impact of the transformation is enormous, the previous existence of many positions, titles will face changes or even disappear. For example, project managers will no longer be able to focus on project management, and the sequencing of product requirements is also managed by the former project manager into the product owner. Even the most basic developers and testers, their day-to-day work style and the scope of their responsibilities are also facing great changes. This also means that the transformation may encounter very big resistance, human nature will resist the unknown change.

The transformation of a platform department is particularly special, the leader of the research and development is firm, and after the initial pilot success, the organization structure reform is drastic, as if all the project managers disappeared overnight. In the past, the decentralized testing team and development team around the functional modules have been reorganized, and each scrum team has several developers and testers from different functional modules, which, in some ways, are the embryonic form of the Cross-functional team we are advocating.

The loss of all forms of personnel has caused great hardship, leaving the company for personal or family reasons, as well as getting jobs on the newly established product line, and others being promoted. But all this caused the original position of the skilled loss, especially the test of the flow of related personnel, was a great hidden danger. In previous research and development models, tests were strictly divided into multiple tiers, performed by different test departments, and communicated with each other through high-level engineers and documentation and process systems to ensure that testing at all levels was implemented. The new organizational structure, in addition to the Scrum team, is the system testing team, and the convergence between Scrum Team Test and system testing appears gray area, because each other's responsibilities have different assumptions, but not found and resolved.

There were people who embraced and opposed "agile" at the time. Interestingly, in the internal forum, we belong to agile strong supporters, and like to talk or debate, so it is the focus of the forum, the target. Many and many debates have been held, and of course most of them have gone nowhere. I think these discussions, as well as the many discussions that take place in the workplace, are very good for private communication and can help people understand this change at a time of change (even pure complaints are not worthless).

The key to organizational change lies in full communication and practical implementation. It doesn't matter if there are different voices, the key is to clarify and solve their doubts, because without everyone's understanding and approval, change is difficult to achieve practical results.

Waste

It's not uncommon for people to work overtime, but it would be even more unfortunate if something so hard did not really come in handy. The Platform department has been hard at meeting deadlines for an important release, and according to customer-submitted defect reports, some of these features are not being used after this important release, but only after subsequent releases.

The platform department is not directly oriented to the end customers, but also need to combine the upper layer of the network element application can really produce results. The conventional pattern is that the network element has a series of customer requirements (with very large granularity) in the segmentation of the system platform requirements, passed to the platform Department of the project Management. There has been a situation, the platform departments out of the submission of functional characteristics, due to the network element application can not be developed in time, and can not be submitted to the customer use.

There are a lot of questions about whether we are doing what we should do (functional characteristics), and how much of it is wasted. The idea of scrum is to prioritize user needs, but some of these key points must be paid attention to, otherwise it is easy to become a mere formality and can not benefit from it, first, to the needs of the appropriate granularity, the team will be able to continuously submit high-priority functional features, demand granularity is not small enough, If there is only one item in the product backlog, then whether it is a PO or a sale or a customer has no choice; second, to gradually achieve the real end-to-end level of demand for the development, management; third, development team and PO (to be able to communicate better with end customers, users) There is frequent communication between the functions of the finished product display, so you can use feedback to improve and improve the development of follow-up functions.

Local optimization

There are words "not afraid of the enemy like God, just afraid of the same team-mates", in fact, do software is also afraid of is not to a place to make. But to say back is really not everybody does not work hard, but to this "one place" view different. Focusing on the achievement of their goals does not guarantee that these efforts will overlap to achieve that "common" goal, and that local optimization may turn out to be a collective one. This kind of phenomenon, the organization all levels have. There is a situation within the team, between the team and the product line.

For example, within a team, due to the lack of habit of the new features of the transformation process team work, within the team is still quite a few distinct development, testing each of the people, since a choice of work, the beginning of the iteration, each of their own task selected to go, and then the whole iteration stared at their own three points to work hard. The problem is that the team needs to be responsible and committed to the incremental software that can eventually work, and such a pattern does not guarantee delivery at the end of the iteration.

The same is true between teams, in order to make their team work more stable, work more focused, the team also required to identify their areas of work, the iteration is some simple and rough to reject many assistance for defect analysis of the request. The result is that the work of defect analysis and repair becomes very difficult, and many of the potential flaws that have not been identified are abandoned for tracking and reporting.

In a larger scope, we have completed the development of the transmission platform is not enough, to be able to produce customer value, but also the upper level of the application software system. But our systems engineering team, the Scrum team, the system domain Test team, and the finished teams, such as the top development team, the functional testing team, the release Test team, and the system testing team, although all are working to improve their performance, the problem is that these partial, one-sided optimizations are observed at the organizational level, The impact on end customers is minimal and even side effects.

The key to agile and lean is here-focus on the value that is generated and remove unnecessary waste. Improper local optimization is also a waste, we need to have the ability to think systematically, look at the problem as a whole, and then improve performance. The build feature team is the beginning.

Software Quality

Software quality is a common problem in many organizations, and any change means that the quality is reduced and then restored to the original, and then become a better cycle than before, in our organization or inevitably experience such a cycle.

In an agile transition, if the risk of these qualities is not well considered, then eventually it will be brought to the organization of the future for a long time "pain", the burden of "debt" needs a lot of cost to repay, the result will be the customer satisfaction and trust will have a great impact.

In quality issues, we usually think there will be three types of problems: old code problems, new feature development issues, and new problems introduced by the change problem.

The legacy quality problems of old code are usually relatively large. A large system, any changes may affect the old code problems, or the old code can not meet the needs of the current needs of the adjustment, often these changes or new requirements will affect those places are often difficult to define, for the old Code Test automation protection is the key.

The problems associated with new feature development are often the result of compromises on progress pressures, a rush to complete the content of the current iteration cycle, or the need to delay the current iteration cycle to do more testing. Agile development Patterns make the original Long-running project progress and project quality contradictions appear in a shorter cycle (4 weeks).

One of the biggest advantages in agile practice is rapid quality feedback. Due to continuous integration, continuous regression testing, quality feedback will be within 2-3 days or even 3-4 hours feedback to the code submitted by the software personnel.

Of course, this kind of quick feedback is based on the level of continuous integration, the most perfect situation is certainly the entire product of all the tests are put into continuous integration, then the overall software will have a very comprehensive quality considerations.

Automated testing

Test automation is seen by many as one of the cornerstones of agile, and many agile practices rely on the degree of automation, such as continuous integration. To realize incremental development, we also need to be able to perform regression testing quickly and comprehensively, to confirm that existing functional features are not affected by the development of new features. Our product line has started experimenting with test automation before making a high-profile transition to agile. A dedicated test automation team operates automated test tools developed by Finnish experts over a period of more than half a year to automate the set of regression test cases that perform very high frequencies. Based on the successful experience gained from this project, the concept of test automation is widely disseminated, and this practice is also beginning to be attached to the Test team as a basic requirement, and automated test cases account for the proportion of all test cases as an indicator to be closely watched by top managers.

There is a lot of debate around test automation when it comes to agile transitions, and the main focus is on whether to pursue 100% of test automation. Both the opposition and the supporters have their reasons, they are difficult to compete, and different ideas have followers in practice. Proponents believe that automated testing can save execution time and can be performed at night and on weekends. Opponents argue that automating the use cases consumes most of the time for testers, and that some of the comments from the grassroots do not have the time to actually test the system, and that some use cases are very difficult to automate, or very expensive. And the latest situation is that in a new release plan, the cost of testing automation in total hours of calculation, then it is necessary to implement 100% test automation?

In my opinion, it is important to test automation and its proportions as a hard target to the team, resulting in the team not to take into account the quality of testing automation. The quality of test automation will affect the length of execution time, the cost of maintaining automated scripts, and the accuracy of testing purposes. Another reason is that knowledge, expertise in test automation, too few experts with a wide range of application test automation experience, and often the ability to implement specific test automation cases, are too busy to impart, mentor, and train other colleagues ' test automation skills.

Process

In the process of agile transformation, if you think that the process can be discarded, you can follow their own ideas to do development testing, such a concept will be a big mistake.

The process is the process because it is carrying a long time accumulation of experience and lessons, it has been proven effective way, how to do something to achieve the best effect and efficiency, and in many years of practice has been continuously supplemented.

For example, peer review, our misconception is that people will automatically organize peer review spontaneously, you can use the development team's own way. The old peer review tradition has not been well followed, especially in the organization of large-scale expansion. The result is our need to design code more problematic than ever before.

such as testing, organizing large-scale adjustments, but the corresponding test in the new organization of what kind of plan, how the test is performed in the new development group, how it is most efficiently tested, the differences and coordination between the development team's test and the external test, and the overall layout and adequacy of the end-to-end development process. Our misconception is that these problems are gradually becoming aware of this lack in the long period of time, and then gradually improve.

Xu Yi, the Nokia Siemens Network, is a lean and agile consultant specialising in agile migrations for large organizations (more than 500 people). Proficient in various styles and types of black box testing, including acceptance test drive development, exploratory testing, test automation, etc.

The author Wang Yu, Nokia Siemens network as Project Quality Manager, the main responsibility is to help development Department quality and process improvement. Work experience from Test engineer and test quality engineer to team leader and project quality manager. Having experienced the entire transformation of a large organization, there are some personal insights into agile, scrum, and all the processes in the organization.