What To Do About Distributed Teams

A recent client of of one of us had a dilemma: their procurement department had selected the lowest cost bidder on a software contract, and that bidder was located on the other side of the country (USA). When work on the “agile” project started, the kickoff consisted of a conference call.

It is a real problem that procurement is viewed as a separate function, apart from how the software development team will operate. Fixing that requires going way, way up in the organization – beyond the CIO – and if the organization is a subdivision of a large company, or a government agency, addressing the issue possibly requires going even beyond the organization itself to the owning organization, which sets procurement policies.

We don’t want to get into procurement here: that is not the topic of this article (it will be a future topic). Instead, we want to look at the very common, real, and unchangeable situation that we sometimes face: when a team – or worse, only part of a team – is remote.

Is it really a bad thing?

Not too long ago, Jeff Sutherland – the “father” of Scrum – published a paper on a software project that was highly distributed, which he claimed had been one of highest productivity distributed software projects ever, with a productivity comparable to that of a small co-located Scrum team. Some noteworthy aspects of the project’s organization included:

1.    There were multiple teams, spread across six geographic locations.
2.    Teams were split across the functional areas of the requirements.
3.    Team members were purposefully spread across geographic boundaries: thus, for any given team, the members were distributed. Any member of a team, at any location, can work on any item on that team’s backlog.
4.    The information to be shared in a team’s standup was written up before the standup and distributed to the team’s members. This helped to overcome communication challenges over long distance phone connections, as well as language barriers.
5.    Standups were done in real time, despite a fourteen hour time zone difference.
6.    Each team had a Product Owner assigned to it. All Product Owners were co-located, and met daily, and there was a “chief” Product Owner.
7.    All Scrum Masters were co-located, there was a “chief” Scrum Master, and there was a “Scrum of Scrums” meeting every Monday. The Scrum Masters were also co-located with the Product Owners.
8.    An Architecture group, also located with the Scrum Masters, met on Monday after the Scrum of Scrums meeting and controlled the direction of the project architecture through the Scrum meetings.
9.    A co-located Automation Test team created scripts for an automated testing tool.
10.    Tests were written simultaneously with code most of the time.
11.    During a Sprint, the Product Owner tested features that were in the Sprint backlog – rather than waiting to the end of the Sprint.
12.    A shared code repository, used by all teams.
13.    Integration of eXtreme Programming (XP) practices, to augment Scrum practices.
14.    Some continuous integration practices were used, such as hourly automated builds, but there was a ways to go in this, especially with regard to test automation for acceptance tests.

One of the reasons cited for the project’s high productivity was the caliber of the teams – made possible by the move to a distributed approach. This enabled the selection of a remote group in Russia, StarSoft, that had extensive experience with systems level software as well as experience using XP, rather than trying to use the best talent that could be found locally. According to Jeff Sutherland,

“The local talent pool is not sufficient to expand team size and salary costs are much higher than outsourced teams...The primary driver is enhanced technical capability resulting in dramatically improved throughput of new application functionality.”

In other words, using a distributed model enabled the project to recruit the best talent, rather than relying on what was available locally.

In contrast to this, many organizations choose remote teams in order to get the lowest cost. That can potentially undermine success. Instead, it is wiser to find the right skills, whether they are local or remote. Looking at a wider geography can enable you to find the right resources more easily. The cost objective is self-defeating if the project is not successful.

Co-location of “thought leadership”

The practice used by this project that is probably the most controversial for the agile community is that Scrum Masters were all located together, as were the team architects, and the Product Owners. There is a general feeling in the agile community that leaders should be no more than facilitators, and so leaders need to be present in person to be able to facilitate. This was not possible in this project, due to the fact that each team was distributed. For the Product Owners, putting them all together is less controversial: agile teams are accustomed to this; but putting all of the Scrum Masters together, and the architects as well, is controversial because doing this effectively creates a collaborative forum that excludes the team members. Agile relies on collaboration, and having an elite “architect” group collaborate privately is viewed as not very agile. In fact, the Scrum community does not even approve of having a role such as “architect”, which is ironic because Jeff Sutherland – the author of the article – seems to feel that in this instance it was fine.

