Agile Developer: Role, Skills, Practices and Career Growth

An agile developer is a software professional who works with a cross-functional team to plan, build, test, integrate, and improve working software in short iterations. Instead of coding from fixed specifications, they take part in agile software development by collaborating with product owners and the rest of the Scrum team, responding to feedback and protecting quality in every release.

Key Highlight of Agile Developer

• The role: An agile developer builds, tests, and improves working software in short cycles, in close collaboration with the whole team.
• Core responsibilities: Planning the work, delivering a usable Increment each Sprint, clarifying requirements with the  Product Owner, and protecting quality through a shared definition of done.
• Technical practices: Test-driven development, continuous integration, refactoring, code review, and pair programming.
• Skills: Strong developer skills in coding, testing, and version control, balanced by communication, feedback, and shared ownership.
• Career growth: Moving from sequential habits to iterative delivery, then deepening credibility through hands-on experience and credentials such as the  Certified Scrum Developer. Whether the title reads agile software developer or simply developer, the expectations are similar.

Introduction

For decades, many teams built software in a straight line. Requirements were gathered first, design followed, then coding, testing, and release. The waterfall development model gave this approach a clear structure. For a side-by-side view, see why Agile over Waterfall. The weakness appears when the real needs of users only become visible after the software exists. By then, changing direction can be slow and expensive.

Agile software development emerged as a response to that problem. Formalised through the Agile Manifesto in 2001, it favours working software, close collaboration with customers and the ability to respond to change over rigid plans. Rather than delivering everything at the end, teams release small pieces of value in short iterations, gather feedback and adjust.

This shift changes what is expected of a software developer. Writing code that compiles is no longer enough. An agile developer is also expected to talk to users and product owners, write automated tests, review teammates’ work, integrate changes frequently, and keep the codebase healthy enough to change next week. Collaboration, testing, feedback, and continuous improvement are part of the job, not optional extras.

It is worth being balanced about this. Not every sequential project is inflexible, and Agile is not automatically better in every situation. Some products benefit from upfront design and fixed scope, and many modern teams blend approaches. The goal of this guide is to explain what the agile developer role actually involves, so you can judge how it fits your own context.

The table below summarises the practical contrast that most teams experience when they move from sequential to iterative delivery.

What Is an Agile Developer?

An agile developer is a software professional who designs, builds, tests, and maintains working software as part of a cross-functional team that delivers in short iterations. The defining feature is not a particular language or toolset but a way of working: the developer shares responsibility for outcomes, welcomes feedback, and keeps the software in a releasable state.

In practice, an agile developer takes part in planning rather than simply receiving tasks. They write code and automated tests together, work closely with testers, designers and product owners, and regularly reflect on how the team can improve. Job advertisements often use the phrase agile software developer for the same idea: a developer whose daily habits follow Agile values, regardless of the framework the team uses. Scrum, Kanban and Extreme Programming (XP) all support this way of working.

The role grows out of the  Agile Manifesto  and its twelve principles, which emphasise delivering working software frequently, maintaining a sustainable pace, paying continuous attention to technical excellence and reflecting regularly on how to become more effective. A developer who lives by these ideas treats quality as a daily responsibility rather than something a separate team inspects at the end.

Agile Developer in Scrum Teams

Scrum is the most widely used Agile framework, so many agile developers work in a Scrum team made up of Developers, one Product Owner, and one Scrum Master. According to the Scrum Guide, the Scrum Team is small, self-managing, and cross-functional, with no sub-teams or hierarchies inside it. Informally, people call a developer in this setting a Scrum developer, and the broader job title is sometimes written as agile scrum developer.

Within the team, Developers contribute in four main ways:

• They shape the Sprint Goal: Developers take part in Sprint Planning, help decide what can realistically be delivered, and work towards a single objective that gives the Sprint coherence.
• They create a usable Increment: Every Sprint, the team produces a done, integrated, and potentially releasable piece of the product, not a pile of half-finished tasks.
• They maintain quality: The team’s shared quality standard, the Definition of Done, applies to every piece of work they build.
• They collaborate on the work: Developers pick up user stories, talk through details with the Product Owner, help each other when work is blocked, and inspect progress together each day.

If you want to understand how this role is described in more detail, our guide to  Scrum developer roles and responsibilities  is a useful companion to this article.

