Category: Agile

Online Survey Concept. Tiny Male and Female Characters Filling Digital Form on Huge Laptop and Smartphone Application

Nearshore Agile Software Testing Services

Quality Assurance & Software Testing

Today digital transformation of businesses and lifestyle have an increased need for software products and services of outstanding quality. In combination with the current fast-paced world, companies expect faster time-to-market and continuous delivery of software solutions.

Which can be provided with effective quality and software testing service, the Nearshore offering of software testing services is a response to the increased demands of the local market. Nearshore software testing services can reduce operating expenses while increasing productivity and ensuring the quality of delivered services in the development lifecycle.

Agile Software Testing Services

What is Nearshore Agile Software Testing Services?

Software testing services refer to the process of verifying a system to identify any errors or gaps in a software application or program so that it functions according to the client and end-user requirements. 

 

Every product deserves to be delivered to the full specifications required by the client, which means quality assurance needs to be thorough, deliberate, and efficient. The traditional means of software development is known as the Waterfall method, which splits the build process into a series of steps. This linear design provides a clear course of action, but sacrifices versatility and seamless delivery.

 

Agile Software Testing can be implemented at the start of the project with continuous integration between development and testing, something the Waterfall method cannot deliver. Rather than being sequential, Agile software development is continuous.

 

And, nearshore refers to the geographical location used for outsourcing projects and services to partnered companies. Most business-minded people are already familiar with offshore and onshore outsourcing, which leverage overseas partners and in-country third-party companies respectively to supplement your software development teams.

 

Nearshore, by comparison, is used for outsourcing companies that are situated within the same time zones used by your company but reside within the borders of a separate country. This allows you to have your quality assurance and software testing extended teams be in a location that is close to the country of your headquarters. A great nearshore location for companies in the U.S. would be Mexico.

What is Nearshore Agile Software Testing Services?

Nearshore is a form of outsourcing that refers to services delivered from an adjacent or nearby location.
Any outsourcing location “near” to its primary market (i.e. Eastern European countries to Western European Countries). Some analysts describe it as services delivered from an adjacent or nearby country.

 

Manual and Automated Testing

Testing can be done both manually and automated. Manual testing utilizes the input, inspection, and attention of human software testers. Automated testing, uses several tools and scripts to do the work.

 

Manual testing is done by a tester to make sure all use cases are working as expected and requires time to validate each case scenario. The software tester works with the application or software, clicking through it to find errors. Manual testing takes some time, but it provides the unique insight of a hands-on experience to help validate the product quality checks.

 

Automated testing is performed by a software tool that executes a test script written in advance. Since each test is pre-programmed, the quality of the tests depends on how well the scripts are written. It’s more reliable and robust than manual, but poor programming may lead to missed bugs in the product.

Benefits of Nearshore Agile Software Testing

Creating software products is a complex task, any project or product in the first iterations is difficult to make bug-free. Quality assurance and testing are crucial in solving these errors, preventing potential system failures that result in higher costs. Having the right nearshore software testing services will guarantee that a dedicated team will work from the beginning of the project on identifying and removing errors on time. This will increase software quality and reduce maintenance costs.

 

The initial development stage is critical for identifying errors, and issues before they become bigger problems. Quality should be one of the main concerns for all software projects from the early stages, ensuring that potential mistakes are minimized.

Principles of Agile Software Testing

Here is a list of some fundamentals of agile software testing. These principles should drive every team’s software development process, reporting, and determining the most effective team strategies.

 

Everyone Should Tests

There are no individuals within your software development teams that are exempt from testing the product. This means that all developers are tasked with interacting with the application and systems, putting more hands on deck to potentially pick out any vulnerabilities and weaknesses within the design of the program.

Continuous Testing

Agile development requires the team to test the software regularly, any product increment should demand running testing use cases again, and again. New issues could arise at any moment, so that is why testing help to reduce bugs quickly and effectively. Both manual and automated testing techniques are very useful for delivering continuous releases of the software product. 

Testing Improves the Team and Project

The feedback generated through the continuous testing process repeatedly informs how you can meet the requirements of a software product. Each time you test, you learn more about what needs to be done to improve the project. The more testing is done, the better the team becomes in all the specifications of a given project.

Faster Feedback Response

Continuous feedback translates to more immediate response times. With every project iteration that comes across, testing reveals more feedback about what needs to be improved. Constant attention to product incremental during each sprint will increase the team’s capability to address any issues, creating a faster cycle of development with greater quality.

Good Coding Practices

Each time the project moves through on a continuous testing cycle, your team of developers fixes any new defects. Every iteration delivers a better, improved version, effectively improving, and optimizing the final code. Adding up new features and having a continuous testing practice will help the end product and end-user have a better user experience.

Minimmum Documentation

Creating documentation for every phase, iteration, or testing cycle is extremely time-consuming. The agile manifesto states that people, interactions, and working software over comprehensive documentation, there is no real need to document every single step. Agile software development and testing promote the use of checklists rather than filling documentation templates per cycle. These checklists focus on the essence of the test and results.

Test-Driven

The agile process for software development is executed with the corresponding testing before releasing functionality. Agile in comparison with waterfall does not wait for the whole project to be finished in order to do testing cycles to see if it functions properly. Every product incremental during the agile building process is done through testing, ensuring continuous participation in the quality of the product.

Nearshore IT solution provider

At Towa, we are certain that these elements serve as a great foundation to build a powerful value proposition for users of IT services.

 

The Nearshore model is much more efficient in achieving higher percentages of work performed at a lower-cost location than offshore.

 

Value propositions

  • Leverage proximity 
    • Proximity and time zone
    • Cultural affinity and ease of doing business
    • Cost savings
  • The total cost of engagement

Although nearshore rates tend to be higher, the overall cost of nearshore engagements is equivalent to or less than offshore, because of the efficiency gains that working in close proximity to the US and in the same time zones can bring.

 

Productivity gains

  • Global nearshore 
    • World-class cost-efficient services
    • Fill the gap left by India centric global sourcing
    • Outstanding customer services
    • Reduce the complexity of IT services management
    • Globalize IT operations
    • Optimize costs
    • Support the evolution of the business

 

Nearshore software testing 

Increase software quality, reduce costs

 

Today’s software applications are increasingly intricate, often operating within multi-layer, multi-platform environments, and shaped in rapid and agile conditions, with increasingly ambitious requirements.
In this complex scenario, software testing becomes even more critical as a means to assure quality and minimize risk, while meeting the market and organization’s needs.


Towa provides a robust and comprehensive testing practice that identifies the correctness, completeness, and quality level of software products. Towa enhances productivity and increases communication with the development teams while helping clients achieve significant cost savings.

 

Services 

  • Quality assurance
  • Software testing
  • Test automation
  • Performance testing
  • Mobile testing
  • Security and penetration testing

IT Services Nearshoring 

 

Towa´s goal is to improve the efficiency of all processes throughout the application lifecycle from vision and development to implementation and continuous maintenance.

 

Services 

  • Application development services 
    • Application modernization
    • Business intelligence
    • Custom application development
    • System integration
    • Ecommerce services
    • Open source
    • Mobile

 

  • Application value management 
    • SLA Management and monitoring
    • Requirements management
    • Configuration management
    • Transition management
    • Communication management
    • QA management
    • Risk management
    • Change management

 

  • IT infrastructure services 
    • End-user support services
    • Server and datacom support
    • IT business process support

Nearshore cloud solutions

Cloud technology maximized


Leading organization are controlling their futures by using the cloud to drive change and innovation, build new business models, and follow new opportunities. 


