Posts

Test Automation in Agile

Although both agile development and automated testing have more or less independently come into more widespread use with each passing year, it seems they were made for each other from the start. The advantages of both are derived from the same desire to increase software production efficiency overall.

Both work best when there is a high degree of collaboration between development and testing although they offer significant benefits to all project stakeholders. You often see a high usage of each approach wherever organizations are growing their continuous integration and continuous delivery capabilities.

Test Automation in Agile versus Traditional Waterfall

There certainly is no reason that teams employing waterfall methods cannot take advantage of test automation too. Typically, however, automation tends to be of lower priority in those scenarios due to the ingrained “throw it over the wall” mentality. Such a back-end loaded scenario is unfortunate because automation, especially test-driven coding, can be used quite effectively during development phases.

In agile, however, the questionable “luxury” of developers shedding testing responsibility is simply anathema to a process of two week scrums in which planning, designing, coding, testing and deployment all happen nearly at once. Without thorough development and testing automation, the productivity and quality of agile cycles would consistently fail to meet project goals.

When Automating Tests, Choose Wisely

Despite the brevity of agile development cycles, there can exist a tendency to over-automate testing. This is where careful planning and in-cycle flexibility are both necessary. Tests will naturally be categorized as to their type, whether that be functional, white box, black box, performance and so on. Within categories, however, individual test tasks need to be sorted by how likely they are to be reused repeatedly in order to optimize automation.

Any test that will be repeated more than twice, especially if it appears it will carry over to the next scrum, is a prime candidate for automation. That pretty much eliminates automation of exploratory testing and perhaps some boundary testing if the boundaries are still in flux and are not easily parameterized. On the other hand, even one-off tests might be amenable to automation in the sense that they are ongoing placeholders within an automation framework test suite for future software revisions.

Avoid Automating for Automation’s Sake

With more sophisticated test automation tools and frameworks, it is uncannily easy to become lost in the forest without seeing the trees. This is especially true of homegrown test frameworks, where the framework development effort might rival that of the applications it is meant to test. It pays at all times to bear in mind that meaningful, reusable tests must be the top priority.

An additional potential trap is not paying enough attention to the ebb and flow of value within your test suites. They naturally become cluttered with marginally valuable test scripts that may have lost relevance and eat up undue cycles of execution time. That is why it is important to set clear criteria for what does and does not get automated plus regular reviews of the test code base.

Staying One Step Ahead

Due to the rapid pace of agile development, anything to gain a leg up will pay dividends. Crisp, detailed planning is one key to getting ahead of the game, but in addition you should implement testing and its automation as early in the development cycle as possible.

The use of pair programming with one developer and one tester simultaneously working on the same code is an innovative practice in this regard. It is especially effective when combined with test-driven development in which the tester first writes the unit tests based on the specification and the developer follows with application code that turns each test “green.”

Actually, the underlying concept of first creating acceptance criteria as test code and then programming the software to make that test succeed can be applied at most points throughout the development cycle. These “live” requirements should be captured in an automated test environment that can be accessed and run by all stakeholders in the project to further increase collaboration.

Conclusion

Test automation is a key tool in agile development project success. As development organizations naturally evolve their entire production team from agile development to continuous integration and continuous deployment, the use of build and test automation becomes ever more critical.

Test automation in an agile development environment, however, has to be finely tuned to a greater degree than when employed in waterfall environments. Precise planning, a shift-left of testing responsibilities, keen maintenance policies and a sharp weather eye for when and when not to use automation are the most important elements for extracting the highest value from test automation.

Traditional vs Agile Software Development

The modern software development life cycle methodology can be subdivided into two types – the Traditional process and the agile process. In this post, we will look at what each of these processes are and then do a comparative analysis between them.

A software system is built in such a way that it can perform complex tasks and computations on the behest of the user. The process of building a software requires a rigorous attention to detail and a general guiding algorithm. The traditional and agile processes essentially are manifestos for software development ideologies, more than anything else. They can be further subdivided into more specific processes that form the basic plan of each unique software development life cycle. The agile methodology post-dates the traditional one in the evolution of the software development processes.

Traditional Software Development

Traditional methodologies are characterized by a sequential series of steps like requirement definition, planning, building, testing and deployment. First, the client requirements are carefully documented to the fullest extent. Then, the general architecture of the software is visualized and the actual coding commences. Then comes the various types of testing and the final deployment. The basic idea here is the detailed visualization of the finished project before the building starts, and working one’s way through to the visualized finished structure.

