49

Pretend the Waterfall team is an outside contractor Since you're interfacing with the Waterfall team's code solely via an API, just pretend you're hiring an outside contractor to create that code for you. The Scrum rules for how you write your code don't apply to them. You submit your requirements to them, they write up a formal Statement of Work for ...


19

First of all, make it known to your stakeholders that there is a project risk in your project. The waterfall team is asking for things (final, unchanging requirements) that you don't have at the start of your project. To mitigate this risk, you can analyse your current backlog for items that may affect the data that you need to exchange with the system ...


17

Following on Tiago's answer, the issue is not the methodology but how the methodology is being tailored on your projects. Based on my experience working on biodefence projects for US govt, as the complexity of a project increases so to does your need for upfront planning and thorough project oversight. Regardless of your use of waterfall or agile or ...


16

Well first thing is to remember that a retrospective, like a user story, is an invitation to a conversation. I wasn't there, so I can only take a guess as the meeting. It sounds like the retrospective may have ended up more focused on solution and not what the actual problem is. The scrum master (CSM is a certification, not a role) should start with some ...


13

Hard problem; I've seen that as well in the past. Analyze deeply what it is they're trying to improve in the whole. Then ask them hard questions, trying to get to the deeper problems before jumping to solutions. why you'd need Project Management meetings how the Scrum Meetings are not supporting that How creating a Gantt chart differs from creating a plan ...


10

Asking if there's a methodology that works fine for a large project sounds like asking if a map route can take someone from South America to Alaska. Is there any (methodology or map)? Yes. Will it do it (work or travel) by itself? Definitely, no. A methodology is a guideline. But, as the map, it's only suggestions of how to reach something or somewhere, ...


9

Classic X/Y Problem In the comments, the OP elaborated on his project environment. He said: [T]he major problem with our project is not that it is either big in KLOC/FP or "complex"...The problem is that the project is more like a "bowl of paperclips" more than a bunch of independent features - you can't touch any feature or issue without impacting most ...


8

"Self-organizing" does not mean uncontrolled You said: Given the team are self-organising and they are deciding to organise away from Scrum... I believe your development team is grossly exceeding their bounds on the pretext of "Self-organizing". To cite a small example, the stakeholders now have to wait for, say, nine months to see the first demo of ...


8

I have been in a similar situation (in a retail bank), with consultants offering what they call 'enterprise Agile'. The result was waterfall and highly problematic. The consultancies are typically very good at lobbying support (especially with the executive). So it can be a challenge to call them out. I would recommend to your Agile coach that they do the ...


7

This is basically what Sprint Reviews in Scrum are about. At the beginning of each sprint, the team commits to deliver a working, deployable product increment including a certain number of backlog items. And in the end of each sprint, the team demonstrates to stakeholders the new features they have completed. In Scrum (and Agile approaches in general), the ...


7