Towa takes a holistic approach to leveraging the cloud with our architecture and advisory Services, Cloud Migration and Application Development Services, Managed Services for Cloud Hosting, and Cloud Application Support Services. We combine all these services into one package and deliver a solution that allows you to phase your implementation of the cloud relative to the business requirements you have. Our approach to the cloud combines both business and technology, ensuring a positive result.

 

Services

  • Cloud architecture and advisory services
  • Inventory application portfolio
  • Cloud roadmap and strategy
  • Build business case
  • Architect solution
  • Cloud migration and application development
  • Cloud application migration
  • Cloud application development
  • Managed services for cloud hosting
  • Cloud hosting
  • Software as a service
  • Managed storage and database services

Conclusion

 

Agile development is a proactive strategy for delivering the highest quality assurance for every project. Constant assessment maintains a system that continuously improves the product, polishing its design until the code, functionality, and interface are performing as expected. Combining agile quality assurance with the convenience of a nearshore outsourcing team delivers premium digital products at an affordable cost with accessible collaboration.

 

Towa is a leading firm across the United States and Mexico for software engineering and outsourcing, including QA and testing. We offer from Mexico our over +300 engineers capabilities as nearshore delivery model service offerings. If you want to learn more about what we can do for your company, contact us here.

 

Towa Software has over 20 years of experience to guarantee the quality of every line of code, we are proud of our products and services delivered. We recommend starting small and build trust with your provider before scaling. 

 

We have expert Project Managers and Innovation Consultants along with top talented teams who have delivered awesome products to customers in U.S.A, Canada, Mexico, London, and Australia.

 

As a leading software development outsourcing company in the USA and Mexico, we have extensive experience in many fields including fintech, banking, payments gateways, e-commerce, retail, marketplaces, health care, Omnichannel, and many more.

 

You can contact us at support@towasoftware.com or give us a call via (+1) 210-787-4525 for more information.

Contract Tips: In Software Outsourcing Agreements

All company sizes, any business can potentially benefit from outsourcing talent. Instead of taking an in-house approach for a team of developers, outsourcing top talent and management skills can save enormously in the software development budget.

It’s a win-win, you will have more time to focus on your core business strategy. And you will hire a dedicated team of skillful engineers to carry on the heavy work of development and launching software products. 

Keep in mind that any contract for software development is different for each type of company. It will be good to have a lawyer to tailor and structure the core areas such as fees, expenses, the scope of services, and costs from time to time.

Why software development agreement is important?

By signing a software development contract, you can protect your business from some downfalls. If not carefully doing it right, you can time-draining legal dispute. Don’t worry. The contract is your best protection against inevitable conflicts over things like:

 

  • Specifications. This is one of the most important elements of the contract. A well-written scope of work (requirement specifications) defines out exactly what the finished product will be like.
  • Payment. What payment terms are agreeable to both parties and when.
  • Work phases. Determine how much work needs to be completed at each stage of the project.
  • Intellectual property rights. Ver important, who owns the software, source code and technology.
  • Copyrighted material. Who owns the copyrighted material that goes into software development.

 

At Towa Software, we have more than 20 years of business experience. When developing a new project for our clients, we will outline the specific requirements like audience research, deadlines for particular areas, prototyping, UI/UX design, coding, testing, DevOps, and many other activities that are needed. The software development contract helps many clients ensure that the software outsourcing company and the client are on the same page, clearly stating development services, timelines, payments and more.

What you should take into consideration when hiring an Outsourcing company?

Watch for contract loopholes in an IT outsourcing contract. There are dozens of common mistakes you can make.

Before the master contract is signed, ready carefully.

Let’s learn what to watch in contract loopholes in software outsourcing, from personal experience. 

Most Popular Types Of Outsourcing Contracts

First, you should be clear about what types of software development contracts are available.

When outsourcing a development team, it is hard to have full control over the work process. Before the project begins, the most important thing you can do is to clarify all the requirements of the contract in detail, most importante is the scope of work.

What costs are involved? Is there any hidden cost? What price rates will be agreed upon? 

Let’s find out the features of each contract for outsourcing services, most commonly used.

Towa Software Agile Remote Teams in Mexico

Fixed Price Contract

A fixed-price contract determines the price of a certain scope of work, regardless of the actual time of end-to-end implementation. Moreover, this type of IT outsourcing model can provide financial incentives for achieving specific project milestones and reach goals.

  • A good option for short-term projects
  • Client and Outsourcing provider agree on a ‘fixed price’ for the service
  • The price is estimated by outsourcing company based on the well-defined scope of work (requirements)
  • The downside is little or non-flexibility under this type of contract for adding or changing the scope of work

Time & Materials Contract

Different from the fixed price project, the T&M model does not need a detailed estimate of all the features and requirements. The client pay for the hours spent on the development of a determined scope of work. Ideal for long-term collaboration: 

  • The Client pays the outsourcing company for work time and used materials monthly.
  • In contrast, to Fix price, T&M allows a great level of flexibility in development, to change requirements, and to allocate resources according to business needs. 
  • Ideal for long-term cooperation.

Dedicated Team Contract

This software development contract model will fit better for all kinds of development tasks. A dedicated team will only focus and work with your software project to achieve results and become a high-performer team in little time.

At Towa Software, we have been proving this model of contract for some time now and believe it is the best way to consolidate an outstanding team, with top talent, dedicated only to your product.

  • More for a long-term project with flexibility and potential to scale
  • The whole team is in one place or remote, same time zones and cost savings
  • The team is managed by senior experts and specialists to guarantee results
  • Highly motivated team members quickly react to any issues and changes
  • The whole team is dedicated to your success

Now that we have discussed in general terms the most used models of contracting with a Software firm, it is time to bring some light to the most common mistakes people suffer when hiring a team of engineers, watch for these loopholes.

How To Avoid Contract Loopholes In Software Outsourcing?

It’s usually the client’s choice to select between Fixed price, Time & Materials, and Dedicated Team for hiring a software development company.

All types of outsourcing models have their risks and opportunities. Even with all things being considered, we strongly recommend watching for these key points to reduce the risk of contract loopholes.

Define Development Specifications

Specifications are the main part of any software development contract. If you don’t clarify what the final product looks like, how it will look, or what customers expect, it’s hard for the development team to build a product that meets your need.

 

Your contract should clearly define:

  • All the functions integrating with your product.
  • Write down the details of the project, be as specific as possible.

 

Also, the contract should describe the development services that you expect your partner to provide. It also shows the procedure of making changes to the scope. Ideally, we recommend stating any changes proposed by each party as following:

  • How many times you can change a request.
  • A description of the change.
  • What is the result of the change has on the project cost and time.

Project Timeline

Every project should have a defined plan. The project should state the hourly rates, development phases, milestones, and deadlines. Defining each stage also helps you and your software provider. Just make sure all supplementary documents are signed by both parties.

 

There are project management tools that help you to manage an effective timeline such as Asana, Smartsheet, Trello, Monday, there are many tools for tracking these activities.

Payment Time

As we mentioned before, the most common forms of payment agreement are:

  • Fixed-price means the price is paid for an entire project. It can be helpful for you to know upfront what the project will cost. This type is less flexible for changes but gives more certainty on how long it will take to develop.
  • In Time and Materials, you have to pay for the time spent and the cost of materials. Time and materials contract is easier to kick off. Because it requires less preparation and planning. Besides, the development team has more flexibility to maintain the high quality of the project.

 

Your contract should detail a schedule of payments including:

  • The date that each payment must be made.
  • How payments will be made.
  • Additional fees that may be incurred.

 

