Customer Experience, Nearshore, Project Management, Successful Outsourcing
As a provider of nearshore successful software development services, Scio has a proprietary interest in assuring the success of our customers’ outsourcing projects. But of course, in that respect, we’re no different than any service provider. So, it could easily be said that this article and more that will follow on this critical subject have a built-in bias we can’t ignore. We want you to understand our experience, our
business model, and how it shapes our approach to providing outsourced services. We hope that understanding will lead you to explore working with us and to hire our team. So yes, this is an exercise in self-interest…. But that said, we also have an interest in promoting improvement in our industry and the knowledge of critical success factors (CSFs) for the outsourcing of software development. This certainly isn’t a new subject – both the buyers and the sellers of outsourcing services have been trading tips, CSFs, and white papers on the subject for years. A quick Google search will turn up thousands of papers from professional societies, trade journals, buyers and suppliers in the field. But it is a sufficiently rich subject, with ongoing learning and improvement, to continue the conversation among participants. Do we have important information to add? We believe we do and we’re willing to expose our knowledge and experience so you can judge for yourself. To begin the discussion, let’s set a few common terms in context:
- Outsourcing is a broad subject and different industries approach it from different angles. In basic terms, we’re only discussing the outsourcing of software development, but many of the lessons learned in outsourcing across other industries do apply. The term comes from tying together the words used to describe «outside resourcing» – bringing resources from outside a company to meet business needs. With that in mind, outsourcing can describe the contract of work to a provider in the same building, city or country, just as well as it can describe the outsourcing of work to a provider in a different country or a different continent.
- Information Technology (IT) Outsourcing is generally considered to be a subsector of Business Process Outsourcing (BPO) that involves operation, management and maintenance of IT services and infrastructure within an organization. Although technical skills are necessary to maintain aspects of IT operations, generall software development is not the primary driver of IT outsourcing contracts.
- Offshore or Offshoring is a term that, like outsourcing, has many meanings specific to the industry where it is used. For our purposes, it means the use of service providers with working hours that have very little or no overlap with their clients. Generally, these providers are on different continents with completely opposite work periods. A great deal of successful software development outsourcing is done by offshore providers so it is not intended to have a negative connotation. But, in many software development projects, communication and collaboration are key and in that respect, using offshore services requires special adaptations that both the client and the provider must be aware of and enforce.
- Nearshore or Nearshoring in our context refers to the contracting of work to providers in a different country that shares significant working hours overlap and often shares a border, region or continent. Scio is a nearshore provider of software development services to North American clients. Our services leverage the benefits of a nearshore relationship with our clients so the situations where we work best tend to exploit those advantages. Successful software development outsourcing relies to a large degree on the relationship between the client and the service provider and the requirements of the work itself. Some software development can leverage nearshore advantages better than others. Some providers have adopted practices that lower the risks inherent in software development outsourcing, regardless of their physical proximity to their client teams. Regardless, understanding the differences between offshoring and nearshoring of software development projects is an important subject for all participants in the industry. There is no «one size fits all» as evidenced by the growth of both nearshore and offshore development centers within large outsourcing consultancies.
- Agile Software Development is a methodology that is widely used across the software development industry. It is based on the idea that software development projects should be composed of short, iterative cycles producing valuable software incrementally while allowing for the evolution of the results based on constant consultation and interaction with the client and user base. The methodology itself is constantly improving and allows for adaptation to many situations. Because of this flexibility, the agile practices adopted for one project or practiced by a development team will vary, but overall the basic principles as they apply to client and team interactions and software quality during a project are expected to remain.
- Scrum Software Development is an extension of the agile framework for software development down to the team level. It includes descriptions of roles, processes, and ceremonies that strengthen agile principles and give structure to the software development process. Like agile, it is an adaptable methodology but it does include more detail specific to the software development process. Scio provides software development teams using a proprietary implementation of agile and scrum. Not all software development projects require agile or scrum, but most can benefit from some level of integration with the methodologies.
- Distributed Agile Teams are a part of the outsourcing of software development when you use either nearshoring or offshoring of a part of your agile team. In agile/scrum methodology, a premium is placed on open and frequent, face-to-face interactions between the development team and the product owner from the client-side. But, agile is also practical and adaptable, so there are practices that help to overcome the team isolation and improve interaction when parts of your team are remote. Scio is a provider of distributed agile teams for software development and integrates the practices necessary to assure success in these situations in all our projects.
What is a Successful Software Development for You?
It is hard to discuss «success» without knowing what it means to clients in general and it is almost impossible for a specific project to be «successful» unless all participants understand what it means from the start. In simple terms, most people would say without thinking it means providing software on time, on or under-estimated costs and that delights users – but that simple definition ignores all the trade-offs and pitfalls that need to be avoided or mitigated and the stakeholders who must be satisfied to arrive at a successful outcome. In researching the literature on this subject, an
IEEE literature review came upon the subject that found some interesting results:
Top 5 CSFs for Success in Software Development Outsourcing
- Contract Flexibility
- Trustworthy Relationship Management
- Competitive Bidding
- Consultation and Negotiation
- Quality Management
Last 5 CSFs for Success in Software Development Outsourcing
- Time Management
- Culture Awareness
- Intellectual Property Rights
- Data Security and Privacy
- Detailed Specification of Product and Project
These results came from a specific set of criteria concerning the basis of the outsourcing contract and relationship, as well as the contract and contract management – rather than a soft assessment of project outcomes, so it is probably not what you might think at first. But consider the elements of the top 5:
- Contract flexibility, like agile practices in software development, this allows the project to evolve in various ways to reach a successful outcome. It is a realization of the simple fact that at the outset of a project, and throughout the development cycle, participants don’t know what they might discover or how they will work together. A flexible contract, instead of locking them into a tight box, provides a framework for realizing opportunities not foreseen at the beginning of a project or dealing with unexpected issues that might derail the project. A good contract focuses on the objectives of the outsourcing relationship rather than operational details.
- Trustworthy relationship management gives everyone involved the ability to bring issues up without fear and mistrust. It allows open negotiation during the development process without bringing everything to a screeching halt. Again, it acknowledges the established truth of software development – there are things we don’t know and opportunities we haven’t considered that will be discovered as we move forward. We won’t be able to consider them if we don’t have a relationship of trust between the players.
- Competitive bidding, when it is done not just on price, but on a range of weighted factors, helps to increase the feeling of trust and control between the service provider and the client. Everyone understands what is important from the outset or has explored the issues until a successful conclusion is reached. Blind bidding, where bids are submitted, but no discussion or negotiation occurs among the top bidders and the potential client do not build this level of understanding however. No amount of paper and diagrams can substitute for the level of understanding that can be reached in direct, verbal negotiation.
- Consultation and negotiation are a realization of the fact that constant communication is necessary in all software development projects to insure the development is on track to meet the goals set out in the beginning of the project or, where needed, the teams can negotiate in good faith to reach alternative outcomes that better fit the situation as it has developed. Virtually all software development projects need both a mechanism to ensure open communication and negotiation.
- Quality management, not just against a set of detailed requirements (that is number 15 in this list after all). When everyone is involved in quality, it becomes a key to reaching a successful outcome. But as the agile methodology guides us, only if the management of quality is a continuous process throughout the incremental software development process. If it can only provide feedback at the end of prescribed phases or the end of the project, the risk of going off-the-rails becomes too large and failure to reach the necessary outcomes of a project area almost assured.
Now, of course, you are likely to see a different list in your head or have a specific list of CSFs in mind for a project. But list brings up an important consideration – what weight should you put on the need to deal with change and to work successfully with your vendor throughout a project or relationship? And it is important to understand, this is a result of the frequency of a CSF being identified among several papers, not the weight it was given in any one paper, if indeed weights were given. So the number of times a CSF was mentioned in the surveyed literature produces the order of the list.
Nearshore? Offshore?
We find these kinds of communication problems come up in many aspects of the provider/client relationship in outsourced software development. Agile and scrum development practices address these problems well, but in the case of offshore services, the agile model becomes stretched in ways that require adaptations that can be costly or distracting in the course of project operations. That is not to say that nearshore distributed teams, a model we use frequently, do not require specialized planning and adaptations, but it is part of our standard practice package, not something we do on a one-off basis. We find all projects benefit from attention to better communication and tighter relationships between our teams and their product owners. And we have that built-in advantage of nearshore; our development team is working in real-time with the client team. There is a lot more to discuss successful software development outsourcing – and we will be doing just that as we continue to provide information from the field.
Agile Methodology, Customer Experience, DevOps, Nearshore, Product Development, Project Management, Successful Outsourcing
Rotating team members on agile software development teams is a controversial subject. Some leaders in the agile community are strongly opposed to the idea and won’t consider it at any level. Others are open to the subject, but frankly too concerned about the possible downsides to actively plan rotations or even hint to their customers it might be a good idea. And of course, there are the wild-eyed optimists who claim it is the best idea possible for every situation.
Our focus for this article is dedicated teams – teams with members selected for their skills and reliability over the long run. Typically, dedicated teams have no set sunset. They are dedicated to a product or part of a product suite and they generally stay through the active development and maintenance of a product lifecycle – which for enterprise software maybe years. But, that said, the ideas that bring up the subject of rotating members of a dedicated team could apply to any long term project, especially with smaller (3-5 member) teams.
And let’s be honest about one other thing too: the longer the project or product lifecycle, the more likely it is there will be an «unplanned» member rotation. Births, deaths, illness, vacations, career advancements and changes – all sorts of life events have to be managed as a part of maintaining a dedicated team. Even if the time a member is away is relatively short, in less than two weeks, the impact on the productivity of a small team needs to be managed to continue to meet client schedules and expectations. In some cases, the remaining team members can sustain production for a period of time by adding additional hours daily and on weekends, but eventually, that will take a toll on their personal commitment to the team. And when there is an unplanned need to bring in a replacement, there are consequences to the team regardless of the additional manpower provided. In fact, it is well understood that if for some reason two members of a small team needed to be replaced over a short period of time, it would be catastrophic for the team. Bringing the new member «up-to-speed» with mentoring and knowledge transfer takes time and effort of other team members away from their work. And, there is the well-understood impact of a team «forming, storming, norming, and performing» cycles as described by Tuckman. Changing a member of a small team always creates issues. Without some planning and forethought – it can kill the effectiveness of a team for an extended period of time.
So – why would anyone want to consider the idea of rotating team members on dedicated agile teams?
- If unplanned changes in a dedicated team are going to happen anyway, why not be prepared? Why not have the process for selecting, integrating, training and mentoring a new team member planned, documented and tested before it actually happens? Why wouldn’t you want the expectation that «this can happen» and «this is how we deal with it» in place and in front of the team and the client from the beginning?
- The longer a team works on a product, the more likely they are to develop «tunnel-vision.» They see the UI, but they become blind to the problems a new user might encounter trying to use it. They know there are newer technologies that might make something more efficient or resilient, but it takes time to test, advocate change, and demo the option to the client team. If what you have works, is it really worth the effort? The longer a team works together, the more «normal» the little quirks about a product become. In the long run, it can make them resistant to needed change and reluctant to suggest options.
- Working with the same people, on the same product, eventually leads to a level of isolation that can begin to make it difficult to want to get started on the «same old stuff» each day. Developers are part of «geek culture» and love to see new technologies, get input from other sources and try «cool» things. When this happens, production slips and members of the team may become less committed to the success of the product they are working on. It doesn’t happen in a day; it is a slow drip that eventually eats away at the team and makes it less effective. It can also make individuals on the team consider career changes because they are afraid their resume will reflect stagnation rather than stability.
- Bringing in «fresh (but experienced) blood» can bring cross-pollination from other experiences, new points of view on coding practices and processes, a new look at alternatives as you move forward and other benefits from another set of eyes on the project. If long term members of the project are not ready to accept new ideas, they can create strong resistance, but if they are positively primed for the idea by considering they could also benefit individually and as a team, it can be a shot in the arm for the team.
- «Ownership» of a product, or an area of responsibility, can be a strong motivator for a team. Their understanding of its deeper value and continued success is part of their pride and keeps the team on track. But, there is also a downside. If the team is the single point of knowledge and «truth» for a product, they are also the single point of failure. If there is no base of knowledge about the product outside of the team, in the wider pool of developers around them, there is no way to replace a team member easily or help them if there is a problem that causes a loss of a member or if the team runs into a serious internal disagreement (it does happen).
- Operationally, these long-term teams become silos. Outside the team, they are the go-to subject matter experts that always have the answers. Inside the team, individuals tend to become specialists, filling a niche that no one else can come close to. This not only runs against the whole concept of «agile organizations» – it becomes a growing risk within the organization.
There are more reasons too – but those concerns represent some of the more common drivers of the idea. They are all real issues and the problems the teams dealing with them have an impact on the projects they are in. But – does planned rotation actually solve the problems? Does the upside outweigh the downsides? Can rotation be planned well enough to overcome internal team dynamics? Will the supposed benefits last long enough to make rotations something you want to do? Can you actually present a case that would make client support, rather than oppose, the practice?
The answer would have to be – it all depends on implementation.
- Like any change, member rotations have to be sold internally before they can be implemented.
- Frank conversations about the health of teams, experiences in long term engagements have to be surfaced and alternative solutions have to be discussed.
- The timing and requirements for new members have to be considered and accepted by the existing team members. Simply dumping the idea on them without preparation is sure to bring disaster.
- The level of the incoming team member will make a difference in acceptance. Replacing a senior member with another senior developer may be more difficult than bringing in a mid-level or junior developer in their place. With less seniority, the new member will have lower expectations and less to live up to. They will be more accepting during knowledge transfer and mentoring and give existing team members new opportunities to grow. But if the outgoing member is considered to be a team leader, the impact may be very deep no matter who is brought in.
- If the practice is fairly new within the organization, replacing a team member is likely to be more problematic regardless of planning and thought. The practice can be new institutionally or within the team, it really doesn’t matter. If team members are not experienced with the concept, issues will arise. Assuming the issue will iron themselves out eventually is not a good way to manage change.
- Frequency is important. Single-member rotation will always cause thrash and lost productivity no matter how well it is planned. A team can only sustain so much change without becoming distracted and losing their center. In complex environments, it may take a considerable time for a new member to build up the necessary knowledge base. Most industry experience seems to circle around a period between six and nine months for the change of one member. More than that and the team might never gain cohesion again. Less than that and silos will begin to form. But, there is no perfect point. You can’t change a member during a critical release for a product, no matter what the calendar says. You have to work with the client team to gain acceptance and cooperation. Timing is a hard nut to crack and will be different in every situation.
This is an important and evolving area of management for outsourced agile teams. It is not widely discussed in the software development industry. Clients come to outsourcing vendors to avoid issues like team cohesion, resilience, and long-term stability. It may be difficult to bring them into a conversation about an issue that is seen as a vendor responsibility.
But, there are some ideas that are coming forward and worth considering. Larger outsourcing vendors can propose a dedicated «pool» rather than a team. The actual team in production continues to be a small number, but the vendor commits to a larger group, perhaps 7-10 including the active team, of developers that are involved and can become a team member with less overhead from change. This allows the members of the pool to become involved in project and product discussions, review code, and be the sounding board for ideas. There has to be an adjustment of the cost to allow this kind of an arrangement and a clear commitment by the vendor to avoiding the issues that are considered part of dedicated team contracts, but in certain situations, it is worth considering.
In the final analysis, it is hard to value the practice of rotating team members on dedicated teams. It can seem like a great idea if you have experienced the downsides of long-term engagements where unplanned changes and team stagnation become barriers to success. If the motivation, implementation, and outcomes are not carefully considered and monitored, it can become a serious distraction from productive development. Neither outcome is good so this is an important consideration and the decisions are likely to be different in every situation.
If you have experience with team member rotation (and not just fears or wild optimism) – I would be interested to hear your thoughts. This is still an unsettled area in agile team dynamics.
Scio is a provider of outsourced, dedicated and project teams for agile software development to our nearshore clients in North America. We have experience with many team and project configurations and would love to discuss how we could help with your next project. Please contact us with your questions.
Agile Methodology, Customer Experience, Nearshore, Product Development, Project Management, Successful Outsourcing
Work is always measured in some way. If you are doing repetitive work, the tendency is to measure the number of repetitions, like the pounds of fruit picked by a field worker in an hour or a day. If you are doing knowledge work, the tendency is to simply measure hours of work spent on the problem, assuming that a) the person doing the work has the necessary set of skills and a comprehensive knowledge base of the subject at hand and b) they spent enough time to evaluate the problem sufficiently and provide a balanced solution. If you are doing time and/or payment-dependent contract work, the main consideration is did you complete the work assigned in the contracted period and at the specified cost?
This all seems relatively benign and normal in the world of work because it assigns a value to work that can then be measured and evaluated in various ways. Did you pick more fruit this week than last? Did you solve more problems in this quarter? Did you complete all your contracted work on time and budget?
Software development is, of course, one of the most valuable types of knowledge work being done globally today. Since development is usually the domain of teams and is at this time, largely done with some form of agile and/or lean methodologies, the measurements tend to be a combination of individual and team metrics applied by various means. Some common metrics are:
When we get beyond these three common methods and their minor variations, we start getting into more complex models (!!) that tie team performance, quality, project length, man-hours, adherence to production and methodology standards and complex team models in DevOps implementations.
We Have Questions
At the end of the exercise, however, it is done, we end up with some sort of measurement of the work of software development. But as we do, we need to ask ourselves a few important questions:
What does our measurement tell us? What is it not telling us? If we are measuring lines of code or functions, is the measurement telling us if the work was efficient or just an output meant to produce more (or a given number of) lines/functions over a given period? Were the lines of code or functions really efficient and useful? Programming is very comparable to writing. Some writers are more efficient at expressing thought and others see a more elegant way to express a thought without addressing it directly. Some programmers are more efficient because they reuse code multiple times throughout the source with efficient use of variables. Some functions in a program are critical and getting them right is tough, requiring time and effort. Other functions are simply «eye-wash» and don’t have a real bottom-line value. There as many ways to game the system as there are ways to produce better code with fewer lines. Every programmer, every team, and every project has different dynamics depending on the language being used, the type of environment, the technical problem being dealt with and many other factors. If you use a pure «number of X metric,» you have to be clear about what it means and doesn’t address.- Is our measurement comparable? Can it be used over the long term or compared across projects or teams? Frequently, this is where the complex math becomes part of the equation and frankly, begins to fail to do its job effectively. The more we try to «normalize» measurements across a single project, between teams, and across projects and teams, the more subjective the outcome becomes. Were the technical hurdles encountered at the beginning of Project A really comparable to Project B? If we decide there is a significant difference, how do we adjust for it? Did Team A experience more changes in team composition than Team B? How do we account for that issue? Are we comparing skill levels, experience, time to reach «normal productivity» or some other factor? Was Team A really suited to provide the skills and experience needed for the given project? Did their productivity fail to reach the levels expected because of issues outside of their control? In most cases, the more you try to normalize between measures of productivity between individuals, teams, and projects, the less sure you can be you have a reasonable common measure. And in the end, the question becomes, is a comparable metric what we really need?
Isn’t any measurement better than no measurement? Can we afford to fly blind? Certainly, if you have an outsourced team, multiple teams, and/or multiple projects you have to begin to understand why some projects seem to work well and some don’t. You need to be able to judge if a project is going off the tracks so you can get it back in line before the problem becomes critical. Finding ways to measure performance and productivity would seem to be the best tool to address the common issues in software development projects. But if the measurements we are using aren’t really addressing the problems we have, how are they helping us? Are they really more than just busy work for managers and bean counters?
The more we look at the problem, the more we begin to understand that measurement for the sake of monitoring «something» isn’t really useful. But on the other hand, measuring any aspect of software development is better than monitoring nothing at all and simply hoping everything will work out in the end. Even a weak measurement provides some level of confidence if it is used consistently and we understand its shortcomings well enough.
In agile teams, there is another, more important way to look at things. If we give the team simple methods they agree on and understand, like story points and burn down charts, they will know when they are performing well and when they are pushing too large a boulder up a hill. Inside the team, they know who is consistently performing and producing efficient code with fewer problems. The team knows when its backlog is too great to finish in the allotted time. Team members learn quickly who can be asked for pointers on how to approach a problem properly and who cannot be depended on reliably. We can stand around, pointing out issues with the common ways to measure agile team performance, but their value is those common agile methods are basically useful to the team to understand where they stand in relation to the work ahead of them and their quality performance. Where we get into trouble is when we try to extract the common measures and try to draw larger conclusions from them.
The Reality is – Communication is the Key
If we get past trying to use performance metrics outside of a single project and narrow our focus to what they do for a team inside of a project, we begin to see their value more clearly. The team knows what is going on. They may attempt to fool themselves or others, but in the end, they can see the light in the tunnel and they know if it is a successful end to the project or an approaching train. The problem is to get them to trust each other and the larger team enough to surface the problems they see as soon as they see them, without fear.
The level of trust and responsibility required for open communication and collaboration is perhaps the largest problem faced in software development projects. It is the «why» behind the invention and popularity of the agile and lean methodologies in wide use today. Conversely, the larger the organization, the more critical and costly the project is to the organization, the less likely it is that the team will feel and be enabled to inquire and speak out about the problems they believe they are facing. In a large organization, metrics are the shorthand to avoid having «high touch» with every team and individual. In a costly, critical project, metrics are meant to be the «truth-tellers» to assure stakeholders that things are well controlled, even though everyone knows that metrics can be gamed without much problem. And the more the metrics are relied on, instead of the knowledge inside of the team, the more likely it is the project will get out of hand before the problems are addressed.
Responsibility. Trust. Communication.
So what is the bottom line on measuring performance and productivity in software development projects?
- Measurement is most useful inside the software development team itself,
Planning Poker
where the knowledge resides about what is really going on from day today. Everywhere else, it is just as likely to be smoke and mirrors as it is, to be honest, and useful – depending on who is using the metrics and for what purpose. If the team doesn’t understand the metrics applied and can’t use them to better understand where they are in relation to the work to be done, their quality performance and general efficiency as a team, the metrics will fail to give back their primary value – keeping the team and project on track.
-
The agile methodology relies on individual and team responsibility, trust and communication. If these three points cannot be achieved within a team, agile and scrum are just a bunch of processes and procedures that may or may not be helpful in organizing work. If the team is just «going through the motions» in taking responsibility for tasks, assessing and managing their backlog, and participating in standups and retrospectives, additional metrics and measurement will not provide much value. They will provide information to a larger audience too late to enable outside forces to do more than triage injuries to the project.
- Working through what may appear to be problems or what may seem to be a simple solution requires peer-level coaching and communication, not blame. If we understand that the team itself really knows what is going on – getting them to assess the problem honestly and figure out how to address it requires something other than pointing fingers, avoiding issues and top-down communication. It also means that the team needs to take responsibility, as soon as anyone recognizes a problem could be on the horizon, to consider it seriously and determine both the size of the problem and solutions that could be used to address it. And so what if the team raises an issue that may turn out to be nothing of great importance? We’ve been called to action to look at it and we will all come out of the conversation wiser. If everyone in the conversation addresses each other as a peer, rather than hierarchically, there is a good reason to think that the next time a problem is encountered or perceived, it will be openly addressed, rather than swept under the rug.
Three points to consider and use in conjunction with standard agile and scrum-based tools. You can use more and you can draw all sorts of conclusions from the systems you bring together. But in the end, if they don’t bring immediate value back to a current project, what value are they really serving?
Looking for a development team? Contact us we can help you!
Scio provides nearshore software development services for our client base in North America. We work closely with our clients to ensure that the projects we are involved in have the level of communication and understanding needed to reach successful outcomes. If you have a project where you think we could help, please contact us. We would be happy to discuss your needs.
Agile Methodology, Customer Experience, Nearshore, Product Development
Common Myths & Misconceptions for Distributed Agile Teams in Software Development
Throughout this series, we have explored some of the best practices for agile-scrum teams, but in the light of distributed team situations. Scio provides software development teams – working from our development center in Morelia – for projects throughout North America. Our practices, methodologies, and culture are tuned to distributed team situations in a nearshore deployment. We discuss the realities of outsourcing and distributed teams with our prospects and clients on a regular basis. As we wrap up this series, let’s discuss some of the common myths and misconceptions that we hear about frequently.
There is no additional overhead for projects using distributed teams for agile-scrum projects.
Reality: Shared vision, communication, strong procedures, and planning are part of the required overhead for working smart in a distributed team environment. But, the truth is – these same elements should be part of any software development project to ensure success. While a distributed environment requires more rigor and attention to details, all projects benefit from addressing these issues.
More specification must be done at the start of a distributed team project
Reality: Increasing the upfront development of specifications for an agile-scrum project creates a false sense of security and understanding. When something needs to change, there will be latent resistance. There is an increased focus for the full team on understanding where the team(s) are and assuring knowledge is shared – but that should be a normal part of communication in any situation.
Distributed teams cannot do agile and scrum
Reality: If teams are able to organize independently, are cross-functional, collaborative, etc. – there is an overhead in coordination between teams (scrum of scrums) but mitigation in the form of improved awareness of the state of tasks can keep it to a minimum. It is much better to spend resources on coordination than fixes because one team went off the track, wasting time and resources.
Distributed teams have lower quality, more redo’s
Reality: If teams are cross-functional, managing their own tasks and backlog, enabled to work directly with the product owners, have a full development environment using test-driven development, continuous integration and practice regular builds on the central repository for the project, a great number of problems can be avoided. Regular team-wide meetings for planning, pruning, technical issues are overhead, but they will lower impediments greatly if done with openness and trust.
In larger projects, it is better to work as one team than two or more smaller teams even if some members are not co-located with the majority of team members
Reality: The communication and planning overhead does not go down in one larger team in comparison to two or more smaller teams, it rises. Size matters – smaller, self-organizing teams are more efficient overall. Team members in a larger team have less push to be individually responsible and to participate actively in the project. They can easily «hide» in the larger team. In larger teams, the overhead for work review actually climbs, because of the number of people who have to be informed and communicated with. And if the «larger team» is composed of remote members without properly recognizing them as distributed teams or single outside team members – the adherence to standard methodology, processes and assurance procedures tends to drop dramatically. They are literally «out of sight, out of mind.»
There are a lot more things that could be said, but the bottom line is – best practices matter in all agile-scrum projects. Agile is not a license to operate without structure – quite the opposite. It depends on individual responsibility, communication, and adherence to the processes and methodologies adopted by the project team. Agile is adaptive. It will scale along with scrum to situations with distributed teams. Teams that adopt the practices and procedures necessary to be successful in distributed situations as a part of their regular work patterns will have better results in all situations.
We hope this series has been useful and informative for you – helping you to understand what is «behind the curtain» in successful projects and some of the lessons we have learned in the field. If you have a project that you believe could benefit from a team that understands how to leverage agile and scrum in a nearshore implementation, don’t hesitate to contact us.
Agile Methodology, Customer Experience, Nearshore, Project Management
Organizational & Team Best Practices
In the previous article in this series, we started exploring the general organizational and team best practices for agile-scrum projects. In this article, we’re going to finish up a few basic issues and then move into points for distributed teams specifically.
As we have said, the main issue to be considered for software development with agile-scrum teams is communication. If communication is in any way blocked or stifled by cultural or organizational constraints, the team and the project will suffer. In a very real way, knowing how far along the work is on a given user story is part of that communication. We discussed building the technical elements of a system for test-driven development and continuous integration for projects, but there is an organizational element too. Team members must feel these tools are a part of their obligation to their team. They must use them religiously and fully to ensure the tools are doing the job of maintaining code and the development process for all team members. Here a few simple rules to live by:
- All development team members should check work into the common code base as frequently as possible.
- Automated, continuous builds should be run hourly with full logs turned on.
- Each individual team member must exchange a clean build by the end of their shift. Avoid situations where an individual is allowed to push multiple builds outside team core hours that could take planned work or tasks off course.
- If a specific development issue is to be addressed outside of core hours by developers, ensure the scope, limitations, and boundaries are clearly negotiated with everyone and adhered to.
Distributed Team Best Practices
When a software development project is based on distributed teams, some specific organizational practices need to be considered. It isn’t enough to just set up groups in a couple of places, and expect everything to work like it did when you were all sitting in the same big room and able to just turn around and see your teammate.
The first point to consider is how each distributed team in the project will work. One common practice is to put all the QA (as an example) in one team and to have another team be just developers. The problem is – when locations are role-based, they tend to lose overall team collaboration and become an island to themselves. The tendency in this situation is to move to an «us against them» mentality. To avoid this, set up fully cross-functional teams that have their own user stories and backlog. It promotes the team and individual responsibility and gives them a clear role in the project as a whole.
With that in mind, there are a few additional points to consider:
- Use feature-based, rather than component or layer-based teams because it ensures teams continue to have a feeling of being integrated with other teams with shared vision and knowledge. It also allows them to be more flexible if the project changes. They can take on a different backlog because they understand where the project is going.
Distribute work evenly – don’t allow one team to sit fallow while another catches up. This, of course, implies that regular discussions of workload (a scrum of scrums), dependencies, and assumptions is critical to the balance on the project as a whole.- When a team has a local «proxy» for the client-side product owner, it is critical that that proxy role has daily contact and communication with the core product owner to assure they can make decisions quickly and with the assurance they are in sync with the current vision.
- Each team must feel enabled to clarify issues directly with the client side (they have their own user stories – remember…) and not be tied to a chain of notification. Invariably, notification chains shorten messages, misunderstand the context, and create communication loops that just slow down clarification and decisions.
- Teams must have daily points of contact between them (scrum of scrums again) to discuss progress, dependencies, impediments, etc. and assure product owners are not being quarried about the same issues multiple times.
One Team Member «Outside»
There are times when it is necessary to have one lone team member outside the main development group or even a couple of individuals remotely located by themselves. This is not an unusual situation, but it is one that takes care to handle properly. All the work you do to assure a cohesive, collaborative team can be lost when one remote member is not paying their role and participating in the process properly.
In basic terms, all the distributed team and organizational best practices apply except:
- Single development team members cannot be a stand-alone unit in the same way a minimal team can – so they need to be formally paired with other team members in a way that assures they will remain «in the loop» throughout the project. To make this work, consider pair programming (especially early in the project) and pairing with a specific QA.
- Avoid situations where single team members are outside of the team core hours more by more than one or two hours. Longer isolation will simply assure they will not integrate easily with the rest of the team – they will remain the lone wolf on the outside you have to watch constantly to assure they don’t go off course.
- «Standard practices» (development environment, burndown chart, shared repositories, active participation in meetings, communication systems, etc. become critical resources to assure the remote team member feels they are a fully integrated and vital part of the project. All aspects of processes must be proven, clearly documented and relatively easy to setup and use.
- If the remote team member is new to your procedures and processes, have a standard initiation program as a part of the project initiation or before. The program should include not just the setup, practices and methodologies necessary to understand the way the team will operate. It should also include the reasoning and expectations they as a team member will operate under.
The single team member working remotely deserves some special consideration. They must feel they are part of the organization and able to be productive in their environment. For that reason, it is important to consider if they are working from their home, what kind of set up they have. Do they have good networking? Do they have a regular work area with good ventilation, light, and isolation from distractions? A worker at home, with the TV blaring in the other room or perhaps a baby that requires attention on a regular basis is going to find it very difficult to be as productive as their teammates. What can you do to assure they are not at a disadvantage? Consider issues in the same way you would any impediment in agile development – what can you do to move the impediment out of their way?
The Take-Away
In the end, it should be easy to see that that making an agile-scrum project successful with distributed teams is nothing more than doubling down on the best practices that are an integral part of agile. If they were important in a team in a single location, they are doubly important in a distributed team and have even more impact on project outcomes. Does a distributed team model immediately burden a project with additional overhead? Well, we will discuss this aspect more in the last article in this series, but the simple answer is no. If you have been using best practices for agile-scrum projects religiously – a project with distributed teams just requires a little more focus and diligence. If you were not as judicious as you should be about your practices, then yes, there will be overhead because your risk of failure will be much higher for distributed teams until you get your practices in line.
In our last article in this series, we will explore common myths that crop up whenever anyone proposes any level of distributed teams in software development. Remember, as a nearshore software development provider, these are objections we discuss with potential clients regularly. So join us – won’t you?
If you jumped into the middle of this series, you can go back to the start here.