Agile Software Development

As its name suggests, the agile method of developing software is a lot less rigorous than the former. The crux here is incremental and iterative development, where phases of the process are revisited time and again. Agile developers recognize that software is not a large block of a structure, but an incredibly organic entity with complex moving parts interacting with each other. Thus, they give more importance to adaptability and constant compatibility testing.

Traditional Vs. Agile Methodologies

Customer Involvement

While traditional methodologies require the user to provide a detailed idea of the exact requirements with respect to the intended software, agile developers are more flexible through their iterative style of work. With agile development, the user is constantly in the loop, suggesting improvements and reviewing every phase. This increased customer involvement works on two levels – one is that it makes reflective changes easy, as opposed to traditional development where chunks of system might have to be dismantled to improve a small part, and the second being that it increases the customer satisfaction drastically.

Cost

This is a key issue. Especially the reworking costs, which tend to shoot after a bout of testing, are very low in agile computing than the traditional methods. Since testing is not compartmentalized in agile development, a potential problem can be identified and swiftly dealt with. This affects the corrective maintenance costs for the software.

Development Flexibility

Again, agile wins hands down in this category. The idea is that in traditional systems, the role of a coder and a business analyst is bifurcated. The architecture stems from the initial customer requirements collected and analyzed by the business analysts which is then developed by the coders. With agile, since the customer interaction is so extensive at every stage of development, and since the developers are the ones who are handling the interaction, the amount of architectural, functional and fiscal flexibility endowed to the project is pretty high.

Documentation

One of the few areas where the agile methodology falls short as compared to the traditional one is the documentation process. Traditional development prides itself in stringent documentation and reviewal of every step in the way to deployment. The documentation process also becomes easier due to the unidirectionality of the algorithm. With agile, the primary interface of documentation and reviewal is the code itself, with annotations and comments added by developers. This can become a bit of an issue in terms of communicability.

System Size

Small to medium sized systems are perfect for agile development since they offer more compatibility to the elastic method of attack that agile brings to the table. Large software systems offer more inertia to iterative change in some respects, especially with the system design parts. In this case, one can either go for the traditional way of software development that deals with bulkier, unilateral systems with better ease and forgo the other advantages offered by agile; or one can compartmentalize the large system into smaller agile developed processes and play a compatibility gamble.

Choosing the development ideology compatible to your software is a difficult and complex decision.

Get in touch with OptimusInfo for more information on Agile and Traditional development processes. Make an informed decision with the help of our experts!

Continuous Integration, Delivery and Deployment Explained

The concepts of continuous integration, delivery and deployment arose from the shift to “small-chunk” software methodologies versus “large-chunk” processes. Waterfall development measures progress by weeks or months, whereas agile development gauges tasks in hours, days or a week at the most. Conceptually, both approaches employ a development pipeline of discrete steps from specification to coding to testing and deployment. However, the brisk, incremental pace of agile methodologies is what imparts that impression of seamless continuity.

Although the agile pipeline, observed from on high, seems to blur differences between continuous integration, delivery and deployment, they each have distinct roles. However, they share an underlying philosophy that favors incremental, stable momentum over big-bang, throw-it-over-the-wall practices. One of the fundamental characteristics of continuous software development is that task duration is short. One effect of that is a significant improvement in organizational responsiveness.

Continuous Integration

Developers tend to prefer working on code via a branch off version control’s mainline in order to reduce distractions caused by other developers’ contributions. Typically, this approach creates greater difficulty merging code back to the mainline than it saves. Continuous integration requires developers to work from a single shared code source without branching. Tasks must be well-scoped and completed in no more than a day. Integration efficiency increases, since it avoids combinatorial integration thrash due to multiple, broad changes with unforeseen side effects.

Continuous integration is greatly facilitated if an easy-to-use, automated unit test framework is included in the development environment. With such a framework, changes are thoroughly validated by the development team prior to builds and regression testing. Such a component usually resides on a dedicated server. If defects are found, they are more quickly remedied while the coding details are still fresh in the minds of developers.

Continuous Delivery