Based on our own experience with both architects and agile teams, it is essential that an architect or technical lead work in a collaborative way. The kind of architect role that is effective for agile teams is one that does not base his or her work around documents, but rather discusses issues with the teams directly, as well as with other stakeholders such as Security, Release Management, the data center or cloud service group (if there is one), and so on. Architects can play a valuable role in that they (1) are aware of the organization’s larger architecture strategies, (2) are charged with thinking more long term and more end-to-end, and can do this throughout a project because they are not saddled with creating stories, (3) have (or should have) expertise in a wide range of aspects of IT beyond software development, including system architecture, scalability, security, maintainability, systems thinking, and design patterns. Certainly programmers should know these things, but they often do not, and an architect – if sufficiently qualified – can serve as a valuable mentor for the team.

The last part is important: an agile architect should be a mentor – not an autocratic decision-maker. Issues should be discussed with the team, rather than decided independently, and the architect should serve as a coach, teaching the team about architecture concerns. For a distributed team, in which all of the architects are located together, this is even more important, because the architect is less accessible physically, and the co-location of the architects makes it inevitable that they will collaborate privately – that is in fact an advantage if there are multiple architects, but it must be ensured that the architects also collaborate with their teams. The “chief” architect, as Jeff Sutherland referred to the role, should make sure that this occurs: the chief architect is also a coach for the architect team and must ensure that they work in a way that is compatible with agile practices. The same applies to the “chief” Scrum Master, and the “chief” Product Owner.

Table 1: Roles and their value for the fully distributed team cited.

Role	Where Located	Value of Role For Fully Distributed Teams
Scrum Master or Team Lead	All at central location	Ensure that remote communication practices are effective.
Product Owner	All at central location	(same as for any Scrum team)
Architect	All at central location	Ensure architectural consistency.
Tester	All at central location	Manual testing; automated test script development; stress testing.
Chief Scrum Master	Central location	Lead the Scrum-Of-Scrums meetings.
Chief Product Owner	Central location	Lead daily Product Owner meetings.
Team Member	At each location	(same as for any Scrum team)
Tech Lead	At each location	Coordinate technical issues across teams.
Test Lead	Central location	Coordinate testing activities.

According to Jeff Sutherland, “SirsiDynix achieved strong central control of teams distributed across geographies by centrally locating ScrumMasters, Product Owners, and Architects. This enabled them to get consistent performance across all distributed teams.”

It should be noted that some of the lessons here conflict with sentiment in some parts of the agile community. The Scrum community in particular is uncomfortable with having specific lead roles such as “architect”, or indeed any “chief XYZ”. Even the concept of “control”, as expressed in the above quote by Jeff Sutherland, is objectionable to much of the Scrum community – which is ironic given Sutherland’s role in the creation of Scrum. The intention in this article is not to take a general position on these points, but to share what we have known to work given the unique challenges of a distributed team, recognizing that there might be other approaches that could also work. Effective leaders often are able to make any approach work: the leadership is what makes the difference.

Use of remote collaboration tools

Many organizations use remote meeting tools such as GoToMeeting, WebEx, Skype, and so on. These tools are really nice, in that they make it simple to set up a conference call and share screens, but they do not really solve the challenges with remote meetings. It is still hard to hear and understand people. When people are remote, they often feel that it is ok to join late, or they call in from their car (not ok if they need to see a shared screen or look at documents), or they multi-task, or they have background noise (another conversation going on in their cubicle), and so on – all of these distractions and interruptions can destroy the cadence and cohesion of a meeting: people start to emotionally disconnect. Here is a hilarious comedy portrayal of this. Preventing these kinds of interruptions requires very strong meeting management – a skill that most agile coaches do not have, since they are accustomed to working with teams in person.

One of the greatest drawbacks to a remote meeting is the inability to whiteboard. Many people think visually. Most agile coaches are accustomed to writing on a board, or putting up sticky notes, or conducting a “dot vote”. These visual techniques cannot be done easily on an ordinary computer screen, although there are touch screens that are available for this purpose, e.g, the “FlexTouch”. In addition, for a technical meeting, it is almost always necessary to draw on a whiteboard, and the drawings can become very expansive – spanning multiple boards. This is not easy to replicate on a computer screen, although that is changing with the advent of very large “4K” screens. Even so, one needs to be able to draw on the screen.

