Episode #125 of the Stack Overflow podcast is here. We talk Tilde Club and mechanical keyboards. Listen now
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 ...


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


4

There are two parts to your question: Do the clients really need to make changes at very short notice If this is a real need, what do we have to do to respond to changes very quickly I would start by speaking with the clients and explaining the impact of last minute changes, which might include: Efficiency lost due to context switching (i.e. shifting to ...


3

Before Agile was taught in school, people were doing Agile. There just wasn't a single name for it. The start to what we call Agile was in February 2001, when seventeen people met in Utah to talk about the things that they found were working well in software development in a world where there were a lot of projects that were behind schedule, over budget, ...


3

With a fixed deadline you have two elements of the development iron triangle left to play with: scope and resources. A typical agile approach would be to (at least initially) fix the resources and start iterating. The idea would be to deliver as much value as possible against the list of requirements. The customer might not get everything they want, but ...


3

This is something a lot of teams run into, at least the ones I've worked with and hear about from colleagues. And, as you might expect, there's room for a lot of tension between the two parties that use different methodologies for delivery. The fact is, if this is something that is simply necessary (there may be reasons), both teams will have to understand ...


2

One simple (if not easy) approach to a Scrum team relying on the work of waterfall teams is to simply treat it as a constraint. Can the team work around it? Can the team make the constraint less impactful on their work? You can look at things like the Five Focusing Steps approach in Goldratt's Theory of Constraints as a way to work through this challenge. ...


2

Is it possible to use agile on projects where scope is known upfront? Yes. Is it the best approach? Maybe. It all boils down on how much uncertainty you'll face along the implementation and how much value you can deliver incrementally. For instance, when setting up a video conf project, do you know... whether the network will be capable of supporting ...


2

TL;DR The question itself is unanswerable from a Q&A perspective because there's no canonical answer. We don't know what the interviewer wants to hear, and we can't guess at "correct" business decisions that really boil down to contractual issues between the company and their client. That said, the question you posed is likely an X/Y problem. The ...


2

As a Scrum Master your responsibility is to ensure your team is following the Scrum framework. The best way to do this is to explain the consequences of not following Scrum and how it will impact on the organisation. Scrum talks about a potentially releasable Increment at the end of each sprint. The value with this approach is that: You can get regular ...


2

Your team produces a potentially shippable product increment at the end of each sprint. Whether this is then subjected to acceptance tests and actually being released is up to the client. Of course, you split the big feature into product backlog items that can be handled within the Scrum framework so that it will take several sprints until it is completed, ...


2

Without understanding fully, I don't think we can suggest the best approach. With that in mind, here is my approach based on the information given. 1) Remove the concept of 1 week development, 1 week testing. It should be test as soon as developed, fix bugs as soon as it is tested. This will ensure that your deliveries have as little amount of bugs as ...


1

An additional possible approach to consider, which could be taken alongside the admirable suggestions here to split up the feature, is to 'release' sections of the feature but with a 'switch' to allow the feature to be turned off, or only turned on for specific users/in specific circumstances when the first parts of this are released. This may help if you ...


1

Direct answer to the question: Other than "unstructured" there is no commonly accepted name for people "just doing it". Deeper answer to your whole question: There have been a number of different approaches to software projects and there are plenty of companies that do not apply any structure. I think no one really compares structured approaches to "just ...


1

If you can make this work for your teams then that is fine. I would caution that a global definition of done has several drawbacks, including: Getting consensus over several teams is challenging. If not all the teams agree with the final solution then they may ignore it or work around it. Some aspects of the definition of done may be specific to each team. ...


1

I'm struggling to see a better approach than a standard agile backlog and fixed date/variable scope approach however as Todd points out this is difficult without knowing what the interview wants to hear. That's where the discussion comes in. Having said that, if I was asked that question I would discuss the how I would break down the requirements as far as ...


1

Lean Agile Kanban approach is better suited to operations and maintenance than a Scrum approach. A big difference is that Kanban does not have fixed time boxes. Work transitions from a backlog to Work in Progress to Done. The key concept is to limit Work in Progress. This prevents too many concurrent tasks happening at once. Do 2 or three things at a time, ...


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