Agile Developer vs Scrum Developer Accountability

People often ask whether an agile developer and a Scrum developer are two different jobs. They are not two universally separate roles. Agile developer is a broad description of a developer who works in an Agile way in any framework. On the other hand, Scrum developer is an informal label for a developer working inside Scrum, where the Scrum Guide defines Developers as one of three accountabilities in the Scrum Team, alongside the Product Owner and the Scrum Master.

Under the Scrum Guide, Developers are the people on the team committed to creating any aspect of a usable Increment each Sprint. They are accountable for creating the plan for the Sprint, instilling quality by adhering to the Definition of Done, adapting their plan each day towards the Sprint Goal, and holding each other accountable as professionals. Notice that “Developer” in Scrum is not limited to programmers. It can include anyone doing the work needed to create the Increment.

In short, every Scrum developer is working as an agile developer, but an agile developer might work in a team that does not use Scrum at all.

Agile Developer Responsibilities

The responsibilities of an agile developer extend well beyond writing code. The developer is expected to contribute to planning, delivery, quality, and continuous improvement, usually as part of a Scrum team that shares accountability for results. Titles and details vary between organisations, but the following responsibilities appear consistently.

The table below maps these responsibilities to the  Scrum events  and activities where they usually show up. Treat it as a typical pattern rather than a rule, since every team adapts its rhythm.

Sprint Planning and Estimation

Sprint Planning is where the team agrees why the Sprint is valuable, what can be done, and how the work will be accomplished. The developer’s job is to understand the proposed Sprint Goal, discuss the selected Product Backlog items, and break them into smaller pieces of work that can be finished within the Sprint. Developers are the people best placed to judge feasibility, so their voice matters when the Product Owner proposes scope.

Estimation is a team conversation, not a quote handed to a manager. Where estimates are useful, an agile developer helps the team compare the relative size of items, flags unknowns, and identifies dependencies on other teams, services, or environments. A good estimation discussion often reveals missing information, and surfacing that early is far cheaper than discovering it mid-Sprint. Estimates are forecasts, not promises, and developers should be comfortable saying so.

A practical example: while discussing a story about exporting reports, a developer notices that the export depends on an API owned by another team. Raising this in planning lets the team either reduce the scope, schedule the dependency early, or agree on a workaround. Developers who want a wider view of the frameworks behind these planning habits can explore the  types of Agile methodology  in use today.

Building Increments

The core of the job is turning planned work into a usable Increment. In agile software development, that means more than finishing isolated coding tasks. An item is only valuable when it is implemented, integrated with the rest of the product, tested, and meets the team’s quality standard. A feature that works only on one developer’s laptop is not an Increment.

To keep this achievable, an agile developer works in small slices. Rather than building an entire module and testing it at the end, they implement a thin, end-to-end slice, verify it, merge it, and move to the next. This reduces integration surprises, keeps work visible, and gives the team something to inspect at the Sprint Review. It also means the product is always close to a releasable state.

Collaboration With Product Owners

A common misunderstanding is that developers receive specifications and simply code them. In Agile, the relationship with the Product Owner is a continuous conversation. The Product Owner is accountable for maximising the value of the product and for the Product Backlog, while the developers bring technical insight that shapes what is possible and sensible.

In practice, a software developer in a Scrum team clarifies the intent behind each of the user stories, asks about acceptance expectations, proposes simpler alternatives when a request is expensive, and shares early work to check that the solution matches the need. A user story is a short description of a capability from the user’s point of view, and its value lies in the conversation it triggers, not in the card itself.

For example, if a story says that customers should be able to filter orders by date, a developer might ask whether the range should include future dates, how the filter behaves on mobile, and what happens with time zones. Resolving those questions before development starts prevents rework later. Feedback flows both ways: developers also tell the Product Owner when  technical debt  is slowing delivery, so the backlog can include the work needed to keep the product healthy.

Quality and Definition of Done

The Definition of Done is a formal description of the state of an Increment when it meets the quality measures required for the product. It gives the whole team a shared standard, so that “done” means the same thing to the developer, the Product Owner, and the stakeholders. In the Scrum Guide, the Definition of Done is a commitment for the Increment: if a Product Backlog item does not meet it, it cannot be released or even presented at the Sprint Review.

