Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Agile and not Agile Teams in a project

Last post 02:28 pm February 18, 2014 by Joshua Partogi
4 replies
11:19 am February 16, 2014

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


11:46 am February 16, 2014

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?


01:38 pm February 16, 2014

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.


12:59 pm February 17, 2014

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.


02:28 pm February 18, 2014

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.


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. For privacy concerns, we cannot allow you to post email addresses. 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.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.