The definition of a project in agile terms is no different to that of a project in traditional terms. The difference is how the project is run and executed and the values behind the project. Common Both agile projects and traditional projects: have a start and end may be constrained by schedule, scope or budget should be for a single product; (lets not ...


7

Waterfall is not a methodology, it's a model. So, there are no strict restrictions and prescriptions like in well defined methodologies. Restrictions are more related with contract (not development model). If you have Fixed Price (or even Firm Fixed Price) contract (it is common practice in "waterfall" projects), it will be very hard to provide additional ...


7

My in-Sprint testplans always try to cover the area's defined in Brian Maricks described Agile testing quadrants. We look at each area at the beginning of the story and defined what effort we are going to put into it, but also if it is relavant for this story. Afterwards we create sub-tasks if needed. Agile: Focus is on test automation: https://less.works/...


7

Both Developers and Executives Broke the Agile Contract It was due for a release tomorrow but, as a result of a review by management, needs reworking. This will undoubtedly add a lot of time onto the estimate for release. You have a basic process failure if the first time your management team reviewed the product was shortly before release. In particular,...


6

I think the crux of your question may actually lie in questions you posed in a comment, rather than in the question itself: Do you find it acceptable that release dates are not met? The answer is... it depends. It really depends on the situation; on the project itself. If it is a purely internal project that is a 'nice to have' or some such thing? Yes, ...


6

There is nothing agile about the consultant's approach and certainly not use of the Scrum framework. That is waterfall with some modern software development terms being misused. Allowing an internal team to learn through controlled experimentation is a good mentality; permitting a consultant to waste money for any length of time is ludicrous.


6

"Water-Scrum-Fall" is counter-productive Looks like "Water-Scrum-Fall" is a name coined by analyst firm Forrester Research to describe the reality of Agile found in many organizations. I would say they are referring to large and medium enterprises, because that is where they do most of their work. They could have called it "Hybrid", but I guess they wanted ...


5

Waterfall is used successfully on the largest projects in the world e.g. 500 people over 6 years at a cost of $21 billion. These are mostly infrastructure projects (bridges, tunnels and railways), aerospace and defense projects (airplanes and weapons systems) and energy projects (pipelines, drilling rigs) It is not the methodology that fails, but the ...


5

TL;DR "Agile" isn't a methodology; it's a set of principles espoused by the Agile Manifesto. SDLC is an ambiguous term that can refer to a specific, waterfall-like methodology or a generic lifecycle. Either way, frameworks like Scrum or Kanban are more usefully classified as project management methodologies rather than lifecycles. Frameworks Aren't ...


5

You mention Definition of Done, and in Agile, the acceptance criteria and other user story content defines if work meets the user's needs, but often allows for shoddy workmanship. We all know we can cut corners to make things work in real-world environments. It's important to understand this has little, if anything, to do with the quality of the developer ...


5

Using an Agile approach while contrained by traditional contracts and customer attitudes can be very challenging. However, there are many aspects of Agile that should still be of value: Transparency Even when working with fixed scope and deadlines it is worth using the approach of incremental delivery. This helps to reduce risk and will build up trust ...


5

The sprint timebox offers you iterations, which are a convenient pace-setting mechanism. For your question, we want to look at the idea of adding incremental development into the process. In incremental development, you complete fully-functioning and potentially shippable increments of the product regularly. You combine these together and you should have a ...


5

This is an unenviable position. I'm not sure there are any good/easy answers. Who is accountable in this scenario? Who approves the changes? Changes (last minute or not) have a financial impact on the company. What is the change control process? It isn't clear whether the 3 PM's who communicate with the clients have the authority to unilaterally ...


4

I take a different view to the other answers on here. The problem here is, clear cut, project management. The fundamental constraints appear to be: Long lead times for work definition Long lead times for work clarification Long lead times for budget approval Long lead times for work acceptance Long turn around time for defect reporting. Now scrum will ...


4

TL;DR You don't have a dependency on multiple stakeholders; you have a process failure at the interface between you and Agency #1. Shopping for alternative methodologies won't fix the process problem, but addressing it directly might. Re-Define Your Stakeholders From your description, you don't have any direct contact with the end user. While they may be ...


4

Measuring Velocity According to one source: Velocity is measured in the same units as feature estimates, whether this is story points, days, ideal days, or hours that the Scrum team delivers - all of which are considered acceptable. However, most sources don't really explain that velocity is based on the idea that you can extrapolate your ...


4

For us, "it depends". We try to take into account of whether this is, for want of a better description, "scope creep" and how much extra time it adds to the task. We're using Scrum in 2 week iterations and if a request comes through that we think we can finish in this sprint without jeopardising our commitment we accept it. Sometimes we'll say "that makes ...


4

When a task meets the acceptance criteria, that means it's done. No other options. In real life, if a developed task meets the acceptance criteria but needs some more attention or some updates that means task is not defined well. You may need to discuss this in retrospective meetings. Possible challenges are as follows: Product ownership is ambiguous....


4

I wonder if the issue is not so much closing off a task as poor estimation of how much work remains. It is pretty common in my experience to have progress stall at 90-95% complete.... mainly because of poor estimation both of what work needs done and poor estimation of resource availability. A better practice for tracking progress is to define something as ...


4

System Development Life Cycle (SDLC) isn't methodology. It is...life cycle :-) Each system (product) goes through several phases during it life. This always happens and is not dependent on methodology. These phases could be mixed in different ways (Waterfall vs Iterative and Incremental approach). But all of them are present. Some methodology may or may ...


Only top voted, non community-wiki answers of a minimum length are eligible