Planning payments ahead of time is always a better practice, know your cash flows and payment due dates in advance.

Cost Estimate 

Cost savings is arguably the major reason to outsource services and staffing. However, one of the common contract loopholes in IT outsourcing is also about the cost.

It’s easy to fall into the temptation of selecting the least expensive providers to save money. Unfortunately, sometimes the lowest bid comes with poor quality.

Nobody wants to provide a negative experience for a customer. So you and your software outsourcing provider should be made clear what are the communication channels, deadlines for payments, and if there is flexibility.

To avoid mistakes in your contract, you have to set all the rules for payment and service.

User Acceptance Testing

In general, acceptance testing is done at the end of each development phase or Sprint. If your provider has a specific QA process that should form part of the testing, it should be documented. The agreement should also note the time assigned for testing, fixing bugs, and warranty time after launch for proving support for any defects or incidents. 

 

For Testing, you should note the following

  • Who does the testing?
  • How long does it take?
  • What is the warranty for bug fixing?

Measure KPIs

Your outsourcing contract should specify the key performance indicators of the project. When the contract clauses are misaligned with the business objectives, problems arise

 

You should consider SLA, service hours, and service elements, human resources as well as technical resources required. This allows you to prevent contract clauses and have a flexible approach to describing the service.

Duration of Contract

When you signed an outsourcing contract, it means the provider is the right one at that moment. However, things can change with time and business strategy. Maybe, you wish to transfer an outsourced service to another vendor or bring it back in-house development. Contract loopholes relating to exit management should be clear, but they are often ignored. 

 

Therefore, from the establishment of the contract, the exit option must be integrated. What are the elements that will be transferred back to the customer? What are the knowledge transfers that will be provided in case of not outsourcing anymore? When and why could you decided to end the services provided must be stated in the contract. 

Security on Top

Many of the most commonly outsourced processes require the transfer of data. Therefore, it can carry significant contract loopholes with data protection.

First of all, to ensure data protection, there are questions that should be asked:

  • Are the outsourcing company’s services compliant with good data protection?
  • What are the security measures in place to prevent abuse of data?

Outsourcing agreements should cover key data protection issues. Then, the provider has to compliant with the legislation.

The contract needs to cover the extraction and removal of your data.

It’s also highly recommended you take advantage of how the transfer back to your systems can be made securely.

Conclusion

 

When starting outsourcing with a new outsourcing partner, many companies tend to sign the contract without having the resources to manage the agreement. As an Owner, CEO, CIO, or CTO you should know how to follow up on a detailed outsourcing contract. But we highly suggest that you write a simple contract through a clear and structured model of cooperation. Both client and software outsourcing providers should consider including timeline, the scope of work, payment terms, data security, clarify service description, ending clause, and notice periods.

 

Towa Software has over 20 years of experience to guarantee the quality of every line of code, we are proud of our products and services delivered. We recommend starting small and build trust with your provider before scaling. 

 

We have expert Project Managers and Innovation Consultants along with top talented teams who have delivered awesome products to customers in U.S.A, Canada, Mexico, London, and Australia.

 

As a leading software development outsourcing company in the USA and Mexico, we have extensive experience in many fields including fintech, banking, payments gateways, e-commerce, retail, marketplaces, health care, Omnichannel, and many more.

 

You can contact us at support@towasoftware.com or give us a call via (+1) 210-787-4525 for more information.

 

You can Book a 15-min call call with one of our Customer Success Managers for a conversation.

Build a Self-Managed Tech Team

You can build a technology and innovation self-managed team to boost your organization.

 

What is a high-performing team in software engineering?

 

There are different several ways to define performance.

One way that makes a big difference is how much the team is dependent on its leader. When the leader makes all the decisions, it limits the team’s potential.

You can measure the effectiveness of leaders when they leave either for a short time or permanently. If team performance declines, it’s a sign that the leader didn’t create the conditions for the team to manage themselves.

Why do self-managed teams need a leader?

You can see the top-performing teams in the world, like sports teams, for example.

  • What do they do?
  • What are the conditions?
  • What behaviors do they demonstrate?

Is the coach on the field during the game to make all the decisions? No, coaches do most of their work before and after the game. They give feedback, share insight, give advice, and prepare their players for the next game.

Inexperienced managers often have a desire to make all decisions, even those on the front lines. They get impatient, and take most of the decisions rather than see them learn from doing or coaching them to improve.

The role of leaders is to get the best performance out of the team.

And to make the vision and goals clear for all.

Build Tech Teams from Mexico
What is a self-managed team?

How a team makes decisions? Is the leader approving or making every decision? The role of the leader is to make employees think for themselves.

In a self-managed team, even the most junior employee is empowered to make a meaningful decision that affects the team’s performance.

When working with your team always ask these questions:

  • Is the company/project vision clear?
  • Are the company/project goals clear?
  • Do you understand what we’re trying to accomplish and objectives?

Everybody has to think of these answers to be a winning team.

Set the common ground and start coaching from there.

In software, teams are very common an engineer comes to you and asks, “What should I do? How should this work? Is this the correct way to do it?” You can respond by asking back, “What’s the goal we’re trying to accomplish? Which direction do you think would serve the vision and our goals better?”

Managers often decide for the person because it’s faster. Then the same engineer goes and does what the boss suggested without taking the time to think why?

It is a far better option to make the engineers think through the vision, the goals, and the trade-offs. Once they’ve done it, they can tell what options are better and why.

The coach has to point out potential flaws in their reasoning. Maybe they made an inaccurate assumption, other data, or a different approach.

Managers must teach engineers how to think about complex matters.

Engineers should consider the vision, the goals, and the data, so they can decide on doing some analysis.
When your engineers do this, you can coach them to solve complex problems, instead of solving for them. At that point, a team member can grow.

How to develop a self-managed team?

Every challenge is a learning opportunity; don’t take them away from the team. Ideally, they should be making most of the front-line decisions.

But even after deciding for your team, you can sit down with them and explain the reasoning behind the decision.

It’s worth investing time into because if everybody on the team thinks and analyzes by themselves, they all can move faster.

How do you measure the performance of management?

A manager being overloaded with work may be a warning sign. Managers should delegate more responsibility to their team and let them own it autonomously.

Strategies for leaders to build self-managed teams

 

1. How often do engineers ask the leader to make decisions

 

Watch for these types of questioning:

  • Can I do this?
  • Should I do this?
  • Am I allowed to do this?
  • Do you approve this?

2. Do more coaching

Don’t make decisions for them, unless you have to. Instead try, when they come with questions, ask back, “What would you do in my place?” make them think through the problem. Or try explaining, that you want them to think for themselves, analyze and take decisions, to become a more complete professional.

 

3. Encourage the team to make decisions

 

Growth happens when somebody gives you an opportunity and trusts you to make it happen. You need space and support to deliver a goal.

A good manager can get results. A great manager can get results and grow their people, so they can do the same for others. Most people are open to and grateful for these opportunities. They see this helps them to grow.

Build Tech Teams from Mexico
Communicate purpose to become a self-managed team

Set a clear expectation for them to think for themselves and to make decisions. Ask them to think about it and make a proposal.

Always clarify the vision and the goals first.

Leaders are not the right people to make frontline decisions. They must help the individual collaborators to make the right decisions.

Help them make decisions, and coach the thinking process and reasoning.

Requisites to become a self-managed team

 

Be patient, building technical self-managed teams takes time. Managers need to observe each team member’s thinking process and select if they are fit to be self-managed.

Some people are not comfortable making decisions. They might be slowing the performance of the overall team.

