New answers tagged

0

Given the details you have provided: Fixed scope Fixed deadline Demotivated team Project is a mess I think agile makes sense, but not scrum. You probably want to do something more lightweight like Crystal Clear. This is briefly described as: The lead designer and two to seven other developers … in a large room or adjacent rooms, ... using such as ...


2

Yes, an agile approach could help you get the work done1. At its core, scrum provides a way for a group of motivated individuals working together to deliver a product. Scrum provides a framework for breaking a larger body of work into smaller pieces (epics, stories, tasks) and then working on those smaller pieces. Scrum also provides a framework for the ...


2

Time, budget and scope Every project, whatever life cycle approach it uses, has to cope with the triple constraint of cost, time and scope. In your case time and scope are fixed. You say nothing about cost, but as you've inherited this project from your partner, I fear that there might be a fixed (or at least capped) cost as well. The unexepcetd risks ...


21

If you have fixed scope, and a fixed deadline, then the only thing you have left to play with is cost. You can throw more people at the problem (which doesn't really work), you can buy premade software, or you can sacrifice quality. ...Or you can change peoples' minds about the fixed scope or fixed deadline thing. That's not an agile problem, that's a ...


8

Welcome to real business. There is an older style of business, which I tend to derisively call "traditional development" and then there's a new style, "agile development." If I try to treat these as opposing ideals, we see a straightforward division down the middle: plans and requirements go on the traditional column, discovery and evolution go in the ...


4

EVERY business relevant project has constraints: Time Resources An expected minimum feature set This is nothing else. Developing agile doesn't mean "people pay us money, so we can develop whatever we want for whenever it may be ready" - you will always have some time-frame. There will always be some date with some minimum requirements and if they are not ...


16

If there's an expectation that specific sets of features are to be delivered on specific dates, then no, this is not agile project management. Agile project management is empirical in nature. Projections are not made based on the wishes of executives but rather on analysis of prior performance. Your description matches up with what I consider to be cargo-...


35

No. This is the exact sort of things that non-software companies tend to do. There are plans, and deadlines, and budgets. And it will inevitably fail, since humans suck at predicting the future. Let's go through the various points here: We keep being told we are going to be working in an agile way on a new project by senior management. If you were ...


3

As someone has already pointed out before the manifesto says: Individuals and interactions over process I would suggest you have a look at the plan put forward and suggest changes to it. Remember the Manifesto says that the backlog is never final, it keeps evolving. So you could take your suggestions to the team. If you have a valid reasoning and ...


4

Agile does not prevent you from planning milestones (E.g we will release V 1.0 in 3 months), but what goes into each milestones cannot be fixed. I think how you should react depends on the nature of the project. If the project is to send a man to the moon by Q2 2017 everyone would agree that it is doomed to fail. If you think you can deliver an MVP by the ...


57

There's a difference between meeting the deadline and fulfilling all requirements. Its like the old adage "fast, good or cheap, pick two". So here you have fixed dates for delivery - that's good, it means you are time-boxed in that what you deliver at the end of your last sprint will be the final product. You remember that you always have to release ...


-2

Its not aglie planning no. But if you prentend you dont know the plan and just work sprint by sprint. It could be aglie working. There are always going to be dates and budgets. There is always a risk they will be missed or overrun and when that happens you are always going to have to fall back to a plan B. If you have been working in an agile way then ...


2

Imagine asking someone to paint a wall, a house and then a whole street for you, how much time would you give that person to do it ? Whatever your answer is, you'll be wrong. That's it. There's no way they could be right about dates if they didn't ask the people who need to do the work what they think. By the way, if you (as a team) accept these dates, ...


5

One advantage that I've found about junior developers is that (if you've recruited for aptitude) they tend to make up for lack of experience with eagerness. First things first, break up work vertically! That is, don't work in layers. When you talk about features in the application, that feature should encompass UI, middle tier, and storage (database, nosql, ...



Top 50 recent answers are included