Change the Scrum Guide™
What is Scrum?
Definition of Done
Scrum and Agile Webcasts
Professional Scrum Foundations™
PSF Subject Areas
Professional Scrum Master™
PSM Subject Areas
Professional Scrum Product Owner™
PSPO Subject Areas
Professional Scrum Developer™
PSD Subject Areas
Scrum Open Assessment
Developer Open Assessment
Professional Scrum Master™ Assessments
PSM I Assessment
PSM II Assessment
Professional Scrum Product Owner™ Assessments
PSPO I Assessment
PSPO II Assessment
Professional Scrum Developer™ Assessments
PSD I Assessment
Work With Us
By posting to our forums you are agreeing to the
Agile and not Agile Teams in a project
Last Post 18 Feb 2014 01:28 PM by Joshua Partogi. 4 Replies.
Most Recent First
You are not authorized to post a reply.
16 Feb 2014 10:19 AM
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
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?
16 Feb 2014 12:38 PM
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.
17 Feb 2014 11:59 AM
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.
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.