Take the time to evaluate your team and make sure they’re capable before you expect them to work autonomously. You may have to replace some people, but building a team of leaders empowered to make good decisions makes a lot of difference.

The mindset of critical thinking and growth is required.

Whether it’s possible to turn your team into a self-managed team, depends mostly on the team members.

What should I do now?

 

If you are interested in hiring a self-managed tech team from Mexico, contact us for a free consultation.

Our engineers have deep knowledge of web development and cloud, with many success stories building e-commerce, marketplaces, mobile apps, fintech, payments, banking, and retail.

 

Learn Why Towa Managed Teams is the right fit for your company, book a 15-min call with us now.

Tips for Product Backlog Management

Product Backlog Management

 

A

s a Product Owner, you are responsible for Product Backlog Management, in order to maximize the value of the Product. The Product Backlog is the single source of truth which contains all the work to be done on the Product. As a Product Owner, you will have to make some choices about what to build first and what to build later. But also what to build and what not to build!

 

In this article, we’ll cover tips about Product Backlog Management.

Tips for Product Owners:

Keep the Product Backlog manageable

A mistake we see many Product Owners making, is that their Product Backlogs are way too exhaustive. The worst Product Backlog I’ve ever encountered contained about 650 Product Backlog Items. This was hell! It was unmaintainable, it was impossible to manage, it was impossible to create transparency and nobody knew where the Product was heading towards. Typically, everyone understands that a Product Backlog of 650 items is unmanageable and this may have been exceptional. But what isn’t so exceptional is that I meet a lot of Product Owners, who typically have 100 to 300 items on their Product Backlogs. Out of 10 Product Owners, I would say that more than half of them have a Product Backlog containing more than 100 items. As a Product Owner, you will have to make choices! You will have to decide what not to do.

 

Only one Product Backlog

Saying ‘no’ to people is hard, it’s difficult, because we’re often afraid of disappointing people. Saying ‘no’ also feels permanent, definitive. But as discussed in past articles about product value, value may change over time, so something you say no to today, may be something you want to do a few months from today. So, to not forget about these items, we see a lot of Product Owners adding these kinds of items to a ‘separate backlog’. This ‘separate backlog’ operates as a container for all ideas, so that we won’t forget about them. The truth however, is that if something is actually valuable, and people are waiting for it to be delivered, then it will come up again later on. So, if you say no to something today and it’s really valuable, it will come up again a couple of days, weeks or months from now anyway. So, there is no need to keep a separate list! Order, maintain and own one Product Backlog! If you don’t want something on that single source of truth Product Backlog, then just say no! The side-effect of saying ‘I’ll put it on the other list’ is that the ownership of the item is transferred from the stakeholder to you as a Product Owner. It also means that the stakeholder will be expecting you to do something with the item. What I often see happening in these situations, is that stakeholders will eventually start complaining that they never get what they asked for…

 

Share some tasks to the Team

Since the Product Owner is responsible for Product Backlog management, many Product Owners want to do all Product Backlog management activities themselves. This isn’t necessarily a bad thing. However, you are allowed to let your Engineering Team support you in managing the Product Backlog! So let them help you! As a Product Owner, you don’t want to describe all the User Stories, acceptance criteria, functional designs, etc. yourself. But, maybe you want to act more as an entrepreneurial Product Owner, therefore more focussing on the vision, the long-term roadmap, the stakeholders, market and business value. So, why not share some of the tasks with them!

 

Not everything is a User Story

We all know the ‘User Story’ a format:

As a <role>,
I want <functionality/what>,
So that <business value/why>.

A User Story is a template which can be used to describe Product Backlog Items. In Scrum, all items on the Product Backlog are called ‘Product Backlog Items’. Some of these Product Backlog Items may written as ‘User Stories’, but others don’t. For bugs or technical debt for example, it often has little or no value to describe such an item as a User Story.

 

Know your Product Backlog

What I see many times in practice, is that Product Owners let pretty much everyone add items to the Product Backlog, resulting in an exhaustive, unmanageable list of wishes. What I used to do as a Product Owner, and worked really well, was that I was fully in control over the Product Backlog. I didn’t have to know all the details of every single item on the Product Backlog, but I did know what items were on it. And I also knew what items I rejected, which ones I didn’t want to do. It is up to you to decide how you want to manage your Product Backlog, but letting everyone add stuff to the Product Backlog often results in reduced transparency, lack of clarity, a wrong ordering and loss of manageability.

 

Reorder continuously

The Product Backlog is a living artifact. It’s something that evolves, changes, grows and shrinks over time. Therefore, you need to reorder the Product Backlog continuously! The ordering of the Product Backlog may change from week to week, so make sure you keep the Product Backlog up-to-date. As a Product Owner, you should make the Product Backlog transparent for all the stakeholders and the Scrum Team. This transparency on the Product Backlog is valuable if and when the Product Backlog is up-to-date. Besides having a transparent and ordered Product Backlog for the stakeholders, you’ll want to have a transparent and ordered Product Backlog for the Development Team. Every Sprint starts with the Sprint Planning and in that meeting you’ll need to have an ordered Product Backlog so that the Development Team can create an actionable plan for the Sprint. Before that Sprint Planning, you’ll probably get some feedback from people during the Sprint Review and you’ll get some actionable improvement actions out of the Sprint Retrospective. So keep ordering and reordering the Product Backlog continuously!

 

 The Product Backlog shouldn’t be complete

A pitfall that a lot of starting Product Owners step into is that they want to create a complete Product Backlog at the start of a new project, especially when they come from more traditional or project oriented environments. They’re used to defining the scope of the project or the team upfront, with all the requirements needed for the project. However, Scrum and Product Ownership aren’t focussed on delivering projects. They’re focussed around products (Value). Product Development is something that never ends, as long as the Product lives, and so, the list of demands, requirements, wishes and more will keep growing and shrinking over time, as long as the Product lives. So don’t try to create something like a ‘complete’ Product Backlog. Create a Product Backlog with the most valuable ideas for the Product and start from there! It will change over time anyway, so don’t try to get it perfect at the start, when you actually know the least!

 

Keep focus on ‘what’ and ‘why’

Another pitfall for a lot of Product Owners is that they are focussed too much on finding and describing ‘solutions’. There are many Product Owners out there that are doing a lot of business analysis, technical analysis and who are creating (functional) designs and descriptions for the Development Team. Although it’s not fundamentally wrong, I have always experienced that nine people have more creative and problem solving power than one person alone. So what I always recommend is that a Product Owner shouldn’t be concerned with the (functional/technical) solution. A Product Owner shouldn’t have to ‘design’ a feature. A Product Owner should be concerned with the problem he or she wants to solve, or the opportunity he or she wants to grasp. For me, a Product Owner should mainly be focussed on the ‘what’ and ‘why’. A Product Owner shouldn’t be concerned so much with the ‘how’. So, use the creative and problem solving power of the team to design the solution!

 

Everyone must see it

As mentioned earlier, the Product Backlog should be transparent for stakeholders and the Development Team. There are many ways of creating more transparency, but one of the most powerful ones is to literally put the Product Backlog on the wall or board! Of course you have to take all kinds of things into account (like a distributed setting or access restrictions), but what typically works great to increase transparency, is to put stuff somewhere on the wall, close to the team, so that when people walk by, they can actually see what the team is working on now, and what they will be working on in the near future.

 

There is more than customer or business value

