I think my team may be doing agile a bit wrong but I can't put my finger on exactly how.

After a collaborative design of a feature that'll take a week or so to accomplish, we break into tasks which is standard. But we then bring each task to 100% compliance wrt things like test coverage and docs. Each task item isnt integrated as to not create breaking changes. But often at the end when we hook things up, we realize we missed or messed up an interface and end up having to do rework and having to redo code reviews.

Here's the core question: Is it better to get a task done to 100% compliance at the risk of needing rework if we miss interfaces? or get it fairly compliant to get to the integration of the tasks, then make additional tasks to bring them up to compliance?

Given CI pipeline tasks i feel like the answer is that 100% is the best way, but it just seems like we could optimize somehow.

  • I see one vote to close already for needing focus. I don't like to jump to conclusions based on the number of question marks I see in a post. Still, this question opens with a request for opinions, and it is difficult to see a problem to solve. Can you edit your question to focus on the problem you are having with this workflow? Commented Feb 14 at 19:07
  • 1
    The "general theme" of the stories you describe doesn't really sound like a user story. These items, like "write a class or function..." sound like developer tasks under a story. Commented Feb 14 at 19:09
  • you are correct. i've modified the post to say tasks. this question is fairly broad. it may be better for a platform like reddit. I'll attempt to revise. understood if it needs to be closed. appreciate the consideration
    – m25
    Commented Feb 14 at 19:49
  • 3
    This is my opinion here, so I'm not writing it as an answer. But your style of thinking is extremely non-agile. The ideas that you can figure out what needs to be done, scatter the work, have people work in isolation, gather the work, and then expect to integrate it , is what is your problem. You need to structure the work with assumption that you don't know what needs to be done, how to do it, what parts it is composed off, etc. Which is why trully agile systems like XP favor iteration, collaboration, and feedback. Wiht TDD, pair programming and trunk-based development supporting everything.
    – Euphoric
    Commented Feb 14 at 20:20
  • 1
    "I wanted to get some opinions" immediately renders the question opinion-based. I'm not suggesting a mere rephrase, but rather redirecting it to a forum that encourages discussion rather than a direct Q&A. As such, I have voted to close this question.
    – Flater
    Commented Feb 14 at 22:24

3 Answers 3


If you have multiple people working in parallel on related tasks, then those tasks should be integrated with each other as early and as often as practical.

The aim of this integration is to find problems with interfaces or interactions as early as possible, before a ton of testing code has been written against the wrong interface or with the wrong assumptions about how the other component would function.

Only the integration into the branch that might be deployed to production an hour later should be held off until the task meets the Definition-of-Done (a.k.a. its 100% complete), but integrations into short-lived branches can be done earlier and more often.


The traditional "agile" way would be to design the tasks in such a way that each can be integrated separately without breaking anything; ideally so that each is an incremental improvement in its own right, but at least without breaking anything, if necessary behind a feature toggle.


You've bumped against a well-documented caveat of Agile which is that product planning practices have their limits without the adequate code-level practices.

Continuous Integration was identified as one of these quintessential enabling practices in the early days of Agile, yet is still often not understood or implemented properly. CI isn't only about tooling (a CI pipeline) but also the discipline of integrating the development work early and often - meaning multiple times a day.

Most probably you're already doing some of it - e.g. if the development tasks involve some kind of dependency between code written by different team members, having an agreed upon interface in place very early is much easier. But other development effort like refactoring or cross-cutting features will benefit from frequent integration.

And together with Continuous Deployment (to a test or staging environment), it allows you to get some feedback from the stakeholders early in an iteration and change course if needed.

It's also possible that asynchronous, written code reviews hamper continuous integration - but that's another debate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.