Given these challenges, a remote meeting must be facilitated very differently from an in-person meeting. Careful thought must be given to how diagramming will be done, if it is needed, and preparations and discipline must be applied to enable people to hear each other. When we facilitate a remote meeting, and someone is not easily understood, we ask them to speak up, or we repeat what they said to confirm that we understood it correctly. In the project described by Jeff Sutherland, team members were required to submit their standup statements in writing prior to the standup, enabling everyone to read it if they cannot understand what is being said. Coaches need to use these techniques. The meeting’s coach or facilitator also needs to set things up before the meeting, since it takes a few minutes (sometimes longer) to overcome technical glitches.

Meet in person at the beginning?

It is really essential to have the entire team meet in person for a few days – a week is recommended – at the beginning of a project so that they can collaborate most effectively on the key “conceptual pillars” of the project: the core vision and requirements, the core design concept, the team roles and collaborative processes, the development pipeline, and the testing strategies. (See this prior post.) These are all very complex issues and require lots of whiteboarding and active sharing of ideas. Doing this remotely will take weeks, and it would be difficult to resolve all of these things in a collaborative way by doing it remotely: one would likely have to fall back to the non-agile approach of having someone dictate much of this. Establishing the key conceptual pillars is extremely important to ensure that risks can be managed well and that things will go smoothly and evolve, instead of having radical and disruptive conceptual changes mid-stream.

How to go through stories remotely?

Agile replaces the traditional practice of writing a detailed requirements document with a more fluid real-time process of having stakeholders describe what they want to developers in person, noting those requirements down as brief “stories”, and then adding details to those, primarily in the form of acceptance criteria. Developers are encouraged to reach out to stakeholders as they program to ask for clarifications, and stakeholders are encouraged to try out the software as soon as a developer thinks that it is complete, followed by a formal demonstration at the end of each iteration. This interactive exchange is more difficult if the stakeholders and developer are not geographically collocated.

In the project cited above, stakeholders wrote requirements down with details ahead of time. This enabled developers to review those requirements before a sprint planning meeting, and then ask clarifying questions. This process seemed to work well for those teams. However, it is mentioned in the article that the remoteness of stakeholders made it necessary for some “multi-tasking” – that is, the developers sometimes had to put a story aside and work on another until they received feedback from a stakeholder about a question.

Regarding trying out software as it is developed, we have seen it work well when remote users try out an application during an iteration by logging in remotely, as soon as a developer thinks that a story is done, rather than waiting until the review at the end of the iteration. The application can be deployed into a test area specifically intended for users to try out stories as they are completed. This reduces the risk that a story will be marked as complete, but then not accepted by the Product Owner (representing the stakeholders) at the end of the iteration. It is important that remote stakeholders have a separate test environment for trying things out, so that they do not interfere in the test environments and disrupt the testing cycle of the team.

How to coach people you can’t see?

One of the greatest challenges for coaching remote teams is that you cannot simply stroll up to people and see how things are going for them. Calling them out of the blue is potentially disruptive, so that leaves email. Asking in an email to schedule a time is cumbersome, and seems “managerial” – something that a coach tries to avoid. We personally recommend going out of one’s way to establish a unique relationship with each team member as soon as possible at the start of a project. Reach out to each person – don’t skip anyone – ask for a time to chat on the phone, and take notes about their perspectives and challenges, because if you can’t see them, it is harder to remember those things and associate them with the person. Primarily ask questions and listen – don’t do the talking. Then, make it your business to remove obstacles for people. Check in on things that you know they are waiting for. Advocate for them. Connect them with people who they have been trying to reach, such as someone in a support function (Testing, Release Management, etc.) from whom they need something. And have a regular, say weekly, chat with each team member about how they feel things are going, on a personal level. Keep their confidence, and be on their side. And if at some point you visit their location in person, make it a point to stop by and chat.

Pair Programming is a great way to increase collaboration in Distributed teams. When teams are distributed in two or more locations, each location team will try to behave as a separate team by itself. They often try to “throw over the wall” to each other. Instead, it is very important to promote One Team behavior within such teams. One technique which we often use is Pair Programming, such that in each Sprint, every developer pairs with a developer at another location during the hours in which their work schedule overlaps. They both work on a single story until it is done, with a handoff from one to the other at the end of each other’s work day, but working together when their work period overlaps. One developer codes the story during the day, and later in the day he pairs up with the other developer, walks him or her through the code that was changed, and checks-in the code before leaving for the day. The other developer checks out the code and resumes coding, and records his findings in a small video (we use the Snagit tool to record) and puts the video in a shared folder which the other developer can access the next day. This way there is a collective code ownership between the team members who are not at the same location.