The final tip for today is that there is more than business or customer value that you need to consider. Of course you want to deliver as much value for customers, users and the organization as possible, but should it be at all costs? Hopefully not! What we’ve seen a lot of Product Owners do, is that they are fully focussed on delivering as much features as possible. But, as a Product Owner, you are not responsible for delivering more features! You are responsible for maximizing value for customers and users! To put it otherwise: You are responsible for the success of the Product. This doesn’t only included deciding on new features or functionalities in the Product. It also means that you should consider resolving bugs, technical debt, improving the Products’ architecture, improving performance and security. It also means you should spend time on test-automation and the deployment/delivery process. If you spend time on automating manual testing and/or manual deployments, you will eventually be able to deliver more value, with higher quality in a shorter period of time!

 

These are the useful tips for Product Owners on the topic of Product Backlog Management! I hope you learned a few things and enjoyed them.

agile innovation design

There are no secrets to success. It is the result of preparation, hard work, and learning from failure.

Colin Powell

Building valuable products: Remote agile teams

Numerous teams are constructing their work into a hierarchy of epic, feature, user story, and task. Using the Scaled Agile Framework (SAFe) has made this hierarchy popular, but many other teams are following that model using the same structure.

Epics provide big valuable products or big valuable changes to products. You construct them into shorter pieces of value so you can deliver solutions to your users sooner than waiting for a killer solution at the end.

 

Features are constructed into high-value stories, which, according to the definition, should provide value in production, and again it occurs faster than building a whole feature.

 

But there is a hidden pattern in the way teams are constructing work into an epic-feature-story hierarchy. Teams use agile tools to manage epics, features, stories, and tasks. But they too often use them to articulate a work breakdown structure (WBS) instead of a value breakdown structure (VBS).

WBS refers to the common, age-old project-management practice of breaking tasks into smaller chunks, allowing teams to estimate time and costs for completion. VBS, instead, focuses on product delivery and sub-products, not tasks and sub-tasks.

Please follow us to detail our findings in building valuable products.

Old thinking ways result in poor user stories

WBS has been used to plan development work for a long time, so it is deeply embedded in our brains. And when we were project-driven, this was a great practice.

 

But with the agile movement for project culture and toward product culture, this method no longer works. You need to think in terms of product delivery and product value.

Rewire your brain

Here are two ideas to help people reframe agile development as a value breakdown structure (VBS) instead of a work breakdown structure (WBS).

 

Method 1: Really understand what you are building, and why…

Here, ask yourself and the team to articulate, at a high level, what they are building. Note that you’re not listing the steps to build it (that’s WBS) but instead are describing what it is (VBS).

 

Collaborate to create a list of what you are building

Let’s imagine the team says you’re building four things:

  • A new report here
  • Modifying an existing report with X
  • A new detail view with a graph for Y
  • Bringing function Z, from older version to newer

The answer could be a list such as the one above, or it could be a one-sentence answer such as “an space ship.”

 

With the team decide whether it’s an epic, feature, or story

In a VBS, epics, features, and stories are the same thing: value delivery. It’s just that each has different rules and syntax due to each having a different level of risk.

Epics are highest risk, features are less risky, and stories the least risky. So epics require more precision to secure you have thought through the risks and have the best chance of success.

Additionally, every epic, feature, and story creates or modifies a product.

So your team need to decide based on the following guidelines:

  • Epics are value that will be delivered to production or be production ready in more than two months.
  • Features can be delivered in a sprint.
  • Stories can be delivered in less time than a sprint.
Group similar types with their product value

Simply ask yourself “How long would it take to deliver this value to production?”

Then simply assign the correct type to the piece of value! Just like that, you now have epics, features, and stories in your backlog.

 

Look at the blocks

Some believe that all valuable work must be visible from the epic level, because the epic level (in SAFe) is also the portfolio level. And the portfolio level is where you make financial decisions about work.

 

But this is not actually correct. All three types—stories, features, and epics—are about value. The goal is to decentralize value decision making and push it downwards, where the risks are low. Stories and features are small, and the product owners and product managers are trusted and empowered to prioritize those types of work.

 

People can also feel as if these stories and features are “orphaned” if they don’t trace to a higher-level container. But, in fact, they do trace to a higher-level container: the product value they are associated with.

 

Remember that all three types either modify or create products. Just ensure that every epic, feature, and story traces to a product.

 

Team work and break down all features and epics

You might have a pile of epics, features, and stories that need to be built. If all of the work is small, you may have only stories. If all the work is big, you may have a list of epics. Or you may have any combination, strictly based on the size of the work. There is no hierarchy here, just a pile of different size work to do.

 

Big items such as epics and features need to be decomposed so they can be prioritized with the other lower-level work. You can do this by asking, “What is a smaller piece of value we could do more quickly than this whole thing?” And as you de-construct them, you don’t do it into tasks but into value items.

 

And once you decompose features and epics into smaller value chunks, you once again ask, “How long would this take to put into production, or to make production-ready?” And again you give them the appropriate epic/feature/story type. Repeat this until every epic and feature has been disintegrated to the story level.

 

Stories do not disintegrated into smaller value; you can disintegrated those into tasks. Note that tasks are the only element in the hierarchy that are like those found in a WBS. They are tasks, not value chunks.

 

In other words, the epics, features, and stories are all value chunks. The tasks are tasks, and they are optional.

 

Eventually every epic is separated into features. Every feature is separated into stories. And all of them are value chunks, not tasks. And thus you have a VBS instead of a WBS.

 

Now the story backlog

So at the story level, you will have a bunch of stories, some of which are standalone, some that trace to features, and some that trace to features that in turn trace to epics. But all stories can now be prioritized against one another.

 

And if they do trace upward, that will be considered during sprint planning. You want to finish a whole feature if possible, so a high-priority feature would increase the priority of the stories as well.

 

Bottom line is that epic versus feature versus story is simply a first-level guess at the size of the effort to deliver value.

Method 2: Adjusting an existing backlog

For teams with an existing backlog that’s more WBS than VBS, this can be quite easy to repair.

  1. Grab the current list of epics, features, and stories and leave it open in the background.
  2. Notice there is a mix of some items that are WBS tasks, and some that are products or value of the VBS type. It is common to have a mix of both styles.
  3. Extract the products or value, and create a fresh backlog with only value delivery items.

To accomplish step 3, take a task-style backlog item and ask, “What product or sub-product does this create or improve?” The answer will be the real VBS item that should be in your backlog instead. If you can’t figure out the answer, then why would you do that task?

 

The third step can be fun and satisfying for your teams. Their new epics, features, and stories are true value work items. Each work item needs refinement, development, test, and deployment. Each is valuable to users.

 

Imagine that your storyboard columns were “refine, develop, test, deploy, done.” Notice that a WBS task-style story doesn’t work on a board such as this: “test component Z” would make sense only in the test column, rather than flowing through them all.

 

Value-type VBS stories, on the other hand, flow through all of this. “New finance report X,” for example: Refine your understanding of it. Develop it. Test it. Deploy it. Done! Value to the user is achieved. But when “Test component Z” moves to done, direct user value has not been achieved.

software-team
Real value on delivery

Once you move away from a WBS to a real VBS, you can easily report on value delivery. Which epics closed? That is value delivery. Which features closed? Value delivery. Stories? Value delivery.

 

So your value delivery reports can simply be reporting on work items closed. And it only works if the work items are real value delivery items, not work breakdown tasks. If every item is a value delivery item, these reports are satisfying and informative.

 

If someone wants a report of value delivery for their dollars, they can now show their recently done backlog and answer that question by just using their work management tools instead of creating PowerPoint presentation. It’s a beautiful and better way!

 

 

Change your focus to value