After the build/integration process, but prior to customer deployment, lies the process of continuous delivery. It includes a staging environment that emulates the final production context as nearly as possible. Achieving production conditions requires such things as identical hardware, software configurations and production data to drive tests. Within this environment, business logic tests and user acceptance tests are performed.

In a typical waterfall process, a nearly complete version of the software under development would be delivered to the staging environment every month or so. In an agile methodology, however, incremental versions are constantly delivered via the development pipeline. As in continuous integration, the impetus behind this is enabling faster turnaround time on defects whether they appear in programming or business logic. Furthermore, it facilitates early customer feedback, which in turn reduces development efforts to accommodate customer requirement modifications.

Continuous Deployment

It is improbable that your software’s customers require actual, live deployment of the software on a daily or even weekly basis. However, a fundamental principle of continuous deployment is that you could deliver software that frequently if the need arose. That characteristic is a natural disciplinary consequence of the continuous development and continuous delivery stages that precede it.

Continuous deployment lies on the same pipeline, works from the same shared code base and embodies precisely the same rapid, continuous change paradigm. It enables incremental feature introduction, measurement and early revenue generation without the burdensome overhead that would result from attempting integration, testing and releasing new features in a “whole-hog” fashion. New ideas enter the development pipeline and emerge into deployments in one or a few weeks instead of months later. Improvements can be added weekly based on real-world feedback.

The Role of Automation in Continuous Development

The success of agile methodology depends on instilling stability into the process from end to end at the start. If done correctly, the evidence is reduced development thrash, instant progress feedback and the ability to create a product that better meets customer requirements.

Automation is key to obtaining such stability, which in turn enhances the automation process itself. It is not unusual for early automation efforts to be fragmented over development, integration, delivery and deployment stages, but the ideal is a one-touch, end-to-end process that validates the stability of the project as a whole.

Overall, the operational goal of a “continuous” approach to software development is the reduction of overhead activities that slow down the implementation of new features and diminish the organization’s responsiveness to defects, changing functional requirements and market shifts. Metaphorically, it is akin to climbing a mountain slope step by step rather than spending months building a rocket-propelled sled to attain the summit in one go. At any point in a continuous process, you are able to measure your progress, adjust your route and keep both feet on the ground.

Agile and Scrum Testing Methodologies

Test teams new to Agile methodologies may find themselves in unfamiliar territory due to their fundamentally distinctive features when compared to serial processes of software development:

  • Collaboration between developers and testers is closer and more direct. Communication via documents is considered inefficient.
  • Agilists regard rapid change as inevitable and welcome. Fluid customer requirements in the quest to deliver high quality software are considered advantageous.
  • Agile development cycles or sprints are typically 10 times shorter than Waterfall cycles. Sprints last two to four weeks. This time compression is possible with test-driven development, tighter collaboration and less reliance on documentation.
  • Each sprint “post mortem” includes discussion of enhancements for the next sprint. In this way, the process itself embraces continuous improvements.

Agile Team Requirements

These features of Agile development imply substantial changes in how development and testing teams accomplish their work compared to serial methodologies:

  • All stakeholders, including business managers, architects, designers, coders, testers and QA participate in developing prioritized requirements. All must employ discipline and accountability to produce functional code by the end of each sprint.
  • Agile testers work in parallel with developers even before code is functional. Testers, are at the forefront of dynamically evolving requirements that are often represented by the tests themselves.
  • Agile works best when expertise is distributed within the teams. Reliance on specialists tends to serialize work. Thus, a tester who is expert in, say, performance testing, must be ready to pinch-hit by applying additional expertise in order to be fully effective.

Agile Development Lifecycle

Fast-paced, iterative sprints are actually sub-cycles in the overall Agile process, which consists of three higher-level phases: Inception, Construction and Transition. Depending on the phase currently in progress, testing approaches may vary. Naturally, the phases and the details of sprint execution are adaptable to an organization’s particular culture, goals, customers and resources.

Inception

Inception includes activities similar to the start of any project regardless of the overarching methodology. Resources are marshaled, responsibilities assigned, funding is secured, tools are acquired and first requirements are defined and validated by all stakeholders.

Construction

This is the phase in which core Agile methodology practices are front and center. The goal of each development iteration – the sprint – is to produce deliverable software from the requirements designated for that sprint. Work arrives from a prioritized stack of tightly scoped requirements. Testers and developers collaborate side by side throughout the sprint. Testing efforts are focus on functionality and coverage during this phase.

Transition

The move from raw software development to production code marks the beginning of the transition phase. However, nothing is “thrown over the wall” in the sense that business, programming and testing personnel must continue close collaboration as the software moves through this complex phase that includes deployment testing, compatibility testing, usability tests, performance testing, localization and the development of user documentation and training. Once this phase ends, the software should be ready for production and release.

Scrum

Scrum is one flavor of Agile methodologies. Other variants include Extreme Programming, Feature-Driven Development and Adaptive Software Development. All flavors value adaptive, iterative, collaborative, and transparent development techniques.

Scrum identifies three essential roles: product owner, development team and Scrum master. The product owner is the actual end customer or an internal representative. The development team consists of those responsible for sprint deliverables. The Scrum master oversees and facilitates the entire process.

Work is pulled from a prioritized backlog of requirements on a daily basis. The Scrum master holds a Daily Scrum, during which each team member reports on the previous day’s accomplishments, the current day’s goals and any roadblocks to completing those goals. Problem-solving during the Daily Scrum is deferred to outside meetings.

Each sprint begins with a half-day Planning event followed by Daily Scrums and Review and Retrospective meetings to close the sprint. The two-hour Review focuses on presenting completed work to stakeholders, whereas the two-hour Retrospective reflects on how the next sprint can be revised based on the experiences of the last sprint.

A Test-Driven Development approach in Agile puts the test team center stage with other stakeholders. Testing trails requirements, design and coding phases in a Waterfall process. That is why testing often falls under the hatchet when a project is nearing its delivery date. Agile development ensures that the test team is continuously ahead of the curve if the methodology is correctly applied.

Agile methodologies’ greatest strength resides in its ability to handle dynamic customer requirements. While it cannot guaranteed eventual success, it is more likely than a serialized methodology to deliver quality software close to the mark with time to rebound. In today’s fast-paced software markets, it is the only approach that can keep up.

Common Challenges for Agile Testing Teams

The fact that Agile methodology has achieved mainstream status is clearly supported by anecdotal evidence and surveys, such as one by VersionOne in which 84 percent of respondents replied in the affirmative that their organization was indeed employing Agile development methods. As Agile development eclipses Waterfall methodologies for software development, it has stirred up some distinct challenges in its wake for testing organizations.

Key Aspects of Agile Development

Three key characteristics of Agile development as distinct from the Waterfall process have significant effects on testing efforts:

  • Agile compresses development time into sprints, which can run from one to several weeks each versus several months for Waterfall development.
  • Whereas Waterfall processes work in a linear fashion through requirements, design, coding, unit testing, integration testing and so on, Agile teams more or less do everything at once. Its continuous integration philosophy implies constant change throughout the development chain.
  • Thorough revision of original requirements to the point of throwing them out and starting over fresh is a not uncommon side effect of Agile processes. Since in Waterfall methodologies the requirements, architecture, coding, testing follow distinct sequential stages, each stage’s result is considered to be whole subject to relatively minor revision.

The scope of work an Agile team embraces is smaller within any single sprint, but the pace and churn is overall higher at any moment.

How Agile Challenges Testers

Requirements Churn’s Effect on Test Coverage

Since requirements and code flux steadily during a sprint, ensuring full test coverage is not always straightforward. Even with an assist from automation, testers must be nimble to avoid missing new code tests on a daily basis and to ensure that what is tested is tested thoroughly.

Test plan documentation with links from test cases to user stories helps ensure high-level coverage. Code coverage tools and source code instrumentation are both essential in demonstrating how much functional logic is tested. Additionally, there must be a system by which developers tag new source code so that it is not overlooked by the test team.

Test team members must be full participants from minute one of any sprint to provide input into the requirements from a testing point of view. The priority of requirements must account for the testability of each one within the scope of the current sprint.

Support of Daily Build Tests

Daily or semi-daily builds of the code base during a sprint is quite common. Test teams must therefore dedicate resources to preparation of solid functional and integration test suites that accurately detect breakage during and after builds. This aspect of testing benefits significantly from automation.

Additionally, the test team – via tools, scripts or pair programming – must facilitate developer unit testing before code check-ins, which substantially mitigates the time-consuming process of tracking down broken features due to cross-module dependencies or broken interfaces.

Waterfall Creep

