We have a project that everyone says we will be doing in a agile way but I doubt we have clearly understood what agile is.

In previous projects we had planning meetings, then defined the product back log and allocated the work to developers in 2 to 3 week sprints. Every morning we had scrum meetings (which seemed to go on for 1/2 an hour each time) and each developer got on with it after that. Hardly anyone wrote any tests until at the end of sprint and work that was not completed was added on to the next sprint.

Developers hardly spoke to each other and there was no TDD involved in development. In fact most developers had a spec at the start and just got on with it for the 2 or 3 weeks the sprint was arranged for. There was hardly any communication with the client/stake holder.

QA got involved usually a few months later and by then we found missing requirements which further increased the amount of work we had to do. Clearly there was no feedback loop.

So my question is, where did we go wrong and how can I prevent the team from making the same mistakes.

  • 4
    Seems like a duplicate of programmers.stackexchange.com/questions/15928/… It does sound like you guys didn't really know what to do and lacked real management to enforce the process
    – sylvanaar
    Aug 21, 2011 at 17:44
  • 1
    Yes I agree with you 100%. My manager read a book on agile and just got on with it (although very badly). I used TDD on the server side of the project but the others did not want to learn it or see the the benefit of it. We had a framework (on the client side) which took forever and the developer kept arguing that he just needed to get on with it (without interference).
    – JD01
    Aug 21, 2011 at 18:19
  • 3
    Although the title seems to be a duplicate, I think this question is helpful on its own because many teams read "generic" explanations of what agile is (and even take training classes and hire consultants) and then run into exactly the same issues as JD01's team anyway. So to put the question into the context of this specific team, might shed light on specific problems and solutions that other more general posts questions wouldn't address.
    – DXM
    Feb 5, 2012 at 23:53

3 Answers 3


What you are describing isn't Agile by definition (Agile Manifesto) it is Waterfall with daily status meetings. Agile means easily adapting to change, if there is no interactive feedback loop with the product owner and thus the customers, then what change is occurring?

Agile is about rapid failures, through constant communication with the product owner/customers. It is better to fail sooner than later, less work is done, and less is "lost". And you don't get stuck with the argument, that "we don't have time to do it correctly, since we spent so much time doing it wrong, we just need to continue on this same path, even though it leads to failure".

Sounds like your managment is doing "SCRUM, but ..." where the "but" is where they throw out all the SCRUM stuff that they don't understand or agree with and just do things the same haphazard waterfall way as always, but with new shiny buzzword names to it all.

In SCRUM the daily stand up is NOT about delivering status to management, it is to force developer interaction, so you know what your fellow team members are doing and can help each other out and not duplicate work. If it takes more than 45 seconds per person you are doing it wrong. It is about transparency for the team, if one person is giving the same status multiple days on something that should be a single days worth of work, the team can resolve the persons problem sooner than later.

If you aren't testing each others code as it is written, then you aren't doing it correctly either. Testing should be embedded into the process not an after thought. QA should be included in the planning sessions and give estimates on how long things will take to test.

If you are not meeting Sprint commitments and rolling things over, you aren't doing it correctly. Sprints are about commitments if you are committing to too much work, stop doing that, there is no way you can introduce any predictibility or repeatability if you can't accurately commit to deliverables.

  • 1
    Thank you Jarrod for your answer. Should TDD be apart of agile? It was hard getting developers thinking in this way. In the end as I mentioned they did some tests at the end (if they remembered) and said it was TDD. I agree with everything you have said. The feedback loop was pretty much non-existent because my manager felt it was interfering with the "framework" which took months and months to right. By then we were stuck implementing functionality that did not meet the customer requirements.
    – JD01
    Aug 21, 2011 at 18:17
  • 3
    TDD is a red herring, I don't agree with it as a religion personally, what good are tests for code that doesn't meet the customers needs. And since testing should be embedded and nothing delivered and demoed that isn't tested, TDD as a mantra is pretty useless. If it doesn't work you don't demo it. If you don't demo it the product owner / customer can't accept it.
    – user7519
    Aug 21, 2011 at 20:04
  • 2
    I started off doing a lot of TDD but have now switched to BDD which is more in align with the customers needs as acceptance tests. Although I feel that TDD helped creating designs I would not have seen otherwise in addition to providing tests.
    – JD01
    Aug 21, 2011 at 20:44
  • 1
    The key reason for TDD is to allow continuous refactoring, reducing the rate of accumulation of technical debt. If there is code you are afraid to change because retesting would be too expensive, the project will meet a premature end. Aug 22, 2011 at 4:06
  • I've heard many people preach TDD, I just have never seen it in practice. Personally my brain doesn't work that way. I tend to have a good general idea of what I'm writing, but as I write I'm rebalancing and moving things around. Writing the tests first just isn't possible for me. I do write unit tests, usually as part of writing the code, but they are written as I write code, not in advance.
    – DaveG
    Feb 19, 2019 at 19:48