Many people see their agile work management tools as a hierarchy of epic, feature, and story. And the WBS mindset win, they fit the WBS into the containers of epic, feature, and story.

 

Instead, focus on products, sub-products, and value delivery. Refine and adjust existing backlogs by separating tasks from value. Think of the epic-feature-story hierarchy as nothing more than a first estimate on time. Epics take more than a three months. Features require 1 sprint. Stories are done within a sprint. And all are value delivery items.

Team building: Empowering your mindset

Recently we had given a mindset workshop to a group of engineers who were participating in Engineering Warriors Training® (EWT). We constantly seek to strengthen our training process, where learning is not only technical, but we also aim to provide tools that enrich the engineer’s personal and professional life.

 

We found in the book “Mindset, The New Psychology of Success” of Carol Dweck PhD, that by cultivating a growth mindset the person becomes more open to learn through new experiences; instead of being intimidated by a new situation or something that may be considered difficult, the engineers (people like you and me) will feel attracted and interested, so that they are willing to try harder than they would normally do to overcome the challenge.

 

People with this type of mindset are excited when they face a problem or something unknown; this is seen not even as something negative but as an opportunity to grow and learn. They have greater resilience and therefore greater perseverance.

 

We may think that someone that has born with this mindset has a great advantage over others; however, in Carol’s proposal she shares that mindset is something that can be trained, just as you train your body for a marathon or for any sport.

 

The “growth mindset” is a choice on how to see the challenges that arise in your life: you can see them as big stones that stop your progress, or as learning bridges through which you will have to stretch your capacity and once reaching the other side you will be stronger and bigger than before.

 

A strategy to cultivate the “Growth mindset” is known as “The power of yet”, this is the power of believing that you can improve. Just by putting the word “YET” before any of your thoughts about your ability to solve something, this way you will open the possibilities for yourself, accepting that you are in a process of growth and learning, from which you will come out bigger than how you began.

 

Small changes that we make in the way we see professional and life challenges, will open us up to greater possibilities and better results.

java-development

What are you yet to resolve (become)?

+ Towa Positive

 

Managing Remote Agile Teams: 7 Strategies

How can teams maintain effective communication when they are separated by location and time zones?

Principles like “software over documentation,” “responding to change over following a plan” and “quality interactions over tools” take on whole new meaning when managing remote teams.

Why Agile prioritizes communication

Agile methodology recognizes face-to-face communication as the most efficient and effective means to share ideas. The benefits of sketching on cards or a whiteboard are two-fold — improving the level of understanding and reducing the time it takes to deliver the core message.

 

Most credit the adoption of Agile thinking as the primary driver to create more open, collaborative office spaces no longer punctuated by rows of cubes and team members appearing every so often. Open spaces led to more drive-by conversations between team members and more feedback collected throughout the development process naturally.

 

Unlike smaller teams who do have the option to co-locate, enterprises managing remote teams often don’t have the luxury of sharing the same physical space each day.

 

Team structure options:

  • The stakeholders and the development team share the same physical space.
  • The business is physically separated from the development team with the stakeholders in one office and the development team in another, often offshore or nearshore.
  • The stakeholders and the development team are separated by distance and time. Additionally, the development team itself is distributed across cities or countries.

 

Distributed teams must actively work to avoid falling into communication traps that shift the project process away from Agile development to a decidedly waterfall one. But, the world is a small place even for distributed teams — made smaller by the available communication platforms from Microsoft Teams, Trello, Slack, Jira, or Skype. Promoting the same close communication expectations is the key to supporting the Agile process on distributed teams.

7 Communication strategies for managing remote agile teams

Foster a culture of continuous integration while builds are regularly reviewed and planned.

 

Creating a culture where continuous integration is the norm is especially valuable on projects with extended timelines or while managing remote teams. In this structure, it’s easy to opt for dividing work for teams along technical boundaries. These technical boundaries may be divided by frontend/backend work or even database and services layer/frontend. Team bandwidth or security might drive the boundaries. Additionally, some businesses may be cautious of releasing intellectual property into a cloud-based platform like GitHub.

 

This usually results in the maintenance of two source code repositories with a commitment to merge them later. Resist this. The technical debt that results from this fractured code is more time-consuming to overcome than if the teams had increased the communication necessary to manage just one code repository in the first place. Overcoming any communication barriers to work on the same code base is worth it in every way.

 

The team manages successfully at leading remote teams and achieving this culture will begin to see evidence manifest in the daily communication and behavior of team members:

  • All members actively strive not to break the build.
  • They will provide visibility to broken builds.
  • All will react with a sense of urgency to adjust build issues.
Commit to frequent builds, so you don’t prioritize upholding the plan over agility.

 

It’s easy to produce a giant spec instead of communicating daily with the remote development team or let distance become a reason to stay the course and avoid developing the solution when challenges or barriers arise.

 

Building on a weekly schedule is good, daily is even better. Hold your team accountable to submit a change set to the source code control each time. Then, take advantage of your compiler as a stand-in team member to ensure your source code has reached or exceeded quality expectations. Adding smoke tests can propel this even further.

 

Welcome the human process of developing custom software.

 

Most people assume custom software development is a purely technical process. While it’s true the process is highly technical requiring years of training and experience to run successfully, software development is a human process first and relies on trust between individuals.

 

Promote knowledge sharing on every team. This is less about documenting processes in a Wiki and more about nurturing this behavior in daily stand-ups or any time team members give updates.

 

Support your team to share beyond what concerns to that day’s work. If a team member expects something they are working on may impact another role the next day, call that out. Once team members master the habit of sharing important, forward-looking insights, that’s when true knowledge sharing has been reached.

 

Foster communication between UX designers and business analysts to accelerate throughput by a factor of two.

 

Fostering close collaboration between designers and business analysts, urging extra attention to the graphical interface. This mean additional time is spent creating visual artifacts for the technical team to complement related user stories. The prize? Less questions related to aesthetics and less iterations created as a result of the mismatched expectations.

 

Consider even non-functional requirements.

 

For teams who are co-located, it’s easy to address questions around performance and scalability as they arise. Imagining and documenting requirements with the appropriate level of detail serves as the link between the business and technical teams.

 

For distributed teams, understanding non-functional requirement feature plays an even bigger role. Without specific directions documented for the technical team, it might result in the production of an architecture that makes assumptions about the non-functional requirements resulting in increased rework, and time waste later.

 

Managing a distributed team may mean documenting more.

 

While all Agile teams strive to write “just enough” requirements, managing a distributed team means accepting “just enough” may still mean documenting more than would be created for a co-located team.

 

Distributed team members can’t quickly sketch on a whiteboard to work through a complex concept. Rather than leaving your development and testing teams left guessing on the nuances that would otherwise be delivered verbally, document them and “give the answers” before the test.

 

By augmenting user stories with test or acceptance criteria you can set the technical team up for success without drastically expanding the narrative.

 

Choose a set of communication tools for your team that allows for the usual escalation of communication needs.

 

When teams are co-located, the level of communication needed escalates naturally. It might begin with co-workers speaking one-to-one in the breakroom. If clarifying details are needed, additional subject matter experts may be pulled into the conversation. Then, the conversation shifts from many-to-one or many-to-many, depending on the context. Maintaining this escalation process is essential to create outlets for quick answers or more in-depth conversations despite any distance that may exist between team members.

 

Types of Communication

  • Chat 1–1
  • Chat many-to-1
  • Voice call
  • Visual call
  • Screen share
  • Collaborative Board

 