Developers are accountable for instilling quality by adhering to this definition. Reviews, testing, and maintainable code all feed into it. A change that has been through peer review is more likely to be correct and readable; tests catch regressions before users do, and clean code makes the next change safer and faster. A concrete example is identifying a defect during code review, such as a missing null check that would have caused errors in production, and fixing it before merge.

A team’s Definition of Done grows as its capabilities grow. The table below shows one illustrative example. Your own team should agree on its own list, because the right standard depends on the product, risk, and tooling.

If the team’s current Definition of Done is too thin, the  Scrum Team  should improve it, often during the Sprint Retrospective. A weak Definition of Done is one of the most common reasons teams accumulate hidden work.

Practices of an Agile Developer

The practices of an agile developer are the technical habits that keep software easy to change while it is being delivered continuously. Together, these agile engineering practices make short iterations sustainable. Without them, teams ship quickly for a few Sprints and then slow down under the weight of defects and tangled code. Many of these practices come from Extreme Programming, and they are described in books such as Practices of an Agile Developer, as well as in the Agile Alliance principles, which keep returning to technical excellence and good design.

The 5 Core Agile Engineering Practices.png

Test-Driven Development

Test-driven development (TDD)  is a practice in which tests guide the implementation. Instead of writing code and testing it afterwards, the developer writes a small failing test first, writes just enough code to make it pass, and then improves the design. This loop is usually called red-green-refactor:

1. Red: Write a short automated test for a behaviour that does not exist yet and watch it fail.
2. Green: Write the simplest code that makes the test pass.
3. Refactor: Clean up the code and the test while keeping everything green.

TDD is not the same as simply writing tests after the code. When tests come afterwards, they tend to confirm what was built rather than shape what should be built. When they come first, they act as a lightweight specification, encourage small units with clear responsibilities, and give the developer immediate feedback. Because every behaviour is covered by a test, the team can change code with confidence.

TDD works best for logic-heavy code such as calculations, validation rules, and services with clear inputs and outputs. It is harder to apply to exploratory user-interface work or unfamiliar technology, where developers might first spike a solution and then add tests. A pragmatic agile developer chooses the approach that fits the problem. For deeper technical guidance, read our guide to  test-driven development practices.

For example, suppose a team must apply a discount to orders over a threshold. The developer first writes a test stating that an order just below the threshold receives no discount, then one stating that an order at the threshold does. Each test fails, then passes as the rule is implemented. When a bug report arrives later, the developer adds a failing test that reproduces it before fixing it, which keeps the defect from returning. Together, these habits are among the most valuable agile engineering practices for protecting a fast-moving codebase.

Continuous Integration and Delivery

Continuous integration  is the practice of merging every developer’s changes into a shared mainline frequently, often several times a day, with each merge verified by an automated build and test run. Its purpose is to expose integration problems within minutes instead of weeks. A team that integrates continuously rarely faces a painful “merge week” before release.

A typical pipeline works like this: a developer pushes a small change, the pipeline compiles the code, runs unit and integration tests, performs static analysis, and reports the result. If the build breaks, fixing it becomes the team’s first priority. This keeps the main branch healthy and makes every commit a candidate for release.

Continuous delivery extends continuous integration by ensuring that the software can be released to production at any time. The artefact that passes the pipeline is packaged, deployed to a production-like environment, and verified, so the decision to release becomes a business choice rather than a technical scramble. Continuous deployment goes one step further by releasing every change that passes the pipeline automatically, without a manual approval step.

Many teams practise continuous delivery without continuous deployment, especially in regulated industries or products with scheduled release windows. What matters is that releasing is routine and low-risk. This capability is a cornerstone of agile software development because it shortens the feedback loop between writing code and learning how it behaves in production. Practices that support it include feature flags, trunk-based development, automated deployment scripts, and monitoring that reveals problems quickly.

Refactoring and Clean Code

Refactoring  means improving the internal structure of code without changing its observable behaviour. Typical refactorings include renaming a confusing variable, extracting a long method into smaller ones, removing duplication, and simplifying conditionals. Done in small steps, refactoring keeps design quality from eroding as features pile up.

Refactoring depends on automated tests. Without them, there is no quick way to confirm that behaviour stayed the same, and “cleanup” becomes a gamble. With tests, developers can restructure code boldly. That is why refactoring is the third step in the TDD cycle, and why teams that skip tests often avoid touching old code at all. The practice is also closely related to the idea of technical debt: shortcuts taken to deliver faster that must eventually be repaid. Regular refactoring pays down this debt in small instalments instead of in a crisis.