Some other techniques which we recommend for distributed teams are:
•    Share the pain caused by time zone differences
•    Make sure that everyone has a calendar that covers the regions and cultures present on the team, so that if someone will be out for a holiday, it will not be a surprise.
•    Have a daily or frequently recurring optional virtual meeting for discussing issues that come up during the day. This does not replace the standup, but is an open forum for sharing ideas. This helps to overcome the fact that people are not co-located and cannot overhear each other or just walk around to each other’s desk.
•    Do retrospectives (every iteration) with the entire team
•    Encourage cross-region communication (for example, by using pair programming)
•    Actively share feedback from stakeholders with the whole team
•    Focus on delivering the value stated in the stories

How to participate in ad-hoc discussions?

Another severe challenge for remote coach is that agile relies on ad-hoc discussions for resolving issues that come up. If you are not there in person, then you cannot observe these discussions happening, and so you can’t lean in and hear what is going on. You can become out of the loop on things pretty quickly.

In the project referenced earlier, the fully distributed nature of each team cleverly avoids this problem: each team member is apart from the rest of the team, so discussions have to be arranged. It is therefore the coach’s job to keep reminding the team that he or she wants to be included. Eventually they will get the message and will do so – as long as your participation is positive. Generally, a coach should not interfere in a discussion unless the discussion has become dysfunctional. A coach is first and foremost a facilitator. If a discussion is remote – over the phone, or via email – then a coach can play a valuable role in making sure that the communication works well, that people who are hard to understand speak up, that decisions get written down and disseminated (e.g., on the team’s wiki or – even better – on a wall in each of the remote offices), and that the discussions stay on topic (especially difficult for email exchanges). However, a coach’s presence should not be felt: it should be an enabling presence – not a contributing presence – kind of like the way ceiling lights help everyone to see in a room, but you don’t notice them per se.

Dealing with regional and cultural differences

Cultural differences is a topic in its own right, and we will have a separate article on that. For now, suffice it to say that the most dangerous mistake people make when leading a cross-cultural team is to assume that we’re more alike than we actually are. Some cultures are not accustomed to speaking their mind in a meeting, while others are – especially if there are people present who have a higher position (and a Scrum Master can be seen as such a person). In some cultures, people will not express an opinion unless they have had time to check their facts and do some thinking offline, or they might even consider it to be rude to speak honestly if it would be critical. Some cultures are accustomed to being given explicit work instructions while others welcome autonomy and self direction. Some cultures see their personal time as sacrosanct while others are perfectly willing to work weekends as needed. If a culture is accustomed to long summer holidays, make sure to plan around that. Some cultures value punctuality while others do not.

In addition, do not underestimate the challenges of language. Even when all parties speak the same language, it can be very difficult for people to understand each other when there are multiple dialects. For example, American English, UK English, Singaporean English, and Indian English are all sufficiently different that it can be difficult to communicate verbally in real time, especially if the communication system is imperfect – which is usually the case. Idioms can be especially problematic. The distractions of communication dropouts, coupled with soft speaking and multiple language dialects can all combine to create enough distraction so that people cannot focus on the issues being discussed. If communication is challenged, it is the job of the meeting facilitator to repeat what people say if it was not clear or not loud, and to verify that all parties are following the discussion. Ask people regularly to summarize their understanding and ask people for their opinions. Do not wait for them to speak up. Plan for the extra time that this consumes: it is a cost of having distributed teams.

Contributors (alphabetically):
Cliff Berg
Sekhar Burra
Nancy Settle-Murphy – facilitator, virtual team expert, cross-cultural trainer, OD consultant, and author of Leading Effective Virtual Teams

How To Rapidly Infuse Technical Practices Into Your Agile Teams

Martin Fowler once wrote, “The scrum community needs to redouble its efforts to ensure that people understand the importance of strong technical practices.” Jeff Sutherland has commented, “It is extremely easy to integrate Scrum with XP practices even on large distributed teams. This can improve productivity, reduce project risk, and enhance software quality.” Ron Jeffries wrote, “Manual testing cannot sustain the two week delivery cycle. Therefore, for a truly successful iterative software project, automated testing is absolutely necessary.” 

You have to trust the team to figure out what they need to learn, and that they will learn it: they should not wait to be trained.