The ability to ask quick clarifying questions is inherent in how most teams work. In the past, this could be accomplished with face-to-face drive-bys in the office. But, increasingly even teams who are co-located are relying on instant messenger or video calls to accomplish this.

 

Instant messaging is a powerful tool for managing remote teams that include non-native English speakers. The tool allows them the space to craft replies without the pressure of discussing directly (and quickly) with a native English speaker. That said, tools like Microsoft Teams or Slack allow for escalation from messaging to voice and video calls and even screen sharing if needed.

 

While the importance of instant messaging cannot be over-emphasized for distributed teams, watching body language and physical reactions to comments or questions are also critically important, especially when discussing challenges or questions to estimate feasibility or understanding.

What does it take to win with distributed Agile software teams?

No digital tool or communication strategy can replace the determination of the leaders needed to achieve the Team highest potential.

 

Co-Innovate with us.

 

Towa SoftwareBoosting Digital Transformation with best ROI – Remote Tech Teams. 300 strong.

 

Tips for distributed agile teams

“Agile development isn’t any longer considered to work for collocated teams only. Also, teams, projects, and organizations that are distributed are asked to focus on delivering value. Yet, with Agile’s emphasis on -among other things- face-to-face communication, this seems like a contradiction. So the question arises, how to adhere to the Agile principles when applying them in a distributed environment.”

H

ere you will learn about the key success factors for distributed teams. Readers will understand that also distributed teams can benefit from a value system and from principles that are beneficial for small teams. In fact, the two trends – distribution in terms of globalization and Agility – can even complement each other.

Many organizations find themselves faced with the challenge of making distributed agile work. Mergers and market consolidation, geographic expansion, and offshoring have made multi-site development the norm rather than the exception. Companies with sites in competitive labor markets can find distributed team members as an alternative when they can’t recruit locally.

Agile can work in a distributed environment, but it requires work; more effort than you’d expect if you’ve never done it before. Here are eight hacks that can make it easier.

Why distributing the team might make sense

You might not be able to get all the people with the right skills in the same location, but the world is filled with talented, motivated people, and being open to working in a distributed way opens up your options.

Besides, today’s technical professionals have more choices about where they live and work. They may like where they live and not want to move. In short, the people you need may not all live in the same location.

Local culture matters. If you’re developing a product that needs to appeal to customers in different countries around the world, you’ll need people who know the local culture and language. There are also political or security reasons for distributing development—from tax advantages for doing work in certain countries, to restrictions on data crossing country borders, to the need for people on the team with particular security clearances.

As you can see, there are a lot of reasons a business would choose to have a distributed team, and whether we like it or not, the number of remote workers is only going to grow. With that in mind, here are eight simple distributed-agile hacks that can set the right tone for a successful remote team.

1. Recruit motivated individuals

It is possible to make distributed development work; open-source projects do it all the time. They have a couple of advantages that other initiatives often lack.

  1. Their team members are often exceptionally self-motivated, at least if they are committers.
  2. They often don’t have to deal with stakeholders or requirements, because they are often building a project for themselves, so they know the problem domain very well.

In more normal situations, having highly motivated team members is really important, and the remote team members are going to have to be exceptionally self-motivated. that’s because they are going to have to work harder to communicate, stay engaged, and stay focused and productive. They won’t have the informal network of co-located team members to fall back on.

The co-located team members are going to have to work harder, too. They are going to have to make a special effort to engage their remote team members.

2. Create self-organizing teams

The worst thing to do when forming any team is to assign people to work on it; it kills motivation and destroys initiative. Since distributed work is even harder than co-located work—because it requires even greater motivation—the distributed team needs to be strong, with members who are committed to the mission, to the way of working, and to each other. That level of commitment doesn’t happen by accident.

Letting people choose to be part of the team—to work with one another—is an important first step. They must want to work in an agile way, and they must want to work with one another. Let people volunteer to join the effort, and then bring them together to establish their norms and working agreements.

3. Co-locate, at the start, to let teams form, storm, and norm

Forming a team usually takes at least a couple of sprints, sometimes longer. You will make your life, and theirs, much harder if you don’t invest in helping them develop into a high-performing team. It takes time and experience working together as a team to develop the trust, commitment, and mutual accountability that they need to perform well together and to be transparent about the state of the work.

Artificial team-building exercises do little to help teams go through the forming-storming-norming-performing process. Bringing teams together for a couple of sprints is really the best way to develop the working relationships that are essential to future performance.

4. If the effort is large, have co-located teams at each site

Let’s say that an organization has sites in multiple locations, as well as multiple teams, each with team members at every location. In this situation, you’re going to end up maximizing the amount of extra work for everyone.

Instead, you should try to form co-located teams at each location and let them figure out how to share the work among themselves, extending Scrum with a scaled agile approach such as SAFe or Nexus. In this approach, multiple teams are working on the same product.

With a scaled Scrum approach such as Nexus, you help multiple Scrum teams simplify cross-team collaboration by resolving and preventing cross-team conflicts and ensuring that they deliver an integrated product increment with every sprint.

Regardless of which framework you use, you should make sure each team has a Scrum Master. Masters will not only help their own team perform better, but they will also help everyone else who needs to collaborate with that team.

5. Co-locate development teams with their product owner

This sounds obvious, but I’ve encountered plenty of strange situations where this is not the case. I’ve seen companies with the development team in one location and the product owner in another. This really hurts collaboration and communication, so don’t do it. Find a different team or a different product owner, move the product owner to the same time zone, or empower a local delegate for the remote product owner if the product owner is co-located with another team.

6. Invest in collaboration, but invest first in teams

Collaboration technology really helps teams be more effective—distributed source-code management, continuous integration, continuous delivery tools, wikis, video conferencing, and chat platforms such as Slack all help high-performance distributed teams be more effective. But they can’t make a low-performance team into a high-performance team. Lack of these tools can decrease the effectiveness of even a high-performance team, however.

7. Share the pain of time-zone separation

When a team has members at multiple sites, they demonstrate mutual respect by sharing the burden of working odd hours. Some teams make the mistake of having the team with the most members set the workday rules, but this sends the message to teams at other sites that their contributions are not valued as much. Making everyone share the burden is not only fairer, but it also creates a sense of empathy with what other team members have to endure.

8. Minimize wait times

Different time zones increase wait times. When a person at one site must wait for a team member at another to start the day to resolve a blocking issue, the rest of the day is lost. These delays add up. The daily stand-up can help uncover these problems, but the team will have to look not only at today’s work but potentially at tomorrow’s as well to know what issues might block them. It won’t be perfect, however, and some additional delay is inevitable.

Flattening roles and refining the product backlog to spot potential conflicts earlier can help. With dependencies reduced, and with teams having members who potentially can work on any product backlog item, blocking issues and slow hand-offs will be less frequent. But the issues can’t be eliminated.

No shortcuts to great teams

Distributed agile development is harder than co-located agile development. Time zone differences make collaboration more challenging. However, teams with members working at the same site but in different buildings will find collaboration more challenging as well. Being agile requires transparency, which doesn’t exist unless team members trust one another, and developing trust requires time spent working together.

Organizations make a big mistake when they think of teams as simply a group of individuals. A great team is far more than the sum of its members’ contributions. Being part of a great team is motivating—it challenges people to do their best, and it rewards them with a sense of shared accomplishment that individual accomplishment cannot. Great teams take time and investment to build, and they are worth preserving when they come together.

“When distributing work, for whatever reason, focus on forming great teams at the beginning. These teams can be formed with distributed individuals if they are motivated and supported, but it does take more practice on everyone’s part.”

Risk Management Banking Industry Trends

