Unstable Requirement vs. Unstable Team

As you would have noticed, the cyberspace is buzzing with discussions on Agile. It covers various aspects of theory and practice of agile methodologies, but I have seen very little discussion on what happens when the agile development team is not stable. What happens when number of the developers leave the team midway through the project and has to be replaced by developers who have not been a part of the project earlier?

Basic assumption in Agile is that both the requirement and the solutions crystallizes in the mind of the developers over multiple iterations. It is a shared knowledge among the member of the project team and can also be supplemented by documentation. The documentation is not expected to replace the understanding of the developers. In many cases the code is expected to be the documentation, but full understanding may not have been translated to code. There is built in redundancy to the developer knowledge as part of it is shared by the whole team. But it is obvious that 100% sharing is not possible. XP can help, but what happens if both developers leave?

So here is my conclusion!


Related Articles

9 Responses to “Unstable Requirement vs. Unstable Team”
  1. Sonata says:

    Imho its not true that an unstable team with stable requirements will work better with a waterfall model. Yes, in an agile setup knowledge is shared more through communication, then through documentation, but consider what happens if the team changes: in a waterfall project the new developer will have to read a lot of documentation before any work can be done. In an agile project, he can sit down with an experienced team member and immediately start working, learning through pair-programming and communication in the daily standups, planning and review meetings, etc.

  2. Stable Requirement + Stable Team does not automatically ensure successfull delivery. It is almost impossible to understand the actual delivery capability of the team (velocity) if you are not following iterations. In waterfall, everything looks good until the deadline is in sight! If you follow agile to deliver working software at the end of each iteration, you will know the delivery capability of the team and can calculate the velocity. You will also get early feedback from the client.

    Also I am not sure how waterfall will work better in the face of unstable team and stable requirements. Can you elaborate?

    • setandbma says:

      In principle:
      Stable requirement = document-able requirement = any body can use it to write code.

      Agile with unstable team = knowledge keeps disappearing from the team

  3. Oliver says:

    In my opinion one of the important thing is that the team achieves a status where they know each other well and they yell together only in such a case the team will evolve to its maximum performance. This is independent of waterfall or agile. As an example you can look at the open source projects where the people only, at least mostly, know each other from the web but not personally. Nonetheless this projects are sucessful.

  4. Aakash says:

    I think Team stability is really not a issue while using the Agile methodology. Requirements are in chunk and progress is made known to all in stand-up meetings. If a new person join in he/she can get a fair amount of information about work done and to be done. As per my understanding we can have “Either will work” instead of “Waterfall will work better”?

  5. Yogesh says:

    It is an unwritten rule that Agile is applicable to be used in case where the requirements is unknown, or expected to undergo constant churn, however it also stands on the foundation that you have a dedicated core team. Once the core team is in place, you can get additional members who can sweep in and out as long as the core is untouched. Its impractical to believe that a product can be developed with out committed and like minded people being as core team which includes the sponsors themselves. So if you have in the state of ‘Nothing works’ it means one of the following is true and needs to be worked on
    a. Commitment, from sponsor to fund the project if it has a commercial setup
    b. Lacking like minded people who are self motivated to contribute and ensure the product/project is alive
    c. Lacking of core team with required technical skills to ensure progress which happens to be one of the key motivation
    d. The project/product has gone too big for a small core team, then its time to get a larger investor/player to get involved.

  6. Lata says:

    Interesting thought ! But the box 1 which is stable requirements and stable team is almost mythical. There will always be gray areas. There are greater chances that agile will work if teams consciously plan for attrition.

  7. Deepesh says:

    But wouldn’t this go completely against one of the core principals of Agile…i.e Requirements are constantly changing and adopting Agile will help you cope with it ????

Check out what others are saying...
  1. […] Unstable Requirement vs. Unstable Team Share this:LinkedInTwitterFacebookStumbleUponPinterestEmailLike this:LikeBe the first to like this. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: