Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
2  
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 '11 at 17:44
    
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 '11 at 18:19
1  
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 '12 at 23:53
add comment

3 Answers

up vote 15 down vote accepted

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.

share|improve this answer
    
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 '11 at 18:17
1  
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. –  Jarrod Roberson Aug 21 '11 at 20:04
1  
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 '11 at 20:44
2  
+1 for 45 seconds per stand-up. –  Daniel Roseman Aug 21 '11 at 22:56
    
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. –  kevin cline Aug 22 '11 at 4:06
add comment

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.

share|improve this answer
    
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 '12 at 2:30
    
yeah silly. I'll +1 for your detailed info. –  Michael Durrant Mar 31 '12 at 18:50
add comment

if the team (and its management) truly want to "be agile," they need to pick one of the agile methodologies (Scrum, for example), get some training on it, and follow it completely. They should also look deeply into Engineering Practices which are used to support the particular agile project methodology chosen.

share|improve this answer
    
I downvoted because I don't think this answers the original question. –  Bryan Oakley Aug 21 '11 at 22:16
    
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 '11 at 0:03
2  
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 '12 at 0:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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