Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Agile and not Agile Teams in a project
Last Post 18 Feb 2014 09:28 AM by Joshua Partogi. 4 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Informative
Sascha Nehm
New Member
New Member
Posts:2
Sascha Nehm

--
16 Feb 2014 06:19 AM
    Hello,

    can anyone recommend a procedure if I have a project that requires content do a agliles, but I need to implement non agile development team also (goods management system development, etc.) These teams operate on a waterfall model with long development phase of the position request to deployment.

    Thanks in advance
    Sascha
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1535
    Ian Mitchell

    --
    16 Feb 2014 06:46 AM
    The first thing to do is to challenge why one project "requires" an agile approach, while you "need" to support waterfall development also.

    The delivery needs shouldn't come from either the project or from you, but rather from the business. How quickly does it need to innovate? What are the risks and opportunities of market disruption?
    Sameh Zeid
    New Member
    New Member
    Posts:2
    Sameh Zeid

    --
    16 Feb 2014 08:38 AM
    Sascha,

    You wrote " I have a project that requires content do a agliles". Come with whoever gave this statement to common definition of Agile, which might not be what we advocate about Agile. I recommend that you document the process to be used in the project which is transparent to your management, team and users. Let not characterize this process as Scrum or Waterfall, let say this what your company is ready for. Build the process documentation on addressing risks which could allow you to convince your management with some Scrum concepts , for example frequent feedback from the business. Understand your project constraints and objectives, your company overall process and the needs of other groups while drafting that process. At least you can have process visibility and transparency on what the team is doing.
    Joerg Kirschbaum
    New Member
    New Member
    Posts:1
    Joerg Kirschbaum

    --
    17 Feb 2014 07:59 AM
    Hi Sascha,
    It is quite common in real-life that you such mixed situations. A lot of people are doing nowadays a hybrid approach for software project management because there are sometimes good reasons not to go fully agile - same as not going fully waterfall. In a lot of bigger companies the organizational culture is simply to rigid to move quickly into agile and they may never do - especially if software is not the core business.
    Assuming you have challenged the decision to do waterfall + agile already here are some recommendations on a hybrid-process:
    1. Define early and frequent synchronisation points between the team; break the waterfallish part into multiple phases if possible
    2. Your risk rises due to the dependencies that are more complex to manage. Stay on top, e.g. with metrics and regular formal risk assessments plus listening, talking and walking around
    3. Plan for 3-4 explicit "synchronisation-sprints" to bring it all together and not only one at the end
    4. Share the project plan with all teams, so they can see what's going on at the other side of the fence (..you'll probably want to have a milestone plan and also an WBS for the waterfall-part)
    5. Let the waterfall team take part in some scrum meetings, at least the sprint reviews/demos, so they get to learn and see how agile teams work and may find some inspiration :-)
    6. Make use of the underlying principles of agile wherever it is sensible: Interactions over processes, customer collaboration over contract negotiation etc.





    Joshua Partogi
    Basic Member
    Basic Member
    Posts:109
    Joshua Partogi

    --
    18 Feb 2014 09:28 AM
    I always find it hard to mix Scrum teams and non-Scrum teams because Waterfall teams tend to be 'static' and Scrum teams tend to be more dynamic as changes may emerge throughout the project. For example: If there are changes for the Scrum teams and if that changes affect the Waterfall teams then either the Waterfall teams become a Scrum teams or if the Waterfall teams do not become a Scrum team, the product developed by the Waterfall teams may become unusable.
    You are not authorized to post a reply.


    Feedback