Jarrod provided a good answer (+1 to that) and I'd like to extend on that a little.

Agile isn't just about rapid failures and feedback between product owner(customer) and the team; it is about rapid feedback between all stakeholders involved. To be truly agile (and this is directly from the manifesto) is to recognize that process exists only to help developers in delivering better product. People above process means that as soon as the team recognizes your existing process doesn't work, you change it and make it work.

"Scrum but..." is also an issue, but there's both sides to this coin. If you look at the manifesto you'll see that it's about the team and making tools/processes work for you. No two teams are the same and therefore each will operate slightly differently and that's ok. You could certainly, take the entire Scrum methodology and try to follow it to the letter and see if that works for your team.

Another alternative is instead of pushing another process onto the team and making everyone follow what Scrum tells you to do, try the agile approach: Communicate with the team and see if together you can identify problem areas and solutions for each one. Then gradually introduce changes in the way you work so that problems are addressed.

It might take a little while, but...

  1. You will fix biggest issues first which will have the largest impact on your teams ability to deliver product
  2. By identifying immediate problems and participating in coming up with solutions, your team members will understand why certain practices are important and won't simply do them because they are told to do them.

If we draw an analogy between Scrum and a design pattern, working the way I proposed would be similar to coding into a pattern, where you keep code as simple as possible and only converge on a design pattern when needed. As opposed to just picking a design pattern and rolling with it (i.e. blindly selecting Scrum and all its processes as one set), which sometimes makes the code more complex and harder to maintain than it could have been otherwise.

The key to understand is that agile is not about coming up with a new process for doing things; it's about continuous change and constant adjustment to existing processes/practices.

  • 1
    to the downvoter: care to elaborate? Did I ruffle a few feathers because I said don't blindly adopt Scrum or was it something else?
    – DXM
    Feb 6, 2012 at 2:30
  • 2
    yeah silly. I'll +1 for your detailed info. Mar 31, 2012 at 18:50
  • 1
    +1 for "The key to understand is that agile is not about coming up with a new process for doing things; it's about continuous change and constant adjustment to existing processes/practices." Aug 14, 2017 at 11:09

if the team (and its management) truly want to "be agile," they should start by reading and discussing as a team the Agile Manifesto and its principals. Then pick one of the agile methodologies that have been created (Scrum, for example), get some training on it, and start by following that. I'd recommend following it pretty closely for a while before modifying it, but that's just me.

They should also look deeply into Engineering Practices which are used to support the particular agile project methodology chosen.

  • 2
    I downvoted because I don't think this answers the original question. Aug 21, 2011 at 22:16
  • 1
    fair enough, I suppose. I was addressing the OP's initial premise: "We have a project that everyone says we will be doing in a agile way but I doubt we have clearly understood what agile is." Many people say that they are, or that they want to, "do agile" or "be agile" without understanding what the Agile Philosophy or the Methodologies that support it really are.
    – StevenV
    Aug 22, 2011 at 0:03
  • 4
    I disagree with blindly following a particular methodology completely. To be "truly" Agile, means that you don't lock yourself in to any particular trend or methodology unless it fits your company and team. It's better to use a methodology as a starting point, and then once you've had a little training and even better some experience, tune to suit your own particular needs. Even more importantly, if the next project and customer require something a little different, tune the methodology to suite. not THAT is truly Agile.
    – S.Robins
    Feb 6, 2012 at 0:16
  • 1
    re-visiting my answer, I agree with S.Robins above and have modified my answer to reflect that.
    – StevenV
    Feb 19, 2019 at 19:19

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