Clean code is the broader goal. It describes code that is easy to read, easy to understand, and easy to change. Characteristics include meaningful names, small functions that do one thing, consistent formatting, limited duplication, and comments that explain why rather than what. Clean code is not about elegance for its own sake. It reduces the time teammates spend understanding each other’s work, which directly affects how quickly the team can deliver.

Code review is a natural partner for both practices. A reviewer who reads a pull request with fresh eyes can spot unclear naming, missing tests, and design concerns that the author no longer sees. Good reviews are respectful, specific, and quick, and they focus on the code rather than the person. Over time, they spread knowledge across the team and raise the baseline of quality.

A useful rule of thumb is the Boy Scout principle: leave the code a little cleaner than you found it. When a developer touches a function to add a feature, a quick refactoring to improve the area is often enough, with no need for a large, separate rewrite project.

Pair and Mob Programming

Pair programming is a practice in which two developers work together on the same task at one workstation or screen. One person, often called the driver, writes the code, while the other, the navigator, reviews each line, thinks about direction, and spots problems early. The pair swaps roles regularly. Mob programming extends the idea to the whole team, or a large part of it, working on one task together with one person typing at a time.

Both approaches turn code review and knowledge sharing into real-time activities. Instead of waiting for a pull request to be reviewed, the second set of eyes is present from the first line. Typical benefits include fewer defects, better design decisions, faster onboarding of new teammates, and shared ownership of the codebase. Costs include scheduling effort and the need for good communication habits, so teams use these practices where they pay off most.

Typical situations where pairing helps include:

• Onboarding a new developer into an unfamiliar codebase.
• Tackling a tricky algorithm, bug, or architectural change.
• Working on code that only one person understands, to reduce key-person risk.

Mob programming is useful when the whole team needs a shared understanding, such as designing a new service, agreeing on coding conventions, or investigating a stubborn production issue. Remote teams can do both with screen sharing and collaborative editors. An agile developer who is comfortable pairing tends to grow faster, because feedback on their approach arrives continuously instead of in occasional reviews.

The table below compares the main practices at a glance, so you can see where each one fits.

Agile Developer Skills

Being an effective agile developer depends on two complementary sets of capabilities. The first is technical competence, the craft of building reliable software. The second is the behaviour that makes teamwork productive. Strong developer skills in one area cannot fully compensate for weakness in the other: a brilliant programmer who ignores feedback slows the team, while a great communicator who cannot test or debug cannot deliver working software.

It is also important to be realistic. No agile developer needs to master every language, framework, or tool. Requirements vary by product, architecture, and team, and a front-end specialist will build a different technical profile from a data engineer. What matters is a solid foundation, curiosity, and the willingness to keep learning.

Technical Skills

Technical skills form the base of the role. Fluency in at least one programming language and its ecosystem is essential, along with an understanding of design principles that keep code modular and testable. Beyond that, an agile developer typically builds capability in several areas.

• Programming fundamentals: Data structures, algorithms, object-oriented or functional design, and sensible API design.
• Automated testing: Writing unit, integration, and end-to-end tests, and knowing which level is appropriate. Familiarity with test-driven development helps developers think about design and behaviour before implementation.
• Version control: Comfort with Git workflows, branching strategies, small commits, and clear commit messages.
• Debugging and diagnostics: Reproducing defects, reading logs and metrics, and isolating root causes.
• Code review: Giving constructive feedback and responding to it gracefully.
• Continuous integration: Understanding builds, pipelines, and how to keep them green.
• Refactoring: Recognising code smells and improving structure safely in small steps.

As a software developer progresses, they also benefit from understanding architecture, security basics, observability, and cloud platforms. These matter more as responsibility grows, but they are best learned gradually rather than all at once. Many successful developers describe themselves as T-shaped: deep in one specialty, with working knowledge across several neighbouring areas.

Collaboration Skills

Agile depends on constant interaction, so collaboration skills are not optional. The most important behaviours include:

