New answers tagged

0

Make sure you define clearly to the team what a 'bug' (/error/issue/defect) is and what it is not. For example, a bug may: BE A deviation in behaviour/appearance from a previously completed feature/story once deployed to production. NOT BE Something a product owner, stakeholder or user doesn't like or a suggestion for a change in behaviour. This is ...


1

This generalising, abstract thing is distracting you. Agile will teach you very quickly to become pragmatic. There is more to be learnt by taking on problems in small parts that are highly specific. Once you grok each part, the repetition of this process will help you learn the process and build domain knowledge at the same time, thus progressing you to ...


2

Since there is no such thing as a "true agilist", I'll make up my own definition. A "true agilist" knows that a larger story is composed of smaller stories. Agile practices teach us to relate these stories to users, and to break down these stories into smaller and smaller piece until we end up with individual pieces that can be completed within the bounds ...


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


23

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


5

There's a couple of potential solutions: Is it really the case that the team should be generating ideas? Engineering teams are generally responsible for implementing ideas that come from product management, not coming up with the product itself and then creating it. Perhaps you need a PM to design the product so that the team can stay focused on creating ...


7

What I think you lack here is a product owner. Somebody who knows about the product you guys are working on and who can make sure that the user stories that end up in your backlog meet DoR (Definition of Ready). This, of course, does not mean that the team should take what is in the backlog at face value. They do need to challenge it and ask for ...


1

Starve them. Seems whacky but what's killing them is you keep spoon feeding them. Scrum works best when you don't push. The more you manage them the worse this will get. If you have a team of smart driven people all you have to do is lay out a goal and make it clear that they are expected to find work. Just make it obvious that you're watching who's ...


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


58

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


1

If by error you mean defect, a mistake in the code that needs to be corrected by a programmer, then what you need is a trouble ticket system. This can be an elaborate piece of software or it can be a whiteboard. Ether way you document the problem, prioritize it, and track it's resolution.


2

Functional requirements require people to be able to think abstractly about the problem. Specifications written this way tend to be very dense and have many implications. Often people writing these get confused between requirements and implementation. User stories don't require as much abstraction. They also force the person writing them to think about ...


4

I don't think that there's a 1-1 mapping between functional requirements and user stories or acceptance criteria. First, your example of a functional requirement isn't a good requirement. It's not atomic - I would write your functional requirement as multiple requirements: The system shall require an email address to create an account. The system ...


1

Here's how we roll: The PBI: is the requirement aka "the what" is what you talk about with a customer. It's what shows up on the Daily Project Update (DPU) for the sprint..... again because the DPU is customer facing. It's what the customer will talk about and refer in terms of estimates and budget. Might comprise one or more tasks. Is business oriented ...


2

If you have resources that depend on each other, with resources being [people | work items | code], then they would all be in the same Team Project. You can easily have separate Teams (Backlogs, Work, & People), Git Repositories (code) all within a single Team Project. If you are using TFVC then use folders. Check out https://nkdagility.com/creating-...


0

IMO I would duplicate the code, make the necessary changes and then refactor whetever duplication remains. Sometimes, you have to make a mess before you can start cleaning up. But I would agree with Kilian Foth's comment. There is something much deeper here. The problem is that if this case happens, then DoSomething was not a good method int the first place....


2

If someone is going to change a method which is reused somewhere in your codebase, he should be responsible for making an impact analysis before. So a dev who starts to implement a change in DoSomething should check beforehand from where this method is called. So lets assume you already found out DoThisSomethingAndMore won't work any more correctly when ...


0

Well, one way or another this comes down to how accurate your estimation of the work involved actually is. And how you manage the risk. I would suggest you have separate processes for minor modifications and major modifications. Minor mods, however you decide to define that, could be fixed price changes, (independent of hours worked). Major mods would have ...


-1

Until a few months ago, I worked for a company that either had a technical writer on each team (i.e., sat with the team all the time) or one that participated in team planning, daily meetings, reviews, and retrospectives even if they did not sit with the teams. I worked there 4-1/2 years and they had been doing this for 3 years before I started there which ...



Top 50 recent answers are included