Despite Agile’s specific rejection of linear, block processes for code development, it is natural for development and test teams to perform work in a sequential manner. This tendency results in sprints resembling mini-Waterfalls when development and test personnel are not working in parallel from a sprint’s first minute. Degradation of Agile into a linear process puts the greatest squeeze on the test team. Therefore, it is vital that testers stay tightly synchronized throughout the continuous integration process.

Squeezing out Essential Tests

Sprints by their nature demand focused prioritization from both developers and testers. When time is short, a tendency to defer certain types of testing to later sprints can result in larger problems that are harder to fix close to the time of final delivery. Pushing off performance, API, compatibility and stress testing will create a pressure cooker situation for the test team.

In this regard, Agile should borrow from Waterfall methodology the concept of an overall, all-encompassing project test plan that provides traceability of all test types. It need not be developed in toto before the first sprint, but the framework should exist from the beginning of the project. It must receive reviews and updates during each subsequent sprint to ensure test types other than functional testing are being adequately executed.

Agile methodology is proven to deliver high-quality software faster for most projects than Watefall methodologies. Agile does, however, require significant adjustments from testing teams to ensure that adequate test coverage, efficient build tests and non-functional testing are being performed effectively throughout each Agile sprint cycle. Deft use of documentation, tools, automation and innovative tracking processes can ensure quality testing is performed within a fast-paced Agile context just as it would in a Waterfall methodology.

Introduction to Agile Project Management

Agile software development was created to address inefficiencies inherent in sequential development methods, such as waterfall methodologies. Creating software with an opaque assembly line process where specification, coding and testing are separate and done in strict order struggles to keep up with fast-moving markets requirements within which modern software products must compete. In order to retain market relevance and extract the highest productivity from development and business resources, companies are ditching plan-driven software methodologies for the responsive, continuous delivery model that the Agile Method offers.

The Agile Method

The Agile Method takes into account the unpredictability of non-trivial software projects that are the bane of plan-driven methodologies. Agile software development is centered on brief, concurrent development/test cycles and close collaboration between all stakeholders.

The Agile Method acknowledges the impossibility that all project requirements are known before coding begins. Participants in a waterfall development process know this also but compensate for missing requirements by padding the schedule to account for their disruptive effect at later development stages.

Unlike plan-driven methodologies, the Agile Method is adaptive and based on iterative requirements discovery. It compresses the typical steps of the waterfall method into sprints. To build a sprint, which typically has a lifespan of a day or two, specific functional component requirements are targeted. These are coded, tested and approved or disapproved by the agile team’s product owner. Feedback is gathered after each sprint, which is used to fine-tune the next sprint.

Principles of Agile Project Management

The original Agile Methodology outlines 12 principles that are essential to meeting the objectives of continuous delivery, intimate stakeholder involvement and self-motivated contributors:

  1. Satisfy customers by continuous delivery of working software
  2. Changes in requirements are expected, planned for and embraced
  3. Useful software is delivered regularly with the shortest possible frequency
  4. Cross-functional collaboration between developers, testers, and business development owners is essential
  5. Project contributors are empowered to make decisions within an environment of trust
  6. Face-to-face communication is the preferred method for information transfer among teams
  7. Useful, working software is the fundamental measure of project progress
  8. Development must occur at a consistent, sustainable rate
  9. Technical excellence and sound design principles must be adhered to at all times
  10. Simplicity is essential in order to maximize the amount of work that is not done
  11. Teams should be self-organizing and self-managed
  12. At each iteration, teams incorporate feedback to adapt to changing circumstances

Benefits of Agile

The Agile Method is widely recognized as the best solution to the problems inherent in building software products of high quality and market relevance. Agile Methodology has a number of valuable benefits:

  • Delivery of working software is frequent and predictable.
  • The rapid, iterative nature of agile development teams means shorter time-to-market and time-to-revenue.
  • Major and minor product revisions are seamless within a continuous delivery environment.
  • Defects are found quickly and when they have the least impact to the overall schedule.
  • Stakeholders are actively engaged and progress is transparent, which leads to the highest business value.
  • The right product is delivered in the end without surprises.
  • Market relevance is achieved by a process that embraces change.
  • Motivated, decision-empowered teams are not waiting to catch what other teams throw over the wall.
  • Contributors expand skills that provide increasing value to the organization

