By Roman Pichler
Let’s face it: for most of us, the term standardization has a negative connotation. We think of rules that are strictly enforced, procedures that must be followed, no matter what. This article tries to put a different perspective on standardizing software development activities. It focuses on a Scrum team making a conscious decision on how its team members create software, thereby fostering effective collaboration.
At Toyota, value creation is optimized by removing waste from the value stream. Defects are a prime example of waste. Defects are created when a task is not properly performed or is accidentally skipped. To prevent defects, minimize variation, and ensure a smooth work flow, Toyota standardizes the work carried out: the same tasks are performed in the same order and same way by every worker. Common work practices serve another purpose: they allow workers to collaborate effectively and cover each other’s work. Following a standard, workers become more effective at doing their work: once we get into a routine, we can do things quicker.
How can we leverage the benefits of standardization and apply them to software development? To start with, we must be clear on two things. First, software development is creative work that generates beneficial variation and involves non-repetitive tasks and experimentation, for instance in form of spikes or prototypes. Second, standardization that is forced on a Scrum team violates the team’s self-organization. At the same time, my experience working with Scrum teams shows that the team members have to adopt a common way of working to collaborate effectively. How can two people pair well if the team members have not agreed on coding standards and other development practices, such as test-first or continuous integration? And are there not some software development activities that are repetitive? Using Test-Driven Development for instance, we carry out a standard task sequence: we first write the unit test; we then implement the class to make the test compile, fail, and succeed. Finally, we may refactor the code to enhance its extensibility.
Often, teams create their own standards over time. Pair programming helps team members to explore different ways of working and to eventually converge on common practices. Sometimes, though, teams can benefit from a facilitated decision-making process that leads to embracing common work practices, for instance, when the team needs to become productive very quickly, the team members have not worked together before, or the team is new to Scrum and is struggling to deliver a potentially shippable increment at the end of each sprint. Note that the team’s ability to agree on standards and norms may be affected by team dynamics. A team caught in the storming phase is likely to struggle to quickly agree on common work practices.
Standards should be developed by the team and not be pushed onto the team. Anyone who feels forced to adopt a new way of working is likely to resist the change. In order to create an awareness within the team of how different ways of working affect the team’s performance, techniques such as pair programming, videotaping team members working together, or simply making a conscious effort to observe each other’s way of working are useful. The team should then analyze the degree of variation, discuss its impact on its ability to transform requirements into working software, and identify and agree on improvement measures. Carefully facilitated, the team will end up standardizing its own work. Retrospectives provide a great opportunity for the team to reflect and monitor how effectively its members collaborate and how common work practices are used.
Depending on the team member’s experience with agile development practices, it may be helpful to involve a mentor to teach the practices, ideally through pairing. Agile development practices such as test-first can be counterintuitive and difficult to understand at first. At Toyota, it is the job of the supervisor or team lead to train employees in standard procedures, by the way. As the ScrumMaster, you need to watch out for any impediments that prevent standardized work and ensure that these are swiftly removed. Otherwise, the team members are likely to disengage from the process and revert back to using their own non-standard work practices.
References
- Ballé, F., and M. Ballé. 2005. The Gold Mine: a Novel of Lean Turnaround. Lean Enterprise Institute.
- Kaner, S., L. Lind, C. Toldi, S. Fisk, and D. Berger. 1996. Facilitator’s Guide to Participatory Decision-Making. New Society Publishers.
- Liker, J. 2003. The Toyota Way: 14 Management Principles From The World’s Greatest Manufacturer. McGraw-Hill.
- Reinertsen, D. 1997. Managing the Design Factory: A Product Developers Tool Kit. Simon & Schuster Ltd.