• Communication: Explaining technical ideas in plain language, asking questions early and speaking up when something is unclear or blocked.
• Feedback: Offering specific, kind and timely input, and receiving it without defensiveness.
• Shared ownership: Caring about the success of the whole scrum team, not only individual tasks.
• Adaptability: Adjusting plans when new information arrives, without treating change as a failure.
• Estimation discussions: Contributing honestly to sizing conversations and being open about uncertainty.
• Constructive conflict resolution: Disagreeing about ideas without damaging relationships, and committing to the team’s decision once made.

Pair programming is one of the best ways to practise these skills, because it requires explaining thinking aloud, listening to a partner’s ideas and agreeing on direction in real time. A developer who is known as a strong agile software developer is usually recognised as much for how they help teammates succeed as for the code they personally write. Teams value people who make others more effective.

A Day in the Life of an Agile Developer

No two teams follow the same schedule, but a typical day for an agile developer revolves around a steady rhythm of collaboration and focused work. The day is shaped by the Sprint Goal, the work in progress, and whichever Scrum events fall on that date. What follows is an illustrative example, not a template every team must copy.

It is important to clarify the purpose of the  Daily Scrum. It is a short event, limited to 15 minutes, for the Developers to inspect progress towards the Sprint Goal and adapt the Sprint Backlog as needed. It is not a status report to a manager, and any technique that helps the Developers coordinate, such as walking the board or discussing blockers, can work. A developer who treats it as a planning conversation with teammates, rather than a performance review, gets far more value from it.

Beyond the Daily Scrum, an agile developer’s day usually mixes planned and unplanned work. Some days are heavy on implementation, with long stretches of focused coding and test writing. Others bring more discussion, such as helping a teammate debug, talking through a design with the Product Owner, or investigating a production alert. The common thread is that work is visible, shared, and continuously integrated.

Sample Sprint Day Timeline

The timeline below shows one possible day in the middle of a Sprint. It assumes the team uses a pull-request workflow and an automated pipeline. Refinement or planning sessions only appear on days when they are scheduled.

On a day like this, the developer might pick up a story about password reset emails. After clarifying with the Product Owner that links should expire after 30 minutes, they write a failing test for expiry, implement the behaviour, and refactor the token logic. In the afternoon, a teammate’s pull request reveals a missing validation case, which the team fixes before merge. Before finishing, the developer checks the work against the Definition of Done to ensure that tests pass, the code is reviewed, and the change is ready to release.

How to Become an Agile Developer

Becoming an agile developer is less about acquiring a single credential and more about building a set of habits over time. Whether you are starting out or already working as a programmer, the following progression is a practical way to move towards the role.

1. Understand Agile principles: Read the Agile Manifesto and its twelve principles, and think about what each means for the way you build software. Understanding the “why” makes the practices easier to adopt.
2. Learn the team’s delivery framework: If your team uses Scrum, study the Scrum Guide and learn the events, artefacts, and accountabilities. If it uses Kanban or a hybrid, learn how work flows and where limits apply.
3. Practise iterative development: Break work into small, shippable slices, deliver them quickly and use feedback to decide what to build next.
4. Adopt automated testing: Start with unit tests for new code, then move towards test-driven development and a reliable pipeline.
5. Take part in code reviews: Review other people’s pull requests, and invite feedback on your own. Reviews are one of the quickest ways to learn a codebase and improve your style.
6. Build feedback-driven habits: Demonstrate your work early, ask for opinions, hold honest retrospectives, and turn lessons into small changes.

To check your understanding along the way, the Agile and Scrum practice test is a handy knowledge check. If you are also considering broader project-management credentials, it may help to read whether PMP is worth it for software developers before investing time and money.

To become a credible agile software developer, aim to collect evidence of your progress: a repository that shows small commits and tests, examples of reviews you have given, and stories about how you responded to changing requirements. Employers value demonstrated behaviour over vocabulary. You also do not need to wait for a formal role to begin. Many developers start by suggesting small process improvements in their current team, such as adding a test for every bug fix or holding short design conversations before large changes.

From Waterfall Developer to Agile

Developers who come from a waterfall development model background already have valuable strengths, such as discipline, documentation habits, and an appreciation for careful design. The change is mostly about shortening feedback cycles and sharing responsibility across the lifecycle. The table below shows how common habits shift.