Fintechs and nonbanks now have a substantial influence in the banking industry. They are highly agile, innovative, and aim at exceeding the demands of modern customers in banking services and experiences. Established retail banks need to compete and often play catch-up. Still, they acknowledge the need to change, and change fast.

 

 

 

Agile culture for remote teams

Distributed teams or remote teams are more important now than ever, the new normal requires teams and individuals to work from home or in different locations to deliver products and services. How can we use it to thrive agile culture?

 

Agile development was originally conceived for clustered teams, or teams physically located together in the same room. In keeping with the idea that “the most efficient and effective method of communicating information to and within a development team is face-to-face conversation”, early agile teams were meant to work together in proximity.

 

But today most businesses have a few–or many–distributed teams. This isn’t just a trend; it makes good sense. Distributed teams can work on projects around the clock, and strong talent can be found in less competitive markets. (Not to mention, talent is easily retained by not requiring an undesired relocation.) But the benefits of distributed teams aren’t without some trade-offs. For many distributed teams, it’s difficult to adopt the agile practice of face-to-face interactions.

 

Other challenges that emerge for distributed software teams:

  • Coordinating across time zones
  • Building rapport when everyone is not in the same office
  • Collaborating among different development cultures
  • Scheduling meetings or informal conversations when both teams are online at the same time for only a few hours (or less)

These are real problems. But not impossible ones. Let’s walk through some strategies to help bridge the distance gap between local and remote teams, and ideas to help mitigate other potential issues as well.

 

How to structure cross-border teams

Good software architecture dictates modular design, so structure your teams the same way. Every team should be self-sufficient in developing a single piece of technology, which minimizes the amount of collaboration required with teams in other offices/locations and makes them generally autonomous. When a project does require teams in different locations to pitch in, they can focus on their integration points and APIs.

 

Code reviews also play an important role. Since people are online at different times, distributing knowledge of the code between teams makes support and maintenance much easier. If a production issue emerges when the team is not online, another team can easily step in to support and resolve the issue, thanks to the know-how they gained from cross-team or cross-location code reviews.

 

Building rapport and co-worker affinity

It’s important in any team, especially in agile projects to have solid rapport across the team. Personal connection builds trust, minimizes missed expectations, eases self-organization, and boosts morale. Within your office, take the time to get to know everyone on your team. And, as much as possible, do the same with the people you work within remote teams. Personal connections are important. The stronger they become, the greater the chance of seeing these colleagues as any other, rather than distant coworkers from unfamiliar places without good relationships.

 

TIP: At Towa, each new employee posts a “intro blog” on our internal Communication tool, Towa’s content collaboration platform. The blog introduces the new hire professionally as well as personally (hobbies, interests, family, etc.) which really helps bridge the gap between offices. The more we know each other as people, the stronger we are working together as teams.

 

Above all, nothing replaces meeting face to face. Team members in each office will benefit from regular face time, and that includes video conferencing as well as visits to remote offices.

Video conferencing tools like Zoom help bridge the gap between teams, especially for distributed agile teams. However, teams that rely on Zoom should be aware of certain limitations.

 

  • Video conferencing often allows for a very short window of communication, while working in the same office gives significant visibility into another’s world: challenges, successes, and opportunities.
  • Zoom has done well to address network hiccups. Still, there may be times when network issues occur between buildings that can make video and audio choppy or difficult to understand.
  • Most people still think of Zoom video conferencing as scheduled time. Create a culture of using video chat for spontaneous casual conversation. Also, use instant messaging tools like Slack, Whatsapp, or Teams for quick communication.

 

To help mitigate some video conferencing issues, encourage team members to have regular 1:1 video chat sessions. These can be less formal, and help facilitate knowledge sharing in a casual way. Teammates can use these moments to build rapport and work better together.

 

Remember, tone, voice, and posture play a significant part in communication. In-person time helps the team know their remote colleagues in higher fidelity, which, in turn, makes future video conferencing more effective.

 

 

Building a united culture

There are four simple ways teams can make working across offices easier and share a common culture:

  • Over communicate decisions across all teammates
  • Setting up the development environment for easy collaboration
  • Clearly define the definition of Done
  • Create guidelines for filing effective bug reports

 

Let’s talk more about it.

 

First, when moving from a co-located office to a distributed culture, communication becomes significantly harder. The first challenge is training the team to understand that, when decisions are made, they need to be communicated. This may sound obvious, but it’s easy to forget! Oftentimes important decisions are made in hallway conversations, informal local team meetings, or by individuals. Plus, it can be easy to dismiss small decisions as unimportant.

Communicate even minute details until both teams find a healthy groove.

When decisions are made, everyone in each office needs to understand the decision and ideally why it was made. Don’t use email. It’s too easy to lose important information. Use a content management system like a wiki where team members can easily browse for updates across the team (and get notified of updates via email or Slack group chat tool). You can also use Slack to create channels for individuals and teams to communicate and see updates. Delays caused by team members working on outdated information, hitting a roadblock, and then asking a question costs the team significantly more time than proactively sharing information.

Second, consistent development environments across the team make it easier to work together and track down issues. Spend time creating a simple “Getting Started” guide and overcome first-day friction by automating the setup as much as possible.

Third, when working between teams, clear standards around the definition of “complete” makes it easier to manage expectations and build agreement across teams. A firm definition of complete eliminates the ambiguity in the work. For instance, when shipping a release that involves multiple teams, make it clear what it means to be complete: code written, pull request created, code reviewed, tested, and merged into the appropriate branch.

And finally, when problems come up. Having clear guidelines for bug reports and troubleshooting how-tos makes it easier for anyone on the team to track down an issue. Code review and good automated tests also share knowledge about the code base and empower the affected team to make the fix and validate that the change doesn’t have any unexpected side effects. Thus, no team becomes a blocker.

 

Maximize the golden hours

Every photographer knows “the golden hours” – just before and after sunrise and sunset–is one of the most effective times to take great landscape photos. The golden hours for distributed software teams are when the local and remote teams are both in their respective posts at the same time. When all teams are online, this is a great time for stand-ups.

For teams that share work between time zones, stand-up is a great time to pass the baton so the team just coming online can pick up where the other team left off. And holding stand-up via video conference makes it easy to ask questions and get up to speed so everyone is off and running as soon as the meeting is done.

 

Sometimes teams are so far apart that meetings will cause some form of pain for one team. (Get up at 6 a.m. for stand-up with the other team? Umm… no thanks.) Rotate the meeting time so it’s a shared burden, rather than continually subjecting the foreign team to the odd hours–a sure-fire way to destroy morale. Closely monitor the entire team’s engagement at stand-up. If there is an undue tension, or the team is not getting a lot out of it, team members will begin to disengage and stop listening or sharing. And stand-up doesn’t absolutely have to be a daily meeting. Meet with the remote team a few times a week and use the other days for a local stand-up. Similarly, a stand-up doesn’t have to be a morning routine, either. Whatever time of day is most convenient for everyone involved is the best time of day.

 

Every team is remote

In a distributed organization, the reality is that every team is remote. All teams need to adapt and learn how to share work between locations, communicate effectively, and grow a consistent culture across geographies. The most effective teams don’t just make the remote team adapt to their own culture because they understand that every team can learn something from the others. They seek to find and share successful practices across all locations. They also embrace “we” rather than an “us vs. them” culture.

 

Because the new reality is that most will become distributed. Businesses are working at home, we all need to manage a work/life balance. Teams that embrace both structure and transparency scale more efficiently. When your project scales beyond your location, the culture will be set up to do the right thing.

 

 

 

AllEscortAllEscort