none
Agile development problem. RRS feed

  • Question

  • Agile develop or not:
    Here is the scenario:
    You are an architect. You are assigned a project at a client.
    Client has approx 10 use cases requirements.
    There is going to be a BAs team and Development team.

    1. BAs will take up each requirement meet with end users and in about a week they will have the spec/use case done.

    2. In the following week Devlopment team is supposed to pick up the use case come up with a design in a week and be done.

    3. In that following week Development team will implement the use case and be done in 2 weeks and should give a demo to the client.

    Here is the problem, while the first use case is done by the BAs team in the first week, in the next week the BAs team picks up the second requirement and the above steps repeat.
    So by the end of the second week BAs are done and hand it over to the Dev team for design.

    Now Dev team notices a bunch of gaps in the second use case and will need to re-design use case1 also as a result of this.

    So all the Design needs to redone, all the code needs to be reimplemented, lot more time is needed.

    Client is unhappy and they want to fire Dev team.

    Has anyone encountered such a problem.
    If so, how to fix this problem.
    Is Agile not good in such scenarios.
    Any suggestions will be appreciated.
    Thursday, September 20, 2007 5:42 PM

All replies

  • I am not MUCH aware about agile but I like the scrum approach especially Daily Scrum meeting.  What I did in past, we created All requirement and specification (at least on module) and then applied Agile on it.... at least one BA representative should attend Daily Scrum meeting so any modification in any case should be implemented during development. Development of specification and requirements for other modules are out of the scope. So, you can say we used agile only for developers!

     

    It’s all from my side! Any comments and suggestions are welcome

    Friday, September 21, 2007 4:17 AM
  • what you are trying to do is not really Agile. It's more like RUP.

     

    One of the core practices of any Agile methodology (XP, SCRUM etc) is to involve all the team members in Requirements meeting - Customer, BA, DEv, QA. They all share common goal of successful implementation of  the feature/functionality identified during that Iteration or Scrum Sprint. So in your example Use Case 1 should have been considered as one cycle.

     

    What many people miss is that Agile is all about embracing Change. So if your client/customer(along with team) is not sold on the idea of true Agile you won't get desired results and project will fail.

    Friday, September 21, 2007 5:42 PM
  • As has already been said one of the principles of Agile is responding\embracing changes in requirements and therefore the acceptance that any of key phases are never complete. If you also accept the principle of iteration of software development then you can easily manage customer expectation and criticism.

     

    check out the Agile Manifesto and other Agile websites.

     

    HTH

     

    Ollie Riches

    Monday, September 24, 2007 10:27 AM
  • I just did a blog on Agile a few days ago and then saw your post. 

     

    The title of the blog is "Agile Development != Low Ceremony && The Movement Needs to Die".

     

    The Summary is:

    A search on Google for Agile Development returns about 4,940,000 hits. Everything is Agile now. Businesses, project management styles, databases, legacy system interface development, architecture, enterprise architecture, enterprises, testing, executives, and the list goes on and on and on and on. Yet the same teams that stank at making software before they were agile, still stink at making software. They just stink at it sooner in the process.

    Low ceremony does not have anything to do with being agile. Agile is an enabled state that is only accomplished through experience. It can be learned, but absolutely not by doing less.

     

    If this is along the lines of what your were looking for, you can read more here:

    http://realworldsa.dotnetdevelopersjournal.com/agiledevelopmentlowceremonyitneedstodie.htm

     

    Friday, September 28, 2007 3:39 PM
  •  TadAnderson wrote:

    I just did a blog on Agile a few days ago and then saw your post. 

     

    The title of the blog is "Agile Development != Low Ceremony && The Movement Needs to Die".

     

    The Summary is:

    A search on Google for Agile Development returns about 4,940,000 hits. Everything is Agile now. Businesses, project management styles, databases, legacy system interface development, architecture, enterprise architecture, enterprises, testing, executives, and the list goes on and on and on and on. Yet the same teams that stank at making software before they were agile, still stink at making software. They just stink at it sooner in the process.

    Low ceremony does not have anything to do with being agile. Agile is an enabled state that is only accomplished through experience. It can be learned, but absolutely not by doing less.

     

    If this is along the lines of what your were looking for, you can read more here:

    http://realworldsa.dotnetdevelopersjournal.com/agiledevelopmentlowceremonyitneedstodie.htm

     

     

    I disagree with the idea of low ceremony = doing less, you just do more of what is really relevant to your project, instead of wasting valuable hours on paperwork.

    Saturday, September 29, 2007 2:01 AM
  • It looks like you have organizational issues here, at the very least because the BA team can be "successful" even while the development team isn't. This leads to both sides covering the respectives arses and to the overall detriment of the project. The project, as a whole, cannot be agile in this setup.

     

    To effectively employ agile techniques on this project, you'd need to abolish these team borders and have a single unified team. Depending on your organizations politics, that might cost you your job eventually, so be careful.

     

    If you are able to make this kind of change, the chance that the project as a whole will succeed will significantly increase, as will the expected lifespan of the dev team. I know it's not easy, but it's what's necessary.

     

    Hope that helps.

    Monday, October 1, 2007 8:02 AM