Let’s face it: for most of us, the term standardization has a negative connotation. We believe of rules which are strictly enforced, procedures that must be followed, regardless of what. This write-up tries to put a different perspective on standardizing software development activities. It focuses on a Scrum team producing a conscious decision on how its team members generate software, thereby fostering efficient collaboration.
At Toyota, value creation is optimized by removing waste from the value stream. Defects are a prime example of waste. Defects are developed when a task is not correctly performed or is accidentally skipped. To prevent defects, minimize variation, and guarantee a smooth function flow, Toyota standardizes the work carried out: the same tasks are performed inside the same order and very same way by every worker. Typical function practices serve another purpose: they enable workers to collaborate successfully and cover each other’s work. Following a standard, workers become far more efficient at doing their work: as soon as we get into a routine, we can do things quicker.
How can we leverage the rewards of standardization and apply them to software development? To start with, we must be clear on two points. First, software development is creative function that generates beneficial variation and entails 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 very same time, my encounter working with Scrum teams shows that the team members have to adopt a common way of working to collaborate successfully. How can two folks pair nicely if the team members have not agreed on coding standards as well as other development practices, including test-first or continuous integration? And are there not some software development activities that are repetitive? Utilizing Test-Driven Development for instance, we carry out a standard task sequence: we very first write the unit test; we then implement the class to make the test compile, fail, and succeed. Lastly, we may refactor the code to improve its extensibility.
Frequently, teams develop their own standards over time. Pair programming helps team members to explore distinct approaches of working and to ultimately converge on widespread practices. Occasionally, though, teams can benefit from a facilitated decision-making process that leads to embracing common function practices, for instance, when the team requirements to turn out to be productive really rapidly, the team members have not worked together just 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 could be affected by team dynamics. A team caught in the storming phase is likely to struggle to swiftly agree on widespread function practices.
Standards should be developed by the team and not be pushed onto the team. Everyone who feels forced to adopt a new way of working is likely to resist the change. So that you can produce an awareness inside the team of how distinct techniques of working affect the team’s performance, tactics for example pair programming, videotaping team members working together, or simply generating a conscious effort to observe every other’s way of working are useful. The team should then analyze the degree of variation, discuss its impact on its capability to transform requirements into working software, and identify and agree on improvement measures. Carefully facilitated, the team will wind up standardizing its own function. Retrospectives offer an excellent chance for the team to reflect and monitor how successfully its members collaborate and how widespread function practices are employed.
Depending on the team member’s expertise with agile development practices, it may be beneficial to involve a mentor to teach the practices, ideally through pairing. Agile development practices including test-first might be counterintuitive and challenging to realize at very first. At Toyota, it really is the job of the supervisor or team result in train employees in regular procedures, by the way. As the ScrumMaster, you’ll need to watch out for any impediments that prevent standardized function and guarantee that these are swiftly removed. Otherwise, the team members are likely to disengage from the method and revert back to utilizing their own non-standard function practices.