But what if your teams do not know how to do these things? Agile promotes self learning: if you are going to trust the team to know how to do its work, then you have to trust them to figure out what they need to learn, and that they will learn it: they should not wait to be trained. Still, it can take a long time for a team’s members to learn a whole host of new skills on their own. Agile transformation is about making this happen rather than waiting for it to happen. How can you get a team to learn the technical side of agile?

One approach that we have seen work really well is to create training teams. These teams provide intensive hands-on classroom training, as well as on-site coaching as a follow-up to the training. In 2012 one of us (Scott) created such a team for training a very large IT organization in agile technical practices, and this recounts that experience.

The directive was to infuse knowledge of technical practices across all of the in-house software development teams across the organization’s many locations around the country. The practices included test-driven development (TDD), test automation, automated quality analysis, and continuous integration (CI). Rather than go through a lengthy narrative on each approach taken, we will summarize the approaches here and then discuss them:

1. Training team consisted of two members (including one of us), each with strong development experience, and experienced with many agile technical practices and tools.
2. Created a standard set of test tool stacks that could be easily installed. Started with test tool stacks to support testing for the most common development tool stacks in that environment (Java, Oracle).
3. Trained entire teams at a time in a classroom, in person, with some lecture, discussion and mostly hands-on practice.
4. The course took three weeks, with short two-hour sessions three times a week, minimizing impact on work.
5. Web based training was not used because it is more difficult to build effective web based training materials. Further, we wanted to ensure that entire teams were trained rapidly and that we had their undivided attention for a period of time.
6. Followed up with those teams after training them, in person, using a “coaching” approach.
7. Measured code quality, test coverage and practice usage after the teams had been trained, and reported their progress in a management scorecard style report.
8. Kept track of which teams had been trained, and reported that in the scorecard. This put pressure on group managers to get their teams trained.
9. We found that many (but not all) testers could be turned into test programmers in ~ 3 weeks, further enhancing the overall benefits.

The results of this were that adoption of agile technical practices advanced rapidly across the organization. Some teams were eager for the changes, and some were resistant, but most were simply supportive of the new direction and were willing to give it a try and see how it worked. In one case, a team – one of the most experienced and productive teams – rejected the use of TDD, but since management had decided to make TDD mandatory, a senior manager spoke to that team’s manager and soon after that the team was using TDD. Fortunately, this was an outlying instance, since we value the Agile Manifesto principle of trusting teams to get the job done in the way that is best for them. To be fair, TDD has a very long learning curve, and it is normal to have some people resist because it is a very substantial change in how one works.

In another case a team that was given a large newly released application to support, because of the training, recognized quickly that the code they had inherited was challenged in terms of fragility and difficulty testing. The team reached out to one of the coaches, received in-depth coaching on how to deal with the problematic code and within less than a month became self-sustaining and was already seeing improvements in the code quality.

Creating the initial training materials was a very substantial task. It took two experts about four months to assemble an appropriate test tool stack and create the three week course. We then started running teams through the course, and following up with those teams afterwards by traveling to their location and staying for several months, sitting with the teams to see if they needed help putting what they had learned in a classroom into practice on their actual project. Our goal was to cement in what they had learned in an actual work setting. Training experts will note that our approach was therefore both experiential and contextual.

At the same time, we sought out those with an agile mindset and technical expertise for taking on the role of internal agile technical expert. This enabled the organization to have continued expertise, long after we left.

How this all works together

Training an entire team together was very effective because it was then possible to assess the outcome for the team’s work, and also because no one was missing from a team when others were not. The entire team was offline together, making themselves more productive as a group. This made it a team learning experience: they all shared a common training experience and therefore shared training reference points. It was a shared journey. Management reporting later focused on team performance with the new skills rather than on individual performance.

Having a standard set of tool stacks was essential, both for training purposes, and for sharing techniques across the organization. The intention here is not to standardize and prevent the use of alternative tools, but to create a common evolving baseline to foster communication and cross training. The standard test tool stack also made it possible to rapidly stand up the tools on a tester’s workstation – appliance-like. Testers who have transitioned to becoming test programmers are often less experienced technically than software developers, and installing and maintaining complex tools is potentially frustrating for them, making automated installation very helpful.