A good way to start is to apply one change at a time. For instance, begin by splitting your next task into the smallest slice that delivers visible value, and demonstrate it to a teammate within a day or two. Then add automated tests to that slice, then invite a review. Within a few weeks, the cycle of building, checking and adjusting begins to feel natural. In an organisation still shifting to agile software development, you may also need patience, because processes, approvals and roles can take time to catch up.

Some developers work alone, as freelancers, founders or maintainers of small products. Agile for a solo developer is still practical, even without a full Scrum Team. A single developer can keep a prioritised backlog, plan in short iterations of one or two weeks, deliver small increments, run automated tests and reflect briefly at the end of each cycle. This agile methodology for single developer work keeps the benefits of feedback and focus, while skipping events that exist mainly to coordinate groups.

Certifications for Agile Developers

Experience is the most persuasive evidence of skill, but certifications can help structure your learning, signal commitment, and open doors, particularly early in a career. For an agile developer, the most relevant credentials are those that combine Scrum knowledge with technical practices. No certification is mandatory, and the best choice depends on your role, region, and goals.

Several organisations offer options. Scrum Alliance offers a developer track beginning with the Certified Scrum Developer. Scrum.org offers Professional Scrum Developer. Other credentials, such as the PMI Agile Certified Practitioner, focus more broadly on agile project approaches. When comparing them, look at the issuing body’s reputation, the practical content, the quality of instructors, and the ongoing renewal requirements.

Certified Scrum Developer

The Certified Scrum Developer (CSD) is a Scrum Alliance certification intended for developers and engineers who want to apply Scrum in practice. It is described as the foundational course in the Scrum Alliance developer track, and it is designed to show that a Scrum developer understands both the framework and the technical practices that help deliver quality software, such as test-driven development, continuous integration, refactoring, and collaborative design.

Based on the current Scrum Alliance information, earning the CSD involves completing formal training from an approved CSD trainer, successfully meeting the course’s assessment, and accepting your CSD licence. Scrum Alliance currently lists at least 14 hours of formal training, although some training providers describe the course as a minimum of two days, so always confirm the latest details on the official Scrum Alliance CSD page before enrolling. The certification is valid for two years and is renewed by earning Scrum Education Units (SEUs), with a renewal fee. Many CSD courses are technical, though some are open to a broader audience.

The credential sits on a path: after CSD, developers can pursue the Advanced Certified Scrum Developer (A-CSD), which requires a CSD and at least 12 months of relevant experience, and later the Certified Scrum Professional – Developer (CSP-D). The table below places the CSD next to nearby credentials. Check each issuer for current prerequisites, as they can change.

To decide whether the CSD is worth your time, ask four questions. Does it match the technical practices your team actually uses? Will the course give you hands-on experience rather than only slides? Do employers in your market recognise the credential? And are you willing to maintain it through continuing education? If the answers are positive, the certification can add structure and confidence to your career plan.

The same engineering and collaboration practices apply across specialisations. A web developer working in Agile, sometimes advertised as an agile web developer, and a full stack engineer, sometimes described as an agile full stack developer, both benefit from the shared habits of testing, continuous integration, and collaboration. These phrases describe how a person works, not separate certification types, and the CSD content is relevant across front-end, back-end, and full-stack roles.

If you want to explore the next steps, these resources can help:

• CSD certification training for details of an instructor-led course.
• How to become a certified Scrum Developer  for a walkthrough of the pathway.
• Benefits of CSD certification if you are weighing the pros and cons.
• CSD vs CSM for a comparison of the two most common Scrum Alliance entry points.

Pay is another common question. Salaries vary widely by country, experience, employer, and role, so treat any single number with caution. For a starting point on compensation, see this overview of certified Scrum developer salary, and compare it with current job listings in your own market.

Conclusion

An agile developer does far more than write code. They plan with the team, build small slices of working software, clarify needs with the Product Owner, keep quality visible through a shared Definition of Done, and learn from feedback every cycle. The technical side relies on agile engineering practices such as test-driven development, continuous integration, refactoring, clean code, code review, and pair programming. The human side relies on communication, adaptability, and shared ownership.

A practical next step is to pick a single upcoming task, split it into the smallest valuable slice, write a test first, ask a teammate to review it, and demonstrate the result within two days. Then reflect on what felt different and what you would adjust. If you later decide a formal credential would support your growth, the Certified Scrum Developer path is a well-defined place to begin. Whatever route you choose, treat learning as part of the work, and the rest tends to follow.