Differences between Agile and Waterfall

  • The waterfall process works well only with fully specifiable projects. Agile has built-in requirements discovery/coding/testing iterations that deliver usable software early and often.
  • Traditional software development is control-centric, whereas agile methodology distributes responsibility.
  • Waterfall development prizes skills specialization, whereas agile contributors fulfill multiple roles.
  • Waterfall development utilizes functional silos, whereas cross-functional collaboration is the key feature in agile development.
  • Contributors are guided by planned tasks in waterfall methodology. In agile methodologies, product features guide activity at any moment in time.
  • Waterfall development engages customers at the beginning and end of the process, whereas customers are active participants throughout agile software development.

The Agile Method has become the de facto standard for competitive, nimble software development products driven by fluid market requirements. Compared to plan-driven methodologies, such as the waterfall process, the seeming informality of agile methodologies may present a challenge to the status quo, but their clear benefits outweigh these concerns in the long run.

Agile QA in Vancouver

agile_vancouver Agile QA in Vancouver

Agile Vancouver is hosting an event this month focused on Agile QA and we’re very proud to co-sponsor. The event is very exciting as Agile Vancouver consistently brings in top-notch speakers from local industry that share their trials and tribulations.

The two day event will consist of workshops, presentations, panels and open discussions on the successful (and sometimes not so successful) practical experiences of development and QA using agile methodologies.

Here are some of the discussion topics:

  • Test Automation Strategies
  • Evolving careers in Testing and QA
  • ROI on testing in an Agile environment
  • Property-based testing
  • Quality in Outsourcing
  • Performance Testing
  • Quality in the Cloud
  • DevOps approach to Quality
  • QA and Distributed Teams
  • New to Agile: Challenges and Opportunities
  • Exploratory Testing
  • Quality Measures & Metrics

For full details, visit AgileVancouver.ca

We hope to see you there!

If you are looking to work with an agile QA team, visit the site for our dedicated QA division, OptimusQA.

Can a lean startup mentality work for all stages of business?

lean_startup_vancouver-150x150 Can a lean startup mentality work for all stages of business?

Lean Startup Vancouver

This was the question at the latest Lean Startup Vancouver event and some top-notch speakers from industry leading companies shared their opinions. Spoiler alert: Yes, we can all benefit from the lean startup mentality.

Jesse Heaslip started the night off with an introduction to the lean movement and gave an overview of Eric Ries’ Lean Startup phenomenon. He explained how he took an idea and with little programming experience created a proof-of-concept that could be demo’d to potential users. This simple example illustrates the lean startup mentality: fail fast. Get your idea to end users as fast as possible to see if it has traction.

Allen Pike from Steam Clock Software later took the stage to explain how his JavaScript user group (VanJS) quickly gained popularity. As a full-time entrepreneur, he had to be efficient with his time and applied lean concepts to get the most results from the least input.

One of the heavyweights of the night came from SAP. Lawell King, Senior Director of Engineering at SAP in Vancouver, explained how SAP is shifting to the agile methodology. He told the audience of 160 people how even a huge incumbent like SAP can transform into a more iterative, fast paced work environment. He explained how it’s much more rewarding and exciting to be involved in a rapidly improving organization.

The second key speaker was Stuart Ashman, currently the QA Director at Joyent but previously handling QA at Sophos. In his 6-years at Sophos he helped the company shift to an agile software testing methodology. He explained how automated testing and flipping the testing triangle (so more testing is done by automation and less bugs are left for users to discover) they were able to reduce the frequency of deployments from once-per-quarter to several times per day.

Lastly, Melissa Ness, Senior Interaction Designer and Usability Specialist at Vision Critical, described how even UX can be lean by getting mock-ups in the hands of end-users early on and feedback sessions can be done remotely. This focus on failing fast and getting feedback from key stakeholders early results in much less wasted time on misguided efforts.

Watch the video below to see some pre-presentation interviews with the speakers.

Lean Startup Vancouver: Speakers – March 8th, 2012 from Jin Lee on Vimeo.

Thanks to Jin and Jesse for putting on a great event.

At Optimus we’ve learned and adopted the lean methodology in all that we do. From software development, to testing, to business intelligence we believe that getting an early mock-up or proof of concept into our clients hands is invaluable. Our projects are always broken down into 1-2 week sprints with deliverables and customer feedback.