Many organizations with remote locations want to use Web based training for agile methods. There is no reason that Web based training cannot be used, and indeed there is a-lot of Web based training available for some of the tools. For example, to learn the tool called “git”, you can use this online interactive tool. However, we wanted to have an intense, immersive experience in order to ensure that developers were entirely focused on the training, in a group setting. The amount that needs to be learned is very broad and deep, and immersion is necessary. If the training were not in a classroom, then it is anticipated that people would not be allowed to devote entire days to it, which is what is needed in order to ramp up quickly. The whole point was to bite the bullet and make in investment and then reap the benefits as quickly as possible.

Assessment is always part of a learning program. Any teacher knows this: you need to test students. The highly innovative Khan Academy system is built around continuous individual assessment through an automated dashboard and progression to the next step when assessment criteria have been met, allowing each student to progress at his or her own rate. We realized that we needed to build assessment into our training process, to both assure that it was effective and to measure its effectiveness, which we felt was true to the empiricism of agile. Thus, after a team was trained, the team was strongly encouraged to not only record and display their code quality and test coverage, but also demo to the business their progress on a regular basis. This was done by integrating their test coverage tool, code quality tool and automated build output into an aggregated dashboard, which we then shared with management in a bi-weekly presentation. Reporting test coverage was mandatory and this was strongly supported by group management. Management was able to see the test coverage of teams that had been trained, and they were able to see that more and more teams were trained over time. This helped to assure management that the very substantial investment of the team’s time in training was worthwhile. It also provided an important metric for agile adoption, since technical practices are a key part of agile. In addition to reporting test coverage, agile coaches working with each team provided subjective assessment of each team’s progress, generally focused on impediments that management could do something about or should be aware of.

We found that many (but not all) testers could be turned into test programmers in ~ 3 weeks.

One of the most interesting discoveries was that most testers can become test programmers. The IT role of “tester” is generally applied to someone who conducts manual acceptance testing, consisting of writing “scripts” and then executing those scripts each time testing is needed. These scripts are written instructions for what to do to test the application, generally consisting of clicking on links, entering data into forms, checking the results that are displayed, etc. It is enormously tedious and labor intensive. Manual testing of this kind is not compatible with agile projects because agile projects rely on continuous testing, and that continuous testing is what enables one to have the short two week development iterations. It is therefore imperative to shift to using automated tests wherever this is possible. The question is, what do you do with all of your testers?

We found that most – but not all – testers could learn how to write automated tests. Automated tests are programs: they are test programs. They are executable code. This means that testers become programmers. Some testers are anxious to learn programming and are able to make the transition. Others are not. We found that among those who were, they were able to become productive test programmers after about three weeks, provided that they had a testing tool stack set up for them and the mentorship of a test automation coach.

We also took the same build, measure and dashboard system and began using the same techniques for software developed by external solution providers. This enabled us to measure the code quality of that software. Code quality ties back to many things such as standards compliance, test coverage, complexity, and other attributes. Using this approach we were able to convince contract management to add quality clauses into contracts. This also separated the vendors who said they were Agile from those who really were Agile in their technical practices. It also exposed a huge problem with one very large vendor in particular which resulted in a significant reduction in cost, potential liability and support problems. Overall, the use of code quality metrics helped in both supplier and contract management. One program utilizing this platform realized a multi-million dollar savings by informing the program managers on the relative quality which resulted in a significant reduction in support and re-work.

“Our space is too complex”

The same techniques have also been successfully applied in the embedded machine systems space. While significantly more complex and overall systems complexity is higher, the same delivery mechanism, teaching/coaching approach and condensed highly impactful training has been just as effective. Cost savings are more significant in this space, especially when moving more testing away from hardware-in-the-loop testing to more automated software-in-the-loop testing, reducing capital expenditures.

So far, we have not found a software space that did not benefit from this approach.

Conclusion

The general approach used here was highly effective, and it can be replicated outside of the domain of testing and continuous integration. For example, we believe that it can be applied to enterprise architecture, to governance, to release management and deployment, to security, and generally to any specialized area that is part of the solution delivery pipeline. The legacy approach of having discrete steps that are performed by different groups in sequence then gives way to an approach in which the development team performs every function, but with the support of specialists through training, coaching, automated testing, and process oversight. The role of specialized groups changes from doing to teaching; from being a gatekeeper to being a guide; from inserting speed bumps to helping teams to create a safer path.


Scott Barnes
Cliff Berg