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 ...


18

Really good question. Really hard to answer. Here is my two cents contribution. Agile showed up as a response to the practices of the late nineties for building software, practices that assumed you could define everything upfront in such detail and plan them out such that it was then just a matter of following that plan to reach a successful outcome. But ...


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 ...


14

TL;DR Trying to "future proof" your data is done by making your tools, processes, and data structures flexible, not by fixing them for eternity. You do this by embracing test-first database design, ensuring your data is normalized and extensible, and that your tools and processes support change. You do not accomplish this by treating your data or ...


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

The agile approach does not necessarily imply shortsightedness. Depending on the problem domain, you may have a very complete understanding (in your example, the industry exists for quite some time, has best practices, etc.) or a very limited understanding (such as a novel idea for a social network). Very complete understanding It would be foolish to throw ...


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 ...


8

How should a PM reconcile the wish to deliver something quickly, which may require extensive rework to add functionality in the future, versus doing extensive design up front then being able to develop all of the functionality quickly thereafter, with minimal rework? This is the question at the heart of agile. You could rephrase the question as: Is 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

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

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

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

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

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

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

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 ...


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

Schedule the Minimum Viable Product (MVP) and business goal milestones Identify the minimum viable product (MVP) that you can roll out to the end users (or a subset of end users) that makes business sense. Working with the team you can get a forecast (not a commitment) of when this can be accomplished. Let us say that this will take 6 months. Keep in mind ...


4

I think Kanban may work best in your environment. And with some people being remote, you're almost forced to use an online Kanban board. I'll try to address the two issues you raise one by one. Global View You can maintain a Global View of the multiple projects by: Having all projects on the same board, and indicate with a color what project the task ...


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