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.
Agile Methodology, Customer Experience, Nearshore, Product Development, Project Management
Organizational and Team Best Practices
While it might seem that adopting the agile-scrum framework to distributed teams is all about the right tools (especially if you read marketing materials from tool makers), in general, it is more about how you organize your teams and processes than anything else. For that reason, we decided to break this part of the discussion into two sections. Our assumption is you are only going to read so much during your breaks between meetings, on your smartphone….
Project Initiation
There are all sorts of reasons that a «kick-off» meeting is critical for project success, in fact, we’ve already talked about a few in the earlier posts from this series. But in this part of the series, we’re focusing on the organizational elements of a successful agile-scrum software development team.
One of the areas that are especially important is the cohesion and understanding between the individual members of the team. If it is not taken care of the upfront, it can take a long time to build. If you are not aware of the teaming model developed by Bruce Tuckman, this is a good time to start considering it. In short, Mr. Tuckman found that teams follow a regular pattern of «storming, norming and performing» during their lifecycle. If you can shorten this cycle and get too strong performance sooner, you are better off. We have found that kickoffs that include games, team-building, and participative events go a long way to achieving this goal. In fact, for longer projects, planning similar events around specific milestones prevents teams from going back through the cycle later in the process.
There are many guides available for these activities, but regardless of which ones you find useful, the actual activities are not something you can simply jump into and do from a book. It takes practice and experience to successfully integrate team activities into project initiation so the sooner you start using them the better. We have found teaming model to be an excellent resource, but again, it requires some hands-on experience to use successfully.
What do you need to do to assure success for project initiation meetings?
- Include as many team members as possible in a single location, even if some must travel greater distances. The time and expense will pay off handsomely in the end.
- If some team members or teams cannot attend, arrange parallel events that the teams can report on or share in an online conference format (voice, video, photos, etc.).
- Sync your agile – scrum processes, artifacts, and ceremonies across teams and participants with actual sessions during the joint event. Execute sprints if possible (use Sprint 0 as a base). Set expectations with everyone that the processes will be standardized and adhered to across the entire team.
- Establish a shared product vision with presentations, question/answer sessions, product games, etc.
- Agree on core project hours for the entire team (including product owners, proxies, etc.) and communication standards. Core hours should overlap considering the time zones involved. Ensure everyone commits to core hours and provides proxies if they cannot be reached.
- Agree to set regular meetings during core hours even if not everyone expects to be in the meetings. This assures if questions come up during the meetings, they can be quickly answered.
- Agree on timing for sprint planning, retrospectives, and other planning activities. The more standardized the timing for these meetings, the more likely they will be to be integrated into individual routines.
- Learn and respect cultural viewpoints across the team, festivals, language preferences. Plan to share status around holidays, common activities, etc.
- Encourage an atmosphere of fun, respect, and collaboration.
This is a lot to accomplish in any timeframe, much less a day or a few hours. Project kickoffs must be carefully planned and managed. They could and often should take more than a day. We’ve had initial meetings, including initial work, take as long as a week. Once you have dealt with them to and from aspects of the travel, the rest is relatively inexpensive – so don’t push to shorten the time more than necessary.
Best Practices for All Scenarios
Planning component breakdown during the kickoff.
We’ve said that part of making agile-scrum for distributed teams successful is including many of the necessary best practices in all projects, not just the ones with distributed members. These best practices are critical for distributed teams, but also just good practice in any software development project. Your distributed teams will «catch on» quicker if these are part of your regular practice and adapt to new situations better.
- Participation by every individual in the team in meetings is always important. That said, it isn’t natural for everyone. Team members must be positively coached to engage in active, personal participation. Avoiding situations where one person becomes the de facto spokesman for the team helps to ensure team members don’t sit back and not contribute. Trust is an important element in participation. Team members must feel comfortable questioning ideas and playing devil’s advocate when necessary to draw out concepts and beliefs. Each team member must feel enabled to speak directly with the client/project team to avoid forming communication chains that will inevitably muddle and shorten their message.
- Plan frequent live demos and retrospectives with time for questions and clarifications. Communication in these meetings should not be more tightly time-bound than necessary, but when long conversations do surface, don’t be shy about moving them to a parking lot to be addressed in a specific meeting meant to resolve that issue with the right people involved.
- Scrum masters should be careful to practice servant-leadership roles. They need to concentrate on removing impediments so tasks can move forward rather than prescribing how tasks should be done.
- Pre-plan a larger window of future sprints on a weekly basis (depends on the length of sprints) specifically to expose interdependencies between teams, roles, etc. and groom backlogs with the team as a whole.
- Lean to short sprints rather than long and synchronize/prioritize between teams regularly. Avoid situations where a team could go too far down a path before syncing with others.
- Have irregular, casual «brown-bag» sessions to discuss technical alignment, decisions and common ground among members and teams.
- Find ways to rotate team members. Rotation can be between locations, roles, among teams, etc. Don’t allow individuals to become insular units by themselves or with specific team members. Accomplishing this goal can be challenging, but it is especially important in longer projects. Rotation should not be «one way» (always to the client site for instance) and where it isn’t possible, consider remote pairing too as an alternative.
Granted, these points are not easy to accomplish. They take planning and practice to get right – but the aim is to ensure a successful project and enough cannot be said about how much of success is preparation. The next installment in this series will continue to explore organizational and team issues, there is a lot to cover. We will also cover issues related to specific scenarios that we have found take a slightly different approach. I hope you will stay with us to see how important it is to understand software development projects in an agile-scrum environment and learn more about what is needed to extend it to distributed teams.
If you are coming in the middle and want to jump back to the start of the series, you can start here. Or if you are looking for a software development partner and want to contact us, just click here and leave us a message and we will be contacting you ASAP.
Agile Methodology, Customer Experience, Nearshore, Product Development, Project Management
Technical Best Practices
Building on the discussion of distributed agile-scrum teams in software development we started in the first post in this series, in this post we will discuss some of the principle technical best practices our team at Scio has found to be beneficial for distributed agile teams.
Communications for Distributed Agile Teams
One of the most important areas to consider technically is the use of flexible instant messaging platforms. While these platforms cannot fully replace face-to-face interaction in all cases (especially for first-time encounters), they can go a long way toward building the trust and open relationships that are expected in an agile environment. They must be flexible enough to adapt to a wide range of network speeds and requirements while providing text chat, file transfer, desktop/app share, voice, and video interaction. This requires an understanding of the available bandwidth at each location included in the project, technical constraints of the end user environment, and fallbacks that can be used when the normal application doesn’t function correctly for some reason. Messaging tools must be as «transparent» as possible – not creating extra overhead for ad-hoc meetings that are necessary to iron out important details on the fly, while still providing some extra tools that smooth interaction in larger meetings like side-channel text chats. It may seem trivial to simply adopt one of the many tools available for the purpose, but in practice, finding something that can be widely adopted and quickly brought into daily use is more challenging than you might think. Issues to consider include:
- Messaging security – Some industries (such as health care) and some projects may require security over and above that provided by the messaging application itself.
- Standards – Special situations may require some standards or rules of the road for users and in a lot of cases, enforced rules may be the easiest route to providing compliance for issues like branding, copyright, and industry compliance. This can be especially important when desktop sharing is used – are there areas in users systems that should not be shared for some reason?
- Special needs users – Are there users on the team that require or could benefit from voice to text (rather than keyboard) interaction? Is video easier for some users? It is better to find a platform that provides options for special needs rather than trying to build in workarounds after the fact.
- Availability – There is nothing worse than a messaging system no one takes seriously. If it needs to be tucked away, if it is only used when «planned for,» if there is no response when it is needed to answer a critical question, it is just another bit of project overhead and not a useful communication tool. If everyone does not adopt the same tool – much the same is true. This is really not a technical issue, it is more organizational in nature, but it is a waste of time to implement a special system no one is using. Make it part of the agreements in the project kickoff – and use it.
And one additional tool that is indispensable for communications – a camera. It can be as simple as using a smartphone, but having a way to capture white boards, project artifacts and even selfies of team members can be invaluable to bring everyone to the «same page» quickly and to act as a project memory in future interactions or to bring missing members up to speed. It seems like a small point, but if you only think of photos after the fact – it will be too late.
Project Management, Testing and Source Control
Deciding on the project management tools to be used (or not used) during the initial planning session is critical to success. The actual tool used may depend on the standards adopted by the client team before the project starts or they may depend on the type of project involved. Regardless, they must be network-based (so everyone sees the same project status without forcing updates), agile-scrum aware (backlog, burndown charts, etc.), and easy to adopt without a great deal of unnecessary overhead. Another point to consider – can individuals take responsibility for stories and status transparently? Can they update their status as a part of their regular work? For this reason, we use the Team Foundation Server as an integrated part of our Visual Studio environment as a standard. It has agile templates built in and allows individuals to manage their work as part of their development environment. No jumping out to another application. Of course, that said, we do adapt Trello for shorter projects and smaller teams. The right tool for the job is always important to consider.
Today, testing automation, continuous integration, and standardized configuration management are not just good ideas, they should be standard for every project. That said, access and availability for members of a distributed agile team is an important technical hurdle to solve immediately at the start of the project. Along with rules (more on that in the next article in this series) to push early and often rather than «once in a while» it is a critical element of any team environment – especially for distributed teams. It is not something you can easily back into «when you decide it is needed.» It requires consideration for implementation, training and the processes that will be used. Again, this is a subject to be fully discussed in the project kickoff, regardless of who is implementing and using the systems. A single code repository with logging enforced will go a long way toward understanding clearly where the team is and what is really complete at any stage. Again, this isn’t just a best practice for distributed agile teams – all development teams should be regularly using these tools so there is little to no time required to reach productivity with them.
One more thing? Clocks on the wall, for each part of the distributed team, with labels. It seems simple – but when you need to reach someone before they leave for the day – it can make all the difference.
Wiki?
It might seem trivial, but a networked team wiki with space for sharing assets, current status (including builds, etc.), coming meetings, etc. can make all the difference to both communication and «personalizing» interactions between team members. A project wiki can include:
- Project wiki with procedures, contact lists, learning during development, editable spring plans, project artifacts (photos, documents) both up to date and historical.
- Team member profiles with photos, fun facts, recent changes, etc.
- Photos and notes from casual and social team meetings (games, lunches, etc.)
- Hours, holidays by location, agreed core team core hours and days when all team members will be available.
Each individual project may have additional technical issues that have to be considered, but this is the starting point we use to consider the set up for every project. In the next segment of this series, we will consider the organizational issues involved in adapting the agile-scrum framework to distributed agile teams. Stay tuned!
Did you come to the party late? You can find the first article of this series here
Agile Methodology, Customer Experience, Nearshore, Product Development, Project Management
Practices required for distributed teams: Basically Agile (and Scrum!)
The use of the agile methodology in combination with the Scrum framework is a widely accepted industry standard for software development throughout the world. Together the methodologies provide an iterative and collaborative system that has been proven to be adaptable and resilient over a wide range of implementations by teams in the industry.
What makes the combination of these methodologies so attractive and useful in the development of software?
- An adaptable framework for iterative software development that provides the customer working software for evaluation in regular, short increments.
- The ability to deal with incomplete or fluctuating product development concepts during the process of development in a way that allows discovery and adjustment as needed.
- The project team includes formal roles and responsibilities for both the client, development team and each individual in decision making during the development process.
- The inclusion of systems for communication, trust, and collaboration across the entire product development team.
- Recognition that the availability of team members for consultation during core working hours is critical to the iterative production process to assure alignment and to allow adjustment as needed.
- The production process includes regular daily meetings, as well as meetings for production assessment and planning that are focused on understanding the status of committed work, clearing production obstacles, and making adjustments where necessary to achieve goals the team has committed to accomplish.
- Outcomes that have proven to be beneficial to both the client and the development team in the development of successful software applications.
Of course, if you dig into the implementation details of agile and scrum for software development, you will find a number of additional benefits. Each team and project can and does adapt the processes within the framework to fit the constraints of their situation. But with the focus on real-time collaboration and face-to-face interaction, what happens when circumstances combine to require the use of agile and scrum across a team that is distributed across geography? Can the agile-scrum framework be adapted to a distributed team? That is the focus of this five-part series – Best Practices for Distributed Agile Teams.
Adapting Agile & Scrum to a Distributed Team
With the availability of broadband network access across the Internet, as well as the benefits and pressures provided by a global marketplace and workforce – it is critical that the benefits of the agile – scrum framework can be both adapted and scaled to provide their benefits to distributed teams. For the purposes of this series, we will consider any team that has members who are not physically in the same location during core working hours, they are distributed. That could mean the team is spread across a metropolitan area where colocation is both time-consuming and expensive or the team is spread across a wider area – across states or national borders.
The business advantages of opening horizons for software development by distributed teams are relatively obvious:
- A distributed model brings a wider field of skills and expertise into play, often with lower costs.
- Varied experience in both technology and problem-solving can bring more answers to the table with a lower cost of recruitment and faster fulfillment of specialized requirements
- Entire teams can be sourced with less time, training and deeper experience in leveraging agile-scrum for software and product development.
The scenarios for distributed development can include:
- Development team together in a development center with
- Client in a different location, same time zone
- Client in different location and time zone
- Split development team
- The development team is split between locations or combined with a client team in another location or both
- Same time zones or different time zones
- Various combinations – split client team, outside consultants, single team members remotely located
Continuity is Key
Regardless of where the client is, adaption to a distributed agile – scrum model is critical to ensure the involvement of key stakeholders, development and product teams and to achieve the benefits of the framework in projects. In fact, at Scio, we have found that consideration and inclusion of the practices required for distributed teams are critical to all our software development projects – whether they are considered to be «distributed» or not. We have found:
- Using the practices required for distributed teams provides a more scalable base for all software development teams.
- If distributed team practices are not in the standard agile repertoire:
- New projects that require a distributed team have a longer ramp to productivity because team members have to adapt to new tools and practices.
- Projects face a higher risk because situational adaptions selected by teams may not be proven and optimal.
- Teams may have to spend many cycles dealing with organizational issues to reach full productivity.
So, from our experience – adaptations of the agile-scrum methodology and framework to allow a distributed team environment is just good practice. They bring many benefits, including better communication, formalized technical environments, and organizational adaptions. They are a critical part of our work environment and our commitment to our clients.
During the following four parts of this series, we will explore some of the best practices Scio has found to be beneficial for distributed teams and some of the myths that we find are common when the idea is considered by organizations. We hope you will stay with us because there is a lot to know about leveraging a distributed team environment successfully for software development.
Customer Experience, Featured, Outsourced Engineering Team, Product Development, Project Management
Background
Before we discuss this subject – let’s reach a common understanding of what we mean by Soft Skills for Software Development Teams. Developing custom software requires a clear understanding of what the client needs to accomplish with the finished product. If you work in application development, you are aware that often this is a subject the client is not fully settled on when development begins, even if they have planned extensively. In fact, if the client believes they have all the bases covered in their application requirements, it is wise to be very careful and ensure they have the ability to be flexible at both a product and contract level. We all know that things will change as the product is realized and new opportunities present themselves. We also know that unexpected issues will come up during the project and the longer and more complex the project – the higher the risk will be. What we don’t know is how much change the project will need to be successful as envisioned and if that will be acceptable to the client. Realizing a product successfully requires that everyone on the development team is able to see more than the task that is in front of them and is enabled, personally and professionally, to help shape the outcomes. Without that, they are just following specifications in detail, not contributing their experience and insight fully and that can mean that things will go off the rails before anyone can pull them back. For developers to effectively provide the insight and experience they have to the project – they need to be able to use a range of soft skills.
On the other hand, no one can expect all or even some software developers to be business consultants, but in most cases, the same skills we expect our business consultants to have, can make all the difference when they are applied to the project from within the development team.
At a high level – what are these skills? Communication, negotiation, problem solving (creativity), and strategic thinking, but – within the context of the development team and its role in the project. There is a larger, more specific view of soft skills, but we will get to that later.
Scio Development Center, Morelia, Mexico
The team context is critical. If the development team cannot come together to support a concept or conclusion that could be advantageous to the project, it has a near zero chance of moving forward, no matter how valuable it may be. This doesn’t discount the visionary individual who sees the opportunity for change, it simply means that before the idea can move forward – the individual needs to exercise their soft skills to bring their team on board as a first step. And if the team does not feel enabled to exercise their creativity and insight, their soft skills for the concept, it will never happen.
Another common misconception is that roles like Project Manager and operations like communication are in themselves soft skills. Both areas benefit from soft skills greatly, but being a good project manager has more to do with how the role is defined than anything else. In larger teams, where the project manager is more of an administrator and deliverable coordinator, more of the work is defined by procedures, checklists, and project plan maintenance than soft skills, although certainly if the plans go wrong, negotiation becomes key. In these larger scenarios, communication also becomes bound up in processes and notification cycles that are often automated, if not run by assistants and procedures. In smaller agile teams, like we use at Scio for agile software development, soft skills are always important because there are fewer intermediaries and roles between the client and the development team. In general, while procedures certainly exist, they are more flexible and can be changed to fit the context of the project quickly. In these situations, there is little to no buffer between the development team and the key stakeholders on the client team. The better the members of the team are at leveraging soft skills, the better off the whole project will be. Smaller teams have to be creative, able to communicate their ideas and support them with analysis and strategy, and finally negotiate a path to a better outcome.
Is there a process under it all?
There is a process that ties together all soft skills that – when it is done right – makes all the difference. It is the process a team or individual uses to arrive at a conclusion for presentation, negotiation, and hopefully, acceptance. It is basically the same system a business analyst uses to present findings, but it needs to rely more on arriving at the conclusion as something everyone in the team can agree to and support. I bring this up because although all soft skills can be used by themselves, it is easier to see the value if you put them in the context of developing a proposal for a change in a project.
Considering the steps
- Gather Information
- Open, contextual questions delivered with empathy. As you gather information, conversations and the questions in them need to be developed within the context of the organization and with an understanding (empathy) for the people you are talking to. The communication soft skill of developing questions to gather information and delivering them with empathy has considerable value and too often ignored. Not using it properly results in few useful answers («yes» and «no» answers don’t give you any context) and little understanding of underlying drivers.
- Research – Of course, the skill of analyzing sources is critical, but so is using the team and peers as resources in research. They will bring different points of view and experience that can be expose additional lines of discussion.
- Analyze
- Document Scenario – Analysis must be based on the scenario under consideration and it must be documented clearly and agreed on by the team.
- Record Analysis – The analysis, under the scenario, needs to be referenced to the research and interviews
- Team Inclusion – Again, the team and any peers consulted need to be pulled into the analysis through review and discussion to ensure they understand what was considered before the conclusions were reached
- Develop Conclusions
- Attach to research and analysis – by the time you reach the conclusions, you should be able to draw clear lines between the research, the analysis and the proposed conclusion. Referencing back to those areas is key to achieving a collaborative conclusion.
- Team Inclusion – Of course, if the team is going to support the proposal, they have to understand the conclusions and how they were reached.
- Reassess
- Record Current Context – Document the current scenario and how it has changed.
- Cycle Back through the steps and document, changing as needed and adding new conclusions.
The process of developing proposals will use all the general skills above and if we get more granular, some more as well. Ultimately, they are the skills teams need to be successful and clients need to make decisions and gain confidence in their development team. But, the development team should not wait until the problem that needs to be solved is so big that it takes days and reams of paper to present. At that point, it is too late for the team to intervene because of project timelines and pressures. If problems are recognized early and conclusions are well-documented, they should be able to be presented in a short PowerPoint presentation. That is a much more realistic target for a development team if they can leverage their soft skills effectively.
A more comprehensive list of soft skills for Software Development Teams?
We’re not going to go into detail with the list we use of soft skills for our team training – but it is a good look at what we find useful to bring development team members to a level that improves their ability to add value to a project from their experience and insight:
–Thought Skills
- Associative Thinking (Connect the Dots)
- Analytical Participation
- Effective Questioning & Participation
–Team Skills
- Cultural Integration
- Collaboration & Coordination
- Key Stakeholder(s) Identification, expectations, Concerns
- Teamwork & Success (also a personal skill)
–Personal Skills
- Time Management (also a team skill)
- Always Learning, Improving
- Self-Confidence, Interpersonal Skills
These areas, laid against the normal team analysis, project management and delivery skills required for software development, bring a better experience for clients and higher job satisfaction for our team members. But with that understanding of the «why» behind a focus on soft skill development, the biggest barriers must also be understood:
- Soft skills do not come easily, especially in the areas of communication, collaboration and negotiation. Everyone must practice, fail, reassess, and continue the cycle to improve self-confidence and the interpersonal skills that are so important.
- Soft skills take time to develop and in the end, have to come from hands-on experience. One class, one try, does not suffice for training. The ball needs to be passed around so that everyone can get time to gain the confidence necessary. It is like driving a car – you cannot watch a series of videos on Youtube and expect to drive a car properly. You need to get into an actual car and feel what happens as you are moving along to learn and grow.
How can you get value out of soft skills?
As a software developer, can you remember situations where you saw a solution to a problem that you couldn’t properly communicate to your team or client? If you have any experience, you have. Taking some time to research, experiment, make mistakes, ask someone to mentor you in soft skills, can make all the difference. If you have mastered some soft skills, mentor others by doing – don’t wait for them to ask.
As a client, look for ways to support your team and enable them to leverage their soft skills. There is no question we are all made smarter by working together and it lowers the burden on you and your team. You can’t expect all ideas from y0ur development team to be acceptable – but the richness possible from an inclusive, collaborative environment can increase your chances of success and decrease your risk considerably.
As we move forward to achieve better outcomes and a more positive customer experience – custom software development must continue to look for opportunities to lower risk and achieve better outcomes. Development teams can act more as partners in product development and success and less as commodity labor. It is a vision we need to continue to work on – and realize – one person, one team, one project at a time.
