Forums

By posting to our forums you are agreeing to the Forum terms of use.
Agile and not Agile Teams in a project
Last Post 18 Feb 2014 01:28 PM by Joshua Partogi. 4 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Informative
snehm
New Member
New Member
Posts:2
snehm

--
16 Feb 2014 10: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
    Advanced Member
    Advanced Member
    Posts:570
    Ian Mitchell

    --
    16 Feb 2014 10: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
    New Member
    New Member
    Posts:2
    Sameh

    --
    16 Feb 2014 12:38 PM
    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.
    agatos
    New Member
    New Member
    Posts:1
    agatos

    --
    17 Feb 2014 11: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
    New Member
    New Member
    Posts:98
    Joshua Partogi

    --
    18 Feb 2014 01:28 PM
    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