Agile methodologies are now recognized as a structured way to work through ambiguous and complex software problems with evolving solution requirements. Practices such as sprints, backlogs, timeboxing, scrum, can be applied in a variety of ways. They all share a critical core: timely problem-solving and product progress become the responsibility of the entire team, including stakeholders.
We have delivered dozens of engagements with business and products leads driving requirements from one side of the Atlantic (North America) back and forth with development teams working from across the other side (European time zone). This article provides an overview of 6 critical success factors, based on our experience of what works reliably (and what fails).
- When’ is the new ‘Where’
- Agile uses time to handle complexity and rapid change
- Team structure and development culture
- Knowledge and signaling
- Reporting as signaling closes the communications gap
- Planning: strategic and tactical approaches
1. ‘When’ is the new ‘Where’
There was a time when all those software development and all the software developers spent the day in the same room, and the inherent ambiguities of software development could be tackled spontaneously face-to-face anytime between 9 to 5. It was easy to turn around and say, “Hey Bob – I’ve just created a pull request. Can we review it together?” Ironically, old-school face-to-face spontaneity was generally no guarantee of timeliness without the serious focus provided by agile methodologies (here, I mean Agile as used in the context of The Manifesto for Agile Software Development, without ties to any particular methodology.)
Agile with remote teams boils down to this: delivering software that delights your customers and exceeds your expectations.
In fact, remote teams and employees are more common than not, given the pain of commute traffic, expensive real estate, and other geographic realities. When you create a pull request, Bob might be asleep no matter where he lives. So while putting everyone in the same room is not an effective replacement for agile discipline, it turns out that applying agile methodologies across remote teams can be very effective. Done right, using agile boosted with a handful of procedural adjustments can make teams multiple time zones away works exceptionally productive. Better yet, it makes it easier for you to get some sleep.
2. Agile: time tames complexity and rapid change
Translating customer needs into product requirements for software developer implementation is difficult. Product leaders often assume the path of least resistance is for developers to schmooze with product managers informally during a daily standup. But it’s important not to get confused between the comforts of kibitzing and the hard work of discovery.
Discovery needs to be sustainable in order to keep up with changing customer requirements. And the most crucial foundation of successful product development is the team structure. But before we look at who does the work, let’s look at the cadence of the work.
Putting everyone in the same room is not an effective replacement for agile discipline. Don’t get confused between the comforts of kibitzing and the hard work of discovery.
When we kick off a development effort for you, here’s what you can generally expect each sprint to look like.
- 8 a.m daily: 15-minute sync call
- First Monday of each Sprint: one to two hours of Sprint planning. Come prepared.
- Last Thursday of every sprint: sprint delivery, review, and retrospective.
In earlier product planning and development stages, we generally recommend two-week sprints; as launch approaches, we shift to 1-week sprints. This daily cadence on your side is matched by a similar Cadence on the remote developer side.
- A stand-up meeting takes place every morning in the remote team’s time zone across the planet.
- Everyone on the team is present for Sprint planning and retrospective meetings, participating as appropriate
Of course, these are excellent best practices to apply for any agile effort. Our focus is on translating those practices into the results that matter to your product and your company. So let’s take a closer look at who does the work.
3. Team structure and development culture
Naturally, software development requires software developers. Where our approach differs is that we don’t stop there. We set out to ensure you can make the most of those developers without you having to worry where they sit.
As a rule, a remote software development team comprises multiple remote clusters of technical professionals in a single location/office. Most of our projects run with a development team of at least 5+ professionals: in some projects, they sit in one of our dev centers, and on others were in different locations but in the same time zone.
It stands to reason that each cluster should work on the same part of the project or cover the same area of functional responsibility (like QA, front-end development, or UI design). This way, the cluster can harness the opportunity to communicate face-to-face across a full working day and be relatively autonomous. This approach works both for full-stack product efforts, like mobile cross-platform application development, as well as deep-dive technical projects, like a kubernetes based data integration pipeline that supplies machine learning models. (There are many more examples.)
For these clusters to work well as a Collective product team requires a couple of additional well-specified roles, in addition to assigned technical specialty resources. Assignment of the roles varies with the size and scope of the project, and straddle both the client and the development side.
- First and foremost is the Product Manager, the linchpin of every product development effort. The experience level and skillsets of the product manager role vary widely with the context of the customer and the market (it’s beyond the scope of this discussion to craft a canonical definition). They are always deeply embedded in the nexus of business and have direct line of sight to the customer. As a rule, it’s probably not suited to outsourcing.
- The Requirements Manager is a critical role we often see just piled onto the overflowing plate of the product manager, or even worse, just ignored. That’s not a recipe for success. It’s a role we provide as part of the engagement, focused on taking in the requirements received by the product manager and his or her stakeholders, then managing for uptake by the team when the time is right (and holding requirements back when the time is not right).
- The Scrum Manager is the most famous spot on the agile process roster. He/she is charged with facilitation across the team, providing something of a circulatory system for maintaining ongoing scope and execution focus. Again, whether we assign a dedicated full-time scrum master or dedicate a scrum master less than 8 hours a day depends on the scope of your project
For both requirements manager and scrum manager, the amount of time that each spends on active engagement with the team or teams varies with the product scope. It’s by no means required that each be full-time dedicated to the project.
4. Knowledge and signaling
Now let’s look at how the team roles and the team cadence work together.
There are two ironclad practices we utilize in CloudGeometry for every project and each iteration: shared understanding and regular sync calls. All clusters within a project must be updated on the goal of the iteration and responsibilities of each cluster. Thus, all clusters are working in a single direction with no dissipation of energy. Iteration planning and product roadmaps are the vehicles to bring in and promote shared understanding. To maintain this concentrated focus, all clusters have regular sync-up calls and have a structured reporting system.
Since the remote team operates as several clusters, we place a high value on knowledge transfer. Practically speaking, knowledge transfer can be done either on a rolling basis or once per iteration (at minimum a single Sprint, at most a milestone release). The former suggests that each pull request needs to be reviewed by a peer in another cluster; the latter implies checkout of code base once an update lands into production. As it turns out, the second path is preferable, as it excludes dependency on a peer in another cluster, which in turn means that the entire process stays streamlined.
There are a couple of tips that can instantly make knowledge transfer more rewarding and productive.
- Schedule knowledge transfer in advance: allocate sufficient time slots and make sure that both the reviewer and reviewee are within their standard working hours. What everyone involved wants is to have their questions answered, so the lack of time or late evening hours doesn’t undermine the process.
- Come prepared: the reviewer should have at hand the list of questions/topics to touch upon, whereas the reviewee should have the list of points they deem important to go over.
- Knowledge transfer works best when everyone must literally stay on the same page. Saying a thing is good; writing it down works better. To that end, they may want to share screens via a number of means: Google Meet, Slack, Skype, etc.
Great products are primarily the result of great team commitment and empathy. However, there are several unambiguous prerequisites to keep team focus and guarantee high delivery quality. We ensure this by adhering to a strict development process. It starts with a concise task specification and definition of ‘done’ with an optional user story for complex features. Once the feature is coded, it is reviewed by another team member and pushed to the sandbox environment, where manual and automated QA are performed. Once the ‘go-ahead’ is given from the QA team, the feature is pushed to staging where the final checks are performed. Along the way, QA and software engineers work closely with the product owner to ensure that everyone is on the same page, ensuring a successful release to production.
5. Reporting as signaling closes the communications gap
One of the most important goals is to provide a clear picture and status update not only to the management but to the whole team in general. That’s why it is important to use such agile artifacts: meeting summaries, release notes, monthly reports, etc. These signaling actions are a critical failsafe that makes or breaks a project.
A designated meeting leader needs to distribute meeting minutes, archive meeting documents, and provide follow-ups to ensure that ideas discussed during a meeting have been put into action. Providing information between remote clusters specifying what was done and what is planned is a very good tool for reducing communication gaps, showing the latest updates for each person even if he/she was absent on the call or had Internet connection issues. It’s also a robust forcing function to drain inevitable ambiguities that happen between meetings.
Each sprint ends with a prepared release notes document, describing what was implemented and listing all completed tasks regarding new features and core functionality changes.
Monthly reports are typically prepared at the beginning of the month to provide an overview of the progress for the previous month, delineating list project activities, and key tasks completed. These reports also provide analysis of current risks and known issues, provide information about upcoming deliverables, holidays, and vacation plans.
Since time is money, it’s a given that project and feature release needs to be completed in well-scoped time frames. In these cases, we adopt a reporting system to signal priorities and provide updates daily, using Gantt charts and other diagram types as fits with the culture of your organization. It helps identify weak points if they arise and provide information regarding how close we are to the final release date.
During a sprint, you can see the progress in real-time via JIRA boards. Every task is tagged with the sprint number and has a standard flow of “Assigned → In Progress → In Review → Testing → Done” flow. Tasks can then be easily searched with a JIRA filter. A yet more detailed report is provided as a separate helicopter-view table format where additional important details are specified, e.g., the date when a feature has been pushed to production.
As mentioned earlier, the sprint ends with a retrospective meeting to discuss sprint results and lessons learned. Usually, we combine our retrospective meeting with the planning meeting for the next sprint, as this helps ensure continuity of the overall development flow. Continuous calibration helps ensure the timely delivery of planned features and products as well as agility in handling unforeseen requests.
6. Planning: strategic and tactical approaches
Whatever the cadence of your milestone release – 3 months, six months, or whatever – we always start with a sprint outlining product priorities. Generally, we find it useful to compile a presentation that contains the exact list of products to be improved or developed in the year ahead, establishing a shared understanding of the key benefits such products will bring to your business and key features to be introduced.
As a next step, we formulate a high-level vision for each product and store it as a JIRA epic for your review and approval. Finally, a preliminary estimate of what’s required to deliver the epics is defined, and relevant resources are reserved for the projects.
Estimating is both an art and a science. We reserve 20% of team capacity for urgent “ASAP” tasks so that they can be handled in mere hours.
We use weekly or bi-weekly sprints depending on business requirements (again, it depends on the customer and the project). The sprint plan is prepared by the technical product owner based on the delivery timing for products defined in the high-level roadmap and individual priorities for every product. Final prioritization also takes your current business needs into consideration; we refine these in the daily sync-ups with your team, storing issues in backlog as appropriate. For instance, a sprint may contain a set of features for a new online reporting system, with integrated modules of a current system using third-party tools and updates for backend engines that define how ad campaigns run. The sprint may also contain such ‘infrastructure features’ as QA automation scripts, CI/CD pipeline creation, or security-related constraints.
During a sprint planning meeting, we discuss tasks inside the team and define the estimates. Every feature gets allocated an appropriate time slot for coding, testing, and fixes.
Estimating is both an art and a science; we’re well aware that it’s generally impossible to know everything you need to know about will be successful with your customer before they get your their hands on your product. For that reason, in addition to planned features for each sprint, also we reserve 20% of team capacity for urgent “ASAP” tasks and 10% for meetings and code review. The ASAP slot gives you the required level of agility in case critical tasks break the surface so that they can be handled in mere hours. The meetings and code review slot guarantees that the team has enough time to discuss potential issues and deliver high-quality code. Once scope, priorities, and resources for the sprint are defined, the product owner shares it with you for final approval in the form of a concise table. Once the scope is confirmed with your decision-makers, tasks get created in JIRA and assigned to appropriate team members.
Last but not least, Also, every few sprints (e.g., every three months), we include refactoring sprint aimed at stabilizing the code as part of the Sprint cycle between Milestone releases. Typically, this means that we identify algorithm infrastructure vulnerabilities in the backlog and allocate time and attention to make sure they are dealt with before the next cycle.
There’s a tremendous difference between product vision and product execution success. If you want to see how you can lock-in that success, we can help with deliberate, disciplined steps to create, maintain, and improve your product strategy. To be clear, these foundation principles of agile with remote teams boil down to this: delivering software that delights your customers and exceeds your expectations.
Solving for Agile Product Development with CloudGeometry
The approaches described here have been honed over years and apply to implementation and release for B2B and B2C SaaS, mobile apps, data pipelines, integrations, client-side deployments, and a range of cloud platforms. Our teams have substantial expertise in establishing the most suitable strategies for the projects we work on, as well as analyzing the overall picture and tweaking everything on the fly, leading to the best possible results. That experience, combined with tools and specialized expertise, gives you an economically sustainable, reliable, and well-architected end-to-end software product and platform.
Let us know how we can help.
